Re: [PATCH 4/4] drm/hyperv: Remove support for Hyper-V 2008 and 2008R2/Win7

[Deepak Rawat]

On Mon, May 2, 2022 at 9:37 AM Michael Kelley  wrote:
>
> The DRM Hyper-V driver has special case code for running on the first
> released versions of Hyper-V: 2008 and 2008 R2/Windows 7.  These versions
> are now out of support (except for extended security updates) and lack
> support for performance features that are needed for effective production
> usage of Linux guests.
>
> The negotiation of the VMbus protocol versions required by these old
> Hyper-V versions has been removed from the VMbus driver.  So now remove
> the handling of these VMbus protocol versions from the DRM Hyper-V
> driver.
>
> Signed-off-by: Michael Kelley 
> ---
>  drivers/gpu/drm/hyperv/hyperv_drm_proto.c | 23 +++
>  1 file changed, 7 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_proto.c 
> b/drivers/gpu/drm/hyperv/hyperv_drm_proto.c
> index c0155c6..76a182a 100644
> --- a/drivers/gpu/drm/hyperv/hyperv_drm_proto.c
> +++ b/drivers/gpu/drm/hyperv/hyperv_drm_proto.c
> @@ -18,16 +18,16 @@
>  #define SYNTHVID_VERSION(major, minor) ((minor) << 16 | (major))
>  #define SYNTHVID_VER_GET_MAJOR(ver) (ver & 0x)
>  #define SYNTHVID_VER_GET_MINOR(ver) ((ver & 0x) >> 16)
> +
> +/* Support for VERSION_WIN7 is removed. #define is retained for reference. */
>  #define SYNTHVID_VERSION_WIN7 SYNTHVID_VERSION(3, 0)
>  #define SYNTHVID_VERSION_WIN8 SYNTHVID_VERSION(3, 2)
>  #define SYNTHVID_VERSION_WIN10 SYNTHVID_VERSION(3, 5)
>
> -#define SYNTHVID_DEPTH_WIN7 16
>  #define SYNTHVID_DEPTH_WIN8 32
> -#define SYNTHVID_FB_SIZE_WIN7 (4 * 1024 * 1024)
> +#define SYNTHVID_WIDTH_WIN8 1600
> +#define SYNTHVID_HEIGHT_WIN8 1200
>  #define SYNTHVID_FB_SIZE_WIN8 (8 * 1024 * 1024)
> -#define SYNTHVID_WIDTH_MAX_WIN7 1600
> -#define SYNTHVID_HEIGHT_MAX_WIN7 1200
>
>  enum pipe_msg_type {
> PIPE_MSG_INVALID,
> @@ -496,12 +496,6 @@ int hyperv_connect_vsp(struct hv_device *hdev)
> case VERSION_WIN8:
> case VERSION_WIN8_1:
> ret = hyperv_negotiate_version(hdev, SYNTHVID_VERSION_WIN8);
> -   if (!ret)
> -   break;
> -   fallthrough;
> -   case VERSION_WS2008:
> -   case VERSION_WIN7:
> -   ret = hyperv_negotiate_version(hdev, SYNTHVID_VERSION_WIN7);
> break;
> default:
> ret = hyperv_negotiate_version(hdev, SYNTHVID_VERSION_WIN10);
> @@ -513,18 +507,15 @@ int hyperv_connect_vsp(struct hv_device *hdev)
> goto error;
> }
>
> -   if (hv->synthvid_version == SYNTHVID_VERSION_WIN7)
> -   hv->screen_depth = SYNTHVID_DEPTH_WIN7;
> -   else
> -   hv->screen_depth = SYNTHVID_DEPTH_WIN8;
> +   hv->screen_depth = SYNTHVID_DEPTH_WIN8;
>
> if (hyperv_version_ge(hv->synthvid_version, SYNTHVID_VERSION_WIN10)) {
> ret = hyperv_get_supported_resolution(hdev);
> if (ret)
> drm_err(dev, "Failed to get supported resolution from 
> host, use default\n");
> } else {
> -   hv->screen_width_max = SYNTHVID_WIDTH_MAX_WIN7;
> -   hv->screen_height_max = SYNTHVID_HEIGHT_MAX_WIN7;
> +   hv->screen_width_max = SYNTHVID_WIDTH_WIN8;
> +   hv->screen_height_max = SYNTHVID_HEIGHT_WIN8;
> }
>
> hv->mmio_megabytes = hdev->channel->offermsg.offer.mmio_megabytes;

Do we need a new version for Windows 11? If the synthetic device
version is decoupled from Windows version, then I guess we can rename
the macro to reflect that.

Reviewed-by: Deepak Rawat 

> --
> 1.8.3.1
>

Re: [PATCH v4 1/2] dt-bindings: display: bridge: ldb: Implement simple Freescale i.MX8MP LDB bridge

[Marek Vasut]

On 5/3/22 02:31, Rob Herring wrote:

Hi,

[...]


  .../bindings/display/bridge/fsl,ldb.yaml  | 92 +++
  1 file changed, 92 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml


A little quick on the applying...


Right


diff --git a/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml 
b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml
new file mode 100644
index ..77f174eee424
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml
@@ -0,0 +1,92 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/fsl,ldb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8MP DPI to LVDS bridge chip
+
+maintainers:
+  - Marek Vasut 
+
+description: |
+  The i.MX8MP mediamix contains two registers which are responsible
+  for configuring the on-SoC DPI-to-LVDS serializer. This describes
+  those registers as bridge within the DT.


This is a subblock of the mediamix? Please add 'reg' for the 2 registers
even if you use a regmap.


I submitted a patch:
[PATCH] dt-bindings: display: bridge: ldb: Fill in reg property


I didn't find a binding for mediamix. You really need the containing
block binding before a child node.


Right, I'm tempted to send a revert outright and wait for the mediamix 
bindings to hit upstream.

[PATCH] dt-bindings: display: bridge: ldb: Fill in reg property

[Marek Vasut]

Add missing reg and reg-names properties for both 'LDB_CTRL'
and 'LVDS_CTRL' registers.

Fixes: 463db5c2ed4ae ("drm: bridge: ldb: Implement simple Freescale i.MX8MP LDB 
bridge")
Signed-off-by: Marek Vasut 
Cc: Laurent Pinchart 
Cc: Lucas Stach 
Cc: Maxime Ripard 
Cc: Peng Fan 
Cc: Rob Herring 
Cc: Robby Cai 
Cc: Robert Foss 
Cc: Sam Ravnborg 
Cc: Thomas Zimmermann 
Cc: devicet...@vger.kernel.org
To: dri-devel@lists.freedesktop.org
---
 .../bindings/display/bridge/fsl,ldb.yaml | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml 
b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml
index 77f174eee424f..2ebaa43eb62e9 100644
--- a/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml
@@ -24,6 +24,15 @@ properties:
   clock-names:
 const: ldb
 
+  reg:
+minItems: 2
+maxItems: 2
+
+  reg-names:
+items:
+  - const: ldb
+  - const: lvds
+
   ports:
 $ref: /schemas/graph.yaml#/properties/ports
 
@@ -56,10 +65,15 @@ examples:
 #include 
 
 blk-ctrl {
-bridge {
+#address-cells = <1>;
+#size-cells = <1>;
+
+bridge@5c {
 compatible = "fsl,imx8mp-ldb";
 clocks = < IMX8MP_CLK_MEDIA_LDB>;
 clock-names = "ldb";
+reg = <0x5c 0x4>, <0x128 0x4>;
+reg-names = "ldb", "lvds";
 
 ports {
 #address-cells = <1>;
-- 
2.35.1

Re: [PATCH] drm/i915/guc: Support programming the EU priority in the GuC descriptor

[Ceraolo Spurio, Daniele]

On 5/3/2022 5:44 PM, Daniele Ceraolo Spurio wrote:

From: Matthew Brost 

The EU priority register must be updated by the GuC rather than the
driver as it is context specific and only the GuC knows which context
is currently executing.

Cc: John Harrison 
Cc: Matt Roper 
Signed-off-by: Matthew Brost 
Signed-off-by: Aravind Iddamsetty 
---
  drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 75291e9846c50..8f3ed60ff07d9 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -2420,6 +2420,8 @@ static void prepare_context_registration_info(struct 
intel_context *ce,
 */
info->hwlrca_lo = lower_32_bits(ce->lrc.lrca);
info->hwlrca_hi = upper_32_bits(ce->lrc.lrca);
+   if (engine->flags & I915_ENGINE_HAS_EU_PRIORITY)
+   info->hwlrca_lo |= lrc_desc_priority(ce->guc_state.prio);


Just realized that I forgot to squash in a change when I moved branch 
(guc_state.prio is the GuC-side value while lrc_desc_priority expects 
the i915 one). Ignore this, will fix up and re-send later.


Daniele


info->flags = CONTEXT_REGISTRATION_FLAG_KMD;
  
  	/*

Re: [PATCH v2] drm/tegra: Stop using iommu_present()

[Dmitry Osipenko]

On 4/11/22 16:46, Robin Murphy wrote:
> @@ -1092,6 +1092,19 @@ static bool host1x_drm_wants_iommu(struct 
> host1x_device *dev)
>   struct host1x *host1x = dev_get_drvdata(dev->dev.parent);
>   struct iommu_domain *domain;
>  
> + /* For starters, this is moot if no IOMMU is available */
> + if (!device_iommu_mapped(>dev))
> + return false;

Unfortunately this returns false on T30 with enabled IOMMU because we
don't use IOMMU for Host1x on T30 [1] to optimize performance. We can't
change it until we will update drivers to support Host1x-dedicated buffers.

[1]
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/host1x/dev.c#L258

-- 
Best regards,
Dmitry

[PATCH] drm/i915/guc: Support programming the EU priority in the GuC descriptor

[Daniele Ceraolo Spurio]

From: Matthew Brost 

The EU priority register must be updated by the GuC rather than the
driver as it is context specific and only the GuC knows which context
is currently executing.

Cc: John Harrison 
Cc: Matt Roper 
Signed-off-by: Matthew Brost 
Signed-off-by: Aravind Iddamsetty 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 75291e9846c50..8f3ed60ff07d9 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -2420,6 +2420,8 @@ static void prepare_context_registration_info(struct 
intel_context *ce,
 */
info->hwlrca_lo = lower_32_bits(ce->lrc.lrca);
info->hwlrca_hi = upper_32_bits(ce->lrc.lrca);
+   if (engine->flags & I915_ENGINE_HAS_EU_PRIORITY)
+   info->hwlrca_lo |= lrc_desc_priority(ce->guc_state.prio);
info->flags = CONTEXT_REGISTRATION_FLAG_KMD;
 
/*
-- 
2.25.1

Re: [PATCH 08/25] drm/msm/dpu: get rid of cached flush_mask

[Abhinav Kumar]

On 2/9/2022 9:25 AM, Dmitry Baryshkov wrote:

Instead of querying the CTL for the flush mask (for SSPP, LM or DSPP),
storing the mask in the mixer configuration and then pushing the mask to
the CTL, tell CTL to cache the flush in place.



This follows the pattern of other update_pending_flush_*** ops which we 
have so this is fine.


This change can go in independent of this series. no need to wait.

Apart from a minor comments nit below,

Reviewed-by: Abhinav Kumar 

Signed-off-by: Dmitry Baryshkov 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c   | 25 ++-
  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h   |  1 -
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 78 +-
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 35 +++---
  4 files changed, 66 insertions(+), 73 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index d21791db6ab1..e6c33022d560 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -396,7 +396,7 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc 
*crtc,
_dpu_crtc_setup_blend_cfg(mixer + lm_idx,
pstate, format);
  
-			mixer[lm_idx].flush_mask |= ctl->ops.get_bitmask_sspp(ctl, sspp_idx);

+   
mixer[lm_idx].lm_ctl->ops.update_pending_flush_sspp(mixer[lm_idx].lm_ctl, 
sspp_idx);
  
  			if (bg_alpha_enable && !format->alpha_enable)

mixer[lm_idx].mixer_op_mode = 0;
@@ -430,7 +430,6 @@ static void _dpu_crtc_blend_setup(struct drm_crtc *crtc)
  
  	for (i = 0; i < cstate->num_mixers; i++) {

mixer[i].mixer_op_mode = 0;
-   mixer[i].flush_mask = 0;
if (mixer[i].lm_ctl->ops.clear_all_blendstages)
mixer[i].lm_ctl->ops.clear_all_blendstages(
mixer[i].lm_ctl);
@@ -447,17 +446,14 @@ static void _dpu_crtc_blend_setup(struct drm_crtc *crtc)
  
  		lm->ops.setup_alpha_out(lm, mixer[i].mixer_op_mode);
  
-		mixer[i].flush_mask |= ctl->ops.get_bitmask_mixer(ctl,

-   mixer[i].hw_lm->idx);
-
/* stage config flush mask */
-   ctl->ops.update_pending_flush(ctl, mixer[i].flush_mask);
+   ctl->ops.update_pending_flush_mixer(ctl,
+   mixer[i].hw_lm->idx);
  
-		DRM_DEBUG_ATOMIC("lm %d, op_mode 0x%X, ctl %d, flush mask 0x%x\n",

+   DRM_DEBUG_ATOMIC("lm %d, op_mode 0x%X, ctl %d\n",
mixer[i].hw_lm->idx - LM_0,
mixer[i].mixer_op_mode,
-   ctl->idx - CTL_0,
-   mixer[i].flush_mask);
+   ctl->idx - CTL_0);
  
  		ctl->ops.setup_blendstage(ctl, mixer[i].hw_lm->idx,

_cfg);
@@ -701,16 +697,9 @@ static void _dpu_crtc_setup_cp_blocks(struct drm_crtc 
*crtc)
dspp->ops.setup_pcc(dspp, );
}
  
-		mixer[i].flush_mask |= ctl->ops.get_bitmask_dspp(ctl,

-   mixer[i].hw_dspp->idx);
-
/* stage config flush mask */
-   ctl->ops.update_pending_flush(ctl, mixer[i].flush_mask);
-
-   DRM_DEBUG_ATOMIC("lm %d, ctl %d, flush mask 0x%x\n",
-   mixer[i].hw_lm->idx - DSPP_0,
-   ctl->idx - CTL_0,
-   mixer[i].flush_mask);
+   ctl->ops.update_pending_flush_dspp(ctl,
+   mixer[i].hw_dspp->idx);
}
  }
  
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h

index b8785c394fcc..9f87fc32b1bb 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
@@ -95,7 +95,6 @@ struct dpu_crtc_mixer {
struct dpu_hw_ctl *lm_ctl;
struct dpu_hw_dspp *hw_dspp;
u32 mixer_op_mode;
-   u32 flush_mask;
  };
  
  /**

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index 02da9ecf71f1..8dc59659bd18 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -139,92 +139,84 @@ static inline void dpu_hw_ctl_trigger_flush(struct 
dpu_hw_ctl *ctx)
DPU_REG_WRITE(>hw, CTL_FLUSH, ctx->pending_flush_mask);
  }
  
-static uint32_t dpu_hw_ctl_get_bitmask_sspp(struct dpu_hw_ctl *ctx,

+static void dpu_hw_ctl_update_pending_flush_sspp(struct dpu_hw_ctl *ctx,
enum dpu_sspp sspp)
  {
-   uint32_t flushbits = 0;
-
switch (sspp) {
case SSPP_VIG0:
-   flushbits =  BIT(0);
+   ctx->pending_flush_mask |=  BIT(0);
break;
case SSPP_VIG1:
-   flushbits = BIT(1);
+   ctx->pending_flush_mask |= BIT(1);
break;
case SSPP_VIG2:
-   flushbits = 

Re: [PATCH v3 0/4] drm/dp: Introduce wait_hpd_asserted() for the DP AUX bus

[Doug Anderson]

Hi,

On Mon, Apr 18, 2022 at 10:18 AM Douglas Anderson  wrote:
>
> This is the 2nd four patches from my RFC series ("drm/dp: Improvements
> for DP AUX channel") [1]. I've broken the series in two so we can make
> progress on the two halves separately.
>
> v2 of this series changes to add wait_hpd_asserted() instead of
> is_hpd_asserted(). This allows us to move the extra delay needed for
> ps8640 into the ps8640 driver itself.
>
> The idea for this series came up during the review process of
> Sankeerth's series trying to add eDP for Qualcomm SoCs [2].
>
> This _doesn't_ attempt to fix the Analogix driver. If this works out,
> ideally someone can post a patch up to do that.
>
> [1] https://lore.kernel.org/r/20220409023628.2104952-1-diand...@chromium.org/
> [2] 
> https://lore.kernel.org/r/1648656179-10347-2-git-send-email-quic_sbill...@quicinc.com/
>
> Changes in v3:
> - Don't check "hpd_asserted" boolean when unset.
> - Handle errors from gpiod_get_value_cansleep() properly.
>
> Changes in v2:
> - Change is_hpd_asserted() to wait_hpd_asserted()
>
> Douglas Anderson (4):
>   drm/dp: Add wait_hpd_asserted() callback to struct drm_dp_aux
>   drm/panel-edp: Take advantage of wait_hpd_asserted() in struct
> drm_dp_aux
>   drm/panel: atna33xc20: Take advantage of wait_hpd_asserted() in struct
> drm_dp_aux
>   drm/bridge: parade-ps8640: Provide wait_hpd_asserted() in struct
> drm_dp_aux
>
>  drivers/gpu/drm/bridge/parade-ps8640.c| 34 +--
>  drivers/gpu/drm/panel/panel-edp.c | 33 ++-
>  .../gpu/drm/panel/panel-samsung-atna33xc20.c  | 41 +--
>  include/drm/dp/drm_dp_helper.h| 26 
>  4 files changed, 98 insertions(+), 36 deletions(-)

It's been about 2 weeks and I haven't seen any review. Dmitry: since
this came up due to your feedback, any chance you'd be willing to
review at least the drm-framework pieces? Philip is no longer on the
Chrome OS team, so I suspect he won't be reviewing the ps8640 patches.
Stephen: maybe you'd be willing to?

Thanks!

-Doug

Re: [RFC PATCH 1/6] drm/dp: Helpers to make it easier for drivers to use DP AUX bus properly

[Doug Anderson]

Hi,

On Mon, Apr 18, 2022 at 4:10 PM Doug Anderson  wrote:
>
> > > 5. In general I've been asserting that it should be up to the panel to
> > > power things on and drive all AUX transactions. ...but clearly my
> > > model isn't reality. We certainly do AUX transactions from the DP
> > > driver because the DP driver needs to know things about the connected
> > > device, like the number of lanes it has, the version of eDP it
> > > supports, and the available bit rates to name a few. Those things all
> > > work today by relying on the fact that pre-enable powers the panel on.
> > > It's pretty easy to say that reading the EDID (and I guess AUX
> > > backlight) is the odd one out. So right now I guess my model is:
> > >
> > > 5a) If the panel code wants to access the AUX bus it can do so by
> > > powering itself on and then just doing an AUX transaction and assuming
> > > that the provider of the AUX bus can power itself on as needed.
> > >
> > > 5b) If the DP code wants to access the AUX bus it should make sure
> > > that the next bridge's pre_enable() has been called. It can then
> > > assume that the device is powered on until the next bridge's
> > > post_disable() has been called.
> > >
> > > So I guess tl;dr: I'm not really a huge fan of the DP driver powering
> > > the panel on by doing a pm_runtime_get() on it. I'd prefer to keep
> > > with the interface that we have to pre_enable() the panel to turn it
> > > on.
> >
> > Again, thank for the explanation. Your concerns make more sense now.
> > As much as I hate writing docs, maybe we should put at least basic notes
> > (regarding panel requirements) somewhere to the DP/DP AUX documentation?
>
> Sure. I actually don't mind writing docs, but my problem is trying to
> figure out where the heck to put them where someone would actually
> notice them. I could throw a blurb in the kernel doc for `struct
> drm_dp_aux` I guess? How about a deal: if you can tell me where to put
> the above facts (essentially 5a and 5b) then I'm happy to post a patch
> adding them.
>
> Huh, actually, maybe the right place is in the "transfer" function of
> that structure which, as of commit bacbab58f09d ("drm: Mention the
> power state requirement on side-channel operations"), actually has a
> blurb. ...but I don't think the blurb there is totally complete. What
> if I changed it to this:
>
>  * Also note that this callback can be called no matter the
>  * state @dev is in and also no matter what state the panel is
>  * in. It's expected:
>  * - If the @dev providing the AUX bus is currently unpowered then
>  *   it will power itself up for the transfer.
>  * - If the panel is not in a state where it can respond (it's not
>  *   powered or it's in a low power state) then this function will
>  *   fail. Note that if a panel driver is initiating a DP AUX transfer
>  *   it may power itself up however it wants. All other code should
>  *   use the pre_enable() bridge chain (which eventually calls the
>  *   panel prepare function) to power the panel.

I didn't ignore this documentation request. Please take a look here
and see what you think:

https://lore.kernel.org/r/20220503162033.1.Ia8651894026707e4fa61267da944ff739610d180@changeid

-Doug

[PATCH] drm: Document that power requirements for DP AUX transfers

[Douglas Anderson]

When doing DP AUX transfers there are two actors that need to be
powered in order for the DP AUX transfer to work: the DP source and
the DP sync. Commit bacbab58f09d ("drm: Mention the power state
requirement on side-channel operations") added some documentation
saying that the DP source is required to power itself up (if needed)
to do AUX transfers. However, that commit doesn't talk anything about
the DP sink.

For full fledged DP the sink isn't really a problem. It's expected
that if an external DP monitor isn't plugged in that attempting to do
AUX transfers won't work. It's also expected that if a DP monitor is
plugged in (and thus asserting HPD) that it AUX transfers will work.

When we're looking at eDP, however, things are less obvious. Let's add
some documentation about expectations. Here's what we'll say:

1. We don't expect the DP AUX transfer function to power on an eDP
panel. If an eDP panel is physically connected but powered off then it
makes sense for the transfer to fail.

2. We'll document that the official way to power on a panel is via the
bridge chain, specifically by making sure that the panel's prepare
function has been called (which is called by
panel_bridge_pre_enable()). It's already specified in the kernel doc
of drm_panel_prepare() that this is the way to power the panel on and
also that after this call "it is possible to communicate with any
integrated circuitry via a command bus."

3. We'll also document that for code running in the panel driver
itself that it is legal for the panel driver to power itself up
however it wants (it doesn't need to officially call
drm_panel_pre_enable()) and then it can do AUX bus transfers. This is
currently the way that edp-panel works when it's running atop the DP
AUX bus.

Signed-off-by: Douglas Anderson 
---

 include/drm/display/drm_dp_helper.h | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/include/drm/display/drm_dp_helper.h 
b/include/drm/display/drm_dp_helper.h
index dca40a045dd6..e5165b708a40 100644
--- a/include/drm/display/drm_dp_helper.h
+++ b/include/drm/display/drm_dp_helper.h
@@ -370,9 +370,17 @@ struct drm_dp_aux {
 * helpers assume this is the case.
 *
 * Also note that this callback can be called no matter the
-* state @dev is in. Drivers that need that device to be powered
-* to perform this operation will first need to make sure it's
-* been properly enabled.
+* state @dev is in and also no matter what state the panel is
+* in. It's expected:
+* - If the @dev providing the AUX bus is currently unpowered then
+*   it will power itself up for the transfer.
+* - If we're on eDP and the panel is not in a state where it can
+*   respond (it's not powered or it's in a low power state) then this
+*   function will return an error (but not crash). Note that if a
+*   panel driver is initiating a DP AUX transfer it may power itself
+*   up however it wants. All other code should ensure that the
+*   pre_enable() bridge chain (which eventually calls the panel
+*   prepare function) has powered the panel.
 */
ssize_t (*transfer)(struct drm_dp_aux *aux,
struct drm_dp_aux_msg *msg);
-- 
2.36.0.464.gb9c8b46e94-goog

Re: [PATCH 07/25] drm/msm/dpu: drop dpu_plane_pipe function

[Abhinav Kumar]

On 2/9/2022 9:25 AM, Dmitry Baryshkov wrote:

There no more need for the dpu_plane_pipe() function, crtc code can
access pstate->pipe_hw.idx directly.

Signed-off-by: Dmitry Baryshkov 


Perhaps this can be squashed with the previous change.

Otherwise,

Reviewed-by: Abhinav Kumar 

---
  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  | 4 ++--
  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 5 -
  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 7 ---
  3 files changed, 2 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 5fc338ef3460..d21791db6ab1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -364,7 +364,7 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc 
*crtc,
pstate = to_dpu_plane_state(state);
fb = state->fb;
  
-		sspp_idx = dpu_plane_pipe(plane);

+   sspp_idx = pstate->pipe_hw->idx;
set_bit(sspp_idx, fetch_active);
  
  		DRM_DEBUG_ATOMIC("crtc %d stage:%d - plane %d sspp %d fb %d\n",

@@ -1112,7 +1112,7 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
pstates[cnt].dpu_pstate = to_dpu_plane_state(pstate);
pstates[cnt].drm_pstate = pstate;
pstates[cnt].stage = pstate->normalized_zpos;
-   pstates[cnt].pipe_id = dpu_plane_pipe(plane);
+   pstates[cnt].pipe_id = to_dpu_plane_state(pstate)->pipe_hw->idx;
  
  		if (pipe_staged[pstates[cnt].pipe_id]) {

multirect_plane[multirect_count].r0 =
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index ca194cd83cd0..d1f9b4bc10ac 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -1391,11 +1391,6 @@ static const struct drm_plane_helper_funcs 
dpu_plane_helper_funcs = {
.atomic_update = dpu_plane_atomic_update,
  };
  
-enum dpu_sspp dpu_plane_pipe(struct drm_plane *plane)

-{
-   return plane ? to_dpu_plane(plane)->pipe : SSPP_NONE;
-}
-
  /* initialize plane */
  struct drm_plane *dpu_plane_init(struct drm_device *dev,
uint32_t pipe, enum drm_plane_type type,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
index aa9478b475d4..d745cde4ea77 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
@@ -54,13 +54,6 @@ struct dpu_multirect_plane_states {
  #define to_dpu_plane_state(x) \
container_of(x, struct dpu_plane_state, base)
  
-/**

- * dpu_plane_pipe - return sspp identifier for the given plane
- * @plane:   Pointer to DRM plane object
- * Returns: sspp identifier of the given plane
- */
-enum dpu_sspp dpu_plane_pipe(struct drm_plane *plane);
-
  /**
   * dpu_plane_flush - final plane operations before commit flush
   * @plane: Pointer to drm plane structure

Re: [PATCH 06/25] drm/msm/dpu: inline dpu_plane_get_ctl_flush

[Abhinav Kumar]

On 2/9/2022 9:25 AM, Dmitry Baryshkov wrote:

There is no need to keep a separate function for calling into the ctl if
we already know all the details. Inline this function in the dpu_crtc.c

Signed-off-by: Dmitry Baryshkov 

Reviewed-by: Abhinav Kumar 

---
  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  | 15 ---
  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 12 
  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h |  9 -
  3 files changed, 8 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 7318bd45637a..5fc338ef3460 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -348,7 +348,6 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc 
*crtc,
struct dpu_format *format;
struct dpu_hw_ctl *ctl = mixer->lm_ctl;
  
-	u32 flush_mask;

uint32_t stage_idx, lm_idx;
int zpos_cnt[DPU_STAGE_MAX + 1] = { 0 };
bool bg_alpha_enable = false;
@@ -356,6 +355,8 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc 
*crtc,
  
  	memset(fetch_active, 0, sizeof(fetch_active));

drm_atomic_crtc_for_each_plane(plane, crtc) {
+   enum dpu_sspp sspp_idx;
+
state = plane->state;
if (!state)
continue;
@@ -363,14 +364,14 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc 
*crtc,
pstate = to_dpu_plane_state(state);
fb = state->fb;
  
-		dpu_plane_get_ctl_flush(plane, ctl, _mask);

-   set_bit(dpu_plane_pipe(plane), fetch_active);
+   sspp_idx = dpu_plane_pipe(plane);
+   set_bit(sspp_idx, fetch_active);
  
  		DRM_DEBUG_ATOMIC("crtc %d stage:%d - plane %d sspp %d fb %d\n",

crtc->base.id,
pstate->stage,
plane->base.id,
-   dpu_plane_pipe(plane) - SSPP_VIG0,
+   sspp_idx - SSPP_VIG0,
state->fb ? state->fb->base.id : -1);
  
  		format = to_dpu_format(msm_framebuffer_format(pstate->base.fb));

@@ -380,13 +381,13 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc 
*crtc,
  
  		stage_idx = zpos_cnt[pstate->stage]++;

stage_cfg->stage[pstate->stage][stage_idx] =
-   dpu_plane_pipe(plane);
+   sspp_idx;
stage_cfg->multirect_index[pstate->stage][stage_idx] =
pstate->multirect_index;
  
  		trace_dpu_crtc_setup_mixer(DRMID(crtc), DRMID(plane),

   state, pstate, stage_idx,
-  dpu_plane_pipe(plane) - SSPP_VIG0,
+  sspp_idx - SSPP_VIG0,
   format->base.pixel_format,
   fb ? fb->modifier : 0);
  
@@ -395,7 +396,7 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc *crtc,

_dpu_crtc_setup_blend_cfg(mixer + lm_idx,
pstate, format);
  
-			mixer[lm_idx].flush_mask |= flush_mask;

+   mixer[lm_idx].flush_mask |= 
ctl->ops.get_bitmask_sspp(ctl, sspp_idx);
  
  			if (bg_alpha_enable && !format->alpha_enable)

mixer[lm_idx].mixer_op_mode = 0;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 0247ff8a67a2..ca194cd83cd0 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -849,18 +849,6 @@ int dpu_plane_validate_multirect_v2(struct 
dpu_multirect_plane_states *plane)
return 0;
  }
  
-/**

- * dpu_plane_get_ctl_flush - get control flush for the given plane
- * @plane: Pointer to drm plane structure
- * @ctl: Pointer to hardware control driver
- * @flush_sspp: Pointer to sspp flush control word
- */
-void dpu_plane_get_ctl_flush(struct drm_plane *plane, struct dpu_hw_ctl *ctl,
-   u32 *flush_sspp)
-{
-   *flush_sspp = ctl->ops.get_bitmask_sspp(ctl, dpu_plane_pipe(plane));
-}
-
  static int dpu_plane_prepare_fb(struct drm_plane *plane,
struct drm_plane_state *new_state)
  {
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
index 42b88b6bc9c2..aa9478b475d4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
@@ -61,15 +61,6 @@ struct dpu_multirect_plane_states {
   */
  enum dpu_sspp dpu_plane_pipe(struct drm_plane *plane);
  
-/**

- * dpu_plane_get_ctl_flush - get control flush mask
- * @plane:   Pointer to DRM plane object
- * @ctl: Pointer to control hardware
- * @flush_sspp: Pointer to sspp 

Re: [RFC PATCH 1/6] drm/dp: Helpers to make it easier for drivers to use DP AUX bus properly

[Doug Anderson]

Hi,

On Mon, Apr 18, 2022 at 4:10 PM Doug Anderson  wrote:
>
> So I guess where does that leave us? Maybe:
>
> 1. I'll add a WARN_ON() in of_dp_aux_populate_ep_devices() if there is
> more than one DP AUX endpoint with a comment explaining why we assume
> one DP AUX endpoint.
>
> 2. I'll create this new structure in drm_dp_aux_bus.h:
>
> struct dp_aux_populate_callbacks {
>   int (*done_probing)(struct drm_dp_aux *aux);
>   void (*pre_remove)(struct drm_dp_aux *aux);
> };
>
> 3. I'll add a second version of the populate functions that AUX bus
> providers can use if they want callbacks:
>
> int of_dp_aux_populate_ep_devices_cb(struct drm_dp_aux *aux,
>  struct dp_aux_populate_callbacks *cb);
> int devm_of_dp_aux_populate_ep_devices_cb(struct drm_dp_aux *aux,
>   struct dp_aux_populate_callbacks 
> *cb);
>
> The old functions will just be changed to wrap the above and pass NULL
> for the callbacks. To me, this seems better/simpler than notifiers or
> any other scheme, but yell if you disagree.
>
> 4. I'll call the callsbacks in dp_aux_ep_probe() after a successful
> probe. I'll add a second callback and will call it in
> dp_aux_ep_remove() before passing the remove through to the panel.
>
>
> If that sounds peachy then I think it should be pretty doable.

I never heard any response about whether people liked the above, but I
went ahead and did something similar to it. It can be found at:

https://lore.kernel.org/r/20220503224029.3195306-1-diand...@chromium.org

[PATCH v2 2/2] drm/bridge: parade-ps8640: Handle DP AUX more properly

[Douglas Anderson]

While it works, for the most part, to assume that the panel has
finished probing when devm_of_dp_aux_populate_ep_devices() returns,
it's a bit fragile. This is talked about at length in commit
a1e3667a9835 ("drm/bridge: ti-sn65dsi86: Promote the AUX channel to
its own sub-dev").

When reviewing the ps8640 code, I managed to convince myself that it
was OK not to worry about it there and that maybe it wasn't really
_that_ fragile. However, it turns out that it really is. Simply
hardcoding panel_edp_probe() to return -EPROBE_DEFER was enough to put
the boot process into an infinite loop. I believe this manages to trip
the same issues that we used to trip with the main MSM code where
something about our actions trigger Linux to re-probe previously
deferred devices right away and each time we try again we re-trigger
Linux to re-probe.

Let's fix this using the callback introduced in the patch ("drm/dp:
Callbacks to make it easier for drivers to use DP AUX bus properly").
When using the new callback, we have to be a little careful. The
probe_done() callback is no longer (always) called in the context of
our probe routine. That means we can't rely on being able to return
-EPROBE_DEFER from it. We re-jigger the order of things a bit to
account for that.

With this change, the device still boots (though obviously the panel
doesn't come up) if I force panel-edp to always return
-EPROBE_DEFER. If I fake it and make the panel probe exactly once it
also works.

Signed-off-by: Douglas Anderson 
---

Changes in v2:
- Rewrote atop new method introduced by patch #1.

 drivers/gpu/drm/bridge/parade-ps8640.c | 77 +-
 1 file changed, 52 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
index edb939b14c04..68131ca91eac 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -104,6 +104,7 @@ struct ps8640 {
struct gpio_desc *gpio_powerdown;
struct device_link *link;
bool pre_enabled;
+   bool bridge_added;
 };
 
 static const struct regmap_config ps8640_regmap_config[] = {
@@ -537,12 +538,11 @@ static const struct drm_bridge_funcs ps8640_bridge_funcs 
= {
.pre_enable = ps8640_pre_enable,
 };
 
-static int ps8640_bridge_host_attach(struct device *dev, struct ps8640 
*ps_bridge)
+static int ps8640_bridge_get_dsi_resources(struct device *dev, struct ps8640 
*ps_bridge)
 {
struct device_node *in_ep, *dsi_node;
struct mipi_dsi_device *dsi;
struct mipi_dsi_host *host;
-   int ret;
const struct mipi_dsi_device_info info = { .type = "ps8640",
   .channel = 0,
   .node = NULL,
@@ -577,17 +577,44 @@ static int ps8640_bridge_host_attach(struct device *dev, 
struct ps8640 *ps_bridg
dsi->format = MIPI_DSI_FMT_RGB888;
dsi->lanes = NUM_MIPI_LANES;
 
-   ret = devm_mipi_dsi_attach(dev, dsi);
+   return 0;
+}
+
+static int ps8640_bridge_link_panel(struct drm_dp_aux *aux)
+{
+   struct ps8640 *ps_bridge = aux_to_ps8640(aux);
+   struct device *dev = aux->dev;
+   struct device_node *np = dev->of_node;
+   int ret;
+
+   /*
+* NOTE about returning -EPROBE_DEFER from this function: if we
+* return an error (most relevant to -EPROBE_DEFER) it will only
+* be passed out to ps8640_probe() if we don't have our panel
+* under the "aux-bus". That should be fine because if the panel is
+* under "aux-bus" it's guaranteed to have probed by the time this
+* function has been called.
+*/
+
+   /* port@1 is ps8640 output port */
+   ps_bridge->panel_bridge = devm_drm_of_get_bridge(dev, np, 1, 0);
+   if (IS_ERR(ps_bridge->panel_bridge))
+   return PTR_ERR(ps_bridge->panel_bridge);
+
+   drm_bridge_add(_bridge->bridge);
+
+   ret = devm_mipi_dsi_attach(dev, ps_bridge->dsi);
if (ret)
-   return ret;
+   drm_bridge_remove(_bridge->bridge);
+   else
+   ps_bridge->bridge_added = true;
 
-   return 0;
+   return ret;
 }
 
 static int ps8640_probe(struct i2c_client *client)
 {
struct device *dev = >dev;
-   struct device_node *np = dev->of_node;
struct ps8640 *ps_bridge;
int ret;
u32 i;
@@ -628,6 +655,14 @@ static int ps8640_probe(struct i2c_client *client)
if (!ps8640_of_panel_on_aux_bus(>dev))
ps_bridge->bridge.ops = DRM_BRIDGE_OP_EDID;
 
+   /*
+* Get MIPI DSI resources early. These can return -EPROBE_DEFER so
+* we want to get them out of the way sooner.
+*/
+   ret = ps8640_bridge_get_dsi_resources(>dev, ps_bridge);
+   if (ret)
+   return ret;
+
ps_bridge->page[PAGE0_DP_CNTL] = client;
 
ps_bridge->regmap[PAGE0_DP_CNTL] = 

[PATCH v2 1/2] drm/dp: Add callbacks to make using DP AUX bus properly easier

[Douglas Anderson]

As talked about in this patch in the kerneldoc of
of_dp_aux_populate_ep_device() and also in the past in commit
a1e3667a9835 ("drm/bridge: ti-sn65dsi86: Promote the AUX channel to
its own sub-dev"), it can be difficult for eDP controller drivers to
know when the panel has finished probing when they're using
of_dp_aux_populate_ep_devices().

The ti-sn65dsi86 driver managed to solve this because it was already
broken up into a bunch of sub-drivers. That means we could solve the
problem there by adding a new sub-driver to get the panel. We could
use the traditional -EPROBE_DEFER retry mechansim to handle the case
where the panel hadn't probed yet.

In parade-ps8640 we didn't really solve this. The code just expects
the panel to be ready right away. While reviewing the code originally
I had managed to convince myself it was fine to just expect the panel
right away, but additional testing has shown that not to be the
case. We could fix parade-ps8640 like we did ti-sn65dsi86 but it's
pretty cumbersome (since we're not already broken into multiple
drivers) and requires a bunch of boilerplate code.

After discussion [1] it seems like the best solution for most people
is:
- Accept that there's always at most one device that will probe as a
  result of the DP AUX bus (it may have sub-devices, but there will be
  one device _directly_ probed).
- When that device finishes probing, we can just have a call back.

This patch implements that idea. We'll now take a callback as an
argument to the populate function. To make this easier to land in
pieces, we'll make wrappers for the old functions. The functions with
the new name (which make it clear that we only have one child) will
take the callback and the functions with the old name will temporarily
wrap.

This patch also includes in a few tiny fixes that I noticed while
working on the code. Specifically:
- We had forgotten a EXPORT_SYMBOL_GPL on the non "devm" populate
  function.
- The kerneldoc of dp_aux_ep_dev_release() had incorrectly included a
  "Returns" clause.

[1] 
https://lore.kernel.org/r/CAD=FV=Ur3afHhsXe7a3baWEnD=mfkfekrbhfu+bt3p67g0m...@mail.gmail.com

Signed-off-by: Douglas Anderson 
---

Changes in v2:
- Change to assume exactly one device.
- Have a probe callback instead of an extra sub device.

 drivers/gpu/drm/display/drm_dp_aux_bus.c | 215 +++
 include/drm/display/drm_dp_aux_bus.h |  24 ++-
 2 files changed, 164 insertions(+), 75 deletions(-)

diff --git a/drivers/gpu/drm/display/drm_dp_aux_bus.c 
b/drivers/gpu/drm/display/drm_dp_aux_bus.c
index dccf3e2ea323..f3412c1c2a3c 100644
--- a/drivers/gpu/drm/display/drm_dp_aux_bus.c
+++ b/drivers/gpu/drm/display/drm_dp_aux_bus.c
@@ -3,10 +3,10 @@
  * Copyright 2021 Google Inc.
  *
  * The DP AUX bus is used for devices that are connected over a DisplayPort
- * AUX bus. The devices on the far side of the bus are referred to as
- * endpoints in this code.
+ * AUX bus. The device on the far side of the bus is referred to as an
+ * endpoint in this code.
  *
- * Commonly there is only one device connected to the DP AUX bus: a panel.
+ * There is only one device connected to the DP AUX bus: an eDP panel.
  * Though historically panels (even DP panels) have been modeled as simple
  * platform devices, putting them under the DP AUX bus allows the panel driver
  * to perform transactions on that bus.
@@ -22,6 +22,11 @@
 #include 
 #include 
 
+struct dp_aux_ep_device_with_data {
+   struct dp_aux_ep_device aux_ep;
+   int (*done_probing)(struct drm_dp_aux *aux);
+};
+
 /**
  * dp_aux_ep_match() - The match function for the dp_aux_bus.
  * @dev: The device to match.
@@ -48,6 +53,8 @@ static int dp_aux_ep_probe(struct device *dev)
 {
struct dp_aux_ep_driver *aux_ep_drv = to_dp_aux_ep_drv(dev->driver);
struct dp_aux_ep_device *aux_ep = to_dp_aux_ep_dev(dev);
+   struct dp_aux_ep_device_with_data *aux_ep_with_data =
+   container_of(aux_ep, struct dp_aux_ep_device_with_data, aux_ep);
int ret;
 
ret = dev_pm_domain_attach(dev, true);
@@ -56,7 +63,31 @@ static int dp_aux_ep_probe(struct device *dev)
 
ret = aux_ep_drv->probe(aux_ep);
if (ret)
-   dev_pm_domain_detach(dev, true);
+   goto err_attached;
+
+   if (aux_ep_with_data->done_probing) {
+   ret = aux_ep_with_data->done_probing(aux_ep->aux);
+   if (ret) {
+   /*
+* The done_probing() callback can only defer if it's
+* called directly from of_dp_aux_populate_ep_device()
+* because we had no DP AUX children. Flag an error.
+*/
+   if (ret == -EPROBE_DEFER) {
+   dev_err(dev,
+   "DP AUX done_probing() can't defer w/ 
aux children\n");
+   ret = -EINVAL;
+   }
+  

[PATCH v2 0/2] drm/dp: Make DP AUX bus usage easier; use it on ps8640

[Douglas Anderson]

This patch is v2 of the first 2 patches from my RFC series ("drm/dp: 
Improvements
for DP AUX channel") [1]. I've broken the series in two so we can make
progress on the two halves separately.

v2 of this series tries to incorporate all the feedback from v1. Hopefully
things are less confusing and simpler this time around. The one thing that got
slightly more confusing is that the done_probing() callback can't return
-EPROBE_DEFER in most cases so we have to adjust drivers a little more.

The idea for this series came up during the review process of
Sankeerth's series trying to add eDP for Qualcomm SoCs [2].

This _doesn't_ attempt to fix the Analogix driver. If this works out,
ideally someone can post a patch up to do that.

[1] https://lore.kernel.org/r/20220409023628.2104952-1-diand...@chromium.org/
[2] 
https://lore.kernel.org/r/1648656179-10347-2-git-send-email-quic_sbill...@quicinc.com/

Changes in v2:
- Change to assume exactly one device.
- Have a probe callback instead of an extra sub device.
- Rewrote atop new method introduced by patch #1.

Douglas Anderson (2):
  drm/dp: Add callbacks to make using DP AUX bus properly easier
  drm/bridge: parade-ps8640: Handle DP AUX more properly

 drivers/gpu/drm/bridge/parade-ps8640.c   |  77 +---
 drivers/gpu/drm/display/drm_dp_aux_bus.c | 215 +++
 include/drm/display/drm_dp_aux_bus.h |  24 ++-
 3 files changed, 216 insertions(+), 100 deletions(-)

-- 
2.36.0.464.gb9c8b46e94-goog

Re: [PATCH 04/25] drm/msm/dpu: move SSPP debugfs creation to dpu_kms.c

[Abhinav Kumar]

On 5/3/2022 3:11 PM, Dmitry Baryshkov wrote:

On 04/05/2022 00:34, Abhinav Kumar wrote:



On 2/9/2022 9:24 AM, Dmitry Baryshkov wrote:

As SSPP blocks are now visible through dpu_kms->rm.sspp_blocks, move
SSPP debugfs creation from dpu_plane to dpu_kms.



Change is fine by itself, but is it really needed?
Wouldnt it be better to keep dpu_debugfs_sspp_init in dpu_plane.c?


No. We are going to break the dependency between planes and SSPPs at 
some point. Let's move the debugfs functions to the generic location.




Alright, keeping that dependency-break in mind,

Reviewed-by: Abhinav Kumar 



Signed-off-by: Dmitry Baryshkov 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h |  1 -
  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 19 +++
  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c   | 16 
  3 files changed, 19 insertions(+), 17 deletions(-)

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

index f805c30643b1..674f311f99b4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
@@ -415,7 +415,6 @@ struct dpu_hw_pipe *dpu_hw_sspp_init(enum 
dpu_sspp idx,

   */
  void dpu_hw_sspp_destroy(struct dpu_hw_pipe *ctx);
-void dpu_debugfs_sspp_init(struct dpu_kms *dpu_kms, struct dentry 
*debugfs_root);
  int _dpu_hw_sspp_init_debugfs(struct dpu_hw_pipe *hw_pipe, struct 
dpu_kms *kms, struct dentry *entry);

  #endif /*_DPU_HW_SSPP_H */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c

index 4d2b75f3bc89..8196b11fe2f3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -259,6 +259,25 @@ void dpu_debugfs_create_regset32(const char 
*name, umode_t mode,
  debugfs_create_file(name, mode, parent, regset, 
_fops_regset32);

  }
+static void dpu_debugfs_sspp_init(struct dpu_kms *dpu_kms, struct 
dentry *debugfs_root)

+{
+    struct dentry *entry = debugfs_create_dir("sspp", debugfs_root);
+    int i;
+
+    if (IS_ERR(entry))
+    return;
+
+    for (i = SSPP_NONE; i < SSPP_MAX; i++) {
+    struct dpu_hw_pipe *pipe_hw;
+
+    if (!dpu_kms->rm.sspp_blks[i - SSPP_NONE])
+    continue;
+
+    pipe_hw = to_dpu_hw_pipe(dpu_kms->rm.sspp_blks[i - SSPP_NONE]);
+    _dpu_hw_sspp_init_debugfs(pipe_hw, dpu_kms, entry);
+    }
+}
+
  static int dpu_kms_debugfs_init(struct msm_kms *kms, struct 
drm_minor *minor)

  {
  struct dpu_kms *dpu_kms = to_dpu_kms(kms);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c

index 146dbccd79cd..37742f74a7bf 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -1359,22 +1359,6 @@ void dpu_plane_danger_signal_ctrl(struct 
drm_plane *plane, bool enable)

  _dpu_plane_set_qos_ctrl(plane, enable, DPU_PLANE_QOS_PANIC_CTRL);
  pm_runtime_put_sync(_kms->pdev->dev);
  }
-
-/* SSPP live inside dpu_plane private data only. Enumerate them 
here. */
-void dpu_debugfs_sspp_init(struct dpu_kms *dpu_kms, struct dentry 
*debugfs_root)

-{
-    struct drm_plane *plane;
-    struct dentry *entry = debugfs_create_dir("sspp", debugfs_root);
-
-    if (IS_ERR(entry))
-    return;
-
-    drm_for_each_plane(plane, dpu_kms->dev) {
-    struct dpu_plane *pdpu = to_dpu_plane(plane);
-
-    _dpu_hw_sspp_init_debugfs(pdpu->pipe_hw, dpu_kms, entry);
-    }
-}
  #endif
  static bool dpu_plane_format_mod_supported(struct drm_plane *plane,

Re: [PATCH 05/25] drm/msm/dpu: move pipe_hw to dpu_plane_state

[Abhinav Kumar]

On 2/9/2022 9:25 AM, Dmitry Baryshkov wrote:

In preparation to adding fully virtualized planes, move struct
dpu_hw_pipe instance from struct dpu_plane to struct dpu_plane_state, as
it will become a part of state (allocated during atomic check) rather
than part of a plane (allocated during boot).

Signed-off-by: Dmitry Baryshkov 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 104 --
  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h |   2 +
  2 files changed, 58 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 37742f74a7bf..0247ff8a67a2 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -100,7 +100,6 @@ struct dpu_plane {
  
  	enum dpu_sspp pipe;
  
-	struct dpu_hw_pipe *pipe_hw;

uint32_t color_fill;
bool is_error;
bool is_rt_pipe;
@@ -300,6 +299,7 @@ static void _dpu_plane_set_qos_lut(struct drm_plane *plane,
struct drm_framebuffer *fb, struct dpu_hw_pipe_cfg *pipe_cfg)
  {
struct dpu_plane *pdpu = to_dpu_plane(plane);
+   struct dpu_plane_state *pstate = to_dpu_plane_state(plane->state);
const struct dpu_format *fmt = NULL;
u64 qos_lut;
u32 total_fl = 0, lut_usage;
@@ -331,7 +331,7 @@ static void _dpu_plane_set_qos_lut(struct drm_plane *plane,
fmt ? (char *)>base.pixel_format : NULL,
pdpu->is_rt_pipe, total_fl, qos_lut);
  
-	pdpu->pipe_hw->ops.setup_creq_lut(pdpu->pipe_hw, qos_lut);

+   pstate->pipe_hw->ops.setup_creq_lut(pstate->pipe_hw, qos_lut);
  }
  
  /**

@@ -343,6 +343,7 @@ static void _dpu_plane_set_danger_lut(struct drm_plane 
*plane,
struct drm_framebuffer *fb)
  {
struct dpu_plane *pdpu = to_dpu_plane(plane);
+   struct dpu_plane_state *pstate = to_dpu_plane_state(plane->state);
const struct dpu_format *fmt = NULL;
u32 danger_lut, safe_lut;
  
@@ -382,7 +383,7 @@ static void _dpu_plane_set_danger_lut(struct drm_plane *plane,

danger_lut,
safe_lut);
  
-	pdpu->pipe_hw->ops.setup_danger_safe_lut(pdpu->pipe_hw,

+   pstate->pipe_hw->ops.setup_danger_safe_lut(pstate->pipe_hw,
danger_lut, safe_lut);
  }
  
@@ -396,14 +397,15 @@ static void _dpu_plane_set_qos_ctrl(struct drm_plane *plane,

bool enable, u32 flags)
  {
struct dpu_plane *pdpu = to_dpu_plane(plane);
+   struct dpu_plane_state *pstate = to_dpu_plane_state(plane->state);
struct dpu_hw_pipe_qos_cfg pipe_qos_cfg;
  
  	memset(_qos_cfg, 0, sizeof(pipe_qos_cfg));
  
  	if (flags & DPU_PLANE_QOS_VBLANK_CTRL) {

-   pipe_qos_cfg.creq_vblank = 
pdpu->pipe_hw->cap->sblk->creq_vblank;
+   pipe_qos_cfg.creq_vblank = 
pstate->pipe_hw->cap->sblk->creq_vblank;
pipe_qos_cfg.danger_vblank =
-   pdpu->pipe_hw->cap->sblk->danger_vblank;
+   pstate->pipe_hw->cap->sblk->danger_vblank;
pipe_qos_cfg.vblank_en = enable;
}
  
@@ -429,7 +431,7 @@ static void _dpu_plane_set_qos_ctrl(struct drm_plane *plane,

pipe_qos_cfg.danger_vblank,
pdpu->is_rt_pipe);
  
-	pdpu->pipe_hw->ops.setup_qos_ctrl(pdpu->pipe_hw,

+   pstate->pipe_hw->ops.setup_qos_ctrl(pstate->pipe_hw,
_qos_cfg);
  }
  
@@ -443,18 +445,19 @@ static void _dpu_plane_set_ot_limit(struct drm_plane *plane,

struct drm_crtc *crtc, struct dpu_hw_pipe_cfg *pipe_cfg)
  {
struct dpu_plane *pdpu = to_dpu_plane(plane);
+   struct dpu_plane_state *pstate = to_dpu_plane_state(plane->state);
struct dpu_vbif_set_ot_params ot_params;
struct dpu_kms *dpu_kms = _dpu_plane_get_kms(plane);
  
  	memset(_params, 0, sizeof(ot_params));

-   ot_params.xin_id = pdpu->pipe_hw->cap->xin_id;
-   ot_params.num = pdpu->pipe_hw->idx - SSPP_NONE;
+   ot_params.xin_id = pstate->pipe_hw->cap->xin_id;
+   ot_params.num = pstate->pipe_hw->idx - SSPP_NONE;
ot_params.width = drm_rect_width(_cfg->src_rect);
ot_params.height = drm_rect_height(_cfg->src_rect);
ot_params.is_wfd = !pdpu->is_rt_pipe;
ot_params.frame_rate = drm_mode_vrefresh(>mode);
ot_params.vbif_idx = VBIF_RT;
-   ot_params.clk_ctrl = pdpu->pipe_hw->cap->clk_ctrl;
+   ot_params.clk_ctrl = pstate->pipe_hw->cap->clk_ctrl;
ot_params.rd = true;
  
  	dpu_vbif_set_ot_limit(dpu_kms, _params);

@@ -467,14 +470,15 @@ static void _dpu_plane_set_ot_limit(struct drm_plane 
*plane,
  static void _dpu_plane_set_qos_remap(struct drm_plane *plane)
  {
struct dpu_plane *pdpu = to_dpu_plane(plane);
+   struct dpu_plane_state *pstate = to_dpu_plane_state(plane->state);
struct dpu_vbif_set_qos_params qos_params;
struct dpu_kms *dpu_kms = 

Re: [PATCH 04/25] drm/msm/dpu: move SSPP debugfs creation to dpu_kms.c

[Dmitry Baryshkov]

On 04/05/2022 00:34, Abhinav Kumar wrote:



On 2/9/2022 9:24 AM, Dmitry Baryshkov wrote:

As SSPP blocks are now visible through dpu_kms->rm.sspp_blocks, move
SSPP debugfs creation from dpu_plane to dpu_kms.



Change is fine by itself, but is it really needed?
Wouldnt it be better to keep dpu_debugfs_sspp_init in dpu_plane.c?


No. We are going to break the dependency between planes and SSPPs at 
some point. Let's move the debugfs functions to the generic location.





Signed-off-by: Dmitry Baryshkov 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h |  1 -
  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 19 +++
  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c   | 16 
  3 files changed, 19 insertions(+), 17 deletions(-)

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

index f805c30643b1..674f311f99b4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
@@ -415,7 +415,6 @@ struct dpu_hw_pipe *dpu_hw_sspp_init(enum dpu_sspp 
idx,

   */
  void dpu_hw_sspp_destroy(struct dpu_hw_pipe *ctx);
-void dpu_debugfs_sspp_init(struct dpu_kms *dpu_kms, struct dentry 
*debugfs_root);
  int _dpu_hw_sspp_init_debugfs(struct dpu_hw_pipe *hw_pipe, struct 
dpu_kms *kms, struct dentry *entry);

  #endif /*_DPU_HW_SSPP_H */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c

index 4d2b75f3bc89..8196b11fe2f3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -259,6 +259,25 @@ void dpu_debugfs_create_regset32(const char 
*name, umode_t mode,
  debugfs_create_file(name, mode, parent, regset, 
_fops_regset32);

  }
+static void dpu_debugfs_sspp_init(struct dpu_kms *dpu_kms, struct 
dentry *debugfs_root)

+{
+    struct dentry *entry = debugfs_create_dir("sspp", debugfs_root);
+    int i;
+
+    if (IS_ERR(entry))
+    return;
+
+    for (i = SSPP_NONE; i < SSPP_MAX; i++) {
+    struct dpu_hw_pipe *pipe_hw;
+
+    if (!dpu_kms->rm.sspp_blks[i - SSPP_NONE])
+    continue;
+
+    pipe_hw = to_dpu_hw_pipe(dpu_kms->rm.sspp_blks[i - SSPP_NONE]);
+    _dpu_hw_sspp_init_debugfs(pipe_hw, dpu_kms, entry);
+    }
+}
+
  static int dpu_kms_debugfs_init(struct msm_kms *kms, struct 
drm_minor *minor)

  {
  struct dpu_kms *dpu_kms = to_dpu_kms(kms);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c

index 146dbccd79cd..37742f74a7bf 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -1359,22 +1359,6 @@ void dpu_plane_danger_signal_ctrl(struct 
drm_plane *plane, bool enable)

  _dpu_plane_set_qos_ctrl(plane, enable, DPU_PLANE_QOS_PANIC_CTRL);
  pm_runtime_put_sync(_kms->pdev->dev);
  }
-
-/* SSPP live inside dpu_plane private data only. Enumerate them here. */
-void dpu_debugfs_sspp_init(struct dpu_kms *dpu_kms, struct dentry 
*debugfs_root)

-{
-    struct drm_plane *plane;
-    struct dentry *entry = debugfs_create_dir("sspp", debugfs_root);
-
-    if (IS_ERR(entry))
-    return;
-
-    drm_for_each_plane(plane, dpu_kms->dev) {
-    struct dpu_plane *pdpu = to_dpu_plane(plane);
-
-    _dpu_hw_sspp_init_debugfs(pdpu->pipe_hw, dpu_kms, entry);
-    }
-}
  #endif
  static bool dpu_plane_format_mod_supported(struct drm_plane *plane,



--
With best wishes
Dmitry

Re: [PATCH] drm/nouveau/subdev/bus: Ratelimit logging for fault errors

[Karol Herbst]

Actually, there is another place we have to put this, we can spam
"SCHED_ERROR" things which are triggered within multiple
drivers/gpu/drm/nouveau/nvkm/engine/fifo/ files.

On Tue, May 3, 2022 at 9:23 PM Karol Herbst  wrote:
>
> not able to hit any error on my machine, but regardless:
>
> Reviewed-by: Karol Herbst 
>
> I suspect there are more places where we could put it, but we can add
> those later.
>
> Anyway, I think it's valuable to push it through fixes, not sure how
> far back we want to CC stable though.
>
> On Fri, Apr 29, 2022 at 9:54 PM Lyude Paul  wrote:
> >
> > There's plenty of ways to fudge the GPU when developing on nouveau by
> > mistake, some of which can result in nouveau seriously spamming dmesg with
> > fault errors. This can be somewhat annoying, as it can quickly overrun the
> > message buffer (or your terminal emulator's buffer) and get rid of actually
> > useful feedback from the driver. While working on my new atomic only MST
> > branch, I ran into this issue a couple of times.
> >
> > So, let's fix this by adding nvkm_error_ratelimited(), and using it to
> > ratelimit errors from faults. This should be fine for developers, since
> > it's nearly always only the first few faults that we care about seeing.
> > Plus, you can turn off rate limiting in the kernel if you really need to.
> >
> > Signed-off-by: Lyude Paul 
> > ---
> >  drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h |  2 ++
> >  drivers/gpu/drm/nouveau/nvkm/subdev/bus/gf100.c| 14 +++---
> >  drivers/gpu/drm/nouveau/nvkm/subdev/bus/nv31.c |  6 +++---
> >  drivers/gpu/drm/nouveau/nvkm/subdev/bus/nv50.c |  6 +++---
> >  4 files changed, 15 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h 
> > b/drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h
> > index 1665738948fb..96113c8bee8c 100644
> > --- a/drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h
> > +++ b/drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h
> > @@ -62,4 +62,6 @@ void nvkm_subdev_intr(struct nvkm_subdev *);
> >  #define nvkm_debug(s,f,a...) nvkm_printk((s), DEBUG,   info, f, ##a)
> >  #define nvkm_trace(s,f,a...) nvkm_printk((s), TRACE,   info, f, ##a)
> >  #define nvkm_spam(s,f,a...)  nvkm_printk((s),  SPAM,dbg, f, ##a)
> > +
> > +#define nvkm_error_ratelimited(s,f,a...) nvkm_printk((s), ERROR, 
> > err_ratelimited, f, ##a)
> >  #endif
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bus/gf100.c 
> > b/drivers/gpu/drm/nouveau/nvkm/subdev/bus/gf100.c
> > index 53a6651ac225..80b5aaceeaad 100644
> > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/bus/gf100.c
> > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bus/gf100.c
> > @@ -35,13 +35,13 @@ gf100_bus_intr(struct nvkm_bus *bus)
> > u32 addr = nvkm_rd32(device, 0x009084);
> > u32 data = nvkm_rd32(device, 0x009088);
> >
> > -   nvkm_error(subdev,
> > -  "MMIO %s of %08x FAULT at %06x [ %s%s%s]\n",
> > -  (addr & 0x0002) ? "write" : "read", data,
> > -  (addr & 0x00fc),
> > -  (stat & 0x0002) ? "!ENGINE " : "",
> > -  (stat & 0x0004) ? "PRIVRING " : "",
> > -  (stat & 0x0008) ? "TIMEOUT " : "");
> > +   nvkm_error_ratelimited(subdev,
> > +  "MMIO %s of %08x FAULT at %06x [ 
> > %s%s%s]\n",
> > +  (addr & 0x0002) ? "write" : 
> > "read", data,
> > +  (addr & 0x00fc),
> > +  (stat & 0x0002) ? "!ENGINE " : 
> > "",
> > +  (stat & 0x0004) ? "PRIVRING " : 
> > "",
> > +  (stat & 0x0008) ? "TIMEOUT " : 
> > "");
> >
> > nvkm_wr32(device, 0x009084, 0x);
> > nvkm_wr32(device, 0x001100, (stat & 0x000e));
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bus/nv31.c 
> > b/drivers/gpu/drm/nouveau/nvkm/subdev/bus/nv31.c
> > index ad8da523bb22..c75e463f3501 100644
> > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/bus/nv31.c
> > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bus/nv31.c
> > @@ -45,9 +45,9 @@ nv31_bus_intr(struct nvkm_bus *bus)
> > u32 addr = nvkm_rd32(device, 0x009084);
> > u32 data = nvkm_rd32(device, 0x009088);
> >
> > -   nvkm_error(subdev, "MMIO %s of %08x FAULT at %06x\n",
> > -  (addr & 0x0002) ? "write" : "read", data,
> > -  (addr & 0x00fc));
> > +   nvkm_error_ratelimited(subdev, "MMIO %s of %08x FAULT at 
> > %06x\n",
> > +  (addr & 0x0002) ? "write" : 
> > "read", data,
> > +  (addr & 0x00fc));
> >
> > stat &= ~0x0008;
> >   

Re: [PATCH 04/25] drm/msm/dpu: move SSPP debugfs creation to dpu_kms.c

[Abhinav Kumar]

On 2/9/2022 9:24 AM, Dmitry Baryshkov wrote:

As SSPP blocks are now visible through dpu_kms->rm.sspp_blocks, move
SSPP debugfs creation from dpu_plane to dpu_kms.



Change is fine by itself, but is it really needed?
Wouldnt it be better to keep dpu_debugfs_sspp_init in dpu_plane.c?


Signed-off-by: Dmitry Baryshkov 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h |  1 -
  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 19 +++
  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c   | 16 
  3 files changed, 19 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
index f805c30643b1..674f311f99b4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
@@ -415,7 +415,6 @@ struct dpu_hw_pipe *dpu_hw_sspp_init(enum dpu_sspp idx,
   */
  void dpu_hw_sspp_destroy(struct dpu_hw_pipe *ctx);
  
-void dpu_debugfs_sspp_init(struct dpu_kms *dpu_kms, struct dentry *debugfs_root);

  int _dpu_hw_sspp_init_debugfs(struct dpu_hw_pipe *hw_pipe, struct dpu_kms 
*kms, struct dentry *entry);
  
  #endif /*_DPU_HW_SSPP_H */

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 4d2b75f3bc89..8196b11fe2f3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -259,6 +259,25 @@ void dpu_debugfs_create_regset32(const char *name, umode_t 
mode,
debugfs_create_file(name, mode, parent, regset, _fops_regset32);
  }
  
+static void dpu_debugfs_sspp_init(struct dpu_kms *dpu_kms, struct dentry *debugfs_root)

+{
+   struct dentry *entry = debugfs_create_dir("sspp", debugfs_root);
+   int i;
+
+   if (IS_ERR(entry))
+   return;
+
+   for (i = SSPP_NONE; i < SSPP_MAX; i++) {
+   struct dpu_hw_pipe *pipe_hw;
+
+   if (!dpu_kms->rm.sspp_blks[i - SSPP_NONE])
+   continue;
+
+   pipe_hw = to_dpu_hw_pipe(dpu_kms->rm.sspp_blks[i - SSPP_NONE]);
+   _dpu_hw_sspp_init_debugfs(pipe_hw, dpu_kms, entry);
+   }
+}
+
  static int dpu_kms_debugfs_init(struct msm_kms *kms, struct drm_minor *minor)
  {
struct dpu_kms *dpu_kms = to_dpu_kms(kms);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 146dbccd79cd..37742f74a7bf 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -1359,22 +1359,6 @@ void dpu_plane_danger_signal_ctrl(struct drm_plane 
*plane, bool enable)
_dpu_plane_set_qos_ctrl(plane, enable, DPU_PLANE_QOS_PANIC_CTRL);
pm_runtime_put_sync(_kms->pdev->dev);
  }
-
-/* SSPP live inside dpu_plane private data only. Enumerate them here. */
-void dpu_debugfs_sspp_init(struct dpu_kms *dpu_kms, struct dentry 
*debugfs_root)
-{
-   struct drm_plane *plane;
-   struct dentry *entry = debugfs_create_dir("sspp", debugfs_root);
-
-   if (IS_ERR(entry))
-   return;
-
-   drm_for_each_plane(plane, dpu_kms->dev) {
-   struct dpu_plane *pdpu = to_dpu_plane(plane);
-
-   _dpu_hw_sspp_init_debugfs(pdpu->pipe_hw, dpu_kms, entry);
-   }
-}
  #endif
  
  static bool dpu_plane_format_mod_supported(struct drm_plane *plane,

Re: [PATCH] drm/msm/dsi: fix address for second DSI PHY on SDM660

[Abhinav Kumar]

On 5/3/2022 1:43 PM, Dmitry Baryshkov wrote:

Correct a typo in the address of the second DSI PHY in the SDM660 device
config.

Fixes: 694dd304cc29 ("drm/msm/dsi: Add phy configuration for SDM630/636/660")
Cc: Konrad Dybcio 
Signed-off-by: Dmitry Baryshkov 


Typo indeed. 0xc996400 is the correct PHY address of DSI1.
0xc996000 which was previously used here is the controller start address 
of DSI1.


Reviewed-by: Abhinav Kumar 

---
  drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c 
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
index 75557ac99adf..8199c53567f4 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
@@ -1062,7 +1062,7 @@ const struct msm_dsi_phy_cfg dsi_phy_14nm_660_cfgs = {
},
.min_pll_rate = VCO_MIN_RATE,
.max_pll_rate = VCO_MAX_RATE,
-   .io_start = { 0xc994400, 0xc996000 },
+   .io_start = { 0xc994400, 0xc996400 },
.num_dsi_phy = 2,
  };
  

Re: [PATCH v2] fbdev: Use helper to get fb_info in all file operations

[Sam Ravnborg]

On Tue, May 03, 2022 at 10:19:34PM +0200, Javier Martinez Canillas wrote:
> A reference to the framebuffer device struct fb_info is stored in the file
> private data, but this reference could no longer be valid and must not be
> accessed directly. Instead, the file_fb_info() accessor function must be
> used since it does sanity checking to make sure that the fb_info is valid.
> 
> This can happen for example if the registered framebuffer device is for a
> driver that just uses a framebuffer provided by the system firmware. In
> that case, the fbdev core would unregister the framebuffer device when a
> real video driver is probed and ask to remove conflicting framebuffers.
> 
> Most fbdev file operations already use the helper to get the fb_info but
> get_fb_unmapped_area() and fb_deferred_io_fsync() don't. Fix those two.
> 
> Since fb_deferred_io_fsync() is not in fbmem.o, the helper has to be
> exported. Rename it and add a fb_ prefix to denote that is public now.
> 
> Reported-by: Junxiao Chang 
> Signed-off-by: Javier Martinez Canillas 
Acked-by: Sam Ravnborg 

[PATCH] drm/msm/dsi: fix address for second DSI PHY on SDM660

[Dmitry Baryshkov]

Correct a typo in the address of the second DSI PHY in the SDM660 device
config.

Fixes: 694dd304cc29 ("drm/msm/dsi: Add phy configuration for SDM630/636/660")
Cc: Konrad Dybcio 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c 
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
index 75557ac99adf..8199c53567f4 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
@@ -1062,7 +1062,7 @@ const struct msm_dsi_phy_cfg dsi_phy_14nm_660_cfgs = {
},
.min_pll_rate = VCO_MIN_RATE,
.max_pll_rate = VCO_MAX_RATE,
-   .io_start = { 0xc994400, 0xc996000 },
+   .io_start = { 0xc994400, 0xc996400 },
.num_dsi_phy = 2,
 };
 
-- 
2.35.1

Re: [PATCH] fbdev: Use helper to get fb_info in all file operations

[Javier Martinez Canillas]

Hello Sam,

On 5/3/22 19:14, Sam Ravnborg wrote:
> Hi Javier,
> 

[snip]

>>  
>>  int fb_deferred_io_fsync(struct file *file, loff_t start, loff_t end, int 
>> datasync)
>>  {
>> -struct fb_info *info = file->private_data;
>> +struct fb_info *info = fb_file_fb_info(file->private_data);
> This looks wrong. I assume you wanted to write:
>> +struct fb_info *info = fb_file_fb_info(file);

Right I did. Thanks for pointing out.

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

[PATCH v2] fbdev: Use helper to get fb_info in all file operations

[Javier Martinez Canillas]

A reference to the framebuffer device struct fb_info is stored in the file
private data, but this reference could no longer be valid and must not be
accessed directly. Instead, the file_fb_info() accessor function must be
used since it does sanity checking to make sure that the fb_info is valid.

This can happen for example if the registered framebuffer device is for a
driver that just uses a framebuffer provided by the system firmware. In
that case, the fbdev core would unregister the framebuffer device when a
real video driver is probed and ask to remove conflicting framebuffers.

Most fbdev file operations already use the helper to get the fb_info but
get_fb_unmapped_area() and fb_deferred_io_fsync() don't. Fix those two.

Since fb_deferred_io_fsync() is not in fbmem.o, the helper has to be
exported. Rename it and add a fb_ prefix to denote that is public now.

Reported-by: Junxiao Chang 
Signed-off-by: Javier Martinez Canillas 
---

Changes in v2:
- Fix copy & paste error passing file->private_data instead of file
  to fb_file_fb_info() function (Sam Ravnborg).

 drivers/video/fbdev/core/fb_defio.c |  5 -
 drivers/video/fbdev/core/fbmem.c| 24 +++-
 include/linux/fb.h  |  1 +
 3 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/drivers/video/fbdev/core/fb_defio.c 
b/drivers/video/fbdev/core/fb_defio.c
index 842c66b3e33d..ccdf903c48bd 100644
--- a/drivers/video/fbdev/core/fb_defio.c
+++ b/drivers/video/fbdev/core/fb_defio.c
@@ -68,12 +68,15 @@ static vm_fault_t fb_deferred_io_fault(struct vm_fault *vmf)
 
 int fb_deferred_io_fsync(struct file *file, loff_t start, loff_t end, int 
datasync)
 {
-   struct fb_info *info = file->private_data;
+   struct fb_info *info = fb_file_fb_info(file);
struct inode *inode = file_inode(file);
int err = file_write_and_wait_range(file, start, end);
if (err)
return err;
 
+   if (!info)
+   return -ENODEV;
+
/* Skip if deferred io is compiled-in but disabled on this fbdev */
if (!info->fbdefio)
return 0;
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 97eb0dee411c..ba2c14a1087d 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -745,7 +745,7 @@ static const struct seq_operations __maybe_unused 
proc_fb_seq_ops = {
  * So look up the fb_info using the inode minor number,
  * and just verify it against the reference we have.
  */
-static struct fb_info *file_fb_info(struct file *file)
+struct fb_info *fb_file_fb_info(struct file *file)
 {
struct inode *inode = file_inode(file);
int fbidx = iminor(inode);
@@ -755,12 +755,13 @@ static struct fb_info *file_fb_info(struct file *file)
info = NULL;
return info;
 }
+EXPORT_SYMBOL(fb_file_fb_info);
 
 static ssize_t
 fb_read(struct file *file, char __user *buf, size_t count, loff_t *ppos)
 {
unsigned long p = *ppos;
-   struct fb_info *info = file_fb_info(file);
+   struct fb_info *info = fb_file_fb_info(file);
u8 *buffer, *dst;
u8 __iomem *src;
int c, cnt = 0, err = 0;
@@ -825,7 +826,7 @@ static ssize_t
 fb_write(struct file *file, const char __user *buf, size_t count, loff_t *ppos)
 {
unsigned long p = *ppos;
-   struct fb_info *info = file_fb_info(file);
+   struct fb_info *info = fb_file_fb_info(file);
u8 *buffer, *src;
u8 __iomem *dst;
int c, cnt = 0, err = 0;
@@ -1181,7 +1182,7 @@ static long do_fb_ioctl(struct fb_info *info, unsigned 
int cmd,
 
 static long fb_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
 {
-   struct fb_info *info = file_fb_info(file);
+   struct fb_info *info = fb_file_fb_info(file);
 
if (!info)
return -ENODEV;
@@ -1293,7 +1294,7 @@ static int fb_get_fscreeninfo(struct fb_info *info, 
unsigned int cmd,
 static long fb_compat_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
 {
-   struct fb_info *info = file_fb_info(file);
+   struct fb_info *info = fb_file_fb_info(file);
const struct fb_ops *fb;
long ret = -ENOIOCTLCMD;
 
@@ -1333,7 +1334,7 @@ static long fb_compat_ioctl(struct file *file, unsigned 
int cmd,
 static int
 fb_mmap(struct file *file, struct vm_area_struct * vma)
 {
-   struct fb_info *info = file_fb_info(file);
+   struct fb_info *info = fb_file_fb_info(file);
int (*fb_mmap_fn)(struct fb_info *info, struct vm_area_struct *vma);
unsigned long mmio_pgoff;
unsigned long start;
@@ -1434,7 +1435,7 @@ fb_release(struct inode *inode, struct file *file)
 __acquires(>lock)
 __releases(>lock)
 {
-   struct fb_info * const info = file_fb_info(file);
+   struct fb_info * const info = fb_file_fb_info(file);
 
if (!info)
return -ENODEV;
@@ -1453,8 +1454,13 @@ unsigned long 

Re: [PATCH] drm/nouveau/subdev/bus: Ratelimit logging for fault errors

[Karol Herbst]

not able to hit any error on my machine, but regardless:

Reviewed-by: Karol Herbst 

I suspect there are more places where we could put it, but we can add
those later.

Anyway, I think it's valuable to push it through fixes, not sure how
far back we want to CC stable though.

On Fri, Apr 29, 2022 at 9:54 PM Lyude Paul  wrote:
>
> There's plenty of ways to fudge the GPU when developing on nouveau by
> mistake, some of which can result in nouveau seriously spamming dmesg with
> fault errors. This can be somewhat annoying, as it can quickly overrun the
> message buffer (or your terminal emulator's buffer) and get rid of actually
> useful feedback from the driver. While working on my new atomic only MST
> branch, I ran into this issue a couple of times.
>
> So, let's fix this by adding nvkm_error_ratelimited(), and using it to
> ratelimit errors from faults. This should be fine for developers, since
> it's nearly always only the first few faults that we care about seeing.
> Plus, you can turn off rate limiting in the kernel if you really need to.
>
> Signed-off-by: Lyude Paul 
> ---
>  drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h |  2 ++
>  drivers/gpu/drm/nouveau/nvkm/subdev/bus/gf100.c| 14 +++---
>  drivers/gpu/drm/nouveau/nvkm/subdev/bus/nv31.c |  6 +++---
>  drivers/gpu/drm/nouveau/nvkm/subdev/bus/nv50.c |  6 +++---
>  4 files changed, 15 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h 
> b/drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h
> index 1665738948fb..96113c8bee8c 100644
> --- a/drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h
> +++ b/drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h
> @@ -62,4 +62,6 @@ void nvkm_subdev_intr(struct nvkm_subdev *);
>  #define nvkm_debug(s,f,a...) nvkm_printk((s), DEBUG,   info, f, ##a)
>  #define nvkm_trace(s,f,a...) nvkm_printk((s), TRACE,   info, f, ##a)
>  #define nvkm_spam(s,f,a...)  nvkm_printk((s),  SPAM,dbg, f, ##a)
> +
> +#define nvkm_error_ratelimited(s,f,a...) nvkm_printk((s), ERROR, 
> err_ratelimited, f, ##a)
>  #endif
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bus/gf100.c 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/bus/gf100.c
> index 53a6651ac225..80b5aaceeaad 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/bus/gf100.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bus/gf100.c
> @@ -35,13 +35,13 @@ gf100_bus_intr(struct nvkm_bus *bus)
> u32 addr = nvkm_rd32(device, 0x009084);
> u32 data = nvkm_rd32(device, 0x009088);
>
> -   nvkm_error(subdev,
> -  "MMIO %s of %08x FAULT at %06x [ %s%s%s]\n",
> -  (addr & 0x0002) ? "write" : "read", data,
> -  (addr & 0x00fc),
> -  (stat & 0x0002) ? "!ENGINE " : "",
> -  (stat & 0x0004) ? "PRIVRING " : "",
> -  (stat & 0x0008) ? "TIMEOUT " : "");
> +   nvkm_error_ratelimited(subdev,
> +  "MMIO %s of %08x FAULT at %06x [ 
> %s%s%s]\n",
> +  (addr & 0x0002) ? "write" : 
> "read", data,
> +  (addr & 0x00fc),
> +  (stat & 0x0002) ? "!ENGINE " : "",
> +  (stat & 0x0004) ? "PRIVRING " : "",
> +  (stat & 0x0008) ? "TIMEOUT " : "");
>
> nvkm_wr32(device, 0x009084, 0x);
> nvkm_wr32(device, 0x001100, (stat & 0x000e));
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bus/nv31.c 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/bus/nv31.c
> index ad8da523bb22..c75e463f3501 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/bus/nv31.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bus/nv31.c
> @@ -45,9 +45,9 @@ nv31_bus_intr(struct nvkm_bus *bus)
> u32 addr = nvkm_rd32(device, 0x009084);
> u32 data = nvkm_rd32(device, 0x009088);
>
> -   nvkm_error(subdev, "MMIO %s of %08x FAULT at %06x\n",
> -  (addr & 0x0002) ? "write" : "read", data,
> -  (addr & 0x00fc));
> +   nvkm_error_ratelimited(subdev, "MMIO %s of %08x FAULT at 
> %06x\n",
> +  (addr & 0x0002) ? "write" : 
> "read", data,
> +  (addr & 0x00fc));
>
> stat &= ~0x0008;
> nvkm_wr32(device, 0x001100, 0x0008);
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bus/nv50.c 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/bus/nv50.c
> index 3a1e45adeedc..2055d0b100d3 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/bus/nv50.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bus/nv50.c
> @@ -60,9 +60,9 @@ nv50_bus_intr(struct nvkm_bus *bus)
> u32 addr = nvkm_rd32(device, 

[PATCH 3/4] drm/i915: allow volatile buffers to use ttm pool allocator

[Robert Beckett]

internal buffers should be shmem backed.
if a volatile buffer is requested, allow ttm to use the pool allocator
to provide volatile pages as backing

Signed-off-by: Robert Beckett 
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 4c25d9b2f138..fdb3a1c18cb6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -309,7 +309,8 @@ static struct ttm_tt *i915_ttm_tt_create(struct 
ttm_buffer_object *bo,
page_flags |= TTM_TT_FLAG_ZERO_ALLOC;
 
caching = i915_ttm_select_tt_caching(obj);
-   if (i915_gem_object_is_shrinkable(obj) && caching == ttm_cached) {
+   if (i915_gem_object_is_shrinkable(obj) && caching == ttm_cached &&
+   !i915_gem_object_is_volatile(obj)) {
page_flags |= TTM_TT_FLAG_EXTERNAL |
  TTM_TT_FLAG_EXTERNAL_MAPPABLE;
i915_tt->is_shmem = true;
-- 
2.25.1

[PATCH 4/4] drm/i915: internal buffers use ttm backend

[Robert Beckett]

refactor internal buffer backend to allocate volatile pages via
ttm pool allocator

Signed-off-by: Robert Beckett 
---
 drivers/gpu/drm/i915/gem/i915_gem_internal.c | 264 ---
 drivers/gpu/drm/i915/gem/i915_gem_internal.h |   5 -
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c  |  12 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.h  |  12 +-
 4 files changed, 125 insertions(+), 168 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_internal.c 
b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
index c698f95af15f..815ec9466cc0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
@@ -4,156 +4,119 @@
  * Copyright © 2014-2016 Intel Corporation
  */
 
-#include 
-#include 
-#include 
-
+#include 
+#include 
+#include "drm/ttm/ttm_bo_api.h"
+#include "gem/i915_gem_internal.h"
+#include "gem/i915_gem_region.h"
+#include "gem/i915_gem_ttm.h"
 #include "i915_drv.h"
-#include "i915_gem.h"
-#include "i915_gem_internal.h"
-#include "i915_gem_object.h"
-#include "i915_scatterlist.h"
-#include "i915_utils.h"
-
-#define QUIET (__GFP_NORETRY | __GFP_NOWARN)
-#define MAYFAIL (__GFP_RETRY_MAYFAIL | __GFP_NOWARN)
-
-static void internal_free_pages(struct sg_table *st)
-{
-   struct scatterlist *sg;
-
-   for (sg = st->sgl; sg; sg = __sg_next(sg)) {
-   if (sg_page(sg))
-   __free_pages(sg_page(sg), get_order(sg->length));
-   }
-
-   sg_free_table(st);
-   kfree(st);
-}
 
-static int i915_gem_object_get_pages_internal(struct drm_i915_gem_object *obj)
+static int i915_internal_get_pages(struct drm_i915_gem_object *obj)
 {
-   struct drm_i915_private *i915 = to_i915(obj->base.dev);
-   struct sg_table *st;
-   struct scatterlist *sg;
-   unsigned int sg_page_sizes;
-   unsigned int npages;
-   int max_order;
-   gfp_t gfp;
-
-   max_order = MAX_ORDER;
-#ifdef CONFIG_SWIOTLB
-   if (is_swiotlb_active(obj->base.dev->dev)) {
-   unsigned int max_segment;
-
-   max_segment = swiotlb_max_segment();
-   if (max_segment) {
-   max_segment = max_t(unsigned int, max_segment,
-   PAGE_SIZE) >> PAGE_SHIFT;
-   max_order = min(max_order, ilog2(max_segment));
-   }
+   struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
+   struct ttm_operation_ctx ctx = {
+   .interruptible = true,
+   .no_wait_gpu = false,
+   };
+   struct ttm_place place = {
+   .fpfn = 0,
+   .lpfn = 0,
+   .mem_type = I915_PL_SYSTEM,
+   .flags = 0,
+   };
+   struct ttm_placement placement = {
+   .num_placement = 1,
+   .placement = ,
+   .num_busy_placement = 0,
+   .busy_placement = NULL,
+   };
+   int ret;
+
+   ret = ttm_bo_validate(bo, , );
+   if (ret) {
+   ret = i915_ttm_err_to_gem(ret);
+   return ret;
}
-#endif
 
-   gfp = GFP_KERNEL | __GFP_HIGHMEM | __GFP_RECLAIMABLE;
-   if (IS_I965GM(i915) || IS_I965G(i915)) {
-   /* 965gm cannot relocate objects above 4GiB. */
-   gfp &= ~__GFP_HIGHMEM;
-   gfp |= __GFP_DMA32;
+   if (bo->ttm && !ttm_tt_is_populated(bo->ttm)) {
+   ret = ttm_tt_populate(bo->bdev, bo->ttm, );
+   if (ret)
+   return ret;
}
 
-create_st:
-   st = kmalloc(sizeof(*st), GFP_KERNEL);
-   if (!st)
-   return -ENOMEM;
+   if (!i915_gem_object_has_pages(obj)) {
+   struct i915_refct_sgt *rsgt =
+   i915_ttm_resource_get_st(obj, bo->resource);
 
-   npages = obj->base.size / PAGE_SIZE;
-   if (sg_alloc_table(st, npages, GFP_KERNEL)) {
-   kfree(st);
-   return -ENOMEM;
-   }
+   if (IS_ERR(rsgt))
+   return PTR_ERR(rsgt);
 
-   sg = st->sgl;
-   st->nents = 0;
-   sg_page_sizes = 0;
-
-   do {
-   int order = min(fls(npages) - 1, max_order);
-   struct page *page;
-
-   do {
-   page = alloc_pages(gfp | (order ? QUIET : MAYFAIL),
-  order);
-   if (page)
-   break;
-   if (!order--)
-   goto err;
-
-   /* Limit subsequent allocations as well */
-   max_order = order;
-   } while (1);
-
-   sg_set_page(sg, page, PAGE_SIZE << order, 0);
-   sg_page_sizes |= PAGE_SIZE << order;
-   st->nents++;
-
-   npages -= 1 << order;
-   if (!npages) {
-   sg_mark_end(sg);
-   break;
-   }
-
-  

[PATCH 2/4] drm/i915: setup ggtt scratch page after memory regions

[Robert Beckett]

reorder scratch page allocation so that memory regions are available
to allocate the buffers

Signed-off-by: Robert Beckett 
---
 drivers/gpu/drm/i915/gt/intel_gt_gmch.c | 20 ++--
 drivers/gpu/drm/i915/gt/intel_gt_gmch.h |  6 ++
 drivers/gpu/drm/i915/i915_driver.c  | 16 ++--
 3 files changed, 34 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_gmch.c 
b/drivers/gpu/drm/i915/gt/intel_gt_gmch.c
index 18e488672d1b..5411df1734ac 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_gmch.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_gmch.c
@@ -440,8 +440,6 @@ static int ggtt_probe_common(struct i915_ggtt *ggtt, u64 
size)
struct drm_i915_private *i915 = ggtt->vm.i915;
struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
phys_addr_t phys_addr;
-   u32 pte_flags;
-   int ret;
 
GEM_WARN_ON(pci_resource_len(pdev, 0) != gen6_gttmmadr_size(i915));
phys_addr = pci_resource_start(pdev, 0) + gen6_gttadr_offset(i915);
@@ -463,6 +461,24 @@ static int ggtt_probe_common(struct i915_ggtt *ggtt, u64 
size)
}
 
kref_init(>vm.resv_ref);
+
+   return 0;
+}
+
+/**
+ * i915_ggtt_setup_scratch_page - setup ggtt scratch page
+ * @i915: i915 device
+ */
+int i915_ggtt_setup_scratch_page(struct drm_i915_private *i915)
+{
+   struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
+   u32 pte_flags;
+   int ret;
+
+   /* gen5- scratch setup currently happens in @intel_gtt_init */
+   if (GRAPHICS_VER(i915) <= 5)
+   return 0;
+
ret = setup_scratch_page(>vm);
if (ret) {
drm_err(>drm, "Scratch setup failed\n");
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_gmch.h 
b/drivers/gpu/drm/i915/gt/intel_gt_gmch.h
index 75ed55c1f30a..c6b79cb78637 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_gmch.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_gmch.h
@@ -15,6 +15,7 @@ int intel_gt_gmch_gen6_probe(struct i915_ggtt *ggtt);
 int intel_gt_gmch_gen8_probe(struct i915_ggtt *ggtt);
 int intel_gt_gmch_gen5_probe(struct i915_ggtt *ggtt);
 int intel_gt_gmch_gen5_enable_hw(struct drm_i915_private *i915);
+int i915_ggtt_setup_scratch_page(struct drm_i915_private *i915);
 
 /* Stubs for non-x86 platforms */
 #else
@@ -41,6 +42,11 @@ static inline int intel_gt_gmch_gen5_enable_hw(struct 
drm_i915_private *i915)
/* No HW should be enabled for this case yet, return fail */
return -ENODEV;
 }
+
+static inline int i915_ggtt_setup_scratch_page(struct drm_i915_private *i915)
+{
+   return 0;
+}
 #endif
 
 #endif /* __INTEL_GT_GMCH_H__ */
diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index 90b0ce5051af..f67476b2f349 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -69,6 +69,7 @@
 #include "gem/i915_gem_mman.h"
 #include "gem/i915_gem_pm.h"
 #include "gt/intel_gt.h"
+#include "gt/intel_gt_gmch.h"
 #include "gt/intel_gt_pm.h"
 #include "gt/intel_rc6.h"
 
@@ -589,12 +590,16 @@ static int i915_driver_hw_probe(struct drm_i915_private 
*dev_priv)
 
ret = intel_gt_tiles_init(dev_priv);
if (ret)
-   goto err_mem_regions;
+   goto err_ggtt;
+
+   ret = i915_ggtt_setup_scratch_page(dev_priv);
+   if (ret)
+   goto err_ggtt;
 
ret = i915_ggtt_enable_hw(dev_priv);
if (ret) {
drm_err(_priv->drm, "failed to enable GGTT\n");
-   goto err_mem_regions;
+   goto err_ggtt;
}
 
pci_set_master(pdev);
@@ -646,11 +651,10 @@ static int i915_driver_hw_probe(struct drm_i915_private 
*dev_priv)
 err_msi:
if (pdev->msi_enabled)
pci_disable_msi(pdev);
-err_mem_regions:
-   intel_memory_regions_driver_release(dev_priv);
 err_ggtt:
i915_ggtt_driver_release(dev_priv);
i915_gem_drain_freed_objects(dev_priv);
+   intel_memory_regions_driver_release(dev_priv);
i915_ggtt_driver_late_release(dev_priv);
 err_perf:
i915_perf_fini(dev_priv);
@@ -896,9 +900,9 @@ int i915_driver_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
intel_modeset_driver_remove_nogem(i915);
 out_cleanup_hw:
i915_driver_hw_remove(i915);
-   intel_memory_regions_driver_release(i915);
i915_ggtt_driver_release(i915);
i915_gem_drain_freed_objects(i915);
+   intel_memory_regions_driver_release(i915);
i915_ggtt_driver_late_release(i915);
 out_cleanup_mmio:
i915_driver_mmio_release(i915);
@@ -955,9 +959,9 @@ static void i915_driver_release(struct drm_device *dev)
 
i915_gem_driver_release(dev_priv);
 
-   intel_memory_regions_driver_release(dev_priv);
i915_ggtt_driver_release(dev_priv);
i915_gem_drain_freed_objects(dev_priv);
+   intel_memory_regions_driver_release(dev_priv);
i915_ggtt_driver_late_release(dev_priv);
 
i915_driver_mmio_release(dev_priv);
-- 
2.25.1

[PATCH 1/4] drm/i915: add gen6 ppgtt dummy creation function

[Robert Beckett]

Internal gem objects will soon just be volatile system memory region
objects.
To enable this, create a separate dummy object creation function
for gen6 ppgtt

Signed-off-by: Robert Beckett 
---
 drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 43 ++--
 1 file changed, 40 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c 
b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
index 1bb766c79dcb..f3b660cfeb7f 100644
--- a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
@@ -372,6 +372,45 @@ static const struct drm_i915_gem_object_ops 
pd_dummy_obj_ops = {
.put_pages = pd_dummy_obj_put_pages,
 };
 
+static struct drm_i915_gem_object *
+i915_gem_object_create_dummy(struct drm_i915_private *i915, phys_addr_t size)
+{
+   static struct lock_class_key lock_class;
+   struct drm_i915_gem_object *obj;
+   unsigned int cache_level;
+
+   GEM_BUG_ON(!size);
+   GEM_BUG_ON(!IS_ALIGNED(size, PAGE_SIZE));
+
+   if (overflows_type(size, obj->base.size))
+   return ERR_PTR(-E2BIG);
+
+   obj = i915_gem_object_alloc();
+   if (!obj)
+   return ERR_PTR(-ENOMEM);
+
+   drm_gem_private_object_init(>drm, >base, size);
+   i915_gem_object_init(obj, _dummy_obj_ops, _class, 0);
+   obj->mem_flags |= I915_BO_FLAG_STRUCT_PAGE;
+
+   /*
+* Mark the object as volatile, such that the pages are marked as
+* dontneed whilst they are still pinned. As soon as they are unpinned
+* they are allowed to be reaped by the shrinker, and the caller is
+* expected to repopulate - the contents of this object are only valid
+* whilst active and pinned.
+*/
+   i915_gem_object_set_volatile(obj);
+
+   obj->read_domains = I915_GEM_DOMAIN_CPU;
+   obj->write_domain = I915_GEM_DOMAIN_CPU;
+
+   cache_level = HAS_LLC(i915) ? I915_CACHE_LLC : I915_CACHE_NONE;
+   i915_gem_object_set_cache_coherency(obj, cache_level);
+
+   return obj;
+}
+
 static struct i915_page_directory *
 gen6_alloc_top_pd(struct gen6_ppgtt *ppgtt)
 {
@@ -383,9 +422,7 @@ gen6_alloc_top_pd(struct gen6_ppgtt *ppgtt)
if (unlikely(!pd))
return ERR_PTR(-ENOMEM);
 
-   pd->pt.base = __i915_gem_object_create_internal(ppgtt->base.vm.gt->i915,
-   _dummy_obj_ops,
-   I915_PDES * SZ_4K);
+   pd->pt.base = i915_gem_object_create_dummy(ppgtt->base.vm.gt->i915, 
I915_PDES * SZ_4K);
if (IS_ERR(pd->pt.base)) {
err = PTR_ERR(pd->pt.base);
pd->pt.base = NULL;
-- 
2.25.1

[PATCH 0/4] ttm for internal

[Robert Beckett]

This series refactors i915's internal buffer backend to use ttm.
It uses ttm's pool allocator to allocate volatile pages in place of the
old code which rolled its own via alloc_pages.
This is continuing progress to align all backends on using ttm.

Robert Beckett (4):
  drm/i915: add gen6 ppgtt dummy creation function
  drm/i915: setup ggtt scratch page after memory regions
  drm/i915: allow volatile buffers to use ttm pool allocator
  drm/i915: internal buffers use ttm backend

 drivers/gpu/drm/i915/gem/i915_gem_internal.c | 264 ---
 drivers/gpu/drm/i915/gem/i915_gem_internal.h |   5 -
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c  |  15 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.h  |  12 +-
 drivers/gpu/drm/i915/gt/gen6_ppgtt.c |  43 ++-
 drivers/gpu/drm/i915/gt/intel_gt_gmch.c  |  20 +-
 drivers/gpu/drm/i915/gt/intel_gt_gmch.h  |   6 +
 drivers/gpu/drm/i915/i915_driver.c   |  16 +-
 8 files changed, 201 insertions(+), 180 deletions(-)

-- 
2.25.1

Re: [PATCH] drm/amdgpu: fix drm-next merge fallout

[Dave Airlie]

On Tue, 3 May 2022 at 23:03, Alex Deucher  wrote:
>
> On Tue, May 3, 2022 at 2:36 AM Christian König
>  wrote:
> >
> > That hunk somehow got missing while solving the conflict between the TTM
> > and AMDGPU changes for drm-next.
> >
> > Signed-off-by: Christian König 
>
> Acked-by: Alex Deucher 
>

I'll pick this directly into drm-next.

Dave.

> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c | 6 +-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c
> > index 7761a3ea172e..88de9f0d4728 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c
> > @@ -631,9 +631,13 @@ static void amdgpu_vm_pt_free(struct amdgpu_vm_bo_base 
> > *entry)
> > if (!entry->bo)
> > return;
> > shadow = amdgpu_bo_shadowed(entry->bo);
> > +   if (shadow) {
> > +   ttm_bo_set_bulk_move(>tbo, NULL);
> > +   amdgpu_bo_unref();
> > +   }
> > +   ttm_bo_set_bulk_move(>bo->tbo, NULL);
> > entry->bo->vm_bo = NULL;
> > list_del(>vm_status);
> > -   amdgpu_bo_unref();
> > amdgpu_bo_unref(>bo);
> >  }
> >
> > --
> > 2.25.1
> >

Re: [PATCH] dt-bindings: Drop redundant 'maxItems/minItems' in if/then schemas

[Marc Kleine-Budde]

On 03.05.2022 11:27:38, Rob Herring wrote:
> Another round of removing redundant minItems/maxItems when 'items' list is
> specified. This time it is in if/then schemas as the meta-schema was
> failing to check this case.
> 
> If a property has an 'items' list, then a 'minItems' or 'maxItems' with the
> same size as the list is redundant and can be dropped. Note that is DT
> schema specific behavior and not standard json-schema behavior. The tooling
> will fixup the final schema adding any unspecified minItems/maxItems.

>  .../bindings/net/can/bosch,c_can.yaml |  3 ---

For net/can:

Acked-by: Marc Kleine-Budde 

regards,
Marc

-- 
Pengutronix e.K. | Marc Kleine-Budde   |
Embedded Linux   | https://www.pengutronix.de  |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917- |


signature.asc
Description: PGP signature

Re: [PATCH v5 1/4] dt-bindings: display: mediatek: dsi: Convert dsi_dtbinding to .yaml

[Rob Herring]

On Thu, Apr 28, 2022 at 09:37:50PM +0800, Rex-BC Chen wrote:
> From: Xinlei Lee 
> 
> Convert mediatek,dsi.txt to mediatek,dsi.yaml format
> 
> Signed-off-by: Xinlei Lee 
> Signed-off-by: Rex-BC Chen 
> ---
>  .../display/mediatek/mediatek,dsi.txt |  62 -
>  .../display/mediatek/mediatek,dsi.yaml| 122 ++
>  2 files changed, 122 insertions(+), 62 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt 
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> deleted file mode 100644
> index 36b01458f45c..
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> +++ /dev/null
> @@ -1,62 +0,0 @@
> -Mediatek DSI Device
> -===
> -
> -The Mediatek DSI function block is a sink of the display subsystem and can
> -drive up to 4-lane MIPI DSI output. Two DSIs can be synchronized for dual-
> -channel output.
> -
> -Required properties:
> -- compatible: "mediatek,-dsi"
> -- the supported chips are mt2701, mt7623, mt8167, mt8173 and mt8183.
> -- reg: Physical base address and length of the controller's registers
> -- interrupts: The interrupt signal from the function block.
> -- clocks: device clocks
> -  See Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
> -- clock-names: must contain "engine", "digital", and "hs"
> -- phys: phandle link to the MIPI D-PHY controller.
> -- phy-names: must contain "dphy"
> -- port: Output port node with endpoint definitions as described in
> -  Documentation/devicetree/bindings/graph.txt. This port should be connected
> -  to the input port of an attached DSI panel or DSI-to-eDP encoder chip.
> -
> -Optional properties:
> -- resets: list of phandle + reset specifier pair, as described in [1].
> -
> -[1] Documentation/devicetree/bindings/reset/reset.txt
> -
> -MIPI TX Configuration Module
> -
> -
> -See phy/mediatek,dsi-phy.yaml
> -
> -Example:
> -
> -mipi_tx0: mipi-dphy@10215000 {
> - compatible = "mediatek,mt8173-mipi-tx";
> - reg = <0 0x10215000 0 0x1000>;
> - clocks = <>;
> - clock-output-names = "mipi_tx0_pll";
> - #clock-cells = <0>;
> - #phy-cells = <0>;
> - drive-strength-microamp = <4600>;
> - nvmem-cells= <_tx_calibration>;
> - nvmem-cell-names = "calibration-data";
> -};
> -
> -dsi0: dsi@1401b000 {
> - compatible = "mediatek,mt8173-dsi";
> - reg = <0 0x1401b000 0 0x1000>;
> - interrupts = ;
> - clocks = < MM_DSI0_ENGINE>, < MM_DSI0_DIGITAL>,
> -  <_tx0>;
> - clock-names = "engine", "digital", "hs";
> - resets = < MT8173_MMSYS_SW0_RST_B_DISP_DSI0>;
> - phys = <_tx0>;
> - phy-names = "dphy";
> -
> - port {
> - dsi0_out: endpoint {
> - remote-endpoint = <_in>;
> - };
> - };
> -};
> diff --git 
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml 
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml
> new file mode 100644
> index ..2ca9229ef69e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml
> @@ -0,0 +1,122 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/mediatek/mediatek,dsi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek DSI Controller Device Tree Bindings
> +
> +maintainers:
> +  - Chun-Kuang Hu 
> +  - Philipp Zabel 
> +  - Jitao Shi 
> +  - Xinlei Lee 
> +
> +description: |
> +  The MediaTek DSI function block is a sink of the display subsystem and can
> +  drive up to 4-lane MIPI DSI output. Two DSIs can be synchronized for dual-
> +  channel output.
> +
> +allOf:
> +  - $ref: /schemas/display/dsi-controller.yaml#
> +
> +properties:
> +  compatible:
> +enum:
> +  - mediatek,mt2701-dsi
> +  - mediatek,mt7623-dsi
> +  - mediatek,mt8167-dsi
> +  - mediatek,mt8173-dsi
> +  - mediatek,mt8183-dsi
> +
> +  reg:
> +maxItems: 1
> +
> +  interrupts:
> +maxItems: 1
> +
> +  power-domains:
> +maxItems: 1
> +
> +  clocks:
> +items:
> +  - description: Engine Clock
> +  - description: Digital Clock
> +  - description: HS Clock
> +
> +  clock-names:
> +items:
> +  - const: engine
> +  - const: digital
> +  - const: hs
> +
> +  resets:
> +maxItems: 1
> +
> +  phys:
> +maxItems: 1
> +
> +  phy-names:
> +items:
> +  - const: dphy
> +
> +  port:
> +$ref: /schemas/graph.yaml#/properties/port
> +description:
> +  Output port node. This port should be connected to the input
> +  port of an attached DSI panel or DSI-to-eDP encoder chip.
> +
> +

1 blank line

> +  

Re: [PATCH] fbdev: Use helper to get fb_info in all file operations

[Sam Ravnborg]

Hi Javier,

On Tue, May 03, 2022 at 06:46:16PM +0200, Javier Martinez Canillas wrote:
> A reference to the framebuffer device struct fb_info is stored in the file
> private data, but this reference could no longer be valid and must not be
> accessed directly. Instead, the file_fb_info() accessor function must be
> used since it does sanity checking to make sure that the fb_info is valid.
> 
> This can happen for example if the registered framebuffer device is for a
> driver that just uses a framebuffer provided by the system firmware. In
> that case, the fbdev core would unregister the framebuffer device when a
> real video driver is probed and ask to remove conflicting framebuffers.
> 
> Most fbdev file operations already use the helper to get the fb_info but
> get_fb_unmapped_area() and fb_deferred_io_fsync() don't. Fix those two.
> 
> Since fb_deferred_io_fsync() is not in fbmem.o, the helper has to be
> exported. Rename it and add a fb_ prefix to denote that is public now.
> 
> Reported-by: Junxiao Chang 
> Signed-off-by: Javier Martinez Canillas 
> ---
> 
>  drivers/video/fbdev/core/fb_defio.c |  5 -
>  drivers/video/fbdev/core/fbmem.c| 24 +++-
>  include/linux/fb.h  |  1 +
>  3 files changed, 20 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/video/fbdev/core/fb_defio.c 
> b/drivers/video/fbdev/core/fb_defio.c
> index 842c66b3e33d..ac1c88b3fbb5 100644
> --- a/drivers/video/fbdev/core/fb_defio.c
> +++ b/drivers/video/fbdev/core/fb_defio.c
> @@ -68,12 +68,15 @@ static vm_fault_t fb_deferred_io_fault(struct vm_fault 
> *vmf)
>  
>  int fb_deferred_io_fsync(struct file *file, loff_t start, loff_t end, int 
> datasync)
>  {
> - struct fb_info *info = file->private_data;
> + struct fb_info *info = fb_file_fb_info(file->private_data);
This looks wrong. I assume you wanted to write:
> + struct fb_info *info = fb_file_fb_info(file);


Sam

Re: [PATCH v3 2/3] drm/fb-helper: Rename preferred_bpp drm_fbdev_generic_setup() parameter

[Jernej Škrabec]

Dne torek, 03. maj 2022 ob 09:15:39 CEST je Javier Martinez Canillas 
napisal(a):
> By default the bits per pixel for the emulated framebuffer device is set
> to dev->mode_config.preferred_depth, but some devices need another value.
> 
> Since this second parameter is only used by a few drivers, and to allow
> drivers to use it for passing other configurations when registering the
> fbdev, rename @preferred_bpp to @options and make it a multi-field param.
> 
> The DRM_FB_OPTION() and DRM_FB_GET_OPTION() macros are provided to drivers
> for computing options bitfield values and getting the values respectively
> 
> For now, only the DRM_FB_BPP option exists but other options can be added.
> 
> Suggested-by: Thomas Zimmermann 
> Signed-off-by: Javier Martinez Canillas 
> Reviewed-by: Thomas Zimmermann 
> Reviewed-by: Laurent Pinchart 
> ---
> 
> Changes in v3:
> - Drop the preferred_bpp local variable (Laurent Pinchart).
> - Add a const qualifier to options parameter (Laurent Pinchart).
> 
> Changes in v2:
> - Rename DRM_FB_SET_OPTION() to DRM_FB_OPTION() and make more clear in
>   the kernel-doc what this macro does (Laurent Pinchart).
> - Fix some kernel-doc issues I didn't notice in v1.
> - Add Reviewed-by tags from Thomas and Laurent.
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |  6 +++--
>  drivers/gpu/drm/arm/hdlcd_drv.c   |  2 +-
>  drivers/gpu/drm/arm/malidp_drv.c  |  2 +-
>  drivers/gpu/drm/aspeed/aspeed_gfx_drv.c   |  2 +-
>  drivers/gpu/drm/ast/ast_drv.c |  2 +-
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c  |  2 +-
>  drivers/gpu/drm/drm_drv.c |  2 +-
>  drivers/gpu/drm/drm_fb_helper.c   | 26 ---
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c |  2 +-
>  .../gpu/drm/hisilicon/kirin/kirin_drm_drv.c   |  2 +-
>  drivers/gpu/drm/imx/dcss/dcss-kms.c   |  2 +-
>  drivers/gpu/drm/imx/imx-drm-core.c|  2 +-
>  drivers/gpu/drm/ingenic/ingenic-drm-drv.c |  2 +-
>  drivers/gpu/drm/mcde/mcde_drv.c   |  2 +-
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c|  2 +-
>  drivers/gpu/drm/meson/meson_drv.c |  2 +-
>  drivers/gpu/drm/mxsfb/mxsfb_drv.c |  2 +-
>  drivers/gpu/drm/pl111/pl111_drv.c |  2 +-
>  drivers/gpu/drm/qxl/qxl_drv.c |  2 +-
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c |  2 +-
>  drivers/gpu/drm/sti/sti_drv.c |  2 +-
>  drivers/gpu/drm/stm/drv.c |  2 +-
>  drivers/gpu/drm/sun4i/sun4i_drv.c |  2 +-

For sun4i:
Acked-by: Jernej Skrabec 

Best regard,
Jernej

>  drivers/gpu/drm/tidss/tidss_drv.c |  2 +-
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c   |  2 +-
>  drivers/gpu/drm/tiny/arcpgu.c |  2 +-
>  drivers/gpu/drm/tiny/bochs.c  |  2 +-
>  drivers/gpu/drm/tve200/tve200_drv.c   |  2 +-
>  drivers/gpu/drm/vboxvideo/vbox_drv.c  |  2 +-
>  drivers/gpu/drm/vc4/vc4_drv.c |  2 +-
>  drivers/gpu/drm/virtio/virtgpu_drv.c  |  2 +-
>  drivers/gpu/drm/xlnx/zynqmp_dpsub.c   |  2 +-
>  include/drm/drm_fb_helper.h   | 14 +-
>  33 files changed, 64 insertions(+), 42 deletions(-)

[PATCH] fbdev: Use helper to get fb_info in all file operations

[Javier Martinez Canillas]

A reference to the framebuffer device struct fb_info is stored in the file
private data, but this reference could no longer be valid and must not be
accessed directly. Instead, the file_fb_info() accessor function must be
used since it does sanity checking to make sure that the fb_info is valid.

This can happen for example if the registered framebuffer device is for a
driver that just uses a framebuffer provided by the system firmware. In
that case, the fbdev core would unregister the framebuffer device when a
real video driver is probed and ask to remove conflicting framebuffers.

Most fbdev file operations already use the helper to get the fb_info but
get_fb_unmapped_area() and fb_deferred_io_fsync() don't. Fix those two.

Since fb_deferred_io_fsync() is not in fbmem.o, the helper has to be
exported. Rename it and add a fb_ prefix to denote that is public now.

Reported-by: Junxiao Chang 
Signed-off-by: Javier Martinez Canillas 
---

 drivers/video/fbdev/core/fb_defio.c |  5 -
 drivers/video/fbdev/core/fbmem.c| 24 +++-
 include/linux/fb.h  |  1 +
 3 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/drivers/video/fbdev/core/fb_defio.c 
b/drivers/video/fbdev/core/fb_defio.c
index 842c66b3e33d..ac1c88b3fbb5 100644
--- a/drivers/video/fbdev/core/fb_defio.c
+++ b/drivers/video/fbdev/core/fb_defio.c
@@ -68,12 +68,15 @@ static vm_fault_t fb_deferred_io_fault(struct vm_fault *vmf)
 
 int fb_deferred_io_fsync(struct file *file, loff_t start, loff_t end, int 
datasync)
 {
-   struct fb_info *info = file->private_data;
+   struct fb_info *info = fb_file_fb_info(file->private_data);
struct inode *inode = file_inode(file);
int err = file_write_and_wait_range(file, start, end);
if (err)
return err;
 
+   if (!info)
+   return -ENODEV;
+
/* Skip if deferred io is compiled-in but disabled on this fbdev */
if (!info->fbdefio)
return 0;
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 97eb0dee411c..f924fda89dd5 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -745,7 +745,7 @@ static const struct seq_operations __maybe_unused 
proc_fb_seq_ops = {
  * So look up the fb_info using the inode minor number,
  * and just verify it against the reference we have.
  */
-static struct fb_info *file_fb_info(struct file *file)
+struct fb_info *fb_file_fb_info(struct file *file)
 {
struct inode *inode = file_inode(file);
int fbidx = iminor(inode);
@@ -755,12 +755,13 @@ static struct fb_info *file_fb_info(struct file *file)
info = NULL;
return info;
 }
+EXPORT_SYMBOL(fb_file_fb_info);
 
 static ssize_t
 fb_read(struct file *file, char __user *buf, size_t count, loff_t *ppos)
 {
unsigned long p = *ppos;
-   struct fb_info *info = file_fb_info(file);
+   struct fb_info *info = fb_file_fb_info(file);
u8 *buffer, *dst;
u8 __iomem *src;
int c, cnt = 0, err = 0;
@@ -825,7 +826,7 @@ static ssize_t
 fb_write(struct file *file, const char __user *buf, size_t count, loff_t *ppos)
 {
unsigned long p = *ppos;
-   struct fb_info *info = file_fb_info(file);
+   struct fb_info *info = fb_file_fb_info(file);
u8 *buffer, *src;
u8 __iomem *dst;
int c, cnt = 0, err = 0;
@@ -1181,7 +1182,7 @@ static long do_fb_ioctl(struct fb_info *info, unsigned 
int cmd,
 
 static long fb_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
 {
-   struct fb_info *info = file_fb_info(file);
+   struct fb_info *info = fb_file_fb_info(file);
 
if (!info)
return -ENODEV;
@@ -1293,7 +1294,7 @@ static int fb_get_fscreeninfo(struct fb_info *info, 
unsigned int cmd,
 static long fb_compat_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
 {
-   struct fb_info *info = file_fb_info(file);
+   struct fb_info *info = fb_file_fb_info(file);
const struct fb_ops *fb;
long ret = -ENOIOCTLCMD;
 
@@ -1333,7 +1334,7 @@ static long fb_compat_ioctl(struct file *file, unsigned 
int cmd,
 static int
 fb_mmap(struct file *file, struct vm_area_struct * vma)
 {
-   struct fb_info *info = file_fb_info(file);
+   struct fb_info *info = fb_file_fb_info(file);
int (*fb_mmap_fn)(struct fb_info *info, struct vm_area_struct *vma);
unsigned long mmio_pgoff;
unsigned long start;
@@ -1434,7 +1435,7 @@ fb_release(struct inode *inode, struct file *file)
 __acquires(>lock)
 __releases(>lock)
 {
-   struct fb_info * const info = file_fb_info(file);
+   struct fb_info * const info = fb_file_fb_info(file);
 
if (!info)
return -ENODEV;
@@ -1453,8 +1454,13 @@ unsigned long get_fb_unmapped_area(struct file *filp,
   unsigned long addr, unsigned long len,
   

Re: [PATCH] dt-bindings: Drop redundant 'maxItems/minItems' in if/then schemas

[Mark Brown]

On Tue, May 03, 2022 at 11:27:38AM -0500, Rob Herring wrote:
> Another round of removing redundant minItems/maxItems when 'items' list is
> specified. This time it is in if/then schemas as the meta-schema was
> failing to check this case.

Acked-by: Mark Brown 


signature.asc
Description: PGP signature

[PATCH] dt-bindings: Drop redundant 'maxItems/minItems' in if/then schemas

[Rob Herring]

Another round of removing redundant minItems/maxItems when 'items' list is
specified. This time it is in if/then schemas as the meta-schema was
failing to check this case.

If a property has an 'items' list, then a 'minItems' or 'maxItems' with the
same size as the list is redundant and can be dropped. Note that is DT
schema specific behavior and not standard json-schema behavior. The tooling
will fixup the final schema adding any unspecified minItems/maxItems.

Cc: Abel Vesa 
Cc: Stephen Boyd 
Cc: Krzysztof Kozlowski 
Cc: Laurent Pinchart 
Cc: Kieran Bingham 
Cc: Jonathan Cameron 
Cc: Lars-Peter Clausen 
Cc: Ulf Hansson 
Cc: Thierry Reding 
Cc: Jonathan Hunter 
Cc: Miquel Raynal 
Cc: Richard Weinberger 
Cc: Vignesh Raghavendra 
Cc: Wolfgang Grandegger 
Cc: Marc Kleine-Budde 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: Paolo Abeni 
Cc: Kishon Vijay Abraham I 
Cc: Vinod Koul 
Cc: Alessandro Zummo 
Cc: Alexandre Belloni 
Cc: Chen-Yu Tsai 
Cc: Greg Kroah-Hartman 
Cc: Mark Brown 
Cc: "Rafael J. Wysocki" 
Cc: Daniel Lezcano 
Cc: Zhang Rui 
Cc: "Niklas Söderlund" 
Cc: Anson Huang 
Cc: Fabrice Gasnier 
Cc: Han Xu 
Cc: Dario Binacchi 
Cc: Florian Fainelli 
Cc: Maxime Ripard 
Cc: Peter Ujfalusi 
Cc: linux-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-...@lists.infradead.org
Cc: linux-...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: linux-...@lists.infradead.org
Cc: linux-...@vger.kernel.org
Cc: linux-ser...@vger.kernel.org
Cc: alsa-de...@alsa-project.org
Cc: linux...@vger.kernel.org
Signed-off-by: Rob Herring 
---
 .../bindings/clock/imx8m-clock.yaml   |  4 
 .../bindings/display/bridge/renesas,lvds.yaml |  4 
 .../bindings/display/renesas,du.yaml  | 23 ---
 .../bindings/iio/adc/st,stm32-adc.yaml|  2 --
 .../bindings/mmc/nvidia,tegra20-sdhci.yaml|  7 +-
 .../devicetree/bindings/mtd/gpmi-nand.yaml|  2 --
 .../bindings/net/can/bosch,c_can.yaml |  3 ---
 .../bindings/phy/brcm,sata-phy.yaml   | 10 
 .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 10 
 .../bindings/serial/samsung_uart.yaml |  4 
 .../sound/allwinner,sun4i-a10-i2s.yaml|  1 -
 .../bindings/sound/ti,j721e-cpb-audio.yaml|  2 --
 .../bindings/thermal/rcar-gen3-thermal.yaml   |  1 -
 13 files changed, 5 insertions(+), 68 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml 
b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml
index 625f573a7b90..458c7645ee68 100644
--- a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml
@@ -55,8 +55,6 @@ allOf:
 then:
   properties:
 clocks:
-  minItems: 7
-  maxItems: 7
   items:
 - description: 32k osc
 - description: 25m osc
@@ -66,8 +64,6 @@ allOf:
 - description: ext3 clock input
 - description: ext4 clock input
 clock-names:
-  minItems: 7
-  maxItems: 7
   items:
 - const: ckil
 - const: osc_25m
diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml 
b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml
index a51baf8a4c76..bb9dbfb9beaf 100644
--- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml
@@ -95,7 +95,6 @@ then:
   properties:
 clocks:
   minItems: 1
-  maxItems: 4
   items:
 - description: Functional clock
 - description: EXTAL input clock
@@ -104,7 +103,6 @@ then:
 
 clock-names:
   minItems: 1
-  maxItems: 4
   items:
 - const: fck
 # The LVDS encoder can use the EXTAL or DU_DOTCLKINx clocks.
@@ -128,12 +126,10 @@ then:
 else:
   properties:
 clocks:
-  maxItems: 1
   items:
 - description: Functional clock
 
 clock-names:
-  maxItems: 1
   items:
 - const: fck
 
diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml 
b/Documentation/devicetree/bindings/display/renesas,du.yaml
index 56cedcd6d576..b3e588022082 100644
--- a/Documentation/devicetree/bindings/display/renesas,du.yaml
+++ b/Documentation/devicetree/bindings/display/renesas,du.yaml
@@ -109,7 +109,6 @@ allOf:
   properties:
 clocks:
   minItems: 1
-  maxItems: 3
   items:
 - description: Functional clock
 - description: DU_DOTCLKIN0 input clock
@@ -117,7 +116,6 @@ allOf:
 
 clock-names:
   minItems: 1
-  maxItems: 3
   items:
 - const: du.0
 - pattern: '^dclkin\.[01]$'
@@ -159,7 +157,6 @@ allOf:
   properties:
 clocks:
   minItems: 2
-  maxItems: 4
   items:
 - description: Functional clock for DU0

[PATCH v3] drm/msm/dp: fix event thread stuck in wait_event after kthread_stop()

[Kuogee Hsieh]

Event thread supposed to exit from its while loop after kthread_stop().
However there may has possibility that event thread is pending in the
middle of wait_event due to condition checking never become true.
To make sure event thread exit its loop after kthread_stop(), this
patch OR kthread_should_stop() into wait_event's condition checking
so that event thread will exit its loop after kernal_stop().

Changes in v2:
--  correct spelling error at commit title

Changes in v3:
-- remove unnecessary parenthesis
-- while(1) to replace while (!kthread_should_stop())

Reported-by: Dmitry Baryshkov 
Fixes: 570d3e5d28db ("drm/msm/dp: stop event kernel thread when DP unbind")
Signed-off-by: Kuogee Hsieh 
---
 drivers/gpu/drm/msm/dp/dp_display.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
b/drivers/gpu/drm/msm/dp/dp_display.c
index c388323..da5c03a 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1103,15 +1103,20 @@ static int hpd_event_thread(void *data)
 
dp_priv = (struct dp_display_private *)data;
 
-   while (!kthread_should_stop()) {
+   while (1) {
if (timeout_mode) {
wait_event_timeout(dp_priv->event_q,
-   (dp_priv->event_pndx == dp_priv->event_gndx),
-   EVENT_TIMEOUT);
+   (dp_priv->event_pndx == dp_priv->event_gndx) ||
+   kthread_should_stop(), EVENT_TIMEOUT);
} else {
wait_event_interruptible(dp_priv->event_q,
-   (dp_priv->event_pndx != dp_priv->event_gndx));
+   (dp_priv->event_pndx != dp_priv->event_gndx) ||
+   kthread_should_stop());
}
+
+   if (kthread_should_stop())
+   break;
+
spin_lock_irqsave(_priv->event_lock, flag);
todo = _priv->event_list[dp_priv->event_gndx];
if (todo->delay) {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2] drm/msm/dp: fix event thread stuck in wait_event after kthread_stop()

[Kuogee Hsieh]

On 5/2/2022 6:13 PM, Stephen Boyd wrote:

Quoting Kuogee Hsieh (2022-05-02 16:04:28)

Event thread supposed to exit from its while loop after kthread_stop().
However there may has possibility that event thread is pending in the
middle of wait_event due to condition checking never become true.
To make sure event thread exit its loop after kthread_stop(), this
patch OR kthread_should_stop() into wait_event's condition checking
so that event thread will exit its loop after kernal_stop().

Changes in v2:
--  correct spelling error at commit title

Reported-by: Dmitry Baryshkov 
Fixes: 570d3e5d28db ("drm/msm/dp: stop event kernel thread when DP unbind")
Signed-off-by: Kuogee Hsieh 
---
  drivers/gpu/drm/msm/dp/dp_display.c | 11 ---
  1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
b/drivers/gpu/drm/msm/dp/dp_display.c
index c388323..5200a58 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1106,12 +1106,17 @@ static int hpd_event_thread(void *data)
 while (!kthread_should_stop()) {
 if (timeout_mode) {
 wait_event_timeout(dp_priv->event_q,
-   (dp_priv->event_pndx == dp_priv->event_gndx),
-   EVENT_TIMEOUT);
+   ((dp_priv->event_pndx == dp_priv->event_gndx) ||

Why the parenthesis (before and after)?


+   kthread_should_stop()), EVENT_TIMEOUT);
 } else {
 wait_event_interruptible(dp_priv->event_q,
-   (dp_priv->event_pndx != dp_priv->event_gndx));
+   ((dp_priv->event_pndx != dp_priv->event_gndx) ||

Why the parenthesis (before and after)?


+   kthread_should_stop()));
 }
+
+   if(kthread_should_stop())

Missing space after if


+   break;

Is it possible to move the wait_event to the end of the loop and always
run the loop initially? That way we don't have to check for
kthread_should_stop() again.


no, since we have to make sure q is not empty so that we can proceed to 
service events.


bu ti thin we can use while (1) instead of while 
(!kthread_should_stop()) since we have add kthread_should_stop() into 
wait_event condition checking.

Re: [PATCH v2] fbdev: Make fb_release() return -ENODEV if fbdev was unregistered

[Javier Martinez Canillas]

On 5/2/22 15:50, Javier Martinez Canillas wrote:
> A reference to the framebuffer device struct fb_info is stored in the file
> private data, but this reference could no longer be valid and must not be
> accessed directly. Instead, the file_fb_info() accessor function must be
> used since it does sanity checking to make sure that the fb_info is valid.
> 
> This can happen for example if the registered framebuffer device is for a
> driver that just uses a framebuffer provided by the system firmware. In
> that case, the fbdev core would unregister the framebuffer device when a
> real video driver is probed and ask to remove conflicting framebuffers.
> 
> The bug has been present for a long time but commit 27599aacbaef ("fbdev:
> Hot-unplug firmware fb devices on forced removal") unmasked it since the
> fbdev core started unregistering the framebuffers' devices associated.
> 
> Fixes: 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced 
> removal")
> Reported-by: Maxime Ripard 
> Reported-by: Junxiao Chang 
> Signed-off-by: Javier Martinez Canillas 
> Reviewed-by: Thomas Zimmermann 
> ---
Applied to drm-misc (drm-misc-fixes).

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH v4] drm/hyperv: Add error message for fb size greater than allocated

[Wei Liu]

On Tue, May 03, 2022 at 07:50:16AM -0700, Saurabh Singh Sengar wrote:
> On Tue, Apr 12, 2022 at 05:06:07AM +, Dexuan Cui wrote:
> > > From: Saurabh Sengar 
> > > Sent: Monday, April 11, 2022 9:29 PM
> > >  ...
> > > Add error message when the size of requested framebuffer is more than
> > > the allocated size by vmbus mmio region for framebuffer
> > 
> > The line lacks a period, but I guess the maintainer may help fix it for you 
> > :-)
> >  
> > > Signed-off-by: Saurabh Sengar 
> > 
> > Reviewed-by: Dexuan Cui 
> 
> Can this be queued for next ? please let me know in case any clarification 
> required.

Applied to hyperv-next. Thanks.

Re: [Intel-gfx] [PATCH 00/11] i915: Introduce Ponte Vecchio

[Tvrtko Ursulin]

On 03/05/2022 15:56, Matt Roper wrote:

On Tue, May 03, 2022 at 09:21:04AM +0100, Tvrtko Ursulin wrote:


On 02/05/2022 17:34, Matt Roper wrote:

Ponte Vecchio (PVC) is a new GPU based on the Xe_HPC architecture.  As a
compute-focused platform, PVC has compute engines and enhanced copy
engines, but no render engine (there is no geometry pipeline) and no
display.

This is just a handful of early enablement patches, including some
initial support for the new copy engines (although we're not yet adding
those to the platform's engine list or exposing them to userspace just
yet).


IMO lets hold off merging this until next week if that sounds acceptable?
This week I need to do a final pull for final bits of DG2 and I would like
to keep it as small as possible.


I was wondering if we should try to apply patch #1 quickly, just to get
the IS_PONTEVECCHIO definition into the tree early and minimize the
cross-tree merge hassles down the road?  Although I guess PVC might not
be as big a problem as some platforms since no display means that we
won't have a huge split of patches between -next and -gt-next that both
need the basic defines present.


Okay, that sounds fair.

Regards,

Tvrtko




Matt



Regards,

Tvrtko



Ayaz A Siddiqui (1):
drm/i915/pvc: Define MOCS table for PVC

John Harrison (1):
drm/i915/pvc: Reduce stack usage in reset selftest with extra blitter
  engine

Lucas De Marchi (2):
drm/i915/pvc: skip all copy engines from aux table invalidate
drm/i915/pvc: read fuses for link copy engines

Matt Roper (5):
drm/i915/pvc: Add forcewake support
drm/i915/pvc: Read correct RP_STATE_CAP register
drm/i915/pvc: Engines definitions for new copy engines
drm/i915/pvc: Interrupt support for new copy engines
drm/i915/pvc: Reset support for new copy engines

Stuart Summers (2):
drm/i915/pvc: add initial Ponte Vecchio definitions
drm/i915/pvc: Remove additional 3D flags from PIPE_CONTROL

   drivers/gpu/drm/i915/gt/gen8_engine_cs.c  |  20 ++-
   drivers/gpu/drm/i915/gt/intel_engine_cs.c |  92 +++
   drivers/gpu/drm/i915/gt/intel_engine_types.h  |  10 +-
   drivers/gpu/drm/i915/gt/intel_gpu_commands.h  |  12 +-
   drivers/gpu/drm/i915/gt/intel_gt_irq.c|  16 ++
   drivers/gpu/drm/i915/gt/intel_gt_regs.h   |  56 ---
   drivers/gpu/drm/i915/gt/intel_gt_types.h  |   1 +
   drivers/gpu/drm/i915/gt/intel_mocs.c  |  24 ++-
   drivers/gpu/drm/i915/gt/intel_rps.c   |   4 +-
   drivers/gpu/drm/i915/gt/intel_workarounds.c   |  13 +-
   drivers/gpu/drm/i915/gt/selftest_hangcheck.c  |   9 +-
   drivers/gpu/drm/i915/gvt/cmd_parser.c |   2 +-
   drivers/gpu/drm/i915/i915_drv.h   |   6 +
   drivers/gpu/drm/i915/i915_pci.c   |  23 +++
   drivers/gpu/drm/i915/i915_reg.h   |   9 ++
   drivers/gpu/drm/i915/intel_device_info.c  |   1 +
   drivers/gpu/drm/i915/intel_device_info.h  |   5 +-
   drivers/gpu/drm/i915/intel_uncore.c   | 150 +-
   drivers/gpu/drm/i915/selftests/intel_uncore.c |   2 +
   19 files changed, 417 insertions(+), 38 deletions(-)

Re: [Intel-gfx] [PATCH 00/11] i915: Introduce Ponte Vecchio

[Matt Roper]

On Tue, May 03, 2022 at 09:21:04AM +0100, Tvrtko Ursulin wrote:
> 
> On 02/05/2022 17:34, Matt Roper wrote:
> > Ponte Vecchio (PVC) is a new GPU based on the Xe_HPC architecture.  As a
> > compute-focused platform, PVC has compute engines and enhanced copy
> > engines, but no render engine (there is no geometry pipeline) and no
> > display.
> > 
> > This is just a handful of early enablement patches, including some
> > initial support for the new copy engines (although we're not yet adding
> > those to the platform's engine list or exposing them to userspace just
> > yet).
> 
> IMO lets hold off merging this until next week if that sounds acceptable?
> This week I need to do a final pull for final bits of DG2 and I would like
> to keep it as small as possible.

I was wondering if we should try to apply patch #1 quickly, just to get
the IS_PONTEVECCHIO definition into the tree early and minimize the
cross-tree merge hassles down the road?  Although I guess PVC might not
be as big a problem as some platforms since no display means that we
won't have a huge split of patches between -next and -gt-next that both
need the basic defines present.


Matt

> 
> Regards,
> 
> Tvrtko
> 
> > 
> > Ayaz A Siddiqui (1):
> >drm/i915/pvc: Define MOCS table for PVC
> > 
> > John Harrison (1):
> >drm/i915/pvc: Reduce stack usage in reset selftest with extra blitter
> >  engine
> > 
> > Lucas De Marchi (2):
> >drm/i915/pvc: skip all copy engines from aux table invalidate
> >drm/i915/pvc: read fuses for link copy engines
> > 
> > Matt Roper (5):
> >drm/i915/pvc: Add forcewake support
> >drm/i915/pvc: Read correct RP_STATE_CAP register
> >drm/i915/pvc: Engines definitions for new copy engines
> >drm/i915/pvc: Interrupt support for new copy engines
> >drm/i915/pvc: Reset support for new copy engines
> > 
> > Stuart Summers (2):
> >drm/i915/pvc: add initial Ponte Vecchio definitions
> >drm/i915/pvc: Remove additional 3D flags from PIPE_CONTROL
> > 
> >   drivers/gpu/drm/i915/gt/gen8_engine_cs.c  |  20 ++-
> >   drivers/gpu/drm/i915/gt/intel_engine_cs.c |  92 +++
> >   drivers/gpu/drm/i915/gt/intel_engine_types.h  |  10 +-
> >   drivers/gpu/drm/i915/gt/intel_gpu_commands.h  |  12 +-
> >   drivers/gpu/drm/i915/gt/intel_gt_irq.c|  16 ++
> >   drivers/gpu/drm/i915/gt/intel_gt_regs.h   |  56 ---
> >   drivers/gpu/drm/i915/gt/intel_gt_types.h  |   1 +
> >   drivers/gpu/drm/i915/gt/intel_mocs.c  |  24 ++-
> >   drivers/gpu/drm/i915/gt/intel_rps.c   |   4 +-
> >   drivers/gpu/drm/i915/gt/intel_workarounds.c   |  13 +-
> >   drivers/gpu/drm/i915/gt/selftest_hangcheck.c  |   9 +-
> >   drivers/gpu/drm/i915/gvt/cmd_parser.c |   2 +-
> >   drivers/gpu/drm/i915/i915_drv.h   |   6 +
> >   drivers/gpu/drm/i915/i915_pci.c   |  23 +++
> >   drivers/gpu/drm/i915/i915_reg.h   |   9 ++
> >   drivers/gpu/drm/i915/intel_device_info.c  |   1 +
> >   drivers/gpu/drm/i915/intel_device_info.h  |   5 +-
> >   drivers/gpu/drm/i915/intel_uncore.c   | 150 +-
> >   drivers/gpu/drm/i915/selftests/intel_uncore.c |   2 +
> >   19 files changed, 417 insertions(+), 38 deletions(-)
> > 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795

Re: [PATCH v4] drm/hyperv: Add error message for fb size greater than allocated

[Saurabh Singh Sengar]

On Tue, Apr 12, 2022 at 05:06:07AM +, Dexuan Cui wrote:
> > From: Saurabh Sengar 
> > Sent: Monday, April 11, 2022 9:29 PM
> >  ...
> > Add error message when the size of requested framebuffer is more than
> > the allocated size by vmbus mmio region for framebuffer
> 
> The line lacks a period, but I guess the maintainer may help fix it for you 
> :-)
>  
> > Signed-off-by: Saurabh Sengar 
> 
> Reviewed-by: Dexuan Cui 

Can this be queued for next ? please let me know in case any clarification 
required.

[CI] drm/i915: use IOMEM_ERR_PTR() directly

[Tvrtko Ursulin]

From: Kefeng Wang 

Use IOMEM_ERR_PTR() instead of self defined IO_ERR_PTR().

Signed-off-by: Kefeng Wang 
Reviewed-by: Jani Nikula 
Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_vma.c | 4 ++--
 drivers/gpu/drm/i915/i915_vma.h | 1 -
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index e782ebfcc0ca..ed8f334cb831 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -548,7 +548,7 @@ void __iomem *i915_vma_pin_iomap(struct i915_vma *vma)
int err;
 
if (WARN_ON_ONCE(vma->obj->flags & I915_BO_ALLOC_GPU_ONLY))
-   return IO_ERR_PTR(-EINVAL);
+   return IOMEM_ERR_PTR(-EINVAL);
 
if (!i915_gem_object_is_lmem(vma->obj)) {
if (GEM_WARN_ON(!i915_vma_is_map_and_fenceable(vma))) {
@@ -601,7 +601,7 @@ void __iomem *i915_vma_pin_iomap(struct i915_vma *vma)
 err_unpin:
__i915_vma_unpin(vma);
 err:
-   return IO_ERR_PTR(err);
+   return IOMEM_ERR_PTR(err);
 }
 
 void i915_vma_flush_writes(struct i915_vma *vma)
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index 6034991d89fe..88ca0bd9c900 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -317,7 +317,6 @@ static inline bool i915_node_color_differs(const struct 
drm_mm_node *node,
  * Returns a valid iomapped pointer or ERR_PTR.
  */
 void __iomem *i915_vma_pin_iomap(struct i915_vma *vma);
-#define IO_ERR_PTR(x) ((void __iomem *)ERR_PTR(x))
 
 /**
  * i915_vma_unpin_iomap - unpins the mapping returned from i915_vma_iomap
-- 
2.32.0

Re: [Intel-gfx] [PATCH v2] drm/doc: add rfc section for small BAR uapi

[Matthew Auld]

On 28/04/2022 12:11, Tvrtko Ursulin wrote:


On 28/04/2022 11:25, Matthew Auld wrote:

On 28/04/2022 09:55, Tvrtko Ursulin wrote:


On 27/04/2022 18:36, Matthew Auld wrote:

On 27/04/2022 09:36, Tvrtko Ursulin wrote:


On 20/04/2022 18:13, Matthew Auld wrote:

Add an entry for the new uapi needed for small BAR on DG2+.

v2:
   - Some spelling fixes and other small tweaks. (Akeem & Thomas)
   - Rework error capture interactions, including no longer needing
 NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
   - Add probed_cpu_visible_size. (Lionel)

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
Cc: mesa-...@lists.freedesktop.org
---
  Documentation/gpu/rfc/i915_small_bar.h   | 190 
+++

  Documentation/gpu/rfc/i915_small_bar.rst |  58 +++
  Documentation/gpu/rfc/index.rst  |   4 +
  3 files changed, 252 insertions(+)
  create mode 100644 Documentation/gpu/rfc/i915_small_bar.h
  create mode 100644 Documentation/gpu/rfc/i915_small_bar.rst

diff --git a/Documentation/gpu/rfc/i915_small_bar.h 
b/Documentation/gpu/rfc/i915_small_bar.h

new file mode 100644
index ..7bfd0cf44d35
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_small_bar.h
@@ -0,0 +1,190 @@
+/**
+ * struct __drm_i915_memory_region_info - Describes one region as 
known to the

+ * driver.
+ *
+ * Note this is using both struct drm_i915_query_item and struct 
drm_i915_query.
+ * For this new query we are adding the new query id 
DRM_I915_QUERY_MEMORY_REGIONS

+ * at _i915_query_item.query_id.
+ */
+struct __drm_i915_memory_region_info {
+    /** @region: The class:instance pair encoding */
+    struct drm_i915_gem_memory_class_instance region;
+
+    /** @rsvd0: MBZ */
+    __u32 rsvd0;
+
+    /** @probed_size: Memory probed by the driver (-1 = unknown) */
+    __u64 probed_size;
+
+    /** @unallocated_size: Estimate of memory remaining (-1 = 
unknown) */

+    __u64 unallocated_size;
+
+    union {
+    /** @rsvd1: MBZ */
+    __u64 rsvd1[8];
+    struct {
+    /**
+ * @probed_cpu_visible_size: Memory probed by the driver
+ * that is CPU accessible. (-1 = unknown).
+ *
+ * This will be always be <= @probed_size, and the
+ * remainder(if there is any) will not be CPU
+ * accessible.
+ */
+    __u64 probed_cpu_visible_size;


Would unallocated_cpu_visible_size be useful, to follow the total 
unallocated_size?


Make sense. But I don't think unallocated_size has actually been 
properly wired up yet. It still just gives the same value as 
probed_size. IIRC for unallocated_size we still need a real 
user/usecase/umd, before wiring that up for real with the existing 
avail tracking. Once we have that we can also add 
unallocated_cpu_visible_size.


So this does nothing at the moment:

  info.unallocated_size = mr->avail;

Right, it is set to "mem->avail = mem->total;" at region init time 
and I indeed can't find it ever getting modified. Okay.


Btw, have we ever considered whether unallocated_size should 
require CAP_SYS_ADMIN/PERFMON or something?


Note sure. But just in case we do add it for real at some point, why 
the added restriction?


To avoid a side channel, albeit perhaps a very weak one. For engine 
utilization we require CAP_SYS_PERFMON, but that is implied by the 
perf core API. It's open for discussion. I guess it may make sense to 
limit it also because it is questionable the field(s) are even useful.







+    };
+    };
+};
+
+/**
+ * struct __drm_i915_gem_create_ext - Existing gem_create 
behaviour, with added

+ * extension support using struct i915_user_extension.
+ *
+ * Note that new buffer flags should be added here, at least for 
the stuff that
+ * is immutable. Previously we would have two ioctls, one to 
create the object
+ * with gem_create, and another to apply various parameters, 
however this
+ * creates some ambiguity for the params which are considered 
immutable. Also in

+ * general we're phasing out the various SET/GET ioctls.
+ */
+struct __drm_i915_gem_create_ext {
+    /**
+ * @size: Requested size for the object.
+ *
+ * The (page-aligned) allocated size for the object will be 
returned.

+ *
+ * Note that for some devices we have might have further minimum
+ * page-size restrictions(larger than 4K), likefor device 
local-memory.
+ * However in general the final size here should always 
reflect any
+ * rounding up, if for example using the 
I915_GEM_CREATE_EXT_MEMORY_REGIONS

+ * extension to place the object in device local-memory.
+ */
+    __u64 size;
+    /**
+ * @handle: Returned handle for the object.
+ *
+ * Object handles are nonzero.
+ */
+    __u32 handle;
+    /**
+ * @flags: Optional flags.
+ *
+ * Supported values:
+ *
+ * 

Re: [PATCH v2] drm/doc: add rfc section for small BAR uapi

[Lionel Landwerlin]

On 03/05/2022 17:27, Matthew Auld wrote:

On 03/05/2022 11:39, Lionel Landwerlin wrote:

On 03/05/2022 13:22, Matthew Auld wrote:

On 02/05/2022 09:53, Lionel Landwerlin wrote:

On 02/05/2022 10:54, Lionel Landwerlin wrote:

On 20/04/2022 20:13, Matthew Auld wrote:

Add an entry for the new uapi needed for small BAR on DG2+.

v2:
   - Some spelling fixes and other small tweaks. (Akeem & Thomas)
   - Rework error capture interactions, including no longer needing
 NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
   - Add probed_cpu_visible_size. (Lionel)

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
Cc: mesa-...@lists.freedesktop.org
---
  Documentation/gpu/rfc/i915_small_bar.h   | 190 
+++

  Documentation/gpu/rfc/i915_small_bar.rst |  58 +++
  Documentation/gpu/rfc/index.rst  |   4 +
  3 files changed, 252 insertions(+)
  create mode 100644 Documentation/gpu/rfc/i915_small_bar.h
  create mode 100644 Documentation/gpu/rfc/i915_small_bar.rst

diff --git a/Documentation/gpu/rfc/i915_small_bar.h 
b/Documentation/gpu/rfc/i915_small_bar.h

new file mode 100644
index ..7bfd0cf44d35
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_small_bar.h
@@ -0,0 +1,190 @@
+/**
+ * struct __drm_i915_memory_region_info - Describes one region 
as known to the

+ * driver.
+ *
+ * Note this is using both struct drm_i915_query_item and struct 
drm_i915_query.
+ * For this new query we are adding the new query id 
DRM_I915_QUERY_MEMORY_REGIONS

+ * at _i915_query_item.query_id.
+ */
+struct __drm_i915_memory_region_info {
+    /** @region: The class:instance pair encoding */
+    struct drm_i915_gem_memory_class_instance region;
+
+    /** @rsvd0: MBZ */
+    __u32 rsvd0;
+
+    /** @probed_size: Memory probed by the driver (-1 = unknown) */
+    __u64 probed_size;
+
+    /** @unallocated_size: Estimate of memory remaining (-1 = 
unknown) */

+    __u64 unallocated_size;
+
+    union {
+    /** @rsvd1: MBZ */
+    __u64 rsvd1[8];
+    struct {
+    /**
+ * @probed_cpu_visible_size: Memory probed by the 
driver

+ * that is CPU accessible. (-1 = unknown).
+ *
+ * This will be always be <= @probed_size, and the
+ * remainder(if there is any) will not be CPU
+ * accessible.
+ */
+    __u64 probed_cpu_visible_size;
+    };



Trying to implement userspace support in Vulkan for this, I have 
an additional question about the value of probed_cpu_visible_size.


When is it set to -1?

I'm guessing before there is support for this value it'll be 0 (MBZ).

After after it should either be the entire lmem or something smaller.


-Lionel



Other pain point of this new uAPI, previously we could query the 
unallocated size for each heap.


unallocated_size should always give the same value as probed_size. 
We have the avail tracking, but we don't currently expose that 
through unallocated_size, due to lack of real userspace/user etc.




Now lmem is effectively divided into 2 heaps, but unallocated_size 
is tracking allocation from both parts of lmem.


Yeah, if we ever properly expose the unallocated_size, then we could 
also just add unallocated_cpu_visible_size.




Is adding new I915_MEMORY_CLASS_DEVICE_NON_MAPPABLE out of question?


I don't think it's out of the question...

I guess user-space should be able to get the current flag behaviour 
just by specifying: device, system. And it does give more flexibly 
to allow something like: device, device-nm, smem.


We can also drop the probed_cpu_visible_size, which would now just 
be the probed_size with device/device-nm. And if we lack device-nm, 
then the entire thing must be CPU mappable.


One of the downsides though, is that we can no longer easily mix 
object pages from both device + device-nm, which we could previously 
do when we didn't specify the flag. At least according to the 
current design/behaviour for @regions that would not be allowed. I 
guess some kind of new flag like ALLOC_MIXED or so? Although 
currently that is only possible with device + device-nm in ttm/i915.



Thanks, I wasn't aware of the restrictions.

Adding unallocated_cpu_visible_size would be great.


So do we want this in the next version? i.e we already have a current 
real use case in mind for unallocated_size where probed_size is not 
good enough?



Yeah in the  next iteration.

We're using unallocated_size to implement VK_EXT_memory_budget and since 
I'm going to expose lmem mappable/unmappable as 2 different heaps on 
Vulkan, I would use that there too.



-Lionel







-Lionel







-Lionel






+    };
+};
+
+/**
+ * struct __drm_i915_gem_create_ext - Existing gem_create 
behaviour, with added

+ * extension support using struct i915_user_extension.
+ *
+ * Note that new buffer flags should be added 

Re: [PATCH v2 00/48] ARM: PXA multiplatform support

[Arnd Bergmann]

On Tue, May 3, 2022 at 4:04 PM Guenter Roeck  wrote:
> On 5/3/22 00:17, Arnd Bergmann wrote:
>
> > If you have a z2 specific config, that would probably not enable CONFIG_OF,
> > which is always turned on for multiplatform, but again that only adds around
> > 250KB in my builds (using gcc-11). This is more than I'd like it to be, but
> > still much less than 1MB.
> >
>
> Maybe it is a bit less; I only compared the size of "Image". Either case,
> it is enough to cause the problem. I am not sure if it is worth the time
> trying to track this down further.

Sure, I'm not worried about the boot regression any more, as that is definitely
explained by the size growth. The only question is whether the patches make
the kernel grow more than it should. The 40+250KB I measured seem
within my expectations, so unless you have specific data showing much
more, I think we're good.

Thanks for all the help!

Arnd

Re: [PATCH v2] drm/doc: add rfc section for small BAR uapi

[Matthew Auld]

On 03/05/2022 11:39, Lionel Landwerlin wrote:

On 03/05/2022 13:22, Matthew Auld wrote:

On 02/05/2022 09:53, Lionel Landwerlin wrote:

On 02/05/2022 10:54, Lionel Landwerlin wrote:

On 20/04/2022 20:13, Matthew Auld wrote:

Add an entry for the new uapi needed for small BAR on DG2+.

v2:
   - Some spelling fixes and other small tweaks. (Akeem & Thomas)
   - Rework error capture interactions, including no longer needing
 NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
   - Add probed_cpu_visible_size. (Lionel)

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
Cc: mesa-...@lists.freedesktop.org
---
  Documentation/gpu/rfc/i915_small_bar.h   | 190 
+++

  Documentation/gpu/rfc/i915_small_bar.rst |  58 +++
  Documentation/gpu/rfc/index.rst  |   4 +
  3 files changed, 252 insertions(+)
  create mode 100644 Documentation/gpu/rfc/i915_small_bar.h
  create mode 100644 Documentation/gpu/rfc/i915_small_bar.rst

diff --git a/Documentation/gpu/rfc/i915_small_bar.h 
b/Documentation/gpu/rfc/i915_small_bar.h

new file mode 100644
index ..7bfd0cf44d35
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_small_bar.h
@@ -0,0 +1,190 @@
+/**
+ * struct __drm_i915_memory_region_info - Describes one region as 
known to the

+ * driver.
+ *
+ * Note this is using both struct drm_i915_query_item and struct 
drm_i915_query.
+ * For this new query we are adding the new query id 
DRM_I915_QUERY_MEMORY_REGIONS

+ * at _i915_query_item.query_id.
+ */
+struct __drm_i915_memory_region_info {
+    /** @region: The class:instance pair encoding */
+    struct drm_i915_gem_memory_class_instance region;
+
+    /** @rsvd0: MBZ */
+    __u32 rsvd0;
+
+    /** @probed_size: Memory probed by the driver (-1 = unknown) */
+    __u64 probed_size;
+
+    /** @unallocated_size: Estimate of memory remaining (-1 = 
unknown) */

+    __u64 unallocated_size;
+
+    union {
+    /** @rsvd1: MBZ */
+    __u64 rsvd1[8];
+    struct {
+    /**
+ * @probed_cpu_visible_size: Memory probed by the driver
+ * that is CPU accessible. (-1 = unknown).
+ *
+ * This will be always be <= @probed_size, and the
+ * remainder(if there is any) will not be CPU
+ * accessible.
+ */
+    __u64 probed_cpu_visible_size;
+    };



Trying to implement userspace support in Vulkan for this, I have an 
additional question about the value of probed_cpu_visible_size.


When is it set to -1?

I'm guessing before there is support for this value it'll be 0 (MBZ).

After after it should either be the entire lmem or something smaller.


-Lionel



Other pain point of this new uAPI, previously we could query the 
unallocated size for each heap.


unallocated_size should always give the same value as probed_size. We 
have the avail tracking, but we don't currently expose that through 
unallocated_size, due to lack of real userspace/user etc.




Now lmem is effectively divided into 2 heaps, but unallocated_size is 
tracking allocation from both parts of lmem.


Yeah, if we ever properly expose the unallocated_size, then we could 
also just add unallocated_cpu_visible_size.




Is adding new I915_MEMORY_CLASS_DEVICE_NON_MAPPABLE out of question?


I don't think it's out of the question...

I guess user-space should be able to get the current flag behaviour 
just by specifying: device, system. And it does give more flexibly to 
allow something like: device, device-nm, smem.


We can also drop the probed_cpu_visible_size, which would now just be 
the probed_size with device/device-nm. And if we lack device-nm, then 
the entire thing must be CPU mappable.


One of the downsides though, is that we can no longer easily mix 
object pages from both device + device-nm, which we could previously 
do when we didn't specify the flag. At least according to the current 
design/behaviour for @regions that would not be allowed. I guess some 
kind of new flag like ALLOC_MIXED or so? Although currently that is 
only possible with device + device-nm in ttm/i915.



Thanks, I wasn't aware of the restrictions.

Adding unallocated_cpu_visible_size would be great.


So do we want this in the next version? i.e we already have a current 
real use case in mind for unallocated_size where probed_size is not good 
enough?





-Lionel







-Lionel






+    };
+};
+
+/**
+ * struct __drm_i915_gem_create_ext - Existing gem_create 
behaviour, with added

+ * extension support using struct i915_user_extension.
+ *
+ * Note that new buffer flags should be added here, at least for 
the stuff that
+ * is immutable. Previously we would have two ioctls, one to 
create the object
+ * with gem_create, and another to apply various parameters, 
however this
+ * creates some ambiguity for the params which are considered 
immutable. Also 

Re: [PATCH 2/3] drm/msm/mdp5: move iommu_domain_alloc() call close to its usage

[Robin Murphy]

On 2022-05-03 14:30, Dmitry Baryshkov wrote:

On Tue, 3 May 2022 at 13:57, Robin Murphy  wrote:


On 2022-05-01 11:10, Dmitry Baryshkov wrote:

Move iommu_domain_alloc() in front of adress space/IOMMU initialization.
This allows us to drop final bits of struct mdp5_cfg_platform which
remained from the pre-DT days.

Signed-off-by: Dmitry Baryshkov 
---
   drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 16 
   drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.h |  6 --
   drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c |  6 --
   3 files changed, 4 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
index 1bf9ff5dbabc..714effb967ff 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
@@ -1248,8 +1248,6 @@ static const struct mdp5_cfg_handler cfg_handlers_v3[] = {
   { .revision = 3, .config = { .hw = _config } },
   };

-static struct mdp5_cfg_platform *mdp5_get_config(struct platform_device *dev);
-
   const struct mdp5_cfg_hw *mdp5_cfg_get_hw_config(struct mdp5_cfg_handler 
*cfg_handler)
   {
   return cfg_handler->config.hw;
@@ -1274,10 +1272,8 @@ struct mdp5_cfg_handler *mdp5_cfg_init(struct mdp5_kms 
*mdp5_kms,
   uint32_t major, uint32_t minor)
   {
   struct drm_device *dev = mdp5_kms->dev;
- struct platform_device *pdev = to_platform_device(dev->dev);
   struct mdp5_cfg_handler *cfg_handler;
   const struct mdp5_cfg_handler *cfg_handlers;
- struct mdp5_cfg_platform *pconfig;
   int i, ret = 0, num_handlers;

   cfg_handler = kzalloc(sizeof(*cfg_handler), GFP_KERNEL);
@@ -1320,9 +1316,6 @@ struct mdp5_cfg_handler *mdp5_cfg_init(struct mdp5_kms 
*mdp5_kms,
   cfg_handler->revision = minor;
   cfg_handler->config.hw = mdp5_cfg;

- pconfig = mdp5_get_config(pdev);
- memcpy(_handler->config.platform, pconfig, sizeof(*pconfig));
-
   DBG("MDP5: %s hw config selected", mdp5_cfg->name);

   return cfg_handler;
@@ -1333,12 +1326,3 @@ struct mdp5_cfg_handler *mdp5_cfg_init(struct mdp5_kms 
*mdp5_kms,

   return ERR_PTR(ret);
   }
-
-static struct mdp5_cfg_platform *mdp5_get_config(struct platform_device *dev)
-{
- static struct mdp5_cfg_platform config = {};
-
- config.iommu = iommu_domain_alloc(_bus_type);
-
- return 
-}
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.h 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.h
index 6b03d7899309..c2502cc33864 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.h
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.h
@@ -104,14 +104,8 @@ struct mdp5_cfg_hw {
   uint32_t max_clk;
   };

-/* platform config data (ie. from DT, or pdata) */
-struct mdp5_cfg_platform {
- struct iommu_domain *iommu;
-};
-
   struct mdp5_cfg {
   const struct mdp5_cfg_hw *hw;
- struct mdp5_cfg_platform platform;
   };

   struct mdp5_kms;
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 9b7bbc3adb97..1c67c2c828cd 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -558,6 +558,7 @@ static int mdp5_kms_init(struct drm_device *dev)
   struct msm_gem_address_space *aspace;
   int irq, i, ret;
   struct device *iommu_dev;
+ struct iommu_domain *iommu;

   ret = mdp5_init(to_platform_device(dev->dev), dev);

@@ -601,14 +602,15 @@ static int mdp5_kms_init(struct drm_device *dev)
   }
   mdelay(16);

- if (config->platform.iommu) {
+ iommu = iommu_domain_alloc(_bus_type);


To preempt the next change down the line as well, could this be
rearranged to work as iommu_domain_alloc(iommu_dev->bus)?


I'd prefer to split this into the separate change, if you don't mind.


Oh, for sure, divide the patches however you see fit - I'm just hoping 
to save your time overall by getting all the IOMMU-related refactoring 
done now as a single series rather than risk me coming back and breaking 
things again in a few months :)


Cheers,
Robin.






+ if (iommu) {
   struct msm_mmu *mmu;

   iommu_dev = >dev;
   if (!dev_iommu_fwspec_get(iommu_dev))


The fwspec helpers are more of an internal thing between the IOMMU
drivers and the respective firmware code - I'd rather that external API
users stuck consistently to using device_iommu_mapped() (it should give
the same result).


Let me check that it works correctly and spin a v2 afterwards.



Otherwise, thanks for sorting this out!

Robin.


   iommu_dev = iommu_dev->parent;

- mmu = msm_iommu_new(iommu_dev, config->platform.iommu);
+ mmu = msm_iommu_new(iommu_dev, iommu);

   aspace = msm_gem_address_space_create(mmu, "mdp5",
   0x1000, 0x1 - 0x1000);

Re: [PATCH] drm/msm: Limit command submission when no IOMMU

[Rob Clark]

On Tue, May 3, 2022 at 5:12 AM Lucas Stach  wrote:
>
> Am Montag, dem 02.05.2022 um 10:29 -0700 schrieb Rob Clark:
> > From: Rob Clark 
> >
> > Running the GPU without an IOMMU is not really a supported (or sane)
> > configuration.  Yet it can be useful during SoC bringup (ie. if the
> > iommu driver doesn't work yet).
> >
> > Lets limit it to users who already have /dev/mem access, to avoid the
> > chance that a user accidentially configures kernel without IOMMU
> > support.
>
> I haven't followed MSM too closely, so ctx->aspace may also include the
> GPU MMU, but if this really only includes the IOMMU (as the commit
> message implies) then this breaks Freedreno on i.MX5.

it includes the gpu mmu, so a2xx should be fine.

BR,
-R

> Regards,
> Lucas
>
> >
> > Signed-off-by: Rob Clark 
> > ---
> >  drivers/gpu/drm/msm/msm_gem_submit.c | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c 
> > b/drivers/gpu/drm/msm/msm_gem_submit.c
> > index 23b68bc945f6..9cd8c8708990 100644
> > --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> > @@ -734,6 +734,11 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void 
> > *data,
> >   if (args->pad)
> >   return -EINVAL;
> >
> > + if (unlikely(!ctx->aspace) && !capable(CAP_SYS_RAWIO)) {
> > + DRM_ERROR_RATELIMITED("IOMMU support or CAP_SYS_RAWIO 
> > required!\n");
> > + return -EPERM;
> > + }
> > +
> >   /* for now, we just have 3d pipe.. eventually this would need to
> >* be more clever to dispatch to appropriate gpu module:
> >*/
>
>

Re: [PATCH v2 00/48] ARM: PXA multiplatform support

[Guenter Roeck]

On 5/3/22 00:17, Arnd Bergmann wrote:

On Tue, May 3, 2022 at 4:55 AM Guenter Roeck  wrote:

On 5/2/22 14:03, Arnd Bergmann wrote:

On Mon, May 2, 2022 at 10:35 PM Guenter Roeck  wrote:

On 5/2/22 12:21, Arnd Bergmann wrote:


qemu puts initrd in the middle of available memory. With the image size
being ~1MB larger than with v5.18-rc, this is too much, and the kernel
overwrites part of initrd. This causes it to be corrupted.

It looks like that would have happened eventually, your patch series just
made it happen now. The kernel is just getting too large to run on such small
systems. I worked around the problem in my version of qemu by loading initrd
at the end of the (small) RAM. With that, I no longer see the boot failure.


Ok, thanks for confirming. If it's just the image size that changed,
then I think
we can live with it. Having the kernel image grow by 1MB seems excessive
though, I'd like to understand better where that increase comes from.

Starting out from pxa_defconfig, I see a 40KB increase from the final patch
that moves to multiplatform support, which I think is fine.

If you have a z2 specific config, that would probably not enable CONFIG_OF,
which is always turned on for multiplatform, but again that only adds around
250KB in my builds (using gcc-11). This is more than I'd like it to be, but
still much less than 1MB.



Maybe it is a bit less; I only compared the size of "Image". Either case,
it is enough to cause the problem. I am not sure if it is worth the time
trying to track this down further.

Guenter

Re: [PATCH 13/14] drm/vc4: crtc: Fix out of order frames during asynchronous page flips

[kernel test robot]

Hi Maxime,

I love your patch! Perhaps something to improve:

[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip next-20220503]
[cannot apply to anholt/for-next v5.18-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/intel-lab-lkp/linux/commits/Maxime-Ripard/drm-vc4-Properly-separate-v3d-on-BCM2711-and-fix-frame-ordering/20220503-201745
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: arc-allyesconfig 
(https://download.01.org/0day-ci/archive/20220503/202205032134.wmmuq85t-...@intel.com/config)
compiler: arceb-elf-gcc (GCC) 11.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/intel-lab-lkp/linux/commit/0db44bd12236a0a64cf67bbef6b11df5bbe37134
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Maxime-Ripard/drm-vc4-Properly-separate-v3d-on-BCM2711-and-fix-frame-ordering/20220503-201745
git checkout 0db44bd12236a0a64cf67bbef6b11df5bbe37134
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.3.0 make.cross W=1 
O=build_dir ARCH=arc SHELL=/bin/bash drivers/gpu/drm/vc4/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/vc4/vc4_crtc.c: In function 'vc4_async_set_fence_cb':
>> drivers/gpu/drm/vc4/vc4_crtc.c:865:57: warning: implicit conversion from 
>> 'enum ' to 'enum dma_resv_usage' [-Wenum-conversion]
 865 | ret = dma_resv_get_singleton(cma_bo->base.resv, false, 
);
 | ^


vim +865 drivers/gpu/drm/vc4/vc4_crtc.c

   848  
   849  static int vc4_async_set_fence_cb(struct drm_device *dev,
   850struct vc4_async_flip_state 
*flip_state)
   851  {
   852  struct drm_framebuffer *fb = flip_state->fb;
   853  struct drm_gem_cma_object *cma_bo = drm_fb_cma_get_gem_obj(fb, 
0);
   854  struct vc4_dev *vc4 = to_vc4_dev(dev);
   855  struct dma_fence *fence;
   856  int ret;
   857  
   858  if (!vc4->is_vc5) {
   859  struct vc4_bo *bo = to_vc4_bo(_bo->base);
   860  
   861  return vc4_queue_seqno_cb(dev, _state->cb.seqno, 
bo->seqno,
   862
vc4_async_page_flip_seqno_complete);
   863  }
   864  
 > 865  ret = dma_resv_get_singleton(cma_bo->base.resv, false, );
   866  if (ret)
   867  return ret;
   868  
   869  if (dma_fence_add_callback(fence, _state->cb.fence,
   870 vc4_async_page_flip_fence_complete))
   871  vc4_async_page_flip_fence_complete(fence, 
_state->cb.fence);
   872  
   873  return 0;
   874  }
   875  

-- 
0-DAY CI Kernel Test Service
https://01.org/lkp

Re: [PATCH v4 1/2] dt-bindings: display: bridge: ldb: Implement simple Freescale i.MX8MP LDB bridge

[Marek Vasut]

On 5/3/22 14:03, Robert Foss wrote:

On Tue, 3 May 2022 at 02:31, Rob Herring  wrote:


On Tue, Apr 26, 2022 at 09:36:44PM +0200, Marek Vasut wrote:

The i.MX8MP contains two syscon registers which are responsible
for configuring the on-SoC DPI-to-LVDS serializer. Add DT binding
which represents this serializer as a bridge.

Acked-by: Sam Ravnborg 
Signed-off-by: Marek Vasut 
Cc: Laurent Pinchart 
Cc: Lucas Stach 
Cc: Maxime Ripard 
Cc: Peng Fan 
Cc: Rob Herring 
Cc: Robby Cai 
Cc: Robert Foss 
Cc: Sam Ravnborg 
Cc: Thomas Zimmermann 
Cc: devicet...@vger.kernel.org
To: dri-devel@lists.freedesktop.org
---
V2: - Consistently use fsl,imx8mp-ldb as compatible
 - Drop items: from compatible:
 - Replace minItems with maxItems in clocks:
 - Drop quotes from clock-names const: ldb
 - Rename syscon to fsl,syscon
 - Use generic name of ldb-lvds in example
V3: - Add AB from Sam
 - Consistently use MX8MP
V4: - Rename to fsl-ldb all over the place
 - Put the LDB node under media block controller in the example
---
  .../bindings/display/bridge/fsl,ldb.yaml  | 92 +++
  1 file changed, 92 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml


A little quick on the applying...


Darnit, you're right.

Marek: Can you supply a new patch with all of the relevant changes?


Sure, it's coming today-ish or so.

Re: [PATCH 2/3] drm/msm/mdp5: move iommu_domain_alloc() call close to its usage

[Dmitry Baryshkov]

On Tue, 3 May 2022 at 13:57, Robin Murphy  wrote:
>
> On 2022-05-01 11:10, Dmitry Baryshkov wrote:
> > Move iommu_domain_alloc() in front of adress space/IOMMU initialization.
> > This allows us to drop final bits of struct mdp5_cfg_platform which
> > remained from the pre-DT days.
> >
> > Signed-off-by: Dmitry Baryshkov 
> > ---
> >   drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 16 
> >   drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.h |  6 --
> >   drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c |  6 --
> >   3 files changed, 4 insertions(+), 24 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c 
> > b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
> > index 1bf9ff5dbabc..714effb967ff 100644
> > --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
> > +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
> > @@ -1248,8 +1248,6 @@ static const struct mdp5_cfg_handler 
> > cfg_handlers_v3[] = {
> >   { .revision = 3, .config = { .hw = _config } },
> >   };
> >
> > -static struct mdp5_cfg_platform *mdp5_get_config(struct platform_device 
> > *dev);
> > -
> >   const struct mdp5_cfg_hw *mdp5_cfg_get_hw_config(struct mdp5_cfg_handler 
> > *cfg_handler)
> >   {
> >   return cfg_handler->config.hw;
> > @@ -1274,10 +1272,8 @@ struct mdp5_cfg_handler *mdp5_cfg_init(struct 
> > mdp5_kms *mdp5_kms,
> >   uint32_t major, uint32_t minor)
> >   {
> >   struct drm_device *dev = mdp5_kms->dev;
> > - struct platform_device *pdev = to_platform_device(dev->dev);
> >   struct mdp5_cfg_handler *cfg_handler;
> >   const struct mdp5_cfg_handler *cfg_handlers;
> > - struct mdp5_cfg_platform *pconfig;
> >   int i, ret = 0, num_handlers;
> >
> >   cfg_handler = kzalloc(sizeof(*cfg_handler), GFP_KERNEL);
> > @@ -1320,9 +1316,6 @@ struct mdp5_cfg_handler *mdp5_cfg_init(struct 
> > mdp5_kms *mdp5_kms,
> >   cfg_handler->revision = minor;
> >   cfg_handler->config.hw = mdp5_cfg;
> >
> > - pconfig = mdp5_get_config(pdev);
> > - memcpy(_handler->config.platform, pconfig, sizeof(*pconfig));
> > -
> >   DBG("MDP5: %s hw config selected", mdp5_cfg->name);
> >
> >   return cfg_handler;
> > @@ -1333,12 +1326,3 @@ struct mdp5_cfg_handler *mdp5_cfg_init(struct 
> > mdp5_kms *mdp5_kms,
> >
> >   return ERR_PTR(ret);
> >   }
> > -
> > -static struct mdp5_cfg_platform *mdp5_get_config(struct platform_device 
> > *dev)
> > -{
> > - static struct mdp5_cfg_platform config = {};
> > -
> > - config.iommu = iommu_domain_alloc(_bus_type);
> > -
> > - return 
> > -}
> > diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.h 
> > b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.h
> > index 6b03d7899309..c2502cc33864 100644
> > --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.h
> > +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.h
> > @@ -104,14 +104,8 @@ struct mdp5_cfg_hw {
> >   uint32_t max_clk;
> >   };
> >
> > -/* platform config data (ie. from DT, or pdata) */
> > -struct mdp5_cfg_platform {
> > - struct iommu_domain *iommu;
> > -};
> > -
> >   struct mdp5_cfg {
> >   const struct mdp5_cfg_hw *hw;
> > - struct mdp5_cfg_platform platform;
> >   };
> >
> >   struct mdp5_kms;
> > diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
> > b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> > index 9b7bbc3adb97..1c67c2c828cd 100644
> > --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> > +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> > @@ -558,6 +558,7 @@ static int mdp5_kms_init(struct drm_device *dev)
> >   struct msm_gem_address_space *aspace;
> >   int irq, i, ret;
> >   struct device *iommu_dev;
> > + struct iommu_domain *iommu;
> >
> >   ret = mdp5_init(to_platform_device(dev->dev), dev);
> >
> > @@ -601,14 +602,15 @@ static int mdp5_kms_init(struct drm_device *dev)
> >   }
> >   mdelay(16);
> >
> > - if (config->platform.iommu) {
> > + iommu = iommu_domain_alloc(_bus_type);
>
> To preempt the next change down the line as well, could this be
> rearranged to work as iommu_domain_alloc(iommu_dev->bus)?

I'd prefer to split this into the separate change, if you don't mind.

>
> > + if (iommu) {
> >   struct msm_mmu *mmu;
> >
> >   iommu_dev = >dev;
> >   if (!dev_iommu_fwspec_get(iommu_dev))
>
> The fwspec helpers are more of an internal thing between the IOMMU
> drivers and the respective firmware code - I'd rather that external API
> users stuck consistently to using device_iommu_mapped() (it should give
> the same result).

Let me check that it works correctly and spin a v2 afterwards.

>
> Otherwise, thanks for sorting this out!
>
> Robin.
>
> >   iommu_dev = iommu_dev->parent;
> >
> > - mmu = msm_iommu_new(iommu_dev, config->platform.iommu);
> > + mmu = msm_iommu_new(iommu_dev, iommu);
> >
> >   aspace = msm_gem_address_space_create(mmu, "mdp5",
> >   0x1000, 0x1 - 0x1000);



-- 
With best 

Re: [PATCH] drm/amdgpu: fix drm-next merge fallout

[Alex Deucher]

On Tue, May 3, 2022 at 2:36 AM Christian König
 wrote:
>
> That hunk somehow got missing while solving the conflict between the TTM
> and AMDGPU changes for drm-next.
>
> Signed-off-by: Christian König 

Acked-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c
> index 7761a3ea172e..88de9f0d4728 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c
> @@ -631,9 +631,13 @@ static void amdgpu_vm_pt_free(struct amdgpu_vm_bo_base 
> *entry)
> if (!entry->bo)
> return;
> shadow = amdgpu_bo_shadowed(entry->bo);
> +   if (shadow) {
> +   ttm_bo_set_bulk_move(>tbo, NULL);
> +   amdgpu_bo_unref();
> +   }
> +   ttm_bo_set_bulk_move(>bo->tbo, NULL);
> entry->bo->vm_bo = NULL;
> list_del(>vm_status);
> -   amdgpu_bo_unref();
> amdgpu_bo_unref(>bo);
>  }
>
> --
> 2.25.1
>

Re: [PATCHv4] drm/amdgpu: disable ASPM on Intel Alder Lake based systems

[Paul Menzel]

Dear Daniel,


Am 03.05.22 um 14:25 schrieb Daniel Stone:

On Sun, 1 May 2022 at 08:08, Paul Menzel  wrote:

Am 26.04.22 um 15:53 schrieb Gong, Richard:

I think so. We captured dmesg log.


Then the (whole) system did *not* freeze, if you could still log in
(maybe over network) and execute `dmesg`. Please also paste the
amdgpu(?) error logs in the commit message.


As mentioned early we need support from Intel on how to get ASPM working
for VI generation on Intel Alder Lake, but we don't know where things
currently stand.


Who is working on this, and knows?


This has gone beyond the point of a reasonable request. The amount of
detail you're demanding is completely unnecessary.


If a quirk is introduced possibly leading to higher power consumption, 
especially on systems nobody has access to yet, then the detail, where 
the system hangs/freezes is not unreasonable at all.


In the Linux logs from the issue there are messages like

[   58.101385] Freezing of tasks failed after 20.003 seconds (4 
tasks refusing to freeze, wq_busy=0):


[   78.278403] Freezing of tasks failed after 20.008 seconds (4 
tasks refusing to freeze, wq_busy=0):


and it looks like several suspend/resume cycles were done.

I see a lot of commit messages over the whole Linux kernel, where this 
level of detail is provided (by default), and


The second question was not for the commit message, but just for 
documentation purpose when the problem is going to be fixed properly. 
And it looks like (at least publicly) analyzing the root cause is not 
happening, and once the quirk lands, nobody is going to feel the 
pressure to work on it, as everyone’s plates are full.



Kind regards,

Paul

Re: [PATCHv4] drm/amdgpu: disable ASPM on Intel Alder Lake based systems

[Daniel Stone]

On Sun, 1 May 2022 at 08:08, Paul Menzel  wrote:
> Am 26.04.22 um 15:53 schrieb Gong, Richard:
> > I think so. We captured dmesg log.
>
> Then the (whole) system did *not* freeze, if you could still log in
> (maybe over network) and execute `dmesg`. Please also paste the
> amdgpu(?) error logs in the commit message.
>
> > As mentioned early we need support from Intel on how to get ASPM working
> > for VI generation on Intel Alder Lake, but we don't know where things
> > currently stand.
>
> Who is working on this, and knows?

This has gone beyond the point of a reasonable request. The amount of
detail you're demanding is completely unnecessary.

Re: [PATCH v19 06/25] soc: mediatek: add mtk_mmsys_write_reg API

[AngeloGioacchino Del Regno]

Il 03/05/22 12:23, Nancy.Lin ha scritto:

Add mtk_mmsys_write_reg API. Simplify code for writing mmsys reg.
It is a preparation for adding support for mmsys config API.

Signed-off-by: Nancy.Lin 
---
  drivers/soc/mediatek/mtk-mmsys.c | 35 ++--
  1 file changed, 15 insertions(+), 20 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index ab3c5cbb0175..3e2e5e3f721d 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -191,22 +191,26 @@ static int mtk_mmsys_find_match_drvdata(struct mtk_mmsys 
*mmsys,
return -EINVAL;
  }
  
+static void mtk_mmsys_write_reg(struct mtk_mmsys *mmsys, u32 offset, u32 mask, u32 val)

+{
+   u32 tmp;
+
+   tmp = readl_relaxed(mmsys->regs + offset);
+   tmp = (tmp & ~mask) | val;
+   writel_relaxed(tmp, mmsys->regs + offset);
+}
+


Uhm... this is the equivalent of regmap_update_bits(): I fear that calling this
mtk_mmsys_write_reg() may lead to confusion.

I think that a more appropriate name would be mtk_mmsys_update_bits() or
something similar, recalling that this is not just a register write, but
a RMW.

Regards,
Angelo

Re: [PATCH v19 09/25] soc: mediatek: mmsys: add mmsys for support 64 reset bits

[AngeloGioacchino Del Regno]

Il 03/05/22 12:23, Nancy.Lin ha scritto:

Add mmsys for support 64 reset bits. It is a preparation for MT8195
vdosys1 HW reset. MT8195 vdosys1 has more than 32 reset bits.

1. Add the number of reset bits in mmsys private data
2. move the whole "reset register code section" behind the
"get mmsys->data" code section for getting the num_resets in mmsys->data.

Signed-off-by: Nancy.Lin 


Reviewed-by: AngeloGioacchino Del Regno 

Re: [PATCH v19 04/25] soc: mediatek: add mtk-mmsys ethdr and mdp_rdma components

[AngeloGioacchino Del Regno]

Il 03/05/22 12:23, Nancy.Lin ha scritto:

Add new mmsys component: ethdr_mixer and mdp_rdma. These components will
use in mt8195 vdosys1.

Signed-off-by: Nancy.Lin 


Reviewed-by: AngeloGioacchino Del Regno 

Re: [PATCH v19 11/25] soc: mediatek: add mtk-mutex component - dp_intf1

[AngeloGioacchino Del Regno]

Il 03/05/22 12:23, Nancy.Lin ha scritto:

Add mtk-mutex DDP_COMPONENT_DP_INTF1 component. The MT8195 vdosys1 path
component contains ovl_adaptor, merge5, and dp_intf1. It is a preparation
for adding support for MT8195 vdosys1 path component.

Signed-off-by: Nancy.Lin 


Reviewed-by: AngeloGioacchino Del Regno 

Re: [PATCH v11 11/24] drm/rockchip: dw_hdmi: Use auto-generated tables

[Robin Murphy]

On 2022-05-03 12:02, Heiko Stübner wrote:

Am Freitag, 22. April 2022, 09:28:28 CEST schrieb Sascha Hauer:

From: Douglas Anderson 

The previous tables for mpll_cfg and curr_ctrl were created using the
20-pages of example settings provided by the PHY vendor.  Those
example settings weren't particularly dense, so there were places
where we were guessing what the settings would be for 10-bit and
12-bit (not that we use those anyway).  It was also always a lot of
extra work every time we wanted to add a new clock rate since we had
to cross-reference several tables.

In  I've gone through the work to figure
out how to generate this table automatically.  Let's now use the
automatically generated table and then we'll never need to look at it
again.

We only support 8-bit mode right now and only support a small number
of clock rates and I've verified that the only 8-bit rate that was
affected was 148.5.  That mode appears to have been wrong in the old
table.

Signed-off-by: Douglas Anderson 
Signed-off-by: Yakir Yang 
Signed-off-by: Sascha Hauer 


This breaks hdmi on my rk3328-rock64 which then ends up in a
[CRTC:37:crtc-0] vblank wait timed out

warning-loop.


Oh yeah, that... IIRC from back when I was looking at it, it's because 
the inno-hdmi phy does its own rate validation at a point when it's 
already far too late to actually reject the mode. It manages to work at 
the moment because its set of supported rates mostly line up with those 
for the Synopsys phy which dw-hdmi-rockchip still insists on validating 
against even when a vendor phy is present.



Some part of the patch11-14 range also creates sparking horizontal
lines on my rk3288-pinky.


I figure that's the PLL jitter issue that's come up before. Similarly, 
when I last tried hacking in a 154MHz rate for my monitor's 1920x1200 
mode, it was rock solid on RK3399, but intolerably glitchy on RK3288.


Robin.


I haven't the time to dig overly deep into that, so left out the
hdmi-rate patches (11-14) for now.


Heiko



---

Notes:
 Changes since v5:
 - Add missing Signed-off-by me
 
 Changes since v3:

 - new patch

  drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 130 +++-
  1 file changed, 69 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index fe4f9556239ac..cb43e7b47157d 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -91,80 +91,88 @@ static struct rockchip_hdmi *to_rockchip_hdmi(struct 
drm_encoder *encoder)
  
  static const struct dw_hdmi_mpll_config rockchip_mpll_cfg[] = {

{
-   2700, {
-   { 0x00b3, 0x},
-   { 0x2153, 0x},
-   { 0x40f3, 0x}
+   30666000, {
+   { 0x00b3, 0x },
+   { 0x2153, 0x },
+   { 0x40f3, 0x },
},
-   }, {
-   3600, {
-   { 0x00b3, 0x},
-   { 0x2153, 0x},
-   { 0x40f3, 0x}
+   },  {
+   3680, {
+   { 0x00b3, 0x },
+   { 0x2153, 0x },
+   { 0x40a2, 0x0001 },
},
-   }, {
-   4000, {
-   { 0x00b3, 0x},
-   { 0x2153, 0x},
-   { 0x40f3, 0x}
+   },  {
+   4600, {
+   { 0x00b3, 0x },
+   { 0x2142, 0x0001 },
+   { 0x40a2, 0x0001 },
},
-   }, {
-   5400, {
-   { 0x0072, 0x0001},
-   { 0x2142, 0x0001},
-   { 0x40a2, 0x0001},
+   },  {
+   61333000, {
+   { 0x0072, 0x0001 },
+   { 0x2142, 0x0001 },
+   { 0x40a2, 0x0001 },
},
-   }, {
-   6500, {
-   { 0x0072, 0x0001},
-   { 0x2142, 0x0001},
-   { 0x40a2, 0x0001},
+   },  {
+   7360, {
+   { 0x0072, 0x0001 },
+   { 0x2142, 0x0001 },
+   { 0x4061, 0x0002 },
},
-   }, {
-   6600, {
-   { 0x013e, 0x0003},
-   { 0x217e, 0x0002},
-   { 0x4061, 0x0002}
+   },  {
+   9200, {
+   { 0x0072, 0x0001 },
+   { 0x2145, 0x0002 },
+   { 0x4061, 0x0002 },
},
-   }, {
-   7425, {
-   { 0x0072, 0x0001},
-   { 0x2145, 0x0002},
-

[PATCH 14/14] drm/vc4: Warn if some v3d code is run on BCM2711

[Maxime Ripard]

The BCM2711 has a separate driver for the v3d, and thus we can't call
into any of the driver entrypoints that rely on the v3d being there.

Let's add a bunch of checks and complain loudly if that ever happen.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_bo.c   | 49 ++
 drivers/gpu/drm/vc4/vc4_drv.c  | 11 +
 drivers/gpu/drm/vc4/vc4_drv.h  |  6 +++
 drivers/gpu/drm/vc4/vc4_gem.c  | 40 ++
 drivers/gpu/drm/vc4/vc4_irq.c  | 16 +++
 drivers/gpu/drm/vc4/vc4_kms.c  |  4 ++
 drivers/gpu/drm/vc4/vc4_perfmon.c  | 41 ++
 drivers/gpu/drm/vc4/vc4_render_cl.c|  4 ++
 drivers/gpu/drm/vc4/vc4_v3d.c  | 15 +++
 drivers/gpu/drm/vc4/vc4_validate.c | 16 +++
 drivers/gpu/drm/vc4/vc4_validate_shaders.c |  4 ++
 11 files changed, 206 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index 3ca16d682fc0..b8d856312846 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -248,6 +248,9 @@ void vc4_bo_add_to_purgeable_pool(struct vc4_bo *bo)
 {
struct vc4_dev *vc4 = to_vc4_dev(bo->base.base.dev);
 
+   if (WARN_ON_ONCE(vc4->is_vc5))
+   return;
+
mutex_lock(>purgeable.lock);
list_add_tail(>size_head, >purgeable.list);
vc4->purgeable.num++;
@@ -259,6 +262,9 @@ static void vc4_bo_remove_from_purgeable_pool_locked(struct 
vc4_bo *bo)
 {
struct vc4_dev *vc4 = to_vc4_dev(bo->base.base.dev);
 
+   if (WARN_ON_ONCE(vc4->is_vc5))
+   return;
+
/* list_del_init() is used here because the caller might release
 * the purgeable lock in order to acquire the madv one and update the
 * madv status.
@@ -387,6 +393,9 @@ struct drm_gem_object *vc4_create_object(struct drm_device 
*dev, size_t size)
struct vc4_dev *vc4 = to_vc4_dev(dev);
struct vc4_bo *bo;
 
+   if (WARN_ON_ONCE(vc4->is_vc5))
+   return ERR_PTR(-ENODEV);
+
bo = kzalloc(sizeof(*bo), GFP_KERNEL);
if (!bo)
return ERR_PTR(-ENOMEM);
@@ -413,6 +422,9 @@ struct vc4_bo *vc4_bo_create(struct drm_device *dev, size_t 
unaligned_size,
struct drm_gem_cma_object *cma_obj;
struct vc4_bo *bo;
 
+   if (WARN_ON_ONCE(vc4->is_vc5))
+   return ERR_PTR(-ENODEV);
+
if (size == 0)
return ERR_PTR(-EINVAL);
 
@@ -475,9 +487,13 @@ int vc4_bo_dumb_create(struct drm_file *file_priv,
   struct drm_device *dev,
   struct drm_mode_create_dumb *args)
 {
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
struct vc4_bo *bo = NULL;
int ret;
 
+   if (WARN_ON_ONCE(vc4->is_vc5))
+   return -ENODEV;
+
ret = vc4_dumb_fixup_args(args);
if (ret)
return ret;
@@ -598,8 +614,12 @@ static void vc4_bo_cache_time_work(struct work_struct 
*work)
 
 int vc4_bo_inc_usecnt(struct vc4_bo *bo)
 {
+   struct vc4_dev *vc4 = to_vc4_dev(bo->base.base.dev);
int ret;
 
+   if (WARN_ON_ONCE(vc4->is_vc5))
+   return -ENODEV;
+
/* Fast path: if the BO is already retained by someone, no need to
 * check the madv status.
 */
@@ -634,6 +654,11 @@ int vc4_bo_inc_usecnt(struct vc4_bo *bo)
 
 void vc4_bo_dec_usecnt(struct vc4_bo *bo)
 {
+   struct vc4_dev *vc4 = to_vc4_dev(bo->base.base.dev);
+
+   if (WARN_ON_ONCE(vc4->is_vc5))
+   return;
+
/* Fast path: if the BO is still retained by someone, no need to test
 * the madv value.
 */
@@ -753,6 +778,9 @@ int vc4_create_bo_ioctl(struct drm_device *dev, void *data,
struct vc4_bo *bo = NULL;
int ret;
 
+   if (WARN_ON_ONCE(vc4->is_vc5))
+   return -ENODEV;
+
ret = vc4_grab_bin_bo(vc4, vc4file);
if (ret)
return ret;
@@ -776,9 +804,13 @@ int vc4_create_bo_ioctl(struct drm_device *dev, void *data,
 int vc4_mmap_bo_ioctl(struct drm_device *dev, void *data,
  struct drm_file *file_priv)
 {
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
struct drm_vc4_mmap_bo *args = data;
struct drm_gem_object *gem_obj;
 
+   if (WARN_ON_ONCE(vc4->is_vc5))
+   return -ENODEV;
+
gem_obj = drm_gem_object_lookup(file_priv, args->handle);
if (!gem_obj) {
DRM_DEBUG("Failed to look up GEM BO %d\n", args->handle);
@@ -802,6 +834,9 @@ vc4_create_shader_bo_ioctl(struct drm_device *dev, void 
*data,
struct vc4_bo *bo = NULL;
int ret;
 
+   if (WARN_ON_ONCE(vc4->is_vc5))
+   return -ENODEV;
+
if (args->size == 0)
return -EINVAL;
 
@@ -872,11 +907,15 @@ vc4_create_shader_bo_ioctl(struct drm_device *dev, void 
*data,
 int vc4_set_tiling_ioctl(struct drm_device *dev, void *data,
  

[PATCH 13/14] drm/vc4: crtc: Fix out of order frames during asynchronous page flips

[Maxime Ripard]

When doing an asynchronous page flip (PAGE_FLIP ioctl with the
DRM_MODE_PAGE_FLIP_ASYNC flag set), the current code waits for the
possible GPU buffer being rendered through a call to
vc4_queue_seqno_cb().

On the BCM2835-37, the GPU driver is part of the vc4 driver and that
function is defined in vc4_gem.c to wait for the buffer to be rendered,
and once it's done, call a callback.

However, on the BCM2711 used on the RaspberryPi4, the GPU driver is
separate (v3d) and that function won't do anything. This was working
because we were going into a path, due to uninitialized variables, that
was always scheduling the callback.

However, we were never actually waiting for the buffer to be rendered
which was resulting in frames being displayed out of order.

The generic API to signal those kind of completion in the kernel are the
DMA fences, and fortunately the v3d drivers supports them and signal
when its job is done. That API also provides an equivalent function that
allows to have a callback being executed when the fence is signalled as
done.

Let's change our driver a bit to rely on the previous function for the
older SoCs, and on DMA fences for the BCM2711.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_crtc.c | 41 --
 1 file changed, 39 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index e0ae7bef08fa..8e1369fca937 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -776,6 +776,7 @@ struct vc4_async_flip_state {
struct drm_pending_vblank_event *event;
 
union {
+   struct dma_fence_cb fence;
struct vc4_seqno_cb seqno;
} cb;
 };
@@ -835,6 +836,43 @@ static void vc4_async_page_flip_seqno_complete(struct 
vc4_seqno_cb *cb)
vc4_bo_dec_usecnt(bo);
 }
 
+static void vc4_async_page_flip_fence_complete(struct dma_fence *fence,
+  struct dma_fence_cb *cb)
+{
+   struct vc4_async_flip_state *flip_state =
+   container_of(cb, struct vc4_async_flip_state, cb.fence);
+
+   vc4_async_page_flip_complete(flip_state);
+   dma_fence_put(fence);
+}
+
+static int vc4_async_set_fence_cb(struct drm_device *dev,
+ struct vc4_async_flip_state *flip_state)
+{
+   struct drm_framebuffer *fb = flip_state->fb;
+   struct drm_gem_cma_object *cma_bo = drm_fb_cma_get_gem_obj(fb, 0);
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
+   struct dma_fence *fence;
+   int ret;
+
+   if (!vc4->is_vc5) {
+   struct vc4_bo *bo = to_vc4_bo(_bo->base);
+
+   return vc4_queue_seqno_cb(dev, _state->cb.seqno, bo->seqno,
+ vc4_async_page_flip_seqno_complete);
+   }
+
+   ret = dma_resv_get_singleton(cma_bo->base.resv, false, );
+   if (ret)
+   return ret;
+
+   if (dma_fence_add_callback(fence, _state->cb.fence,
+  vc4_async_page_flip_fence_complete))
+   vc4_async_page_flip_fence_complete(fence, 
_state->cb.fence);
+
+   return 0;
+}
+
 static int
 vc4_async_page_flip_common(struct drm_crtc *crtc,
   struct drm_framebuffer *fb,
@@ -874,8 +912,7 @@ vc4_async_page_flip_common(struct drm_crtc *crtc,
 */
drm_atomic_set_fb_for_plane(plane->state, fb);
 
-   vc4_queue_seqno_cb(dev, _state->cb.seqno, bo->seqno,
-  vc4_async_page_flip_seqno_complete);
+   vc4_async_set_fence_cb(dev, flip_state);
 
/* Driver takes ownership of state on successful async commit. */
return 0;
-- 
2.35.1

[PATCH 12/14] drm/vc4: crtc: Don't call into BO Handling on Async Page-Flips on BCM2711

[Maxime Ripard]

The BCM2711 doesn't have a v3d GPU so we don't want to call into its BO
management code. Let's create an asynchronous page-flip handler for the
BCM2711 that just calls into the common code.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_crtc.c | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index bd85b1f13cee..e0ae7bef08fa 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -923,16 +923,31 @@ static int vc4_async_page_flip(struct drm_crtc *crtc,
return 0;
 }
 
+static int vc5_async_page_flip(struct drm_crtc *crtc,
+  struct drm_framebuffer *fb,
+  struct drm_pending_vblank_event *event,
+  uint32_t flags)
+{
+   return vc4_async_page_flip_common(crtc, fb, event, flags);
+}
+
 int vc4_page_flip(struct drm_crtc *crtc,
  struct drm_framebuffer *fb,
  struct drm_pending_vblank_event *event,
  uint32_t flags,
  struct drm_modeset_acquire_ctx *ctx)
 {
-   if (flags & DRM_MODE_PAGE_FLIP_ASYNC)
-   return vc4_async_page_flip(crtc, fb, event, flags);
-   else
+   if (flags & DRM_MODE_PAGE_FLIP_ASYNC) {
+   struct drm_device *dev = crtc->dev;
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
+
+   if (vc4->is_vc5)
+   return vc5_async_page_flip(crtc, fb, event, flags);
+   else
+   return vc4_async_page_flip(crtc, fb, event, flags);
+   } else {
return drm_atomic_helper_page_flip(crtc, fb, event, flags, ctx);
+   }
 }
 
 struct drm_crtc_state *vc4_crtc_duplicate_state(struct drm_crtc *crtc)
-- 
2.35.1

[PATCH 11/14] drm/vc4: crtc: Move the BO Handling out of Common Page-Flip Handler

[Maxime Ripard]

The function vc4_async_page_flip() handles asynchronous page-flips in
the vc4 driver.

However, it mixes some generic code with code that should only be run on
older generations that have the GPU handled by the vc4 driver.

Let's split the generic part out of vc4_async_page_flip() and into a
common function that we be reusable by an handler made for the BCM2711.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_crtc.c | 75 ++
 1 file changed, 48 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 0410db97b9d1..bd85b1f13cee 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -835,40 +835,19 @@ static void vc4_async_page_flip_seqno_complete(struct 
vc4_seqno_cb *cb)
vc4_bo_dec_usecnt(bo);
 }
 
-/* Implements async (non-vblank-synced) page flips.
- *
- * The page flip ioctl needs to return immediately, so we grab the
- * modeset semaphore on the pipe, and queue the address update for
- * when V3D is done with the BO being flipped to.
- */
-static int vc4_async_page_flip(struct drm_crtc *crtc,
-  struct drm_framebuffer *fb,
-  struct drm_pending_vblank_event *event,
-  uint32_t flags)
+static int
+vc4_async_page_flip_common(struct drm_crtc *crtc,
+  struct drm_framebuffer *fb,
+  struct drm_pending_vblank_event *event,
+  uint32_t flags)
 {
struct drm_device *dev = crtc->dev;
struct drm_plane *plane = crtc->primary;
-   int ret = 0;
struct vc4_async_flip_state *flip_state;
-   struct drm_gem_cma_object *cma_bo = drm_fb_cma_get_gem_obj(fb, 0);
-   struct vc4_bo *bo = to_vc4_bo(_bo->base);
-
-   /* Increment the BO usecnt here, so that we never end up with an
-* unbalanced number of vc4_bo_{dec,inc}_usecnt() calls when the
-* plane is later updated through the non-async path.
-* FIXME: we should move to generic async-page-flip when it's
-* available, so that we can get rid of this hand-made prepare_fb()
-* logic.
-*/
-   ret = vc4_bo_inc_usecnt(bo);
-   if (ret)
-   return ret;
 
flip_state = kzalloc(sizeof(*flip_state), GFP_KERNEL);
-   if (!flip_state) {
-   vc4_bo_dec_usecnt(bo);
+   if (!flip_state)
return -ENOMEM;
-   }
 
drm_framebuffer_get(fb);
flip_state->fb = fb;
@@ -902,6 +881,48 @@ static int vc4_async_page_flip(struct drm_crtc *crtc,
return 0;
 }
 
+/* Implements async (non-vblank-synced) page flips.
+ *
+ * The page flip ioctl needs to return immediately, so we grab the
+ * modeset semaphore on the pipe, and queue the address update for
+ * when V3D is done with the BO being flipped to.
+ */
+static int vc4_async_page_flip(struct drm_crtc *crtc,
+  struct drm_framebuffer *fb,
+  struct drm_pending_vblank_event *event,
+  uint32_t flags)
+{
+   struct drm_device *dev = crtc->dev;
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
+   struct drm_gem_cma_object *cma_bo = drm_fb_cma_get_gem_obj(fb, 0);
+   struct vc4_bo *bo = to_vc4_bo(_bo->base);
+   int ret;
+
+   if (WARN_ON_ONCE(vc4->is_vc5))
+   return -ENODEV;
+
+   /*
+* Increment the BO usecnt here, so that we never end up with an
+* unbalanced number of vc4_bo_{dec,inc}_usecnt() calls when the
+* plane is later updated through the non-async path.
+*
+* FIXME: we should move to generic async-page-flip when
+* it's available, so that we can get rid of this
+* hand-made prepare_fb() logic.
+*/
+   ret = vc4_bo_inc_usecnt(bo);
+   if (ret)
+   return ret;
+
+   ret = vc4_async_page_flip_common(crtc, fb, event, flags);
+   if (ret) {
+   vc4_bo_dec_usecnt(bo);
+   return ret;
+   }
+
+   return 0;
+}
+
 int vc4_page_flip(struct drm_crtc *crtc,
  struct drm_framebuffer *fb,
  struct drm_pending_vblank_event *event,
-- 
2.35.1

[PATCH 10/14] drm/vc4: crtc: Move the BO handling out of common page-flip callback

[Maxime Ripard]

We'll soon introduce another completion callback source that won't need
to use the BO reference counting, so let's move it around to create a
function we will be able to share between both callbacks.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_crtc.c | 34 --
 1 file changed, 20 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 1f247c037ce0..0410db97b9d1 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -802,21 +802,8 @@ vc4_async_page_flip_complete(struct vc4_async_flip_state 
*flip_state)
drm_crtc_vblank_put(crtc);
drm_framebuffer_put(flip_state->fb);
 
-   /* Decrement the BO usecnt in order to keep the inc/dec calls balanced
-* when the planes are updated through the async update path.
-* FIXME: we should move to generic async-page-flip when it's
-* available, so that we can get rid of this hand-made cleanup_fb()
-* logic.
-*/
-   if (flip_state->old_fb) {
-   struct drm_gem_cma_object *cma_bo;
-   struct vc4_bo *bo;
-
-   cma_bo = drm_fb_cma_get_gem_obj(flip_state->old_fb, 0);
-   bo = to_vc4_bo(_bo->base);
-   vc4_bo_dec_usecnt(bo);
+   if (flip_state->old_fb)
drm_framebuffer_put(flip_state->old_fb);
-   }
 
kfree(flip_state);
 }
@@ -825,8 +812,27 @@ static void vc4_async_page_flip_seqno_complete(struct 
vc4_seqno_cb *cb)
 {
struct vc4_async_flip_state *flip_state =
container_of(cb, struct vc4_async_flip_state, cb.seqno);
+   struct vc4_bo *bo = NULL;
+
+   if (flip_state->old_fb) {
+   struct drm_gem_cma_object *cma_bo =
+   drm_fb_cma_get_gem_obj(flip_state->old_fb, 0);
+   bo = to_vc4_bo(_bo->base);
+   }
 
vc4_async_page_flip_complete(flip_state);
+
+   /*
+* Decrement the BO usecnt in order to keep the inc/dec
+* calls balanced when the planes are updated through
+* the async update path.
+*
+* FIXME: we should move to generic async-page-flip when
+* it's available, so that we can get rid of this
+* hand-made cleanup_fb() logic.
+*/
+   if (bo)
+   vc4_bo_dec_usecnt(bo);
 }
 
 /* Implements async (non-vblank-synced) page flips.
-- 
2.35.1

[PATCH 09/14] drm/vc4: crtc: Use an union to store the page flip callback

[Maxime Ripard]

We'll need to extend the vc4_async_flip_state structure to rely on
another callback implementation, so let's move the current one into a
union.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_crtc.c | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index dd5fb25d0f43..1f247c037ce0 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -775,17 +775,17 @@ struct vc4_async_flip_state {
struct drm_framebuffer *old_fb;
struct drm_pending_vblank_event *event;
 
-   struct vc4_seqno_cb cb;
+   union {
+   struct vc4_seqno_cb seqno;
+   } cb;
 };
 
 /* Called when the V3D execution for the BO being flipped to is done, so that
  * we can actually update the plane's address to point to it.
  */
 static void
-vc4_async_page_flip_complete(struct vc4_seqno_cb *cb)
+vc4_async_page_flip_complete(struct vc4_async_flip_state *flip_state)
 {
-   struct vc4_async_flip_state *flip_state =
-   container_of(cb, struct vc4_async_flip_state, cb);
struct drm_crtc *crtc = flip_state->crtc;
struct drm_device *dev = crtc->dev;
struct drm_plane *plane = crtc->primary;
@@ -821,6 +821,14 @@ vc4_async_page_flip_complete(struct vc4_seqno_cb *cb)
kfree(flip_state);
 }
 
+static void vc4_async_page_flip_seqno_complete(struct vc4_seqno_cb *cb)
+{
+   struct vc4_async_flip_state *flip_state =
+   container_of(cb, struct vc4_async_flip_state, cb.seqno);
+
+   vc4_async_page_flip_complete(flip_state);
+}
+
 /* Implements async (non-vblank-synced) page flips.
  *
  * The page flip ioctl needs to return immediately, so we grab the
@@ -881,8 +889,8 @@ static int vc4_async_page_flip(struct drm_crtc *crtc,
 */
drm_atomic_set_fb_for_plane(plane->state, fb);
 
-   vc4_queue_seqno_cb(dev, _state->cb, bo->seqno,
-  vc4_async_page_flip_complete);
+   vc4_queue_seqno_cb(dev, _state->cb.seqno, bo->seqno,
+  vc4_async_page_flip_seqno_complete);
 
/* Driver takes ownership of state on successful async commit. */
return 0;
-- 
2.35.1

[PATCH 08/14] drm/vc4: drv: Skip BO Backend Initialization on BCM2711

[Maxime Ripard]

On the BCM2711, we currently call the vc4_bo_cache_init() and
vc4_gem_init() functions. These functions initialize the BO and GEM
backends.

However, this code was initially created to accomodate the requirements
of the GPU on the older SoCs, while the BCM2711 has a separate driver
for it. So let's just skip these calls when we're on a newer hardware.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_drv.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 4f9e2067dad0..64c7696aa9e4 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -285,19 +285,23 @@ static int vc4_drm_bind(struct device *dev)
platform_set_drvdata(pdev, drm);
INIT_LIST_HEAD(>debugfs_list);
 
-   mutex_init(>bin_bo_lock);
+   if (!is_vc5) {
+   mutex_init(>bin_bo_lock);
 
-   ret = vc4_bo_cache_init(drm);
-   if (ret)
-   return ret;
+   ret = vc4_bo_cache_init(drm);
+   if (ret)
+   return ret;
+   }
 
ret = drmm_mode_config_init(drm);
if (ret)
return ret;
 
-   ret = vc4_gem_init(drm);
-   if (ret)
-   return ret;
+   if (!is_vc5) {
+   ret = vc4_gem_init(drm);
+   if (ret)
+   return ret;
+   }
 
node = of_find_compatible_node(NULL, NULL, 
"raspberrypi,bcm2835-firmware");
if (node) {
-- 
2.35.1

[PATCH 07/14] drm/vc4: plane: Register a different drm_plane_helper_funcs on BCM2711

[Maxime Ripard]

On the BCM2711, our current definition of drm_plane_helper_funcs uses
the custom vc4_prepare_fb() and vc4_cleanup_fb().

Those functions rely on the buffer allocation path that was relying on
the GPU, and is no longer relevant.

Let's create another drm_plane_helper_funcs structure that we will
register on the BCM2711.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_plane.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index ba7359516d75..1e866dc00ac3 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -1389,6 +1389,13 @@ static const struct drm_plane_helper_funcs 
vc4_plane_helper_funcs = {
.atomic_async_update = vc4_plane_atomic_async_update,
 };
 
+static const struct drm_plane_helper_funcs vc5_plane_helper_funcs = {
+   .atomic_check = vc4_plane_atomic_check,
+   .atomic_update = vc4_plane_atomic_update,
+   .atomic_async_check = vc4_plane_atomic_async_check,
+   .atomic_async_update = vc4_plane_atomic_async_update,
+};
+
 static bool vc4_format_mod_supported(struct drm_plane *plane,
 uint32_t format,
 uint64_t modifier)
@@ -1493,7 +1500,10 @@ struct drm_plane *vc4_plane_init(struct drm_device *dev,
if (ret)
return ERR_PTR(ret);
 
-   drm_plane_helper_add(plane, _plane_helper_funcs);
+   if (vc4->is_vc5)
+   drm_plane_helper_add(plane, _plane_helper_funcs);
+   else
+   drm_plane_helper_add(plane, _plane_helper_funcs);
 
drm_plane_create_alpha_property(plane);
drm_plane_create_rotation_property(plane, DRM_MODE_ROTATE_0,
-- 
2.35.1

[PATCH 06/14] drm/vc4: kms: Register a different drm_mode_config_funcs on BCM2711

[Maxime Ripard]

On the BCM2711, our current definition of drm_mode_config_funcs uses the
custom vc4_fb_create().

However, that function relies on the buffer allocation path that was
relying on the GPU, and is no longer relevant.

Let's create another drm_mode_config_funcs structure that we will
register on the BCM2711.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_kms.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 3c232d85ab85..1d3b31fb71ea 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -997,6 +997,12 @@ static const struct drm_mode_config_funcs vc4_mode_funcs = 
{
.fb_create = vc4_fb_create,
 };
 
+static const struct drm_mode_config_funcs vc5_mode_funcs = {
+   .atomic_check = vc4_atomic_check,
+   .atomic_commit = drm_atomic_helper_commit,
+   .fb_create = drm_gem_fb_create,
+};
+
 int vc4_kms_load(struct drm_device *dev)
 {
struct vc4_dev *vc4 = to_vc4_dev(dev);
@@ -1031,7 +1037,7 @@ int vc4_kms_load(struct drm_device *dev)
dev->mode_config.max_height = 2048;
}
 
-   dev->mode_config.funcs = _mode_funcs;
+   dev->mode_config.funcs = vc4->is_vc5 ? _mode_funcs : 
_mode_funcs;
dev->mode_config.helper_private = _mode_config_helpers;
dev->mode_config.preferred_depth = 24;
dev->mode_config.async_page_flip = true;
-- 
2.35.1

[PATCH 05/14] drm/vc4: drv: Register a different driver on BCM2711

[Maxime Ripard]

Prior to the BCM2711/RaspberryPi4, the GPU was a part of the display
components of the SoC. It was thus a part of the vc4 driver.

However, with the BCM2711, it got split out and thus the v3d driver was
created. The vc4 driver now only handles the display part.

We didn't properly split out the code when doing the BCM2711 support
though, and most of the code around buffer allocations is still
involved, even though it doesn't have the backing hardware anymore.

Let's start the split out by creating a new drm_driver that only reports
and uses what we support on the BCM2711. The ioctl were properly
filtered already, but we were still exposing a .gem_create_object hook,
as well as having an .open and .postclose hooks which are only relevant
on older generations.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_drv.c | 51 ---
 1 file changed, 42 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index eb08940028d3..4f9e2067dad0 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -76,6 +76,19 @@ int vc4_dumb_fixup_args(struct drm_mode_create_dumb *args)
return 0;
 }
 
+static int vc4_dumb_create(struct drm_file *file_priv,
+  struct drm_device *dev,
+  struct drm_mode_create_dumb *args)
+{
+   int ret;
+
+   ret = vc4_dumb_fixup_args(args);
+   if (ret)
+   return ret;
+
+   return drm_gem_cma_dumb_create_internal(file_priv, dev, args);
+}
+
 static int vc4_get_param_ioctl(struct drm_device *dev, void *data,
   struct drm_file *file_priv)
 {
@@ -173,7 +186,7 @@ static const struct drm_ioctl_desc vc4_drm_ioctls[] = {
DRM_IOCTL_DEF_DRV(VC4_PERFMON_GET_VALUES, vc4_perfmon_get_values_ioctl, 
DRM_RENDER_ALLOW),
 };
 
-static struct drm_driver vc4_drm_driver = {
+static const struct drm_driver vc4_drm_driver = {
.driver_features = (DRIVER_MODESET |
DRIVER_ATOMIC |
DRIVER_GEM |
@@ -202,6 +215,27 @@ static struct drm_driver vc4_drm_driver = {
.patchlevel = DRIVER_PATCHLEVEL,
 };
 
+static const struct drm_driver vc5_drm_driver = {
+   .driver_features = (DRIVER_MODESET |
+   DRIVER_ATOMIC |
+   DRIVER_GEM),
+
+#if defined(CONFIG_DEBUG_FS)
+   .debugfs_init = vc4_debugfs_init,
+#endif
+
+   DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE(vc4_dumb_create),
+
+   .fops = _drm_fops,
+
+   .name = DRIVER_NAME,
+   .desc = DRIVER_DESC,
+   .date = DRIVER_DATE,
+   .major = DRIVER_MAJOR,
+   .minor = DRIVER_MINOR,
+   .patchlevel = DRIVER_PATCHLEVEL,
+};
+
 static void vc4_match_add_drivers(struct device *dev,
  struct component_match **match,
  struct platform_driver *const *drivers,
@@ -225,6 +259,7 @@ static void vc4_match_add_drivers(struct device *dev,
 static int vc4_drm_bind(struct device *dev)
 {
struct platform_device *pdev = to_platform_device(dev);
+   const struct drm_driver *driver;
struct rpi_firmware *firmware = NULL;
struct drm_device *drm;
struct vc4_dev *vc4;
@@ -236,14 +271,12 @@ static int vc4_drm_bind(struct device *dev)
dev->coherent_dma_mask = DMA_BIT_MASK(32);
 
is_vc5 = of_device_is_compatible(dev->of_node, "brcm,bcm2711-vc5");
+   if (is_vc5)
+   driver = _drm_driver;
+   else
+   driver = _drm_driver;
 
-   /* If VC4 V3D is missing, don't advertise render nodes. */
-   node = of_find_matching_node_and_match(NULL, vc4_v3d_dt_match, NULL);
-   if (!node || !of_device_is_available(node))
-   vc4_drm_driver.driver_features &= ~DRIVER_RENDER;
-   of_node_put(node);
-
-   vc4 = devm_drm_dev_alloc(dev, _drm_driver, struct vc4_dev, base);
+   vc4 = devm_drm_dev_alloc(dev, driver, struct vc4_dev, base);
if (IS_ERR(vc4))
return PTR_ERR(vc4);
vc4->is_vc5 = is_vc5;
@@ -275,7 +308,7 @@ static int vc4_drm_bind(struct device *dev)
return -EPROBE_DEFER;
}
 
-   ret = drm_aperture_remove_framebuffers(false, _drm_driver);
+   ret = drm_aperture_remove_framebuffers(false, driver);
if (ret)
return ret;
 
-- 
2.35.1

[PATCH 04/14] drm/vc4: bo: Split out Dumb buffers fixup

[Maxime Ripard]

The vc4_bo_dumb_create() both fixes up the allocation arguments to match
the hardware constraints and actually performs the allocation.

Since we're going to introduce a new function that uses a different
allocator, let's split the arguments fixup to a separate function we
will be able to reuse.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_bo.c  |  9 +++--
 drivers/gpu/drm/vc4/vc4_drv.c | 13 +
 drivers/gpu/drm/vc4/vc4_drv.h |  1 +
 3 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index 6d505da6b6cf..3ca16d682fc0 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -475,15 +475,12 @@ int vc4_bo_dumb_create(struct drm_file *file_priv,
   struct drm_device *dev,
   struct drm_mode_create_dumb *args)
 {
-   int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
struct vc4_bo *bo = NULL;
int ret;
 
-   if (args->pitch < min_pitch)
-   args->pitch = min_pitch;
-
-   if (args->size < args->pitch * args->height)
-   args->size = args->pitch * args->height;
+   ret = vc4_dumb_fixup_args(args);
+   if (ret)
+   return ret;
 
bo = vc4_bo_create(dev, args->size, false, VC4_BO_TYPE_DUMB);
if (IS_ERR(bo))
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 5f39e40ef238..eb08940028d3 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -63,6 +63,19 @@ void __iomem *vc4_ioremap_regs(struct platform_device *pdev, 
int index)
return map;
 }
 
+int vc4_dumb_fixup_args(struct drm_mode_create_dumb *args)
+{
+   int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
+
+   if (args->pitch < min_pitch)
+   args->pitch = min_pitch;
+
+   if (args->size < args->pitch * args->height)
+   args->size = args->pitch * args->height;
+
+   return 0;
+}
+
 static int vc4_get_param_ioctl(struct drm_device *dev, void *data,
   struct drm_file *file_priv)
 {
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 37c93654480f..9c324c12c410 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -885,6 +885,7 @@ static inline void vc4_debugfs_add_regset32(struct 
drm_device *drm,
 
 /* vc4_drv.c */
 void __iomem *vc4_ioremap_regs(struct platform_device *dev, int index);
+int vc4_dumb_fixup_args(struct drm_mode_create_dumb *args);
 
 /* vc4_dpi.c */
 extern struct platform_driver vc4_dpi_driver;
-- 
2.35.1

[PATCH 03/14] drm/vc4: bo: Rename vc4_dumb_create

[Maxime Ripard]

We're going to add a new variant of the dumb BO allocation function, so
let's rename vc4_dumb_create() to something a bit more specific.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_bo.c  | 6 +++---
 drivers/gpu/drm/vc4/vc4_drv.c | 2 +-
 drivers/gpu/drm/vc4/vc4_drv.h | 6 +++---
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index 49c0f2ac868b..6d505da6b6cf 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -471,9 +471,9 @@ struct vc4_bo *vc4_bo_create(struct drm_device *dev, size_t 
unaligned_size,
return bo;
 }
 
-int vc4_dumb_create(struct drm_file *file_priv,
-   struct drm_device *dev,
-   struct drm_mode_create_dumb *args)
+int vc4_bo_dumb_create(struct drm_file *file_priv,
+  struct drm_device *dev,
+  struct drm_mode_create_dumb *args)
 {
int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
struct vc4_bo *bo = NULL;
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 53067525b586..5f39e40ef238 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -175,7 +175,7 @@ static struct drm_driver vc4_drm_driver = {
 
.gem_create_object = vc4_create_object,
 
-   DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE(vc4_dumb_create),
+   DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE(vc4_bo_dumb_create),
 
.ioctls = vc4_drm_ioctls,
.num_ioctls = ARRAY_SIZE(vc4_drm_ioctls),
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 82453a3bcffe..37c93654480f 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -814,9 +814,9 @@ struct vc4_validated_shader_info {
 struct drm_gem_object *vc4_create_object(struct drm_device *dev, size_t size);
 struct vc4_bo *vc4_bo_create(struct drm_device *dev, size_t size,
 bool from_cache, enum vc4_kernel_bo_type type);
-int vc4_dumb_create(struct drm_file *file_priv,
-   struct drm_device *dev,
-   struct drm_mode_create_dumb *args);
+int vc4_bo_dumb_create(struct drm_file *file_priv,
+  struct drm_device *dev,
+  struct drm_mode_create_dumb *args);
 int vc4_create_bo_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
 int vc4_create_shader_bo_ioctl(struct drm_device *dev, void *data,
-- 
2.35.1

[PATCH 02/14] drm/vc4: Consolidate Hardware Revision Check

[Maxime Ripard]

A new generation of controller has been introduced with the
BCM2711/RaspberryPi4. This generation needs a bunch of quirks, and over
time we've piled on a number of checks in most parts of the drivers.

All these checks are performed several times, and are not always
consistent. Let's create a single, global, variable to hold it and use
it everywhere.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_crtc.c  |  6 +++---
 drivers/gpu/drm/vc4/vc4_drv.c   |  4 
 drivers/gpu/drm/vc4/vc4_drv.h   |  6 +++---
 drivers/gpu/drm/vc4/vc4_hvs.c   | 18 +-
 drivers/gpu/drm/vc4/vc4_kms.c   | 12 +---
 drivers/gpu/drm/vc4/vc4_plane.c | 13 ++---
 6 files changed, 30 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 59b20c8f132b..dd5fb25d0f43 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -256,7 +256,7 @@ static u32 vc4_get_fifo_full_level(struct vc4_crtc 
*vc4_crtc, u32 format)
 * Removing 1 from the FIFO full level however
 * seems to completely remove that issue.
 */
-   if (!vc4->hvs->hvs5)
+   if (!vc4->is_vc5)
return fifo_len_bytes - 3 * HVS_FIFO_LATENCY_PIX - 1;
 
return fifo_len_bytes - 3 * HVS_FIFO_LATENCY_PIX;
@@ -389,7 +389,7 @@ static void vc4_crtc_config_pv(struct drm_crtc *crtc, 
struct drm_encoder *encode
if (is_dsi)
CRTC_WRITE(PV_HACT_ACT, mode->hdisplay * pixel_rep);
 
-   if (vc4->hvs->hvs5)
+   if (vc4->is_vc5)
CRTC_WRITE(PV_MUX_CFG,
   VC4_SET_FIELD(PV_MUX_CFG_RGB_PIXEL_MUX_MODE_NO_SWAP,
 PV_MUX_CFG_RGB_PIXEL_MUX_MODE));
@@ -1149,7 +1149,7 @@ int vc4_crtc_init(struct drm_device *drm, struct vc4_crtc 
*vc4_crtc,
  crtc_funcs, NULL);
drm_crtc_helper_add(crtc, crtc_helper_funcs);
 
-   if (!vc4->hvs->hvs5) {
+   if (!vc4->is_vc5) {
drm_mode_crtc_set_gamma_size(crtc, ARRAY_SIZE(vc4_crtc->lut_r));
 
drm_crtc_enable_color_mgmt(crtc, 0, false, crtc->gamma_size);
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 162bc18e7497..53067525b586 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -217,10 +217,13 @@ static int vc4_drm_bind(struct device *dev)
struct vc4_dev *vc4;
struct device_node *node;
struct drm_crtc *crtc;
+   bool is_vc5;
int ret = 0;
 
dev->coherent_dma_mask = DMA_BIT_MASK(32);
 
+   is_vc5 = of_device_is_compatible(dev->of_node, "brcm,bcm2711-vc5");
+
/* If VC4 V3D is missing, don't advertise render nodes. */
node = of_find_matching_node_and_match(NULL, vc4_v3d_dt_match, NULL);
if (!node || !of_device_is_available(node))
@@ -230,6 +233,7 @@ static int vc4_drm_bind(struct device *dev)
vc4 = devm_drm_dev_alloc(dev, _drm_driver, struct vc4_dev, base);
if (IS_ERR(vc4))
return PTR_ERR(vc4);
+   vc4->is_vc5 = is_vc5;
 
drm = >base;
platform_set_drvdata(pdev, drm);
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 15e0c2ac3940..82453a3bcffe 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -74,6 +74,8 @@ struct vc4_perfmon {
 struct vc4_dev {
struct drm_device base;
 
+   bool is_vc5;
+
unsigned int irq;
 
struct vc4_hvs *hvs;
@@ -316,6 +318,7 @@ struct vc4_v3d {
 };
 
 struct vc4_hvs {
+   struct vc4_dev *vc4;
struct platform_device *pdev;
void __iomem *regs;
u32 __iomem *dlist;
@@ -333,9 +336,6 @@ struct vc4_hvs {
struct drm_mm_node mitchell_netravali_filter;
 
struct debugfs_regset32 regset;
-
-   /* HVS version 5 flag, therefore requires updated dlist structures */
-   bool hvs5;
 };
 
 struct vc4_plane {
diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
index 2a58fc421cf6..ba2c8e5a9b64 100644
--- a/drivers/gpu/drm/vc4/vc4_hvs.c
+++ b/drivers/gpu/drm/vc4/vc4_hvs.c
@@ -220,10 +220,11 @@ u8 vc4_hvs_get_fifo_frame_count(struct vc4_hvs *hvs, 
unsigned int fifo)
 
 int vc4_hvs_get_fifo_from_output(struct vc4_hvs *hvs, unsigned int output)
 {
+   struct vc4_dev *vc4 = hvs->vc4;
u32 reg;
int ret;
 
-   if (!hvs->hvs5)
+   if (!vc4->is_vc5)
return output;
 
switch (output) {
@@ -273,6 +274,7 @@ int vc4_hvs_get_fifo_from_output(struct vc4_hvs *hvs, 
unsigned int output)
 static int vc4_hvs_init_channel(struct vc4_hvs *hvs, struct drm_crtc *crtc,
struct drm_display_mode *mode, bool oneshot)
 {
+   struct vc4_dev *vc4 = hvs->vc4;
struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
struct vc4_crtc_state *vc4_crtc_state = 

[PATCH 01/14] drm/vc4: plane: Prevent async update if we don't have a dlist

[Maxime Ripard]

The vc4 planes are setup in hardware by creating a hardware descriptor
in a dedicated RAM. As part of the process to setup a plane in KMS, we
thus need to allocate some part of that dedicated RAM to store our
descriptor there.

The async update path will just reuse the descriptor already allocated
for that plane and will modify it directly in RAM to match whatever has
been asked for.

In order to do that, it will compare the descriptor for the old plane
state and the new plane state, will make sure they fit in the same size,
and check that only the position or buffer address have changed.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_plane.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index b3438f4a81ce..811a2d004cc4 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -1321,6 +1321,10 @@ static int vc4_plane_atomic_async_check(struct drm_plane 
*plane,
 
old_vc4_state = to_vc4_plane_state(plane->state);
new_vc4_state = to_vc4_plane_state(new_plane_state);
+
+   if (!new_vc4_state->hw_dlist)
+   return -EINVAL;
+
if (old_vc4_state->dlist_count != new_vc4_state->dlist_count ||
old_vc4_state->pos0_offset != new_vc4_state->pos0_offset ||
old_vc4_state->pos2_offset != new_vc4_state->pos2_offset ||
-- 
2.35.1

[PATCH 00/14] drm/vc4: Properly separate v3d on BCM2711, and fix frame ordering

[Maxime Ripard]

Hi,

Here's a series that fixes a significant issue we missed when adding support
for the BCM2711 / RaspberryPi4 in the vc4 driver.

Indeed, before the introduction of the BCM2711 support, the GPU was fairly
intertwined with the display hardware, and was thus supported by the vc4
driver. Among other things, the driver needed to accomodate for a bunch of
hardware limitations (such as a lack of IOMMU) by implementing a custom memory
management backend, tied with the v3d hardware.

On the BCM2711, that GPU got moved into a completely separate hardware block
and thus we gained a new driver for it, v3d.

However, when we introduced the display support for the BCM2711 in vc4, we
didn't properly split out the v3d-related functions and ended up reusing a
significant portion of the code supposed to be backed by the v3d.

This created a bunch of easy to miss issues that would only pop up with IGT
tests, or when heavily testing some features (like asynchronous page-flipping).

This series properly does the split now by creating separate code path where
relevant, adds a loud complain when we use a v3d entry-point on the BCM2711,
and fixes an issue where we would just ignore any fence on an asynchronous
page-flip, resulting in frames appearing out-of-order for some workloads.

Let me know what you think,
Maxime

Maxime Ripard (14):
  drm/vc4: plane: Prevent async update if we don't have a dlist
  drm/vc4: Consolidate Hardware Revision Check
  drm/vc4: bo: Rename vc4_dumb_create
  drm/vc4: bo: Split out Dumb buffers fixup
  drm/vc4: drv: Register a different driver on BCM2711
  drm/vc4: kms: Register a different drm_mode_config_funcs on BCM2711
  drm/vc4: plane: Register a different drm_plane_helper_funcs on BCM2711
  drm/vc4: drv: Skip BO Backend Initialization on BCM2711
  drm/vc4: crtc: Use an union to store the page flip callback
  drm/vc4: crtc: Move the BO handling out of common page-flip callback
  drm/vc4: crtc: Move the BO Handling out of Common Page-Flip Handler
  drm/vc4: crtc: Don't call into BO Handling on Async Page-Flips on
BCM2711
  drm/vc4: crtc: Fix out of order frames during asynchronous page flips
  drm/vc4: Warn if some v3d code is run on BCM2711

 drivers/gpu/drm/vc4/vc4_bo.c   |  62 ++-
 drivers/gpu/drm/vc4/vc4_crtc.c | 193 +++--
 drivers/gpu/drm/vc4/vc4_drv.c  |  97 +--
 drivers/gpu/drm/vc4/vc4_drv.h  |  19 +-
 drivers/gpu/drm/vc4/vc4_gem.c  |  40 +
 drivers/gpu/drm/vc4/vc4_hvs.c  |  18 +-
 drivers/gpu/drm/vc4/vc4_irq.c  |  16 ++
 drivers/gpu/drm/vc4/vc4_kms.c  |  24 ++-
 drivers/gpu/drm/vc4/vc4_perfmon.c  |  41 +
 drivers/gpu/drm/vc4/vc4_plane.c|  29 +++-
 drivers/gpu/drm/vc4/vc4_render_cl.c|   4 +
 drivers/gpu/drm/vc4/vc4_v3d.c  |  15 ++
 drivers/gpu/drm/vc4/vc4_validate.c |  16 ++
 drivers/gpu/drm/vc4/vc4_validate_shaders.c |   4 +
 14 files changed, 470 insertions(+), 108 deletions(-)

-- 
2.35.1

Re: [PATCH] drm/msm: Limit command submission when no IOMMU

[Lucas Stach]

Am Montag, dem 02.05.2022 um 10:29 -0700 schrieb Rob Clark:
> From: Rob Clark 
> 
> Running the GPU without an IOMMU is not really a supported (or sane)
> configuration.  Yet it can be useful during SoC bringup (ie. if the
> iommu driver doesn't work yet).
> 
> Lets limit it to users who already have /dev/mem access, to avoid the
> chance that a user accidentially configures kernel without IOMMU
> support.

I haven't followed MSM too closely, so ctx->aspace may also include the
GPU MMU, but if this really only includes the IOMMU (as the commit
message implies) then this breaks Freedreno on i.MX5.

Regards,
Lucas

> 
> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/msm/msm_gem_submit.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c 
> b/drivers/gpu/drm/msm/msm_gem_submit.c
> index 23b68bc945f6..9cd8c8708990 100644
> --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> @@ -734,6 +734,11 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void 
> *data,
>   if (args->pad)
>   return -EINVAL;
>  
> + if (unlikely(!ctx->aspace) && !capable(CAP_SYS_RAWIO)) {
> + DRM_ERROR_RATELIMITED("IOMMU support or CAP_SYS_RAWIO 
> required!\n");
> + return -EPERM;
> + }
> +
>   /* for now, we just have 3d pipe.. eventually this would need to
>* be more clever to dispatch to appropriate gpu module:
>*/

Re: [PATCH v4 1/2] dt-bindings: display: bridge: ldb: Implement simple Freescale i.MX8MP LDB bridge

[Robert Foss]

On Tue, 3 May 2022 at 02:31, Rob Herring  wrote:
>
> On Tue, Apr 26, 2022 at 09:36:44PM +0200, Marek Vasut wrote:
> > The i.MX8MP contains two syscon registers which are responsible
> > for configuring the on-SoC DPI-to-LVDS serializer. Add DT binding
> > which represents this serializer as a bridge.
> >
> > Acked-by: Sam Ravnborg 
> > Signed-off-by: Marek Vasut 
> > Cc: Laurent Pinchart 
> > Cc: Lucas Stach 
> > Cc: Maxime Ripard 
> > Cc: Peng Fan 
> > Cc: Rob Herring 
> > Cc: Robby Cai 
> > Cc: Robert Foss 
> > Cc: Sam Ravnborg 
> > Cc: Thomas Zimmermann 
> > Cc: devicet...@vger.kernel.org
> > To: dri-devel@lists.freedesktop.org
> > ---
> > V2: - Consistently use fsl,imx8mp-ldb as compatible
> > - Drop items: from compatible:
> > - Replace minItems with maxItems in clocks:
> > - Drop quotes from clock-names const: ldb
> > - Rename syscon to fsl,syscon
> > - Use generic name of ldb-lvds in example
> > V3: - Add AB from Sam
> > - Consistently use MX8MP
> > V4: - Rename to fsl-ldb all over the place
> > - Put the LDB node under media block controller in the example
> > ---
> >  .../bindings/display/bridge/fsl,ldb.yaml  | 92 +++
> >  1 file changed, 92 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml
>
> A little quick on the applying...

Darnit, you're right.

Marek: Can you supply a new patch with all of the relevant changes?

>
> >
> > diff --git a/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml 
> > b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml
> > new file mode 100644
> > index ..77f174eee424
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml
> > @@ -0,0 +1,92 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/bridge/fsl,ldb.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Freescale i.MX8MP DPI to LVDS bridge chip
> > +
> > +maintainers:
> > +  - Marek Vasut 
> > +
> > +description: |
> > +  The i.MX8MP mediamix contains two registers which are responsible
> > +  for configuring the on-SoC DPI-to-LVDS serializer. This describes
> > +  those registers as bridge within the DT.
>
> This is a subblock of the mediamix? Please add 'reg' for the 2 registers
> even if you use a regmap.
>
> I didn't find a binding for mediamix. You really need the containing
> block binding before a child node.
>
> Rob

Re: [PATCH 0/4] Remove support for Hyper-V 2008 and 2008R2/Win7

[Wei Liu]

On Mon, May 02, 2022 at 09:36:27AM -0700, Michael Kelley wrote:
> Linux code for running as a Hyper-V guest includes special cases for the
> first released versions of Hyper-V: 2008 and 2008R2/Windows 7. These
> versions were very thinly used for running Linux guests when first
> released more than 12 years ago, and they are now out of support
> (except for extended security updates). As initial versions, they
> lack the performance features needed for effective production usage
> of Linux guests. In total, there's no need to continue to support
> the latest Linux kernels on these versions of Hyper-V.
> 
> Simplify the code for running on Hyper-V by removing the special
> cases. This includes removing the negotiation of the VMbus protocol
> versions for 2008 and 2008R2, and the special case code based on
> those VMbus protocol versions. Changes are in the core VMbus code and
> several drivers for synthetic VMbus devices.
> 
> Some drivers have driver-specific protocols with the Hyper-V host and
> may have versions of those protocols that are limited to 2008 and
> 2008R2. This patch set does the clean-up only for the top-level
> VMbus protocol versions, and not the driver-specific protocols.
> Cleaning up the driver-specific protocols can be done with
> follow-on patches.
> 
> There's no specific urgency to removing the special case code for
> 2008 and 2008R2, so if the broader Linux kernel community surfaces
> a reason why this clean-up should not be done now, we can wait.
> But I think we want to eventually stop carrying around this extra
> baggage, and based on discussions with the Hyper-V team within
> Microsoft, we're already past the point that it has any value.
> 

I will wait for a week for people to voice their opinions. If I hear no
objection I will apply this series to hyperv-next.

Thanks,
Wei.

> Michael Kelley (4):
>   Drivers: hv: vmbus: Remove support for Hyper-V 2008 and Hyper-V
> 2008R2/Win7
>   scsi: storvsc: Remove support for Hyper-V 2008 and 2008R2/Win7
>   video: hyperv_fb: Remove support for Hyper-V 2008 and 2008R2/Win7
>   drm/hyperv: Remove support for Hyper-V 2008 and 2008R2/Win7
> 
>  drivers/gpu/drm/hyperv/hyperv_drm_proto.c | 23 
>  drivers/hv/channel_mgmt.c | 29 ++-
>  drivers/hv/connection.c   |  6 ++--
>  drivers/hv/vmbus_drv.c| 60 
> +++
>  drivers/scsi/storvsc_drv.c| 36 +--
>  drivers/video/fbdev/hyperv_fb.c   | 23 ++--
>  include/linux/hyperv.h| 10 --
>  7 files changed, 52 insertions(+), 135 deletions(-)
> 
> -- 
> 1.8.3.1
> 

Re: [PATCH v2] drm/doc: add rfc section for small BAR uapi

[Tvrtko Ursulin]

On 03/05/2022 11:22, Matthew Auld wrote:

On 02/05/2022 09:53, Lionel Landwerlin wrote:

On 02/05/2022 10:54, Lionel Landwerlin wrote:

On 20/04/2022 20:13, Matthew Auld wrote:

Add an entry for the new uapi needed for small BAR on DG2+.

v2:
   - Some spelling fixes and other small tweaks. (Akeem & Thomas)
   - Rework error capture interactions, including no longer needing
 NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
   - Add probed_cpu_visible_size. (Lionel)

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
Cc: mesa-...@lists.freedesktop.org
---
  Documentation/gpu/rfc/i915_small_bar.h   | 190 
+++

  Documentation/gpu/rfc/i915_small_bar.rst |  58 +++
  Documentation/gpu/rfc/index.rst  |   4 +
  3 files changed, 252 insertions(+)
  create mode 100644 Documentation/gpu/rfc/i915_small_bar.h
  create mode 100644 Documentation/gpu/rfc/i915_small_bar.rst

diff --git a/Documentation/gpu/rfc/i915_small_bar.h 
b/Documentation/gpu/rfc/i915_small_bar.h

new file mode 100644
index ..7bfd0cf44d35
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_small_bar.h
@@ -0,0 +1,190 @@
+/**
+ * struct __drm_i915_memory_region_info - Describes one region as 
known to the

+ * driver.
+ *
+ * Note this is using both struct drm_i915_query_item and struct 
drm_i915_query.
+ * For this new query we are adding the new query id 
DRM_I915_QUERY_MEMORY_REGIONS

+ * at _i915_query_item.query_id.
+ */
+struct __drm_i915_memory_region_info {
+    /** @region: The class:instance pair encoding */
+    struct drm_i915_gem_memory_class_instance region;
+
+    /** @rsvd0: MBZ */
+    __u32 rsvd0;
+
+    /** @probed_size: Memory probed by the driver (-1 = unknown) */
+    __u64 probed_size;
+
+    /** @unallocated_size: Estimate of memory remaining (-1 = 
unknown) */

+    __u64 unallocated_size;
+
+    union {
+    /** @rsvd1: MBZ */
+    __u64 rsvd1[8];
+    struct {
+    /**
+ * @probed_cpu_visible_size: Memory probed by the driver
+ * that is CPU accessible. (-1 = unknown).
+ *
+ * This will be always be <= @probed_size, and the
+ * remainder(if there is any) will not be CPU
+ * accessible.
+ */
+    __u64 probed_cpu_visible_size;
+    };



Trying to implement userspace support in Vulkan for this, I have an 
additional question about the value of probed_cpu_visible_size.


When is it set to -1?

I'm guessing before there is support for this value it'll be 0 (MBZ).

After after it should either be the entire lmem or something smaller.


-Lionel



Other pain point of this new uAPI, previously we could query the 
unallocated size for each heap.


unallocated_size should always give the same value as probed_size. We 
have the avail tracking, but we don't currently expose that through 
unallocated_size, due to lack of real userspace/user etc.




Now lmem is effectively divided into 2 heaps, but unallocated_size is 
tracking allocation from both parts of lmem.


Yeah, if we ever properly expose the unallocated_size, then we could 
also just add unallocated_cpu_visible_size.




Is adding new I915_MEMORY_CLASS_DEVICE_NON_MAPPABLE out of question?


I don't think it's out of the question...

I guess user-space should be able to get the current flag behaviour just 
by specifying: device, system. And it does give more flexibly to allow 
something like: device, device-nm, smem.


I was also thinking about that option, albeit both regions under the 
existing class just separate instances with "capability" flags differing.


Downsides I thought were a) it does not really match the underlying 
resource, which is one and not two from the backing storage POV, and b) 
it allows userspace to do potentially do too much of restrictive 
regions=device-mappable,system  (even if only an innocent mistake); 
disallowing i915 to manage the space better in cases where multiple 
clients happen to fight over it.


The last part is going back to what I was commenting earlier, where I 
though migrating objects which had cpu-access set to any device should 
be allowed. (When mappable region is over subscribed.)


Regards,

Tvrtko

We can also drop the probed_cpu_visible_size, which would now just be 
the probed_size with device/device-nm. And if we lack device-nm, then 
the entire thing must be CPU mappable.


One of the downsides though, is that we can no longer easily mix object 
pages from both device + device-nm, which we could previously do when we 
didn't specify the flag. At least according to the current 
design/behaviour for @regions that would not be allowed. I guess some 
kind of new flag like ALLOC_MIXED or so? Although currently that is only 
possible with device + device-nm in ttm/i915.





-Lionel






+    };
+};
+
+/**
+ * struct 

Re: (subset) [PATCH v11 00/24] drm/rockchip: RK356x VOP2 support

[Heiko Stuebner]

On Fri, 22 Apr 2022 09:28:17 +0200, Sascha Hauer wrote:
> It's v11 time. There's only one small change to v10. Discussion seems to
> have settled now. Is there anything left that prevents the series from
> being merged? I'd really like to have it in during the next merge
> window.
> 
> This series still depends on:
> drm/rockchip: Refactor IOMMU initialisation 
> (https://lists.freedesktop.org/archives/dri-devel/2022-April/349548.html)
> arm64: dts: rockchip: add basic dts for the radxa rock3 model a
> 
> [...]

Applied, thanks!

[07/24] drm/rockchip: dw_hdmi: add rk3568 support
commit: 28bbb5ffbe32741e65d798070986d212cc11e1bb
[08/24] dt-bindings: display: rockchip: dw-hdmi: Add compatible for rk3568 HDMI
commit: 77b0693f875d4d916d0518ac0de68d4d0de3934f
[09/24] drm/rockchip: dw_hdmi: add regulator support
commit: ca80c4eb4b01a7f1c2f333d0a329937ef9c7f03a
[10/24] dt-bindings: display: rockchip: dw-hdmi: Add regulator support
commit: 80266ccb864b6443fd0bf54bb17444d2632fad21
[15/24] dt-bindings: display: rockchip: dw-hdmi: Make unwedge pinctrl optional
commit: 6e944f52a225484b87bb343d0ba28165edf04b19

Best regards,
-- 
Heiko Stuebner 

Re: [PATCH v11 11/24] drm/rockchip: dw_hdmi: Use auto-generated tables

[Heiko Stübner]

Am Freitag, 22. April 2022, 09:28:28 CEST schrieb Sascha Hauer:
> From: Douglas Anderson 
> 
> The previous tables for mpll_cfg and curr_ctrl were created using the
> 20-pages of example settings provided by the PHY vendor.  Those
> example settings weren't particularly dense, so there were places
> where we were guessing what the settings would be for 10-bit and
> 12-bit (not that we use those anyway).  It was also always a lot of
> extra work every time we wanted to add a new clock rate since we had
> to cross-reference several tables.
> 
> In  I've gone through the work to figure
> out how to generate this table automatically.  Let's now use the
> automatically generated table and then we'll never need to look at it
> again.
> 
> We only support 8-bit mode right now and only support a small number
> of clock rates and I've verified that the only 8-bit rate that was
> affected was 148.5.  That mode appears to have been wrong in the old
> table.
> 
> Signed-off-by: Douglas Anderson 
> Signed-off-by: Yakir Yang 
> Signed-off-by: Sascha Hauer 

This breaks hdmi on my rk3328-rock64 which then ends up in a
[CRTC:37:crtc-0] vblank wait timed out

warning-loop.

Some part of the patch11-14 range also creates sparking horizontal
lines on my rk3288-pinky.

I haven't the time to dig overly deep into that, so left out the
hdmi-rate patches (11-14) for now.


Heiko


> ---
> 
> Notes:
> Changes since v5:
> - Add missing Signed-off-by me
> 
> Changes since v3:
> - new patch
> 
>  drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 130 +++-
>  1 file changed, 69 insertions(+), 61 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
> b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> index fe4f9556239ac..cb43e7b47157d 100644
> --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> @@ -91,80 +91,88 @@ static struct rockchip_hdmi *to_rockchip_hdmi(struct 
> drm_encoder *encoder)
>  
>  static const struct dw_hdmi_mpll_config rockchip_mpll_cfg[] = {
>   {
> - 2700, {
> - { 0x00b3, 0x},
> - { 0x2153, 0x},
> - { 0x40f3, 0x}
> + 30666000, {
> + { 0x00b3, 0x },
> + { 0x2153, 0x },
> + { 0x40f3, 0x },
>   },
> - }, {
> - 3600, {
> - { 0x00b3, 0x},
> - { 0x2153, 0x},
> - { 0x40f3, 0x}
> + },  {
> + 3680, {
> + { 0x00b3, 0x },
> + { 0x2153, 0x },
> + { 0x40a2, 0x0001 },
>   },
> - }, {
> - 4000, {
> - { 0x00b3, 0x},
> - { 0x2153, 0x},
> - { 0x40f3, 0x}
> + },  {
> + 4600, {
> + { 0x00b3, 0x },
> + { 0x2142, 0x0001 },
> + { 0x40a2, 0x0001 },
>   },
> - }, {
> - 5400, {
> - { 0x0072, 0x0001},
> - { 0x2142, 0x0001},
> - { 0x40a2, 0x0001},
> + },  {
> + 61333000, {
> + { 0x0072, 0x0001 },
> + { 0x2142, 0x0001 },
> + { 0x40a2, 0x0001 },
>   },
> - }, {
> - 6500, {
> - { 0x0072, 0x0001},
> - { 0x2142, 0x0001},
> - { 0x40a2, 0x0001},
> + },  {
> + 7360, {
> + { 0x0072, 0x0001 },
> + { 0x2142, 0x0001 },
> + { 0x4061, 0x0002 },
>   },
> - }, {
> - 6600, {
> - { 0x013e, 0x0003},
> - { 0x217e, 0x0002},
> - { 0x4061, 0x0002}
> + },  {
> + 9200, {
> + { 0x0072, 0x0001 },
> + { 0x2145, 0x0002 },
> + { 0x4061, 0x0002 },
>   },
> - }, {
> - 7425, {
> - { 0x0072, 0x0001},
> - { 0x2145, 0x0002},
> - { 0x4061, 0x0002}
> + },  {
> + 122666000, {
> + { 0x0051, 0x0002 },
> + { 0x2145, 0x0002 },
> + { 0x4061, 0x0002 },
>   },
> - }, {
> - 8350, {
> - { 0x0072, 0x0001},
> + },  {
> + 14720, {
> + { 0x0051, 0x0002 },
> + { 0x2145, 0x0002 },
> + { 0x4064, 0x0003 },
>   },
> - }, {
> - 10800, {
> - { 0x0051, 0x0002},
> - 

Re: [PATCH 2/3] drm/msm/mdp5: move iommu_domain_alloc() call close to its usage

[Robin Murphy]

On 2022-05-01 11:10, Dmitry Baryshkov wrote:

Move iommu_domain_alloc() in front of adress space/IOMMU initialization.
This allows us to drop final bits of struct mdp5_cfg_platform which
remained from the pre-DT days.

Signed-off-by: Dmitry Baryshkov 
---
  drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 16 
  drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.h |  6 --
  drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c |  6 --
  3 files changed, 4 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
index 1bf9ff5dbabc..714effb967ff 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
@@ -1248,8 +1248,6 @@ static const struct mdp5_cfg_handler cfg_handlers_v3[] = {
{ .revision = 3, .config = { .hw = _config } },
  };
  
-static struct mdp5_cfg_platform *mdp5_get_config(struct platform_device *dev);

-
  const struct mdp5_cfg_hw *mdp5_cfg_get_hw_config(struct mdp5_cfg_handler 
*cfg_handler)
  {
return cfg_handler->config.hw;
@@ -1274,10 +1272,8 @@ struct mdp5_cfg_handler *mdp5_cfg_init(struct mdp5_kms 
*mdp5_kms,
uint32_t major, uint32_t minor)
  {
struct drm_device *dev = mdp5_kms->dev;
-   struct platform_device *pdev = to_platform_device(dev->dev);
struct mdp5_cfg_handler *cfg_handler;
const struct mdp5_cfg_handler *cfg_handlers;
-   struct mdp5_cfg_platform *pconfig;
int i, ret = 0, num_handlers;
  
  	cfg_handler = kzalloc(sizeof(*cfg_handler), GFP_KERNEL);

@@ -1320,9 +1316,6 @@ struct mdp5_cfg_handler *mdp5_cfg_init(struct mdp5_kms 
*mdp5_kms,
cfg_handler->revision = minor;
cfg_handler->config.hw = mdp5_cfg;
  
-	pconfig = mdp5_get_config(pdev);

-   memcpy(_handler->config.platform, pconfig, sizeof(*pconfig));
-
DBG("MDP5: %s hw config selected", mdp5_cfg->name);
  
  	return cfg_handler;

@@ -1333,12 +1326,3 @@ struct mdp5_cfg_handler *mdp5_cfg_init(struct mdp5_kms 
*mdp5_kms,
  
  	return ERR_PTR(ret);

  }
-
-static struct mdp5_cfg_platform *mdp5_get_config(struct platform_device *dev)
-{
-   static struct mdp5_cfg_platform config = {};
-
-   config.iommu = iommu_domain_alloc(_bus_type);
-
-   return 
-}
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.h 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.h
index 6b03d7899309..c2502cc33864 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.h
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.h
@@ -104,14 +104,8 @@ struct mdp5_cfg_hw {
uint32_t max_clk;
  };
  
-/* platform config data (ie. from DT, or pdata) */

-struct mdp5_cfg_platform {
-   struct iommu_domain *iommu;
-};
-
  struct mdp5_cfg {
const struct mdp5_cfg_hw *hw;
-   struct mdp5_cfg_platform platform;
  };
  
  struct mdp5_kms;

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 9b7bbc3adb97..1c67c2c828cd 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -558,6 +558,7 @@ static int mdp5_kms_init(struct drm_device *dev)
struct msm_gem_address_space *aspace;
int irq, i, ret;
struct device *iommu_dev;
+   struct iommu_domain *iommu;
  
  	ret = mdp5_init(to_platform_device(dev->dev), dev);
  
@@ -601,14 +602,15 @@ static int mdp5_kms_init(struct drm_device *dev)

}
mdelay(16);
  
-	if (config->platform.iommu) {

+   iommu = iommu_domain_alloc(_bus_type);


To preempt the next change down the line as well, could this be 
rearranged to work as iommu_domain_alloc(iommu_dev->bus)?



+   if (iommu) {
struct msm_mmu *mmu;
  
  		iommu_dev = >dev;

if (!dev_iommu_fwspec_get(iommu_dev))


The fwspec helpers are more of an internal thing between the IOMMU 
drivers and the respective firmware code - I'd rather that external API 
users stuck consistently to using device_iommu_mapped() (it should give 
the same result).


Otherwise, thanks for sorting this out!

Robin.


iommu_dev = iommu_dev->parent;
  
-		mmu = msm_iommu_new(iommu_dev, config->platform.iommu);

+   mmu = msm_iommu_new(iommu_dev, iommu);
  
  		aspace = msm_gem_address_space_create(mmu, "mdp5",

0x1000, 0x1 - 0x1000);

Re: [PATCH v2] drm/doc: add rfc section for small BAR uapi

[Lionel Landwerlin]

On 03/05/2022 13:22, Matthew Auld wrote:

On 02/05/2022 09:53, Lionel Landwerlin wrote:

On 02/05/2022 10:54, Lionel Landwerlin wrote:

On 20/04/2022 20:13, Matthew Auld wrote:

Add an entry for the new uapi needed for small BAR on DG2+.

v2:
   - Some spelling fixes and other small tweaks. (Akeem & Thomas)
   - Rework error capture interactions, including no longer needing
 NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
   - Add probed_cpu_visible_size. (Lionel)

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
Cc: mesa-...@lists.freedesktop.org
---
  Documentation/gpu/rfc/i915_small_bar.h   | 190 
+++

  Documentation/gpu/rfc/i915_small_bar.rst |  58 +++
  Documentation/gpu/rfc/index.rst  |   4 +
  3 files changed, 252 insertions(+)
  create mode 100644 Documentation/gpu/rfc/i915_small_bar.h
  create mode 100644 Documentation/gpu/rfc/i915_small_bar.rst

diff --git a/Documentation/gpu/rfc/i915_small_bar.h 
b/Documentation/gpu/rfc/i915_small_bar.h

new file mode 100644
index ..7bfd0cf44d35
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_small_bar.h
@@ -0,0 +1,190 @@
+/**
+ * struct __drm_i915_memory_region_info - Describes one region as 
known to the

+ * driver.
+ *
+ * Note this is using both struct drm_i915_query_item and struct 
drm_i915_query.
+ * For this new query we are adding the new query id 
DRM_I915_QUERY_MEMORY_REGIONS

+ * at _i915_query_item.query_id.
+ */
+struct __drm_i915_memory_region_info {
+    /** @region: The class:instance pair encoding */
+    struct drm_i915_gem_memory_class_instance region;
+
+    /** @rsvd0: MBZ */
+    __u32 rsvd0;
+
+    /** @probed_size: Memory probed by the driver (-1 = unknown) */
+    __u64 probed_size;
+
+    /** @unallocated_size: Estimate of memory remaining (-1 = 
unknown) */

+    __u64 unallocated_size;
+
+    union {
+    /** @rsvd1: MBZ */
+    __u64 rsvd1[8];
+    struct {
+    /**
+ * @probed_cpu_visible_size: Memory probed by the driver
+ * that is CPU accessible. (-1 = unknown).
+ *
+ * This will be always be <= @probed_size, and the
+ * remainder(if there is any) will not be CPU
+ * accessible.
+ */
+    __u64 probed_cpu_visible_size;
+    };



Trying to implement userspace support in Vulkan for this, I have an 
additional question about the value of probed_cpu_visible_size.


When is it set to -1?

I'm guessing before there is support for this value it'll be 0 (MBZ).

After after it should either be the entire lmem or something smaller.


-Lionel



Other pain point of this new uAPI, previously we could query the 
unallocated size for each heap.


unallocated_size should always give the same value as probed_size. We 
have the avail tracking, but we don't currently expose that through 
unallocated_size, due to lack of real userspace/user etc.




Now lmem is effectively divided into 2 heaps, but unallocated_size is 
tracking allocation from both parts of lmem.


Yeah, if we ever properly expose the unallocated_size, then we could 
also just add unallocated_cpu_visible_size.




Is adding new I915_MEMORY_CLASS_DEVICE_NON_MAPPABLE out of question?


I don't think it's out of the question...

I guess user-space should be able to get the current flag behaviour 
just by specifying: device, system. And it does give more flexibly to 
allow something like: device, device-nm, smem.


We can also drop the probed_cpu_visible_size, which would now just be 
the probed_size with device/device-nm. And if we lack device-nm, then 
the entire thing must be CPU mappable.


One of the downsides though, is that we can no longer easily mix 
object pages from both device + device-nm, which we could previously 
do when we didn't specify the flag. At least according to the current 
design/behaviour for @regions that would not be allowed. I guess some 
kind of new flag like ALLOC_MIXED or so? Although currently that is 
only possible with device + device-nm in ttm/i915.



Thanks, I wasn't aware of the restrictions.

Adding unallocated_cpu_visible_size would be great.


-Lionel







-Lionel






+    };
+};
+
+/**
+ * struct __drm_i915_gem_create_ext - Existing gem_create 
behaviour, with added

+ * extension support using struct i915_user_extension.
+ *
+ * Note that new buffer flags should be added here, at least for 
the stuff that
+ * is immutable. Previously we would have two ioctls, one to 
create the object
+ * with gem_create, and another to apply various parameters, 
however this
+ * creates some ambiguity for the params which are considered 
immutable. Also in

+ * general we're phasing out the various SET/GET ioctls.
+ */
+struct __drm_i915_gem_create_ext {
+    /**
+ * @size: Requested size for the object.
+ *
+ * The (page-aligned) allocated 

Re: [PATCH v2] drm/doc: add rfc section for small BAR uapi

[Matthew Auld]

On 02/05/2022 09:53, Lionel Landwerlin wrote:

On 02/05/2022 10:54, Lionel Landwerlin wrote:

On 20/04/2022 20:13, Matthew Auld wrote:

Add an entry for the new uapi needed for small BAR on DG2+.

v2:
   - Some spelling fixes and other small tweaks. (Akeem & Thomas)
   - Rework error capture interactions, including no longer needing
 NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
   - Add probed_cpu_visible_size. (Lionel)

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
Cc: mesa-...@lists.freedesktop.org
---
  Documentation/gpu/rfc/i915_small_bar.h   | 190 +++
  Documentation/gpu/rfc/i915_small_bar.rst |  58 +++
  Documentation/gpu/rfc/index.rst  |   4 +
  3 files changed, 252 insertions(+)
  create mode 100644 Documentation/gpu/rfc/i915_small_bar.h
  create mode 100644 Documentation/gpu/rfc/i915_small_bar.rst

diff --git a/Documentation/gpu/rfc/i915_small_bar.h 
b/Documentation/gpu/rfc/i915_small_bar.h

new file mode 100644
index ..7bfd0cf44d35
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_small_bar.h
@@ -0,0 +1,190 @@
+/**
+ * struct __drm_i915_memory_region_info - Describes one region as 
known to the

+ * driver.
+ *
+ * Note this is using both struct drm_i915_query_item and struct 
drm_i915_query.
+ * For this new query we are adding the new query id 
DRM_I915_QUERY_MEMORY_REGIONS

+ * at _i915_query_item.query_id.
+ */
+struct __drm_i915_memory_region_info {
+    /** @region: The class:instance pair encoding */
+    struct drm_i915_gem_memory_class_instance region;
+
+    /** @rsvd0: MBZ */
+    __u32 rsvd0;
+
+    /** @probed_size: Memory probed by the driver (-1 = unknown) */
+    __u64 probed_size;
+
+    /** @unallocated_size: Estimate of memory remaining (-1 = 
unknown) */

+    __u64 unallocated_size;
+
+    union {
+    /** @rsvd1: MBZ */
+    __u64 rsvd1[8];
+    struct {
+    /**
+ * @probed_cpu_visible_size: Memory probed by the driver
+ * that is CPU accessible. (-1 = unknown).
+ *
+ * This will be always be <= @probed_size, and the
+ * remainder(if there is any) will not be CPU
+ * accessible.
+ */
+    __u64 probed_cpu_visible_size;
+    };



Trying to implement userspace support in Vulkan for this, I have an 
additional question about the value of probed_cpu_visible_size.


When is it set to -1?

I'm guessing before there is support for this value it'll be 0 (MBZ).

After after it should either be the entire lmem or something smaller.


-Lionel



Other pain point of this new uAPI, previously we could query the 
unallocated size for each heap.


unallocated_size should always give the same value as probed_size. We 
have the avail tracking, but we don't currently expose that through 
unallocated_size, due to lack of real userspace/user etc.




Now lmem is effectively divided into 2 heaps, but unallocated_size is 
tracking allocation from both parts of lmem.


Yeah, if we ever properly expose the unallocated_size, then we could 
also just add unallocated_cpu_visible_size.




Is adding new I915_MEMORY_CLASS_DEVICE_NON_MAPPABLE out of question?


I don't think it's out of the question...

I guess user-space should be able to get the current flag behaviour just 
by specifying: device, system. And it does give more flexibly to allow 
something like: device, device-nm, smem.


We can also drop the probed_cpu_visible_size, which would now just be 
the probed_size with device/device-nm. And if we lack device-nm, then 
the entire thing must be CPU mappable.


One of the downsides though, is that we can no longer easily mix object 
pages from both device + device-nm, which we could previously do when we 
didn't specify the flag. At least according to the current 
design/behaviour for @regions that would not be allowed. I guess some 
kind of new flag like ALLOC_MIXED or so? Although currently that is only 
possible with device + device-nm in ttm/i915.





-Lionel






+    };
+};
+
+/**
+ * struct __drm_i915_gem_create_ext - Existing gem_create behaviour, 
with added

+ * extension support using struct i915_user_extension.
+ *
+ * Note that new buffer flags should be added here, at least for the 
stuff that
+ * is immutable. Previously we would have two ioctls, one to create 
the object
+ * with gem_create, and another to apply various parameters, however 
this
+ * creates some ambiguity for the params which are considered 
immutable. Also in

+ * general we're phasing out the various SET/GET ioctls.
+ */
+struct __drm_i915_gem_create_ext {
+    /**
+ * @size: Requested size for the object.
+ *
+ * The (page-aligned) allocated size for the object will be 
returned.

+ *
+ * Note that for some devices we have might have further minimum
+ * page-size restrictions(larger 

Re: [Intel-gfx] [PATCH v2] drm/i915: Fix race in __i915_vma_remove_closed

[Tvrtko Ursulin]

On 20/04/2022 10:57, Karol Herbst wrote:

i915_vma_reopen checked if the vma is closed before without taking the
lock. So multiple threads could attempt removing the vma.

Instead the lock needs to be taken before actually checking.

v2: move struct declaration


Fix looks correct to me. In which case it seems breakage was introduced 
with:


Fixes: 155ab8836caa ("drm/i915: Move object close under its own lock")
Cc: Matthew Auld 
Cc:  # v5.3+

AFAICT at least. I will add these tags and pull it in unless someone 
shouts a correction.


Regards,

Tvrtko


Cc: Chris Wilson 
Cc: intel-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5732
Signed-off-by: Karol Herbst 
---
  drivers/gpu/drm/i915/i915_vma.c | 11 +++
  1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 162e8d83691b..2efdad2b43fa 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1615,17 +1615,17 @@ void i915_vma_close(struct i915_vma *vma)
  
  static void __i915_vma_remove_closed(struct i915_vma *vma)

  {
-   struct intel_gt *gt = vma->vm->gt;
-
-   spin_lock_irq(>closed_lock);
list_del_init(>closed_link);
-   spin_unlock_irq(>closed_lock);
  }
  
  void i915_vma_reopen(struct i915_vma *vma)

  {
+   struct intel_gt *gt = vma->vm->gt;
+
+   spin_lock_irq(>closed_lock);
if (i915_vma_is_closed(vma))
__i915_vma_remove_closed(vma);
+   spin_unlock_irq(>closed_lock);
  }
  
  static void force_unbind(struct i915_vma *vma)

@@ -1641,6 +1641,7 @@ static void force_unbind(struct i915_vma *vma)
  static void release_references(struct i915_vma *vma, bool vm_ddestroy)
  {
struct drm_i915_gem_object *obj = vma->obj;
+   struct intel_gt *gt = vma->vm->gt;
  
  	GEM_BUG_ON(i915_vma_is_active(vma));
  
@@ -1651,7 +1652,9 @@ static void release_references(struct i915_vma *vma, bool vm_ddestroy)
  
  	spin_unlock(>vma.lock);
  
+	spin_lock_irq(>closed_lock);

__i915_vma_remove_closed(vma);
+   spin_unlock_irq(>closed_lock);
  
  	if (vm_ddestroy)

i915_vm_resv_put(vma->vm);

Re: (subset) [PATCH v11 00/24] drm/rockchip: RK356x VOP2 support

[Heiko Stuebner]

On Fri, 22 Apr 2022 09:28:17 +0200, Sascha Hauer wrote:
> It's v11 time. There's only one small change to v10. Discussion seems to
> have settled now. Is there anything left that prevents the series from
> being merged? I'd really like to have it in during the next merge
> window.
> 
> This series still depends on:
> drm/rockchip: Refactor IOMMU initialisation 
> (https://lists.freedesktop.org/archives/dri-devel/2022-April/349548.html)
> arm64: dts: rockchip: add basic dts for the radxa rock3 model a
> 
> [...]

Applied, thanks!

[06/24] arm64: dts: rockchip: rk3399: rename HDMI ref clock to 'ref'
commit: bd820bc5e77087a71a42c36f2660b8a35d2c01a5

Best regards,
-- 
Heiko Stuebner 

Re: (subset) [PATCH v11 00/24] drm/rockchip: RK356x VOP2 support

[Heiko Stuebner]

On Fri, 22 Apr 2022 09:28:17 +0200, Sascha Hauer wrote:
> It's v11 time. There's only one small change to v10. Discussion seems to
> have settled now. Is there anything left that prevents the series from
> being merged? I'd really like to have it in during the next merge
> window.
> 
> This series still depends on:
> drm/rockchip: Refactor IOMMU initialisation 
> (https://lists.freedesktop.org/archives/dri-devel/2022-April/349548.html)
> arm64: dts: rockchip: add basic dts for the radxa rock3 model a
> 
> [...]

Applied, thanks!

[02/24] drm/rockchip: Embed drm_encoder into rockchip_decoder
commit: 540b8f271e53362a308f6bf288d38b630cf3fbd2
[03/24] drm/rockchip: Add crtc_endpoint_id to rockchip_encoder
commit: cf544c6a885c52d79e4d8bf139fb8cb63a878512
[04/24] drm/rockchip: dw_hdmi: rename vpll clock to reference clock
commit: a9d37e684492ab5db1cce28b655e20c01191873f
[05/24] dt-bindings: display: rockchip: dw-hdmi: use "ref" as clock name
commit: a5fc012e6ee75a899173398573e77207542f588a

Best regards,
-- 
Heiko Stuebner 

Re: [PATCH v2] drm/doc: add rfc section for small BAR uapi

[Lionel Landwerlin]

On 03/05/2022 12:07, Matthew Auld wrote:

On 02/05/2022 19:03, Lionel Landwerlin wrote:

On 02/05/2022 20:58, Abodunrin, Akeem G wrote:



-Original Message-
From: Landwerlin, Lionel G 
Sent: Monday, May 2, 2022 12:55 AM
To: Auld, Matthew ; 
intel-...@lists.freedesktop.org

Cc: dri-devel@lists.freedesktop.org; Thomas Hellström
; Bloomfield, Jon
; Daniel Vetter ; 
Justen,

Jordan L ; Kenneth Graunke
; Abodunrin, Akeem G
; mesa-...@lists.freedesktop.org
Subject: Re: [PATCH v2] drm/doc: add rfc section for small BAR uapi

On 20/04/2022 20:13, Matthew Auld wrote:

Add an entry for the new uapi needed for small BAR on DG2+.

v2:
    - Some spelling fixes and other small tweaks. (Akeem & Thomas)
    - Rework error capture interactions, including no longer needing
  NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
    - Add probed_cpu_visible_size. (Lionel)

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
Cc: mesa-...@lists.freedesktop.org
---
   Documentation/gpu/rfc/i915_small_bar.h   | 190

+++

Documentation/gpu/rfc/i915_small_bar.rst |  58 +++
   Documentation/gpu/rfc/index.rst  |   4 +
   3 files changed, 252 insertions(+)
   create mode 100644 Documentation/gpu/rfc/i915_small_bar.h
   create mode 100644 Documentation/gpu/rfc/i915_small_bar.rst

diff --git a/Documentation/gpu/rfc/i915_small_bar.h
b/Documentation/gpu/rfc/i915_small_bar.h
new file mode 100644
index ..7bfd0cf44d35
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_small_bar.h
@@ -0,0 +1,190 @@
+/**
+ * struct __drm_i915_memory_region_info - Describes one region as
+known to the
+ * driver.
+ *
+ * Note this is using both struct drm_i915_query_item and struct

drm_i915_query.

+ * For this new query we are adding the new query id
+DRM_I915_QUERY_MEMORY_REGIONS
+ * at _i915_query_item.query_id.
+ */
+struct __drm_i915_memory_region_info {
+   /** @region: The class:instance pair encoding */
+   struct drm_i915_gem_memory_class_instance region;
+
+   /** @rsvd0: MBZ */
+   __u32 rsvd0;
+
+   /** @probed_size: Memory probed by the driver (-1 = unknown) */
+   __u64 probed_size;
+
+   /** @unallocated_size: Estimate of memory remaining (-1 = 
unknown)

*/

+   __u64 unallocated_size;
+
+   union {
+   /** @rsvd1: MBZ */
+   __u64 rsvd1[8];
+   struct {
+   /**
+    * @probed_cpu_visible_size: Memory probed by the

driver

+    * that is CPU accessible. (-1 = unknown).
+    *
+    * This will be always be <= @probed_size, and 
the

+    * remainder(if there is any) will not be CPU
+    * accessible.
+    */
+   __u64 probed_cpu_visible_size;
+   };


Trying to implement userspace support in Vulkan for this, I have an 
additional

question about the value of probed_cpu_visible_size.

When is it set to -1?
I believe it is set to -1 if it is unknown, and/or not cpu 
accessible...


Cheers!
~Akeem



So what should I expect on system memory?


I guess just probed_cpu_visible_size == probed_size. Or maybe we can 
just use -1 here?




What value is returned when all of probed_size is CPU visible on 
local memory?


probed_size == probed_cpu_visible_size.



Thanks, looks good to me.

Then maybe we should update the comment to say that.

Looks like there are no cases where we'll get -1.


-Lionel







Thanks,


-Lionel



I'm guessing before there is support for this value it'll be 0 (MBZ).

After after it should either be the entire lmem or something smaller.


-Lionel



+   };
+};
+
+/**
+ * struct __drm_i915_gem_create_ext - Existing gem_create behaviour,
+with added
+ * extension support using struct i915_user_extension.
+ *
+ * Note that new buffer flags should be added here, at least for the
+stuff that
+ * is immutable. Previously we would have two ioctls, one to create
+the object
+ * with gem_create, and another to apply various parameters, however
+this
+ * creates some ambiguity for the params which are considered
+immutable. Also in
+ * general we're phasing out the various SET/GET ioctls.
+ */
+struct __drm_i915_gem_create_ext {
+   /**
+    * @size: Requested size for the object.
+    *
+    * The (page-aligned) allocated size for the object will be 
returned.

+    *
+    * Note that for some devices we have might have further minimum
+    * page-size restrictions(larger than 4K), like for device 
local-memory.
+    * However in general the final size here should always 
reflect any

+    * rounding up, if for example using the

I915_GEM_CREATE_EXT_MEMORY_REGIONS

+    * extension to place the object in device local-memory.
+    */
+   __u64 size;
+   /**
+    * @handle: Returned handle for the object.
+    *
+    * Object handles are nonzero.
+    */
+   __u32 handle;
+   /**

Re: (subset) [PATCH v11 00/24] drm/rockchip: RK356x VOP2 support

[Heiko Stuebner]

On Fri, 22 Apr 2022 09:28:17 +0200, Sascha Hauer wrote:
> It's v11 time. There's only one small change to v10. Discussion seems to
> have settled now. Is there anything left that prevents the series from
> being merged? I'd really like to have it in during the next merge
> window.
> 
> This series still depends on:
> drm/rockchip: Refactor IOMMU initialisation 
> (https://lists.freedesktop.org/archives/dri-devel/2022-April/349548.html)
> arm64: dts: rockchip: add basic dts for the radxa rock3 model a
> 
> [...]

Applied, thanks!

[01/24] clk: rk3568: Mark hclk_vo as critical
commit: 602c602204dff45b8fb4dbe5ca5ba163991fb778

Best regards,
-- 
Heiko Stuebner 

Re: [PATCH v2] drm/doc: add rfc section for small BAR uapi

[Matthew Auld]

On 02/05/2022 19:03, Lionel Landwerlin wrote:

On 02/05/2022 20:58, Abodunrin, Akeem G wrote:



-Original Message-
From: Landwerlin, Lionel G 
Sent: Monday, May 2, 2022 12:55 AM
To: Auld, Matthew ; 
intel-...@lists.freedesktop.org

Cc: dri-devel@lists.freedesktop.org; Thomas Hellström
; Bloomfield, Jon
; Daniel Vetter ; 
Justen,

Jordan L ; Kenneth Graunke
; Abodunrin, Akeem G
; mesa-...@lists.freedesktop.org
Subject: Re: [PATCH v2] drm/doc: add rfc section for small BAR uapi

On 20/04/2022 20:13, Matthew Auld wrote:

Add an entry for the new uapi needed for small BAR on DG2+.

v2:
    - Some spelling fixes and other small tweaks. (Akeem & Thomas)
    - Rework error capture interactions, including no longer needing
  NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
    - Add probed_cpu_visible_size. (Lionel)

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
Cc: mesa-...@lists.freedesktop.org
---
   Documentation/gpu/rfc/i915_small_bar.h   | 190

+++

   Documentation/gpu/rfc/i915_small_bar.rst |  58 +++
   Documentation/gpu/rfc/index.rst  |   4 +
   3 files changed, 252 insertions(+)
   create mode 100644 Documentation/gpu/rfc/i915_small_bar.h
   create mode 100644 Documentation/gpu/rfc/i915_small_bar.rst

diff --git a/Documentation/gpu/rfc/i915_small_bar.h
b/Documentation/gpu/rfc/i915_small_bar.h
new file mode 100644
index ..7bfd0cf44d35
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_small_bar.h
@@ -0,0 +1,190 @@
+/**
+ * struct __drm_i915_memory_region_info - Describes one region as
+known to the
+ * driver.
+ *
+ * Note this is using both struct drm_i915_query_item and struct

drm_i915_query.

+ * For this new query we are adding the new query id
+DRM_I915_QUERY_MEMORY_REGIONS
+ * at _i915_query_item.query_id.
+ */
+struct __drm_i915_memory_region_info {
+   /** @region: The class:instance pair encoding */
+   struct drm_i915_gem_memory_class_instance region;
+
+   /** @rsvd0: MBZ */
+   __u32 rsvd0;
+
+   /** @probed_size: Memory probed by the driver (-1 = unknown) */
+   __u64 probed_size;
+
+   /** @unallocated_size: Estimate of memory remaining (-1 = unknown)

*/

+   __u64 unallocated_size;
+
+   union {
+   /** @rsvd1: MBZ */
+   __u64 rsvd1[8];
+   struct {
+   /**
+    * @probed_cpu_visible_size: Memory probed by the

driver

+    * that is CPU accessible. (-1 = unknown).
+    *
+    * This will be always be <= @probed_size, and the
+    * remainder(if there is any) will not be CPU
+    * accessible.
+    */
+   __u64 probed_cpu_visible_size;
+   };


Trying to implement userspace support in Vulkan for this, I have an 
additional

question about the value of probed_cpu_visible_size.

When is it set to -1?

I believe it is set to -1 if it is unknown, and/or not cpu accessible...

Cheers!
~Akeem



So what should I expect on system memory?


I guess just probed_cpu_visible_size == probed_size. Or maybe we can 
just use -1 here?




What value is returned when all of probed_size is CPU visible on local 
memory?


probed_size == probed_cpu_visible_size.




Thanks,


-Lionel



I'm guessing before there is support for this value it'll be 0 (MBZ).

After after it should either be the entire lmem or something smaller.


-Lionel



+   };
+};
+
+/**
+ * struct __drm_i915_gem_create_ext - Existing gem_create behaviour,
+with added
+ * extension support using struct i915_user_extension.
+ *
+ * Note that new buffer flags should be added here, at least for the
+stuff that
+ * is immutable. Previously we would have two ioctls, one to create
+the object
+ * with gem_create, and another to apply various parameters, however
+this
+ * creates some ambiguity for the params which are considered
+immutable. Also in
+ * general we're phasing out the various SET/GET ioctls.
+ */
+struct __drm_i915_gem_create_ext {
+   /**
+    * @size: Requested size for the object.
+    *
+    * The (page-aligned) allocated size for the object will be 
returned.

+    *
+    * Note that for some devices we have might have further minimum
+    * page-size restrictions(larger than 4K), like for device 
local-memory.

+    * However in general the final size here should always reflect any
+    * rounding up, if for example using the

I915_GEM_CREATE_EXT_MEMORY_REGIONS

+    * extension to place the object in device local-memory.
+    */
+   __u64 size;
+   /**
+    * @handle: Returned handle for the object.
+    *
+    * Object handles are nonzero.
+    */
+   __u32 handle;
+   /**
+    * @flags: Optional flags.
+    *
+    * Supported values:
+    *
+    * I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS - Signal to the

kernel that

+    * the object will need to be accessed 

Re: [PATCH v2] drm/doc: add rfc section for small BAR uapi

[Matthew Auld]

On 02/05/2022 08:54, Lionel Landwerlin wrote:

On 20/04/2022 20:13, Matthew Auld wrote:

Add an entry for the new uapi needed for small BAR on DG2+.

v2:
   - Some spelling fixes and other small tweaks. (Akeem & Thomas)
   - Rework error capture interactions, including no longer needing
 NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
   - Add probed_cpu_visible_size. (Lionel)

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
Cc: mesa-...@lists.freedesktop.org
---
  Documentation/gpu/rfc/i915_small_bar.h   | 190 +++
  Documentation/gpu/rfc/i915_small_bar.rst |  58 +++
  Documentation/gpu/rfc/index.rst  |   4 +
  3 files changed, 252 insertions(+)
  create mode 100644 Documentation/gpu/rfc/i915_small_bar.h
  create mode 100644 Documentation/gpu/rfc/i915_small_bar.rst

diff --git a/Documentation/gpu/rfc/i915_small_bar.h 
b/Documentation/gpu/rfc/i915_small_bar.h

new file mode 100644
index ..7bfd0cf44d35
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_small_bar.h
@@ -0,0 +1,190 @@
+/**
+ * struct __drm_i915_memory_region_info - Describes one region as 
known to the

+ * driver.
+ *
+ * Note this is using both struct drm_i915_query_item and struct 
drm_i915_query.
+ * For this new query we are adding the new query id 
DRM_I915_QUERY_MEMORY_REGIONS

+ * at _i915_query_item.query_id.
+ */
+struct __drm_i915_memory_region_info {
+    /** @region: The class:instance pair encoding */
+    struct drm_i915_gem_memory_class_instance region;
+
+    /** @rsvd0: MBZ */
+    __u32 rsvd0;
+
+    /** @probed_size: Memory probed by the driver (-1 = unknown) */
+    __u64 probed_size;
+
+    /** @unallocated_size: Estimate of memory remaining (-1 = 
unknown) */

+    __u64 unallocated_size;
+
+    union {
+    /** @rsvd1: MBZ */
+    __u64 rsvd1[8];
+    struct {
+    /**
+ * @probed_cpu_visible_size: Memory probed by the driver
+ * that is CPU accessible. (-1 = unknown).
+ *
+ * This will be always be <= @probed_size, and the
+ * remainder(if there is any) will not be CPU
+ * accessible.
+ */
+    __u64 probed_cpu_visible_size;
+    };



Trying to implement userspace support in Vulkan for this, I have an 
additional question about the value of probed_cpu_visible_size.


When is it set to -1?


I don't anything is currently using -1, for any of these fields.



I'm guessing before there is support for this value it'll be 0 (MBZ).

After after it should either be the entire lmem or something smaller.


Yup.




-Lionel



+    };
+};
+
+/**
+ * struct __drm_i915_gem_create_ext - Existing gem_create behaviour, 
with added

+ * extension support using struct i915_user_extension.
+ *
+ * Note that new buffer flags should be added here, at least for the 
stuff that
+ * is immutable. Previously we would have two ioctls, one to create 
the object
+ * with gem_create, and another to apply various parameters, however 
this
+ * creates some ambiguity for the params which are considered 
immutable. Also in

+ * general we're phasing out the various SET/GET ioctls.
+ */
+struct __drm_i915_gem_create_ext {
+    /**
+ * @size: Requested size for the object.
+ *
+ * The (page-aligned) allocated size for the object will be 
returned.

+ *
+ * Note that for some devices we have might have further minimum
+ * page-size restrictions(larger than 4K), like for device 
local-memory.

+ * However in general the final size here should always reflect any
+ * rounding up, if for example using the 
I915_GEM_CREATE_EXT_MEMORY_REGIONS

+ * extension to place the object in device local-memory.
+ */
+    __u64 size;
+    /**
+ * @handle: Returned handle for the object.
+ *
+ * Object handles are nonzero.
+ */
+    __u32 handle;
+    /**
+ * @flags: Optional flags.
+ *
+ * Supported values:
+ *
+ * I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS - Signal to the 
kernel that

+ * the object will need to be accessed via the CPU.
+ *
+ * Only valid when placing objects in I915_MEMORY_CLASS_DEVICE, and
+ * only strictly required on platforms where only some of the device
+ * memory is directly visible or mappable through the CPU, like 
on DG2+.

+ *
+ * One of the placements MUST also be I915_MEMORY_CLASS_SYSTEM, to
+ * ensure we can always spill the allocation to system memory, if we
+ * can't place the object in the mappable part of
+ * I915_MEMORY_CLASS_DEVICE.
+ *
+ * Note that since the kernel only supports flat-CCS on objects 
that can

+ * *only* be placed in I915_MEMORY_CLASS_DEVICE, we therefore don't
+ * support I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS together with
+ * flat-CCS.
+ *
+ * Without this hint, the kernel 

Re: [Intel-gfx] [PATCH 06/11] drm/i915/pvc: Reduce stack usage in reset selftest with extra blitter engine

[Tvrtko Ursulin]

On 02/05/2022 17:34, Matt Roper wrote:

From: John Harrison 

PVC adds extra blitter engines (in the following patch). The reset
selftest has a local array on the stack which is sized by the number
of engines. The increase pushes the size of this array to the point
where it trips the 'stack too large' compile warning. This patch takes
the allocation of the stack and makes it dynamic instead.

Signed-off-by: John Harrison 
Signed-off-by: Matt Roper 
---
  drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 9 +++--
  1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c 
b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
index 83ff4c2e57c5..3b9d82276db2 100644
--- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
+++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
@@ -979,6 +979,7 @@ static int __igt_reset_engines(struct intel_gt *gt,
enum intel_engine_id id, tmp;
struct hang h;
int err = 0;
+   struct active_engine *threads;


Drive by nits - sticks out like a sore thumb a bit here - I'd put it 
above "id, tmp" so it's all nicely sorted by width.
  
  	/* Check that issuing a reset on one engine does not interfere

 * with any other engine.
@@ -996,8 +997,11 @@ static int __igt_reset_engines(struct intel_gt *gt,
h.ctx->sched.priority = 1024;
}
  
+	threads = kzalloc(sizeof(*threads) * I915_NUM_ENGINES, GFP_KERNEL);


And this could be kcalloc (or kmalloc_array since zeroing is not needed) 
if that's any better. Seems selftests use that pattern anyway.


Both comments are optional really.

Regards,

Tvrtko


+   if (!threads)
+   return -ENOMEM;
+
for_each_engine(engine, gt, id) {
-   struct active_engine threads[I915_NUM_ENGINES] = {};
unsigned long device = i915_reset_count(global);
unsigned long count = 0, reported;
bool using_guc = intel_engine_uses_guc(engine);
@@ -1016,7 +1020,7 @@ static int __igt_reset_engines(struct intel_gt *gt,
break;
}
  
-		memset(threads, 0, sizeof(threads));

+   memset(threads, 0, sizeof(*threads) * I915_NUM_ENGINES);
for_each_engine(other, gt, tmp) {
struct task_struct *tsk;
  
@@ -1236,6 +1240,7 @@ static int __igt_reset_engines(struct intel_gt *gt,

break;
}
}
+   kfree(threads);
  
  	if (intel_gt_is_wedged(gt))

err = -EIO;

Re: [PATCH] drm/i915/gem: Make drop_pages() return bool

[Das, Nirmoy]

On 5/3/2022 8:15 AM, Lucas De Marchi wrote:

Commit e4e806253003 ("drm/i915: Change shrink ordering to use locking
around unbinding.") changed the return type to int without changing the
return values or their meaning to "0 is success". Move it back to
boolean.

Signed-off-by: Lucas De Marchi 



Reviewed-by: Nirmoy Das 


---
  drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c 
b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
index 6a6ff98a8746..1030053571a2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
@@ -36,7 +36,7 @@ static bool can_release_pages(struct drm_i915_gem_object *obj)
return swap_available() || obj->mm.madv == I915_MADV_DONTNEED;
  }
  
-static int drop_pages(struct drm_i915_gem_object *obj,

+static bool drop_pages(struct drm_i915_gem_object *obj,
   unsigned long shrink, bool trylock_vm)
  {
unsigned long flags;

Re: [Intel-gfx] [PATCH 00/11] i915: Introduce Ponte Vecchio

[Tvrtko Ursulin]

On 02/05/2022 17:34, Matt Roper wrote:

Ponte Vecchio (PVC) is a new GPU based on the Xe_HPC architecture.  As a
compute-focused platform, PVC has compute engines and enhanced copy
engines, but no render engine (there is no geometry pipeline) and no
display.

This is just a handful of early enablement patches, including some
initial support for the new copy engines (although we're not yet adding
those to the platform's engine list or exposing them to userspace just
yet).


IMO lets hold off merging this until next week if that sounds 
acceptable? This week I need to do a final pull for final bits of DG2 
and I would like to keep it as small as possible.


Regards,

Tvrtko



Ayaz A Siddiqui (1):
   drm/i915/pvc: Define MOCS table for PVC

John Harrison (1):
   drm/i915/pvc: Reduce stack usage in reset selftest with extra blitter
 engine

Lucas De Marchi (2):
   drm/i915/pvc: skip all copy engines from aux table invalidate
   drm/i915/pvc: read fuses for link copy engines

Matt Roper (5):
   drm/i915/pvc: Add forcewake support
   drm/i915/pvc: Read correct RP_STATE_CAP register
   drm/i915/pvc: Engines definitions for new copy engines
   drm/i915/pvc: Interrupt support for new copy engines
   drm/i915/pvc: Reset support for new copy engines

Stuart Summers (2):
   drm/i915/pvc: add initial Ponte Vecchio definitions
   drm/i915/pvc: Remove additional 3D flags from PIPE_CONTROL

  drivers/gpu/drm/i915/gt/gen8_engine_cs.c  |  20 ++-
  drivers/gpu/drm/i915/gt/intel_engine_cs.c |  92 +++
  drivers/gpu/drm/i915/gt/intel_engine_types.h  |  10 +-
  drivers/gpu/drm/i915/gt/intel_gpu_commands.h  |  12 +-
  drivers/gpu/drm/i915/gt/intel_gt_irq.c|  16 ++
  drivers/gpu/drm/i915/gt/intel_gt_regs.h   |  56 ---
  drivers/gpu/drm/i915/gt/intel_gt_types.h  |   1 +
  drivers/gpu/drm/i915/gt/intel_mocs.c  |  24 ++-
  drivers/gpu/drm/i915/gt/intel_rps.c   |   4 +-
  drivers/gpu/drm/i915/gt/intel_workarounds.c   |  13 +-
  drivers/gpu/drm/i915/gt/selftest_hangcheck.c  |   9 +-
  drivers/gpu/drm/i915/gvt/cmd_parser.c |   2 +-
  drivers/gpu/drm/i915/i915_drv.h   |   6 +
  drivers/gpu/drm/i915/i915_pci.c   |  23 +++
  drivers/gpu/drm/i915/i915_reg.h   |   9 ++
  drivers/gpu/drm/i915/intel_device_info.c  |   1 +
  drivers/gpu/drm/i915/intel_device_info.h  |   5 +-
  drivers/gpu/drm/i915/intel_uncore.c   | 150 +-
  drivers/gpu/drm/i915/selftests/intel_uncore.c |   2 +
  19 files changed, 417 insertions(+), 38 deletions(-)