Re: [PATCH] drm/amdgpu/discovery: fix possible memory leak

[Yang Yingliang]

Hi,

On 2022/10/19 11:37, Luben Tuikov wrote:

On 2022-10-18 04:05, Yang Yingliang wrote:

If kset_register() fails, the refcount of device is not 0, the name allocated
in dev_set_name() is leaked. Fix this by calling kset_put(), so that it will
be freed in callback function kobject_cleanup().


Good catch, but looking at the code it seems that what is being
leaked is the memory pointed to by kset.kobj.name which is allocated
in kobject_set_name(&kset.kobj, ...), which is called right
before the call to kset_register().


Ah, I forgot to use format-patch to generate new patch after updating commit

message in my local tree and sent a old one. Thanks for point out.


Modify the description with this explanation and repost the patch and I'll R-B 
it then.
Something like:


If kset_register() fails, the refcount of the device is not 0, and the name 
allocated
in kobject_set_name(&kset.kobj, ...) is leaked. Fix this by calling kset_put(),
so that kset.kobj.name is freed in the callback function kobject_cleanup().

Now, if there's a leak of dev_set_name(), then that would be something
else/another patch.

The rest below looks good.

Since this patch touches only files under drm/amd/amdgpu/ and for a highly 
AMD-specific
feature, you didn't need to spam the dri-dev ML--amdgfx ML should be plenty 
enough.

OK.

Thanks,
Yang


Regards,
Luben


Fixes: a6c40b178092 ("drm/amdgpu: Show IP discovery in sysfs")
Signed-off-by: Yang Yingliang 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
index 3993e6134914..638edcf70227 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
@@ -863,7 +863,7 @@ static int amdgpu_discovery_sysfs_ips(struct amdgpu_device 
*adev,
res = kset_register(&ip_hw_id->hw_id_kset);
if (res) {
DRM_ERROR("Couldn't register ip_hw_id 
kset");
-   kfree(ip_hw_id);
+   kset_put(&ip_hw_id->hw_id_kset);
return res;
}
if (hw_id_names[ii]) {
@@ -954,7 +954,7 @@ static int amdgpu_discovery_sysfs_recurse(struct 
amdgpu_device *adev)
res = kset_register(&ip_die_entry->ip_kset);
if (res) {
DRM_ERROR("Couldn't register ip_die_entry kset");
-   kfree(ip_die_entry);
+   kset_put(&ip_die_entry->ip_kset);
return res;
}
  
@@ -989,6 +989,7 @@ static int amdgpu_discovery_sysfs_init(struct amdgpu_device *adev)

res = kset_register(&adev->ip_top->die_kset);
if (res) {
DRM_ERROR("Couldn't register die_kset");
+   kset_put(&adev->ip_top->die_kset);
goto Err;
}
  

.

[PATCH -next] drm/amd/display: make dcn32_mpc_funcs static

[ruanjinjie]

The symbol is not used outside of the file, so mark it static.

Fixes the following warning:

drivers/gpu/drm/amd/amdgpu/../display/dc/dcn32/dcn32_mpc.c:985:24: warning:
symbol 'dcn32_mpc_funcs' was not declared. Should it be static?

Signed-off-by: ruanjinjie 
---
 drivers/gpu/drm/amd/display/dc/dcn32/dcn32_mpc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_mpc.c 
b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_mpc.c
index 4edd0655965b..206a5ddbaf6d 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_mpc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_mpc.c
@@ -982,7 +982,7 @@ static bool mpc32_program_3dlut(
return true;
 }
 
-const struct mpc_funcs dcn32_mpc_funcs = {
+static const struct mpc_funcs dcn32_mpc_funcs = {
.read_mpcc_state = mpc1_read_mpcc_state,
.insert_plane = mpc1_insert_plane,
.remove_mpcc = mpc1_remove_mpcc,
-- 
2.25.1

[PATCH -next] drm/amd/display: make dcn32_mmhubbub_funcs static

[ruanjinjie]

The symbol is not used outside of the file, so mark it static.

Fixes the following warning:

drivers/gpu/drm/amd/amdgpu/../display/dc/dcn32/dcn32_mmhubbub.c:214:28:
warning: symbol 'dcn32_mmhubbub_funcs' was
not declared. Should it be static?

Signed-off-by: ruanjinjie 
---
 drivers/gpu/drm/amd/display/dc/dcn32/dcn32_mmhubbub.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_mmhubbub.c 
b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_mmhubbub.c
index 41b0baf8e183..c3b089ba511a 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_mmhubbub.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_mmhubbub.c
@@ -211,7 +211,7 @@ static void mmhubbub32_config_mcif_arb(struct mcif_wb 
*mcif_wb,
REG_UPDATE(MCIF_WB_ARBITRATION_CONTROL, 
MCIF_WB_CLIENT_ARBITRATION_SLICE,  params->arbitration_slice);
 }
 
-const struct mcif_wb_funcs dcn32_mmhubbub_funcs = {
+static const struct mcif_wb_funcs dcn32_mmhubbub_funcs = {
.warmup_mcif= mmhubbub32_warmup_mcif,
.enable_mcif= mmhubbub2_enable_mcif,
.disable_mcif   = mmhubbub2_disable_mcif,
-- 
2.25.1

Re: [PATCH v2] drm_bridge: register content protect property

[Hsin-Yi Wang]

On Wed, Oct 19, 2022 at 2:26 AM Sean Paul  wrote:
>
> On Mon, Oct 17, 2022 at 9:49 AM Hsin-Yi Wang  wrote:
> >
> > On Wed, Oct 12, 2022 at 12:20 PM Hsin-Yi Wang  wrote:
> > >
> > > Some bridges are able to update HDCP status from userspace request if
> > > they support HDCP.
> > >
> > > HDCP property is the same as other connector properties that need to be
> > > created after the connecter is initialized and before the connector is
> > > registered.
> > >
> > anx7625 is a user for this.
>
> I feel like we should not unconditionally attach this property for
> bridges, this should be done in the driver which supports it IMO.
>
I sent another version to register the property in drm driver:
https://lore.kernel.org/lkml/20221019061936.3599965-1-hsi...@chromium.org/T/#u

Ideally it should be registered by the bridge driver. But some bridge
drivers have already changed to DRM_BRIDGE_ATTACH_NO_CONNECTOR, so
they can't get a connector during the attach stage (or any time before
the connector is registered). Is it acceptable that drm driver help
register the property if CONFIG_DRM_DISPLAY_HDCP_HELPER is defined?

Thanks

> Sean
>
> >
> >
> > > Signed-off-by: Hsin-Yi Wang 
> > > Reported-by: kernel test robot 
> > > ---
> > > v2: Fix compile error when config is not set.
> > > ---
> > >  drivers/gpu/drm/drm_bridge_connector.c | 3 +++
> > >  include/drm/display/drm_hdcp_helper.h  | 8 
> > >  2 files changed, 11 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_bridge_connector.c 
> > > b/drivers/gpu/drm/drm_bridge_connector.c
> > > index 1c7d936523df5..a3b9ef8dc3f0b 100644
> > > --- a/drivers/gpu/drm/drm_bridge_connector.c
> > > +++ b/drivers/gpu/drm/drm_bridge_connector.c
> > > @@ -7,6 +7,7 @@
> > >  #include 
> > >  #include 
> > >
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -398,6 +399,8 @@ struct drm_connector 
> > > *drm_bridge_connector_init(struct drm_device *drm,
> > > if (panel_bridge)
> > > drm_panel_bridge_set_orientation(connector, panel_bridge);
> > >
> > > +   drm_connector_attach_content_protection_property(connector, true);
> > > +
> > > return connector;
> > >  }
> > >  EXPORT_SYMBOL_GPL(drm_bridge_connector_init);
> > > diff --git a/include/drm/display/drm_hdcp_helper.h 
> > > b/include/drm/display/drm_hdcp_helper.h
> > > index 8aaf87bf27351..c65d9f06a2532 100644
> > > --- a/include/drm/display/drm_hdcp_helper.h
> > > +++ b/include/drm/display/drm_hdcp_helper.h
> > > @@ -15,8 +15,16 @@ struct drm_device;
> > >  struct drm_connector;
> > >
> > >  int drm_hdcp_check_ksvs_revoked(struct drm_device *dev, u8 *ksvs, u32 
> > > ksv_count);
> > > +#if defined(CONFIG_DRM_DISPLAY_HDCP_HELPER)
> > >  int drm_connector_attach_content_protection_property(struct 
> > > drm_connector *connector,
> > >  bool 
> > > hdcp_content_type);
> > > +#else
> > > +static inline int 
> > > drm_connector_attach_content_protection_property(struct drm_connector 
> > > *connector,
> > > +  bool 
> > > hdcp_content_type)
> > > +{
> > > +   return 0;
> > > +}
> > > +#endif
> > >  void drm_hdcp_update_content_protection(struct drm_connector *connector, 
> > > u64 val);
> > >
> > >  #endif
> > > --
> > > 2.38.0.rc1.362.ged0d419d3c-goog
> > >

[PATCH] drm/mediatek: mtk-dpi: register content protect property

[Hsin-Yi Wang]

Register content protect property in drm so that bridge can update
the property from userspace request.

HDCP property needs to be created after the connecter is initialized
and before the connector is registered. Since some bridge may be
attached without connector, register this property in drm driver if
CONFIG_DRM_DISPLAY_HDCP_HELPER is defined.

Signed-off-by: Hsin-Yi Wang 
---
Context: 
https://lore.kernel.org/lkml/20221012042030.573466-1-hsi...@chromium.org/T/
---
 drivers/gpu/drm/mediatek/mtk_dpi.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 508a6d994e831..3374ebe82aeb2 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -18,6 +18,7 @@
 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -799,6 +800,15 @@ static int mtk_dpi_bind(struct device *dev, struct device 
*master, void *data)
ret = PTR_ERR(dpi->connector);
goto err_cleanup;
}
+
+#if defined(CONFIG_DRM_DISPLAY_HDCP_HELPER)
+   ret = drm_connector_attach_content_protection_property(dpi->connector, 
true);
+   if (ret) {
+   dev_err(dev, "attach content protection: %d\n", ret);
+   return ret;
+   }
+#endif
+
drm_connector_attach_encoder(dpi->connector, &dpi->encoder);
 
return 0;
-- 
2.38.0.413.g74048e4d9e-goog

Re: [PATCH 1/3] drm/i915/gt: Change RC6 residency functions to accept register ID's

[Dixit, Ashutosh]

On Mon, 17 Oct 2022 01:27:35 -0700, Jani Nikula wrote:

Hi Jani,

Thanks for reviewing, great suggestions overall. I have taken care of most
of them in series version v6. Please see below.

> On Fri, 14 Oct 2022, Ashutosh Dixit  wrote:
> > @@ -811,9 +809,23 @@ u64 intel_rc6_residency_ns(struct intel_rc6 *rc6, 
> > const i915_reg_t reg)
> > return mul_u64_u32_div(time_hw, mul, div);
> >  }
> >
> > -u64 intel_rc6_residency_us(struct intel_rc6 *rc6, i915_reg_t reg)
> > +u64 intel_rc6_residency_us(struct intel_rc6 *rc6, const enum rc6_res_reg 
> > id)
> > +{
> > +   return DIV_ROUND_UP_ULL(intel_rc6_residency_ns(rc6, id), 1000);
> > +}
> > +
> > +void intel_rc6_print_rc6_res(struct seq_file *m,
> > +const char *title,
> > +const enum rc6_res_reg id)
>
> intel_rc6_print_rc5_res is unnecessary duplication.
>
> intel_rc6_print_residency() maybe?

Done.

>
> >  {
> > -   return DIV_ROUND_UP_ULL(intel_rc6_residency_ns(rc6, reg), 1000);
> > +   struct intel_gt *gt = m->private;
> > +   i915_reg_t reg = gt->rc6.res_reg[id];
> > +   intel_wakeref_t wakeref;
> > +
> > +   with_intel_runtime_pm(gt->uncore->rpm, wakeref)
> > +   seq_printf(m, "%s %u (%llu us)\n", title,
> > +  intel_uncore_read(gt->uncore, reg),
> > +  intel_rc6_residency_us(>->rc6, id));
> >  }
> >
> >  #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
> > diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.h 
> > b/drivers/gpu/drm/i915/gt/intel_rc6.h
> > index b6fea71afc223..584d2d3b2ec3f 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_rc6.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_rc6.h
> > @@ -6,7 +6,7 @@
> >  #ifndef INTEL_RC6_H
> >  #define INTEL_RC6_H
> >
> > -#include "i915_reg_defs.h"
> > +#include "intel_rc6_types.h"
>
> You can forward declare enums as a gcc extension.
>
> enum rc6_res_reg;

Tried but was seeing compile errors so left as is.

> >  struct intel_engine_cs;
> >  struct intel_rc6;
> > @@ -21,7 +21,10 @@ void intel_rc6_sanitize(struct intel_rc6 *rc6);
> >  void intel_rc6_enable(struct intel_rc6 *rc6);
> >  void intel_rc6_disable(struct intel_rc6 *rc6);
> >
> > -u64 intel_rc6_residency_ns(struct intel_rc6 *rc6, i915_reg_t reg);
> > -u64 intel_rc6_residency_us(struct intel_rc6 *rc6, i915_reg_t reg);
> > +u64 intel_rc6_residency_ns(struct intel_rc6 *rc6, const enum rc6_res_reg 
> > id);
> > +u64 intel_rc6_residency_us(struct intel_rc6 *rc6, const enum rc6_res_reg 
> > id);
> > +void intel_rc6_print_rc6_res(struct seq_file *m,
> > +const char *title,
> > +const enum rc6_res_reg id);
>
> "const enum" makes no sense.

Removed. Probably const for pass-by-value function arguments never makes
sense, I had left the const thinking it would indicate that the function
won't modify that argument, but is probably not worth it so removed all
"const enum"s.

>
> >
> >  #endif /* INTEL_RC6_H */
> > diff --git a/drivers/gpu/drm/i915/gt/intel_rc6_types.h 
> > b/drivers/gpu/drm/i915/gt/intel_rc6_types.h
> > index e747492b2f46e..0386a3f6e4dc6 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_rc6_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_rc6_types.h
> > @@ -13,7 +13,17 @@
> >
> >  struct drm_i915_gem_object;
> >
> > +enum rc6_res_reg {
> > +   RC6_RES_REG_RC6_LOCKED,
> > +   RC6_RES_REG_RC6,
> > +   RC6_RES_REG_RC6p,
> > +   RC6_RES_REG_RC6pp
> > +};
>
> Naming: intel_rc6_* for all.

Done.

> I think you need to take the abstraction further away from
> registers. You don't need the *register* part here for anything. Stop
> thinking in terms of registers in the interface.
>
> The callers care about things like "RC6+ residency since boot", and the
> callers don't care about where or how this information originates
> from. They just want the info, and the register is an implementation
> detail hidden behind the interface.
>
> I.e. use the enum to identify the data you want, not which register it
> comes from.

Done, please take a look at the new patch.

>
> > +
> > +#define VLV_RC6_RES_REG_MEDIA_RC6 RC6_RES_REG_RC6p
>
> Please handle this in the enum.

Done.

>
> > +
> >  struct intel_rc6 {
> > +   i915_reg_t res_reg[4];
>
> Maybe the id enum should have _MAX as last value, used for size here.

Done.

Thanks.
--
Ashutosh


>
> > u64 prev_hw_residency[4];
> > u64 cur_residency[4];
> >
> > diff --git a/drivers/gpu/drm/i915/gt/selftest_rc6.c 
> > b/drivers/gpu/drm/i915/gt/selftest_rc6.c
> > index 8c70b7e120749..a236e3f8f3183 100644
> > --- a/drivers/gpu/drm/i915/gt/selftest_rc6.c
> > +++ b/drivers/gpu/drm/i915/gt/selftest_rc6.c
> > @@ -19,11 +19,11 @@ static u64 rc6_residency(struct intel_rc6 *rc6)
> >
> > /* XXX VLV_GT_MEDIA_RC6? */
> >
> > -   result = intel_rc6_residency_ns(rc6, GEN6_GT_GFX_RC6);
> > +   result = intel_rc6_residency_ns(rc6, RC6_RES_REG_RC6);
> > if (HAS_RC6p(rc6_to_i915(rc6)))
> > -   result += intel_rc6_residency_ns(rc6, GEN6_GT_GFX_RC6p);
> > +   result += intel_rc6_residenc

[PATCH 2/4] drm/i915/mtl: Modify CAGF functions for MTL

[Ashutosh Dixit]

From: Badal Nilawar 

Update CAGF functions for MTL to get actual resolved frequency of 3D and
SAMedia.

v2: Update MTL_MIRROR_TARGET_WP1 position/formatting (MattR)
Move MTL branches in cagf functions to top (MattR)
Fix commit message (Andi)
v3: Added comment about registers not needing forcewake for Gen12+ and
returning 0 freq in RC6

Bspec: 66300

Signed-off-by: Ashutosh Dixit 
Signed-off-by: Badal Nilawar 
---
 drivers/gpu/drm/i915/gt/intel_gt_regs.h |  4 
 drivers/gpu/drm/i915/gt/intel_rps.c | 12 ++--
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index a7a0129d0e3fc..b4b1b54ad738f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -21,6 +21,10 @@
  */
 #define PERF_REG(offset)   _MMIO(offset)
 
+/* MTL workpoint reg to get core C state and actual freq of 3D, SAMedia */
+#define MTL_MIRROR_TARGET_WP1  _MMIO(0xc60)
+#define   MTL_CAGF_MASKREG_GENMASK(8, 0)
+
 /* RPM unit config (Gen8+) */
 #define RPM_CONFIG0_MMIO(0xd00)
 #define   GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT3
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
b/drivers/gpu/drm/i915/gt/intel_rps.c
index df21258976d86..5a743ae4dd11e 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -2093,7 +2093,9 @@ u32 intel_rps_get_cagf(struct intel_rps *rps, u32 rpstat)
struct drm_i915_private *i915 = rps_to_i915(rps);
u32 cagf;
 
-   if (GRAPHICS_VER(i915) >= 12)
+   if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70))
+   cagf = rpstat & MTL_CAGF_MASK;
+   else if (GRAPHICS_VER(i915) >= 12)
cagf = (rpstat & GEN12_CAGF_MASK) >> GEN12_CAGF_SHIFT;
else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
cagf = (rpstat >> 8) & 0xff;
@@ -2116,7 +2118,13 @@ static u32 read_cagf(struct intel_rps *rps)
struct intel_uncore *uncore = rps_to_uncore(rps);
u32 freq;
 
-   if (GRAPHICS_VER(i915) >= 12) {
+   /*
+* For Gen12+ reading freq from HW does not need a forcewake and
+* registers will return 0 freq when GT is in RC6
+*/
+   if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70)) {
+   freq = intel_uncore_read(rps_to_gt(rps)->uncore, 
MTL_MIRROR_TARGET_WP1);
+   } else if (GRAPHICS_VER(i915) >= 12) {
freq = intel_uncore_read(uncore, GEN12_RPSTAT1);
} else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915)) {
vlv_punit_get(i915);
-- 
2.38.0

[PATCH 4/4] drm/i915/mtl: C6 residency and C state type for MTL SAMedia

[Ashutosh Dixit]

From: Badal Nilawar 

Add support for C6 residency and C state type for MTL SAMedia. Also add
mtl_drpc.

v2: Fixed review comments (Ashutosh)
v3: Sort registers and fix whitespace errors in intel_gt_regs.h (Matt R)
Remove MTL_CC_SHIFT (Ashutosh)
Adapt to RC6 residency register code refactor (Jani N)
v4: Move MTL branch to top in drpc_show

Signed-off-by: Ashutosh Dixit 
Signed-off-by: Badal Nilawar 
---
 drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 60 ++-
 drivers/gpu/drm/i915/gt/intel_gt_regs.h   |  5 ++
 drivers/gpu/drm/i915/gt/intel_rc6.c   | 17 --
 3 files changed, 77 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c 
b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
index 235d593cfaeba..c88d8ec62b692 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
@@ -256,6 +256,62 @@ static int ilk_drpc(struct seq_file *m)
return 0;
 }
 
+static int mtl_drpc(struct seq_file *m)
+{
+   struct intel_gt *gt = m->private;
+   struct intel_uncore *uncore = gt->uncore;
+   u32 gt_core_status, rcctl1, global_forcewake;
+   u32 mtl_powergate_enable = 0, mtl_powergate_status = 0;
+
+   gt_core_status = intel_uncore_read(uncore, MTL_MIRROR_TARGET_WP1);
+
+   global_forcewake = intel_uncore_read(uncore, FORCEWAKE_GT_GEN9);
+
+   rcctl1 = intel_uncore_read(uncore, GEN6_RC_CONTROL);
+   mtl_powergate_enable = intel_uncore_read(uncore, GEN9_PG_ENABLE);
+   mtl_powergate_status = intel_uncore_read(uncore,
+GEN9_PWRGT_DOMAIN_STATUS);
+
+   seq_printf(m, "RC6 Enabled: %s\n",
+  str_yes_no(rcctl1 & GEN6_RC_CTL_RC6_ENABLE));
+   if (gt->type == GT_MEDIA) {
+   seq_printf(m, "Media Well Gating Enabled: %s\n",
+  str_yes_no(mtl_powergate_enable & 
GEN9_MEDIA_PG_ENABLE));
+   } else {
+   seq_printf(m, "Render Well Gating Enabled: %s\n",
+  str_yes_no(mtl_powergate_enable & 
GEN9_RENDER_PG_ENABLE));
+   }
+
+   seq_puts(m, "Current RC state: ");
+   switch (REG_FIELD_GET(MTL_CC_MASK, gt_core_status)) {
+   case MTL_CC0:
+   seq_puts(m, "on\n");
+   break;
+   case MTL_CC6:
+   seq_puts(m, "RC6\n");
+   break;
+   default:
+   seq_puts(m, "Unknown\n");
+   break;
+   }
+
+   if (gt->type == GT_MEDIA)
+   seq_printf(m, "Media Power Well: %s\n",
+  (mtl_powergate_status &
+   GEN9_PWRGT_MEDIA_STATUS_MASK) ? "Up" : "Down");
+   else
+   seq_printf(m, "Render Power Well: %s\n",
+  (mtl_powergate_status &
+   GEN9_PWRGT_RENDER_STATUS_MASK) ? "Up" : "Down");
+
+   /* Works for both render and media gt's */
+   intel_rc6_print_residency(m, "RC6 residency since boot:", 
INTEL_RC6_RES_RC6);
+
+   seq_printf(m, "Global Forcewake Requests: 0x%x\n", global_forcewake);
+
+   return fw_domains_show(m, NULL);
+}
+
 static int drpc_show(struct seq_file *m, void *unused)
 {
struct intel_gt *gt = m->private;
@@ -264,7 +320,9 @@ static int drpc_show(struct seq_file *m, void *unused)
int err = -ENODEV;
 
with_intel_runtime_pm(gt->uncore->rpm, wakeref) {
-   if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
+   if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70))
+   err = mtl_drpc(m);
+   else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
err = vlv_drpc(m);
else if (GRAPHICS_VER(i915) >= 6)
err = gen6_drpc(m);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index b4b1b54ad738f..9f168867eb8ae 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -24,6 +24,9 @@
 /* MTL workpoint reg to get core C state and actual freq of 3D, SAMedia */
 #define MTL_MIRROR_TARGET_WP1  _MMIO(0xc60)
 #define   MTL_CAGF_MASKREG_GENMASK(8, 0)
+#define   MTL_CC0  0x0
+#define   MTL_CC6  0x3
+#define   MTL_CC_MASK  REG_GENMASK(12, 9)
 
 /* RPM unit config (Gen8+) */
 #define RPM_CONFIG0_MMIO(0xd00)
@@ -1516,6 +1519,8 @@
 #define FORCEWAKE_MEDIA_VLV_MMIO(0x1300b8)
 #define FORCEWAKE_ACK_MEDIA_VLV_MMIO(0x1300bc)
 
+#define MTL_MEDIA_MC6  _MMIO(0x138048)
+
 #define GEN6_GT_THREAD_STATUS_REG  _MMIO(0x13805c)
 #define   GEN6_GT_THREAD_STATUS_CORE_MASK  0x7
 
diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c 
b/drivers/gpu/drm/i915/gt/intel_rc6.c
index 6db4e

[PATCH 0/4] i915: CAGF and RC6 changes for MTL

[Ashutosh Dixit]

This series includes the code changes to get CAGF, RC State and C6
Residency of MTL.

v3: Included "Use GEN12 RPSTAT register" patch

v4:
  - Rebased
  - Dropped "Use GEN12 RPSTAT register" patch from this series
going to send separate series for it

v5:
- Included "drm/i915/gt: Change RC6 residency functions to accept register
  ID's" based on code review feedback

v6:
- Addressed Jani N's review comments on "drm/i915/gt: Change RC6 residency
  functions to accept register ID's"
- Minor changes to other patches, please see individual patches for changelogs

Ashutosh Dixit (1):
  drm/i915/gt: Use RC6 residency types as arguments to residency
functions

Badal Nilawar (2):
  drm/i915/mtl: Modify CAGF functions for MTL
  drm/i915/mtl: C6 residency and C state type for MTL SAMedia

Don Hiatt (1):
  drm/i915: Use GEN12_RPSTAT register for GT freq

 drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 87 ++-
 drivers/gpu/drm/i915/gt/intel_gt_regs.h   | 11 +++
 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c   | 12 +--
 drivers/gpu/drm/i915/gt/intel_rc6.c   | 64 +-
 drivers/gpu/drm/i915/gt/intel_rc6.h   |  8 +-
 drivers/gpu/drm/i915/gt/intel_rc6_types.h | 15 +++-
 drivers/gpu/drm/i915/gt/intel_rps.c   | 40 -
 drivers/gpu/drm/i915/gt/intel_rps.h   |  2 +
 drivers/gpu/drm/i915/gt/selftest_rc6.c|  6 +-
 drivers/gpu/drm/i915/i915_pmu.c   |  9 +-
 10 files changed, 188 insertions(+), 66 deletions(-)

-- 
2.38.0

[PATCH 1/4] drm/i915: Use GEN12_RPSTAT register for GT freq

[Ashutosh Dixit]

From: Don Hiatt 

On GEN12+ use GEN12_RPSTAT register to get actual resolved GT
freq. GEN12_RPSTAT does not require a forcewake and will return 0 freq if
GT is in RC6.

v2:
  - Fixed review comments(Ashutosh)
  - Added function intel_rps_read_rpstat_fw to read RPSTAT without
forcewake, required especially for GEN6_RPSTAT1 (Ashutosh, Tvrtko)
v3:
  - Updated commit title and message for more clarity (Ashutosh)
  - Replaced intel_rps_read_rpstat with direct read to GEN12_RPSTAT1 in
read_cagf (Ashutosh)

Cc: Don Hiatt 
Cc: Andi Shyti 
Signed-off-by: Don Hiatt 
Signed-off-by: Badal Nilawar 
Signed-off-by: Ashutosh Dixit 
Reviewed-by: Andi Shyti 
---
 drivers/gpu/drm/i915/gt/intel_gt_regs.h |  2 ++
 drivers/gpu/drm/i915/gt/intel_rps.c | 32 +
 drivers/gpu/drm/i915/gt/intel_rps.h |  2 ++
 drivers/gpu/drm/i915/i915_pmu.c |  3 +--
 4 files changed, 33 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 36d95b79022c0..a7a0129d0e3fc 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1543,6 +1543,8 @@
 
 #define GEN12_RPSTAT1  _MMIO(0x1381b4)
 #define   GEN12_VOLTAGE_MASK   REG_GENMASK(10, 0)
+#define   GEN12_CAGF_SHIFT 11
+#define   GEN12_CAGF_MASK  REG_GENMASK(19, 11)
 
 #define GEN11_GT_INTR_DW(x)_MMIO(0x190018 + ((x) * 4))
 #define   GEN11_CSME   (31)
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
b/drivers/gpu/drm/i915/gt/intel_rps.c
index fc23c562d9b2a..df21258976d86 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -2068,12 +2068,34 @@ void intel_rps_sanitize(struct intel_rps *rps)
rps_disable_interrupts(rps);
 }
 
+u32 intel_rps_read_rpstat_fw(struct intel_rps *rps)
+{
+   struct drm_i915_private *i915 = rps_to_i915(rps);
+   i915_reg_t rpstat;
+
+   rpstat = (GRAPHICS_VER(i915) >= 12) ? GEN12_RPSTAT1 : GEN6_RPSTAT1;
+
+   return intel_uncore_read_fw(rps_to_gt(rps)->uncore, rpstat);
+}
+
+u32 intel_rps_read_rpstat(struct intel_rps *rps)
+{
+   struct drm_i915_private *i915 = rps_to_i915(rps);
+   i915_reg_t rpstat;
+
+   rpstat = (GRAPHICS_VER(i915) >= 12) ? GEN12_RPSTAT1 : GEN6_RPSTAT1;
+
+   return intel_uncore_read(rps_to_gt(rps)->uncore, rpstat);
+}
+
 u32 intel_rps_get_cagf(struct intel_rps *rps, u32 rpstat)
 {
struct drm_i915_private *i915 = rps_to_i915(rps);
u32 cagf;
 
-   if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
+   if (GRAPHICS_VER(i915) >= 12)
+   cagf = (rpstat & GEN12_CAGF_MASK) >> GEN12_CAGF_SHIFT;
+   else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
cagf = (rpstat >> 8) & 0xff;
else if (GRAPHICS_VER(i915) >= 9)
cagf = (rpstat & GEN9_CAGF_MASK) >> GEN9_CAGF_SHIFT;
@@ -2094,7 +2116,9 @@ static u32 read_cagf(struct intel_rps *rps)
struct intel_uncore *uncore = rps_to_uncore(rps);
u32 freq;
 
-   if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915)) {
+   if (GRAPHICS_VER(i915) >= 12) {
+   freq = intel_uncore_read(uncore, GEN12_RPSTAT1);
+   } else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915)) {
vlv_punit_get(i915);
freq = vlv_punit_read(i915, PUNIT_REG_GPU_FREQ_STS);
vlv_punit_put(i915);
@@ -2260,7 +2284,7 @@ static void rps_frequency_dump(struct intel_rps *rps, 
struct drm_printer *p)
rpinclimit = intel_uncore_read(uncore, GEN6_RP_UP_THRESHOLD);
rpdeclimit = intel_uncore_read(uncore, GEN6_RP_DOWN_THRESHOLD);
 
-   rpstat = intel_uncore_read(uncore, GEN6_RPSTAT1);
+   rpstat = intel_rps_read_rpstat(rps);
rpcurupei = intel_uncore_read(uncore, GEN6_RP_CUR_UP_EI) & 
GEN6_CURICONT_MASK;
rpcurup = intel_uncore_read(uncore, GEN6_RP_CUR_UP) & 
GEN6_CURBSYTAVG_MASK;
rpprevup = intel_uncore_read(uncore, GEN6_RP_PREV_UP) & 
GEN6_CURBSYTAVG_MASK;
@@ -2395,7 +2419,7 @@ static void slpc_frequency_dump(struct intel_rps *rps, 
struct drm_printer *p)
drm_printf(p, "PM MASK=0x%08x\n", pm_mask);
drm_printf(p, "pm_intrmsk_mbz: 0x%08x\n",
   rps->pm_intrmsk_mbz);
-   drm_printf(p, "RPSTAT1: 0x%08x\n", intel_uncore_read(uncore, 
GEN6_RPSTAT1));
+   drm_printf(p, "RPSTAT1: 0x%08x\n", intel_rps_read_rpstat(rps));
drm_printf(p, "RPNSWREQ: %dMHz\n", 
intel_rps_get_requested_frequency(rps));
drm_printf(p, "Lowest (RPN) frequency: %dMHz\n",
   intel_gpu_freq(rps, caps.min_freq));
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.h 
b/drivers/gpu/drm/i915/gt/intel_rps.h
index 110300dfd4383..9e1cad9ba0e9c 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.h
+++ b/drivers/gpu/drm/i915/gt/intel_rps.h
@@ -48,6 +48,8 @@ u32 intel_rps_get_rp1_frequency(stru

[PATCH 3/4] drm/i915/gt: Use RC6 residency types as arguments to residency functions

[Ashutosh Dixit]

Previously RC6 residency functions directly accepted RC6 residency register
MMIO offsets (there are four RC6 residency registers). This worked but
required an assumption on the residency register layout so was not future
proof.

Therefore change RC6 residency functions to accept RC6 residency types
instead of register MMIO offsets. The knowledge of register offsets as well
as ID to offset mapping is now maintained solely in intel_rc6 and can be
tailored for different platforms and different register layouts as need
arises.

v2: Address review comments by Jani N
- Change residency functions to accept RC6 residency types instead of
  register ID's
- s/intel_rc6_print_rc5_res/intel_rc6_print_residency/
- Remove "const enum" in function arguments
- Naming: intel_rc6_* for enum
- Use INTEL_RC6_RES_MAX and other minor changes

Suggested-by: Rodrigo Vivi 
Suggested-by: Jani Nikula 
Reported-by: Jani Nikula 
Signed-off-by: Ashutosh Dixit 
---
 drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 27 +++--
 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c   | 12 ++--
 drivers/gpu/drm/i915/gt/intel_rc6.c   | 55 +++
 drivers/gpu/drm/i915/gt/intel_rc6.h   |  8 ++-
 drivers/gpu/drm/i915/gt/intel_rc6_types.h | 15 -
 drivers/gpu/drm/i915/gt/selftest_rc6.c|  6 +-
 drivers/gpu/drm/i915/i915_pmu.c   |  6 +-
 7 files changed, 70 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c 
b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
index 40d0a3be42acf..235d593cfaeba 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
@@ -83,19 +83,6 @@ static int fw_domains_show(struct seq_file *m, void *data)
 }
 DEFINE_INTEL_GT_DEBUGFS_ATTRIBUTE(fw_domains);
 
-static void print_rc6_res(struct seq_file *m,
- const char *title,
- const i915_reg_t reg)
-{
-   struct intel_gt *gt = m->private;
-   intel_wakeref_t wakeref;
-
-   with_intel_runtime_pm(gt->uncore->rpm, wakeref)
-   seq_printf(m, "%s %u (%llu us)\n", title,
-  intel_uncore_read(gt->uncore, reg),
-  intel_rc6_residency_us(>->rc6, reg));
-}
-
 static int vlv_drpc(struct seq_file *m)
 {
struct intel_gt *gt = m->private;
@@ -115,8 +102,8 @@ static int vlv_drpc(struct seq_file *m)
seq_printf(m, "Media Power Well: %s\n",
   (pw_status & VLV_GTLC_PW_MEDIA_STATUS_MASK) ? "Up" : "Down");
 
-   print_rc6_res(m, "Render RC6 residency since boot:", GEN6_GT_GFX_RC6);
-   print_rc6_res(m, "Media RC6 residency since boot:", VLV_GT_MEDIA_RC6);
+   intel_rc6_print_residency(m, "Render RC6 residency since boot:", 
INTEL_RC6_RES_RC6);
+   intel_rc6_print_residency(m, "Media RC6 residency since boot:", 
INTEL_RC6_RES_VLV_MEDIA);
 
return fw_domains_show(m, NULL);
 }
@@ -192,11 +179,11 @@ static int gen6_drpc(struct seq_file *m)
}
 
/* Not exactly sure what this is */
-   print_rc6_res(m, "RC6 \"Locked to RPn\" residency since boot:",
- GEN6_GT_GFX_RC6_LOCKED);
-   print_rc6_res(m, "RC6 residency since boot:", GEN6_GT_GFX_RC6);
-   print_rc6_res(m, "RC6+ residency since boot:", GEN6_GT_GFX_RC6p);
-   print_rc6_res(m, "RC6++ residency since boot:", GEN6_GT_GFX_RC6pp);
+   intel_rc6_print_residency(m, "RC6 \"Locked to RPn\" residency since 
boot:",
+ INTEL_RC6_RES_RC6_LOCKED);
+   intel_rc6_print_residency(m, "RC6 residency since boot:", 
INTEL_RC6_RES_RC6);
+   intel_rc6_print_residency(m, "RC6+ residency since boot:", 
INTEL_RC6_RES_RC6p);
+   intel_rc6_print_residency(m, "RC6++ residency since boot:", 
INTEL_RC6_RES_RC6pp);
 
if (GRAPHICS_VER(i915) <= 7) {
seq_printf(m, "RC6   voltage: %dmV\n",
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c 
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
index 9041609523697..19a6e052c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
@@ -93,13 +93,13 @@ sysfs_gt_attribute_r_func(struct device *dev, struct 
device_attribute *attr,
sysfs_gt_attribute_r_func(d, a, f, INTEL_GT_SYSFS_MAX)
 
 #ifdef CONFIG_PM
-static u32 get_residency(struct intel_gt *gt, i915_reg_t reg)
+static u32 get_residency(struct intel_gt *gt, enum intel_rc6_res_type id)
 {
intel_wakeref_t wakeref;
u64 res = 0;
 
with_intel_runtime_pm(gt->uncore->rpm, wakeref)
-   res = intel_rc6_residency_us(>->rc6, reg);
+   res = intel_rc6_residency_us(>->rc6, id);
 
return DIV_ROUND_CLOSEST_ULL(res, 1000);
 }
@@ -123,7 +123,7 @@ static ssize_t rc6_enable_show(struct device *dev,
 
 static u32 __rc6_residency_ms_show(struct intel_gt *gt)
 {
-   return get_residency(gt, GEN6_GT_GFX_RC6);
+   return get_r

Re: [Intel-gfx] [PATCH v4 15/17] drm/i915/vm_bind: Handle persistent vmas in execbuf3

[Niranjana Vishwanathapura]

On Tue, Oct 18, 2022 at 01:20:06PM -0700, Niranjana Vishwanathapura wrote:

On Tue, Oct 18, 2022 at 07:01:57PM +0100, Matthew Auld wrote:

On 18/10/2022 08:16, Niranjana Vishwanathapura wrote:

Handle persistent (VM_BIND) mappings during the request submission
in the execbuf3 path.

v2: Ensure requests wait for bindings to complete.
v3: Remove short term pinning with PIN_VALIDATE flag.
   Individualize fences before adding to dma_resv obj.

Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Andi Shyti 
---
.../gpu/drm/i915/gem/i915_gem_execbuffer3.c   | 208 +-
1 file changed, 207 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
index a9b4cc44bf66..8120e4c6b7da 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
@@ -3,6 +3,7 @@
 * Copyright © 2022 Intel Corporation
 */
+#include 
#include 
#include 
@@ -19,6 +20,7 @@
#include "i915_gem_vm_bind.h"
#include "i915_trace.h"
+#define __EXEC3_HAS_PINBIT_ULL(33)
#define __EXEC3_ENGINE_PINNED   BIT_ULL(32)
#define __EXEC3_INTERNAL_FLAGS  (~0ull << 32)
@@ -42,7 +44,9 @@
 * execlist. Hence, no support for implicit sync.
 *
 * The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only
- * works with execbuf3 ioctl for submission.
+ * works with execbuf3 ioctl for submission. All BOs mapped on that VM (through
+ * VM_BIND call) at the time of execbuf3 call are deemed required for that
+ * submission.
 *
 * The execbuf3 ioctl directly specifies the batch addresses instead of as
 * object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not
@@ -58,6 +62,13 @@
 * So, a lot of code supporting execbuf2 ioctl, like relocations, VA evictions,
 * vma lookup table, implicit sync, vma active reference tracking etc., are not
 * applicable for execbuf3 ioctl.
+ *
+ * During each execbuf submission, request fence is added to all VM_BIND mapped
+ * objects with DMA_RESV_USAGE_BOOKKEEP. The DMA_RESV_USAGE_BOOKKEEP usage will
+ * prevent over sync (See enum dma_resv_usage). Note that DRM_I915_GEM_WAIT and
+ * DRM_I915_GEM_BUSY ioctls do not check for DMA_RESV_USAGE_BOOKKEEP usage and
+ * hence should not be used for end of batch check. Instead, the execbuf3
+ * timeline out fence should be used for end of batch check.
 */
/**
@@ -127,6 +138,23 @@ eb_find_vma(struct i915_address_space *vm, u64 addr)
return i915_gem_vm_bind_lookup_vma(vm, va);
}
+static void eb_scoop_unbound_vma_all(struct i915_address_space *vm)
+{
+   struct i915_vma *vma, *vn;
+
+   /**
+* Move all unbound vmas back into vm_bind_list so that they are
+* revalidated.
+*/
+   spin_lock(&vm->vm_rebind_lock);
+   list_for_each_entry_safe(vma, vn, &vm->vm_rebind_list, vm_rebind_link) {
+   list_del_init(&vma->vm_rebind_link);
+   if (!list_empty(&vma->vm_bind_link))
+   list_move_tail(&vma->vm_bind_link, &vm->vm_bind_list);
+   }
+   spin_unlock(&vm->vm_rebind_lock);
+}
+
static int eb_lookup_vma_all(struct i915_execbuffer *eb)
{
unsigned int i, current_batch = 0;
@@ -141,14 +169,108 @@ static int eb_lookup_vma_all(struct i915_execbuffer *eb)
++current_batch;
}
+   eb_scoop_unbound_vma_all(eb->context->vm);
+
+   return 0;
+}
+
+static int eb_lock_vma_all(struct i915_execbuffer *eb)
+{
+   struct i915_address_space *vm = eb->context->vm;
+   struct i915_vma *vma;
+   int err;
+
+   err = i915_gem_object_lock(eb->context->vm->root_obj, &eb->ww);
+   if (err)
+   return err;
+
+   list_for_each_entry(vma, &vm->non_priv_vm_bind_list,
+   non_priv_vm_bind_link) {
+   err = i915_gem_object_lock(vma->obj, &eb->ww);
+   if (err)
+   return err;
+   }
+
return 0;
}
+static void eb_release_persistent_vma_all(struct i915_execbuffer *eb)
+{
+   struct i915_address_space *vm = eb->context->vm;
+   struct i915_vma *vma, *vn;
+
+   lockdep_assert_held(&vm->vm_bind_lock);
+
+   if (!(eb->args->flags & __EXEC3_HAS_PIN))
+   return;
+
+   assert_object_held(vm->root_obj);
+
+   list_for_each_entry_safe(vma, vn, &vm->vm_bind_list, vm_bind_link)
+   if (i915_vma_verify_bind_complete(vma))
+   list_move_tail(&vma->vm_bind_link, &vm->vm_bound_list);
+
+   eb->args->flags &= ~__EXEC3_HAS_PIN;
+}
+
static void eb_release_vma_all(struct i915_execbuffer *eb)
{
+   eb_release_persistent_vma_all(eb);
eb_unpin_engine(eb);
}
+static int eb_reserve_fence_for_persistent_vma_all(struct i915_execbuffer *eb)
+{
+   struct i915_address_space *vm = eb->context->vm;
+   u64 num_fences = 1;
+   struct i915_vma *vma;
+   int ret;
+
+   /* Reserve enough slots to acc

Re: [PATCH v4 12/17] drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl

[Niranjana Vishwanathapura]

On Tue, Oct 18, 2022 at 06:30:58PM +0100, Matthew Auld wrote:

On 18/10/2022 08:16, Niranjana Vishwanathapura wrote:

Implement new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only
works in vm_bind mode. The vm_bind mode only works with
this new execbuf3 ioctl.

The new execbuf3 ioctl will not have any list of objects to validate
bind as all required objects binding would have been requested by the
userspace before submitting the execbuf3.

Legacy features like relocations etc are not supported by execbuf3.

v2: Add more input validity checks.
v3: batch_address is a VA (not an array) if num_batches=1,
minor cleanup
v4: replace vm->vm_bind_mode check with i915_gem_vm_is_vm_bind_mode()

Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 .../gpu/drm/i915/gem/i915_gem_execbuffer3.c   | 580 ++
 drivers/gpu/drm/i915/gem/i915_gem_ioctls.h|   2 +
 drivers/gpu/drm/i915/i915_driver.c|   1 +
 include/uapi/drm/i915_drm.h   |  61 ++
 5 files changed, 645 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 8d76bb888dc3..6a801684d569 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -150,6 +150,7 @@ gem-y += \
gem/i915_gem_domain.o \
gem/i915_gem_execbuffer_common.o \
gem/i915_gem_execbuffer.o \
+   gem/i915_gem_execbuffer3.o \
gem/i915_gem_internal.o \
gem/i915_gem_object.o \
gem/i915_gem_lmem.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
new file mode 100644
index ..a9b4cc44bf66
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
@@ -0,0 +1,580 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+#include 
+
+#include 
+
+#include "gt/intel_context.h"
+#include "gt/intel_gpu_commands.h"
+#include "gt/intel_gt.h"
+
+#include "i915_drv.h"
+#include "i915_gem_context.h"
+#include "i915_gem_execbuffer_common.h"
+#include "i915_gem_ioctls.h"
+#include "i915_gem_vm_bind.h"
+#include "i915_trace.h"
+
+#define __EXEC3_ENGINE_PINNED  BIT_ULL(32)
+#define __EXEC3_INTERNAL_FLAGS (~0ull << 32)
+
+/* Catch emission of unexpected errors for CI! */
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
+#undef EINVAL
+#define EINVAL ({ \
+   DRM_DEBUG_DRIVER("EINVAL at %s:%d\n", __func__, __LINE__); \
+   22; \
+})
+#endif
+
+/**
+ * DOC: User command execution with execbuf3 ioctl
+ *
+ * A VM in VM_BIND mode will not support older execbuf mode of binding.
+ * The execbuf ioctl handling in VM_BIND mode differs significantly from the
+ * older execbuf2 ioctl (See struct drm_i915_gem_execbuffer2).
+ * Hence, a new execbuf3 ioctl has been added to support VM_BIND mode. (See
+ * struct drm_i915_gem_execbuffer3). The execbuf3 ioctl will not accept any
+ * execlist. Hence, no support for implicit sync.
+ *
+ * The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only
+ * works with execbuf3 ioctl for submission.
+ *
+ * The execbuf3 ioctl directly specifies the batch addresses instead of as
+ * object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not
+ * support many of the older features like in/out/submit fences, fence array,
+ * default gem context etc. (See struct drm_i915_gem_execbuffer3).
+ *
+ * In VM_BIND mode, VA allocation is completely managed by the user instead of
+ * the i915 driver. Hence all VA assignment, eviction are not applicable in
+ * VM_BIND mode. Also, for determining object activeness, VM_BIND mode will not
+ * be using the i915_vma active reference tracking. It will instead check the
+ * dma-resv object's fence list for that.
+ *
+ * So, a lot of code supporting execbuf2 ioctl, like relocations, VA evictions,
+ * vma lookup table, implicit sync, vma active reference tracking etc., are not
+ * applicable for execbuf3 ioctl.
+ */
+
+/**
+ * struct i915_execbuffer - execbuf struct for execbuf3
+ * @i915: reference to the i915 instance we run on
+ * @file: drm file reference
+ * args: execbuf3 ioctl structure
+ * @gt: reference to the gt instance ioctl submitted for
+ * @context: logical state for the request
+ * @gem_context: callers context
+ * @requests: requests to be build
+ * @composite_fence: used for excl fence in dma_resv objects when > 1 BB 
submitted
+ * @ww: i915_gem_ww_ctx instance
+ * @num_batches: number of batches submitted
+ * @batch_addresses: addresses corresponds to the submitted batches
+ * @batches: references to the i915_vmas corresponding to the batches
+ */
+struct i915_execbuffer {
+   struct drm_i915_private *i915;
+   struct drm_file *file;
+   struct drm_i915_gem_execbuffer3 *args;
+
+   struct intel_gt *gt;
+   struct intel_context *context;
+   struct i915_gem_

Re: [PATCH v2 5/7] drm/i915/mtl: Handle wopcm per-GT and limit calculations.

[Matt Roper]

On Tue, Oct 18, 2022 at 05:44:38PM -0700, John Harrison wrote:
> On 10/12/2022 17:03, Daniele Ceraolo Spurio wrote:
> > From: Aravind Iddamsetty 
> > 
...
> > diff --git a/drivers/gpu/drm/i915/intel_wopcm.c 
> > b/drivers/gpu/drm/i915/gt/intel_wopcm.c
> > similarity index 86%
> > rename from drivers/gpu/drm/i915/intel_wopcm.c
> > rename to drivers/gpu/drm/i915/gt/intel_wopcm.c
> > index 322fb9eeb880..487fbbbdf3d6 100644
> > --- a/drivers/gpu/drm/i915/intel_wopcm.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_wopcm.c
> > @@ -43,6 +43,7 @@
> >   /* Default WOPCM size is 2MB from Gen11, 1MB on previous platforms */
> >   #define GEN11_WOPCM_SIZE  SZ_2M
> >   #define GEN9_WOPCM_SIZE   SZ_1M
> > +#define XELPM_SAMEDIA_WOPCM_SIZE   SZ_2M
> XELPM? Isn't it just XELP?

Xe_LP is the older TGL-ADL gfx IP name.  MTL's media IP is called
Xe_LPM+ (which we should label as XELPMP in code, so it looks like the
final "P" is missing here).


Matt

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation

Re: [PATCH] drm/amdgpu/discovery: fix possible memory leak

[Luben Tuikov]

On 2022-10-18 23:37, Luben Tuikov wrote:
> On 2022-10-18 04:05, Yang Yingliang wrote:
>> If kset_register() fails, the refcount of device is not 0, the name allocated
>> in dev_set_name() is leaked. Fix this by calling kset_put(), so that it will
>> be freed in callback function kobject_cleanup().
>>
> 
> Good catch, but looking at the code it seems that what is being
> leaked is the memory pointed to by kset.kobj.name which is allocated
> in kobject_set_name(&kset.kobj, ...), which is called right
> before the call to kset_register().
> 
> Modify the description with this explanation and repost the patch and I'll 
> R-B it then.
> Something like:
> 
>> If kset_register() fails, the refcount of the device is not 0, and the name 
>> allocated
>> in kobject_set_name(&kset.kobj, ...) is leaked. Fix this by calling 
>> kset_put(),
>> so that kset.kobj.name is freed in the callback function kobject_cleanup().
> 
> Now, if there's a leak of dev_set_name(), then that would be something
> else/another patch.
> 
> The rest below looks good.
> 
> Since this patch touches only files under drm/amd/amdgpu/ and for a highly 
> AMD-specific
> feature, you didn't need to spam the dri-dev ML--amdgfx ML should be plenty 
> enough.

Also, don't forget to CC stable (by a tag in the commit description).

Regards,
Luben

> 
> Regards,
> Luben
> 
>> Fixes: a6c40b178092 ("drm/amdgpu: Show IP discovery in sysfs")
>> Signed-off-by: Yang Yingliang 
>> ---
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
>> index 3993e6134914..638edcf70227 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
>> @@ -863,7 +863,7 @@ static int amdgpu_discovery_sysfs_ips(struct 
>> amdgpu_device *adev,
>>  res = kset_register(&ip_hw_id->hw_id_kset);
>>  if (res) {
>>  DRM_ERROR("Couldn't register ip_hw_id 
>> kset");
>> -kfree(ip_hw_id);
>> +kset_put(&ip_hw_id->hw_id_kset);
>>  return res;
>>  }
>>  if (hw_id_names[ii]) {
>> @@ -954,7 +954,7 @@ static int amdgpu_discovery_sysfs_recurse(struct 
>> amdgpu_device *adev)
>>  res = kset_register(&ip_die_entry->ip_kset);
>>  if (res) {
>>  DRM_ERROR("Couldn't register ip_die_entry kset");
>> -kfree(ip_die_entry);
>> +kset_put(&ip_die_entry->ip_kset);
>>  return res;
>>  }
>>  
>> @@ -989,6 +989,7 @@ static int amdgpu_discovery_sysfs_init(struct 
>> amdgpu_device *adev)
>>  res = kset_register(&adev->ip_top->die_kset);
>>  if (res) {
>>  DRM_ERROR("Couldn't register die_kset");
>> +kset_put(&adev->ip_top->die_kset);
>>  goto Err;
>>  }
>>  

Re: [PATCH] drm/amdgpu/discovery: fix possible memory leak

[Luben Tuikov]

On 2022-10-18 04:05, Yang Yingliang wrote:
> If kset_register() fails, the refcount of device is not 0, the name allocated
> in dev_set_name() is leaked. Fix this by calling kset_put(), so that it will
> be freed in callback function kobject_cleanup().
> 

Good catch, but looking at the code it seems that what is being
leaked is the memory pointed to by kset.kobj.name which is allocated
in kobject_set_name(&kset.kobj, ...), which is called right
before the call to kset_register().

Modify the description with this explanation and repost the patch and I'll R-B 
it then.
Something like:

> If kset_register() fails, the refcount of the device is not 0, and the name 
> allocated
> in kobject_set_name(&kset.kobj, ...) is leaked. Fix this by calling 
> kset_put(),
> so that kset.kobj.name is freed in the callback function kobject_cleanup().

Now, if there's a leak of dev_set_name(), then that would be something
else/another patch.

The rest below looks good.

Since this patch touches only files under drm/amd/amdgpu/ and for a highly 
AMD-specific
feature, you didn't need to spam the dri-dev ML--amdgfx ML should be plenty 
enough.

Regards,
Luben

> Fixes: a6c40b178092 ("drm/amdgpu: Show IP discovery in sysfs")
> Signed-off-by: Yang Yingliang 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
> index 3993e6134914..638edcf70227 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
> @@ -863,7 +863,7 @@ static int amdgpu_discovery_sysfs_ips(struct 
> amdgpu_device *adev,
>   res = kset_register(&ip_hw_id->hw_id_kset);
>   if (res) {
>   DRM_ERROR("Couldn't register ip_hw_id 
> kset");
> - kfree(ip_hw_id);
> + kset_put(&ip_hw_id->hw_id_kset);
>   return res;
>   }
>   if (hw_id_names[ii]) {
> @@ -954,7 +954,7 @@ static int amdgpu_discovery_sysfs_recurse(struct 
> amdgpu_device *adev)
>   res = kset_register(&ip_die_entry->ip_kset);
>   if (res) {
>   DRM_ERROR("Couldn't register ip_die_entry kset");
> - kfree(ip_die_entry);
> + kset_put(&ip_die_entry->ip_kset);
>   return res;
>   }
>  
> @@ -989,6 +989,7 @@ static int amdgpu_discovery_sysfs_init(struct 
> amdgpu_device *adev)
>   res = kset_register(&adev->ip_top->die_kset);
>   if (res) {
>   DRM_ERROR("Couldn't register die_kset");
> + kset_put(&adev->ip_top->die_kset);
>   goto Err;
>   }
>  

[PATCH v2] drm: mediatek: Modify dpi power on/off sequence.

[xinlei.lee]

From: Xinlei Lee 

Modify dpi power on/off sequence so that the first gpio operation will take 
effect.

Fixes: 6bd4763fd532 ("drm/mediatek: set dpi pin mode to gpio low to avoid 
leakage current")

Signed-off-by: Xinlei Lee 
---
change note:
v1: Rebase on linus/master v6.1-rc1. Change nothing.

Because dpi power_on/off is protected by dpi->refcount, the first time
it cannot be powered on and off successfully, it will cause leakage.
---
---
 drivers/gpu/drm/mediatek/mtk_dpi.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 508a6d994e83..f83cf64c2828 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -461,9 +461,6 @@ static void mtk_dpi_power_off(struct mtk_dpi *dpi)
if (--dpi->refcount != 0)
return;
 
-   if (dpi->pinctrl && dpi->pins_gpio)
-   pinctrl_select_state(dpi->pinctrl, dpi->pins_gpio);
-
mtk_dpi_disable(dpi);
clk_disable_unprepare(dpi->pixel_clk);
clk_disable_unprepare(dpi->engine_clk);
@@ -488,9 +485,6 @@ static int mtk_dpi_power_on(struct mtk_dpi *dpi)
goto err_pixel;
}
 
-   if (dpi->pinctrl && dpi->pins_dpi)
-   pinctrl_select_state(dpi->pinctrl, dpi->pins_dpi);
-
return 0;
 
 err_pixel:
@@ -720,6 +714,9 @@ static void mtk_dpi_bridge_disable(struct drm_bridge 
*bridge)
 {
struct mtk_dpi *dpi = bridge_to_dpi(bridge);
 
+   if (dpi->pinctrl && dpi->pins_gpio)
+   pinctrl_select_state(dpi->pinctrl, dpi->pins_gpio);
+
mtk_dpi_power_off(dpi);
 }
 
@@ -727,6 +724,9 @@ static void mtk_dpi_bridge_enable(struct drm_bridge *bridge)
 {
struct mtk_dpi *dpi = bridge_to_dpi(bridge);
 
+   if (dpi->pinctrl && dpi->pins_dpi)
+   pinctrl_select_state(dpi->pinctrl, dpi->pins_dpi);
+
mtk_dpi_power_on(dpi);
mtk_dpi_set_display_mode(dpi, &dpi->mode);
mtk_dpi_enable(dpi);
-- 
2.18.0

[PATCH v12, 3/3] drm: mediatek: Add mt8186 dpi compatibles and platform data

[xinlei.lee]

From: Xinlei Lee 

Add the compatible because use edge_cfg_in_mmsys in mt8186.

Signed-off-by: Xinlei Lee 
Reviewed-by: CK Hu 
Reviewed-by: AngeloGioacchino Del Regno 

---
 drivers/gpu/drm/mediatek/mtk_dpi.c | 21 +
 drivers/gpu/drm/mediatek/mtk_drm_drv.c |  2 ++
 2 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index b9d740efdb6a..fa39e37caeb3 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -940,6 +940,24 @@ static const struct mtk_dpi_conf mt8183_conf = {
.csc_enable_bit = CSC_ENABLE,
 };
 
+static const struct mtk_dpi_conf mt8186_conf = {
+   .cal_factor = mt8183_calculate_factor,
+   .reg_h_fre_con = 0xe0,
+   .max_clock_khz = 15,
+   .output_fmts = mt8183_output_fmts,
+   .num_output_fmts = ARRAY_SIZE(mt8183_output_fmts),
+   .edge_cfg_in_mmsys = true,
+   .pixels_per_iter = 1,
+   .is_ck_de_pol = true,
+   .swap_input_support = true,
+   .support_direct_pin = true,
+   .dimension_mask = HPW_MASK,
+   .hvsize_mask = HSIZE_MASK,
+   .channel_swap_shift = CH_SWAP,
+   .yuv422_en_bit = YUV422_EN,
+   .csc_enable_bit = CSC_ENABLE,
+};
+
 static const struct mtk_dpi_conf mt8192_conf = {
.cal_factor = mt8183_calculate_factor,
.reg_h_fre_con = 0xe0,
@@ -1090,6 +1108,9 @@ static const struct of_device_id mtk_dpi_of_ids[] = {
{ .compatible = "mediatek,mt8183-dpi",
  .data = &mt8183_conf,
},
+   { .compatible = "mediatek,mt8186-dpi",
+ .data = &mt8186_conf,
+   },
{ .compatible = "mediatek,mt8192-dpi",
  .data = &mt8192_conf,
},
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 91f58db5915f..a5a1a91429ec 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -631,6 +631,8 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
  .data = (void *)MTK_DPI },
{ .compatible = "mediatek,mt8183-dpi",
  .data = (void *)MTK_DPI },
+   { .compatible = "mediatek,mt8186-dpi",
+ .data = (void *)MTK_DPI },
{ .compatible = "mediatek,mt8192-dpi",
  .data = (void *)MTK_DPI },
{ .compatible = "mediatek,mt8195-dp-intf",
-- 
2.18.0

[PATCH v12,0/3] Add dpi output format control for MT8186

[xinlei.lee]

From: Xinlei Lee 

Base on the branch of linus/master v6.1 rc1.

Change since v11:
1. Rebase on v6.1-rc1. Change nothing.

Change since v10:
1. Modify patch title and add review tag.

Change since v9:
1. Modify the location of the mmsys_dev member variable.

Change since v8:
1. Modified the title and some description information.

Changes since v7:
1. This series is based on the following patch:
   [1] soc: mediatek: Add mmsys func to adapt to dpi output for MT8186
   
https://patchwork.kernel.org/project/linux-mediatek/patch/1663161662-1598-2-git-send-email-xinlei@mediatek.com/
2. Modify the DPI_FORMAT_MASK macro definition to GENMASK(1, 0);
3. Add all settings to mtk_mmsys_ddp_dpi_fmt_config;
4. Modify the commit title to Add mt8186 dpi compatibles and platform
data.

Changes since v6:
1. Different from other ICs, when mt8186 DPI changes the output format,
the mmsys_base+400 register needs to be set to be valid at the same
time.
   In this series, all the situations that mmsys need to be set up are
perfected (not necessarily used in practice).
2. Put the value that controls the mmsys function in mtk-mmsys.h.
3. Encountered the sink ic switched between dual edge and single edge,
perfected setting and clearing mmsys bit operations in mtk_dpi.c.

Changes since v5:
1. Separate the patch that adds edge_cfg_in_mmsys from the patch that
adds mt8186 dpi support.
2. Move the mmsys register definition to mmsys driver.
 
Changes since v4:
1. This series of cancellations is based on the following patches:
   [1] Add MediaTek SoC(vdosys1) support for mt8195
   
https://patchwork.kernel.org/project/linux-mediatek/cover/20220711075245.10492-1-nancy@mediatek.com/
   [2] Add MediaTek SoC DRM (vdosys1) support for mt8195
   
https://patchwork.kernel.org/project/linux-mediatek/cover/20220804072827.22383-1-nancy@mediatek.com/
2. Added mtk_mmsys_update_bits function in mtk-mmsys.c;
3. MMSYS 0x400 register is modified to MT8186_MMSYS_DPI_OUTPUT_FORMAT;
4. Fix formatting issues.

Changes since v3:
1. Fix formatting issues;
2. Modify the edge output control name & description;
3. Fix the threading problem.

Changes since v2:
1. Modify key nouns in the description;
2. Add the label of jitao to Co-developed-by;
3. Macro definition address lowercase problem and function naming;
4. Add missing a description of this property in the mtk_dpi_conf.

Change since v1:
1. Modify mt8186 compatiable location.
2. Modify MT8186_DPI_OUTPUT_FORMAT name.

When MT8186 outputs dpi signal, it is necessary to add dual edge output
format control in mmsys.

Xinlei Lee (3):
  soc: mediatek: Add all settings to mtk_mmsys_ddp_dpi_fmt_config func
  drm: mediatek: Set dpi format in mmsys
  drm: mediatek: Add mt8186 dpi compatibles and platform data

 drivers/gpu/drm/mediatek/mtk_dpi.c | 32 ++
 drivers/gpu/drm/mediatek/mtk_drm_drv.c |  2 ++
 drivers/soc/mediatek/mt8186-mmsys.h|  8 ---
 drivers/soc/mediatek/mtk-mmsys.c   | 27 +-
 include/linux/soc/mediatek/mtk-mmsys.h |  7 ++
 5 files changed, 67 insertions(+), 9 deletions(-)

-- 
2.18.0

[PATCH v12,2/3] drm: mediatek: Set dpi format in mmsys

[xinlei.lee]

From: Xinlei Lee 

Dpi output needs to adjust the output format to dual edge for MT8186.

Co-developed-by: Jitao Shi 
Signed-off-by: Jitao Shi 
Signed-off-by: Xinlei Lee 
Reviewed-by: CK Hu 
---
 drivers/gpu/drm/mediatek/mtk_dpi.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 508a6d994e83..b9d740efdb6a 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -29,6 +30,7 @@
 #include "mtk_disp_drv.h"
 #include "mtk_dpi_regs.h"
 #include "mtk_drm_ddp_comp.h"
+#include "mtk_drm_drv.h"
 
 enum mtk_dpi_out_bit_num {
MTK_DPI_OUT_BIT_NUM_8BITS,
@@ -66,6 +68,7 @@ struct mtk_dpi {
struct drm_connector *connector;
void __iomem *regs;
struct device *dev;
+   struct device *mmsys_dev;
struct clk *engine_clk;
struct clk *pixel_clk;
struct clk *tvd_clk;
@@ -134,6 +137,7 @@ struct mtk_dpi_yc_limit {
  * @yuv422_en_bit: Enable bit of yuv422.
  * @csc_enable_bit: Enable bit of CSC.
  * @pixels_per_iter: Quantity of transferred pixels per iteration.
+ * @edge_cfg_in_mmsys: If the edge configuration for DPI's output needs to be 
set in MMSYS.
  */
 struct mtk_dpi_conf {
unsigned int (*cal_factor)(int clock);
@@ -152,6 +156,7 @@ struct mtk_dpi_conf {
u32 yuv422_en_bit;
u32 csc_enable_bit;
u32 pixels_per_iter;
+   bool edge_cfg_in_mmsys;
 };
 
 static void mtk_dpi_mask(struct mtk_dpi *dpi, u32 offset, u32 val, u32 mask)
@@ -448,8 +453,12 @@ static void mtk_dpi_dual_edge(struct mtk_dpi *dpi)
mtk_dpi_mask(dpi, DPI_OUTPUT_SETTING,
 dpi->output_fmt == MEDIA_BUS_FMT_RGB888_2X12_LE ?
 EDGE_SEL : 0, EDGE_SEL);
+   if (dpi->conf->edge_cfg_in_mmsys)
+   mtk_mmsys_ddp_dpi_fmt_config(dpi->mmsys_dev, 
MTK_DPI_RGB888_DDR_CON);
} else {
mtk_dpi_mask(dpi, DPI_DDR_SETTING, DDR_EN | DDR_4PHASE, 0);
+   if (dpi->conf->edge_cfg_in_mmsys)
+   mtk_mmsys_ddp_dpi_fmt_config(dpi->mmsys_dev, 
MTK_DPI_RGB888_SDR_CON);
}
 }
 
@@ -777,8 +786,10 @@ static int mtk_dpi_bind(struct device *dev, struct device 
*master, void *data)
 {
struct mtk_dpi *dpi = dev_get_drvdata(dev);
struct drm_device *drm_dev = data;
+   struct mtk_drm_private *priv = drm_dev->dev_private;
int ret;
 
+   dpi->mmsys_dev = priv->mmsys_dev;
ret = drm_simple_encoder_init(drm_dev, &dpi->encoder,
  DRM_MODE_ENCODER_TMDS);
if (ret) {
-- 
2.18.0

[PATCH v12, 1/3] soc: mediatek: Add all settings to mtk_mmsys_ddp_dpi_fmt_config func

[xinlei.lee]

From: Xinlei Lee 

The difference between MT8186 and other ICs is that when modifying the
output format, we need to modify the mmsys_base+0x400 register to take
effect.
So when setting the dpi output format, we need to call mmsys_func to set
it to MT8186 synchronously.
Adding mmsys all the settings that need to be modified with dpi are for
mt8186.

Fixes: a071e52f75d1 ("soc: mediatek: Add mmsys func to adapt to dpi
output for MT8186")

Signed-off-by: Xinlei Lee 
Reviewed-by: AngeloGioacchino Del Regno 

Reviewed-by: CK Hu 
---
 drivers/soc/mediatek/mt8186-mmsys.h|  8 +---
 drivers/soc/mediatek/mtk-mmsys.c   | 27 --
 include/linux/soc/mediatek/mtk-mmsys.h |  7 +++
 3 files changed, 33 insertions(+), 9 deletions(-)

diff --git a/drivers/soc/mediatek/mt8186-mmsys.h 
b/drivers/soc/mediatek/mt8186-mmsys.h
index 09b1ccbc0093..035aec1eb616 100644
--- a/drivers/soc/mediatek/mt8186-mmsys.h
+++ b/drivers/soc/mediatek/mt8186-mmsys.h
@@ -5,9 +5,11 @@
 
 /* Values for DPI configuration in MMSYS address space */
 #define MT8186_MMSYS_DPI_OUTPUT_FORMAT 0x400
-#define DPI_FORMAT_MASK0x1
-#define DPI_RGB888_DDR_CON BIT(0)
-#define DPI_RGB565_SDR_CON BIT(1)
+#define DPI_FORMAT_MASKGENMASK(1, 0)
+#define DPI_RGB888_SDR_CON 0
+#define DPI_RGB888_DDR_CON 1
+#define DPI_RGB565_SDR_CON 2
+#define DPI_RGB565_DDR_CON 3
 
 #define MT8186_MMSYS_OVL_CON   0xF04
 #define MT8186_MMSYS_OVL0_CON_MASK 0x3
diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index d2c7a87aab87..205f6de45851 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -238,12 +238,27 @@ static void mtk_mmsys_update_bits(struct mtk_mmsys 
*mmsys, u32 offset, u32 mask,
 
 void mtk_mmsys_ddp_dpi_fmt_config(struct device *dev, u32 val)
 {
-   if (val)
-   mtk_mmsys_update_bits(dev_get_drvdata(dev), 
MT8186_MMSYS_DPI_OUTPUT_FORMAT,
- DPI_RGB888_DDR_CON, DPI_FORMAT_MASK);
-   else
-   mtk_mmsys_update_bits(dev_get_drvdata(dev), 
MT8186_MMSYS_DPI_OUTPUT_FORMAT,
- DPI_RGB565_SDR_CON, DPI_FORMAT_MASK);
+   struct mtk_mmsys *mmsys = dev_get_drvdata(dev);
+
+   switch (val) {
+   case MTK_DPI_RGB888_SDR_CON:
+   mtk_mmsys_update_bits(mmsys, MT8186_MMSYS_DPI_OUTPUT_FORMAT,
+ DPI_FORMAT_MASK, DPI_RGB888_SDR_CON);
+   break;
+   case MTK_DPI_RGB565_SDR_CON:
+   mtk_mmsys_update_bits(mmsys, MT8186_MMSYS_DPI_OUTPUT_FORMAT,
+ DPI_FORMAT_MASK, DPI_RGB565_SDR_CON);
+   break;
+   case MTK_DPI_RGB565_DDR_CON:
+   mtk_mmsys_update_bits(mmsys, MT8186_MMSYS_DPI_OUTPUT_FORMAT,
+ DPI_FORMAT_MASK, DPI_RGB565_DDR_CON);
+   break;
+   case MTK_DPI_RGB888_DDR_CON:
+   default:
+   mtk_mmsys_update_bits(mmsys, MT8186_MMSYS_DPI_OUTPUT_FORMAT,
+ DPI_FORMAT_MASK, DPI_RGB888_DDR_CON);
+   break;
+   }
 }
 EXPORT_SYMBOL_GPL(mtk_mmsys_ddp_dpi_fmt_config);
 
diff --git a/include/linux/soc/mediatek/mtk-mmsys.h 
b/include/linux/soc/mediatek/mtk-mmsys.h
index d2b02bb43768..b85f66db33e1 100644
--- a/include/linux/soc/mediatek/mtk-mmsys.h
+++ b/include/linux/soc/mediatek/mtk-mmsys.h
@@ -9,6 +9,13 @@
 enum mtk_ddp_comp_id;
 struct device;
 
+enum mtk_dpi_out_format_con {
+   MTK_DPI_RGB888_SDR_CON,
+   MTK_DPI_RGB888_DDR_CON,
+   MTK_DPI_RGB565_SDR_CON,
+   MTK_DPI_RGB565_DDR_CON
+};
+
 enum mtk_ddp_comp_id {
DDP_COMPONENT_AAL0,
DDP_COMPONENT_AAL1,
-- 
2.18.0

Re: [PATCH v2] drm: Remove drm_mode_config::fb_base

[Zack Rusin]

On Tue, 2022-10-18 at 23:59 +0300, Andy Shevchenko wrote:
> ⚠ External Email
> 
> On Tue, Oct 18, 2022 at 08:26:17PM +, Zack Rusin wrote:
> > > On Oct 18, 2022, at 4:20 PM, Andy Shevchenko 
> > >  wrote:
> > > On Tue, Oct 18, 2022 at 12:11:51PM -0400, Zack Rusin wrote:
> > > > From: Zack Rusin 
> > > > 
> > > > v2: Thomas and Laurent noticed that in radeon_fb.c I forgot to set the
> > > > info->apertures->ranges[0].base and Laurent noticed a neat little 
> > > > cleanup
> > > > in the hisilicon driver as a result of the drm_mode_config::fb_base
> > > > removal.
> > > 
> > > You need to address LKP comment.
> > 
> > That came after v3, and I fixed it in the meantime. I will wait with sending
> > v4 until tomorrow to make sure I give everyone time to look at in case
> > there’s something else.
> 
> Hmm... Am I missing v3? I answer to v2 and LKP complaint against v1.

Possibly, it definitely went to the list, message-id
20221018164929.368012-1-z...@kde.org patchwork sees it at
https://patchwork.freedesktop.org/patch/507479/?series=109828&rev=3
lkp email came after I've sent it out. Anyway, it's not a big deal, I've just 
sent
out v4 which should be complete.

z

[PATCH v4] drm: Remove drm_mode_config::fb_base

[Zack Rusin]

From: Zack Rusin 

v4: Fix issue spotted by the kernel test robot

The fb_base in struct drm_mode_config has been unused for a long time.
Some drivers set it and some don't leading to a very confusing state
where the variable can't be relied upon, because there's no indication
as to which driver sets it and which doesn't.

The only usage of fb_base is internal to two drivers so instead of trying
to force it into all the drivers to get it into a coherent state
completely remove it.

Signed-off-by: Zack Rusin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c |  2 --
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c   |  2 --
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c   |  2 --
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c|  1 -
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c|  2 --
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c|  2 --
 drivers/gpu/drm/ast/ast_mode.c   |  2 --
 drivers/gpu/drm/gma500/framebuffer.c |  6 +++---
 drivers/gpu/drm/gma500/psb_drv.h |  1 +
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c  | 16 +++-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h  |  3 ---
 drivers/gpu/drm/mgag200/mgag200_mode.c   |  1 -
 drivers/gpu/drm/msm/msm_fbdev.c  |  2 --
 drivers/gpu/drm/nouveau/nouveau_display.c|  1 -
 drivers/gpu/drm/nouveau/nv04_fbcon.c |  6 --
 drivers/gpu/drm/omapdrm/omap_fbdev.c |  2 --
 drivers/gpu/drm/qxl/qxl_display.c|  2 --
 drivers/gpu/drm/radeon/radeon_display.c  |  2 --
 drivers/gpu/drm/radeon/radeon_fb.c   |  2 +-
 drivers/gpu/drm/tegra/fb.c   |  1 -
 drivers/gpu/drm/tiny/bochs.c |  1 -
 include/drm/drm_mode_config.h|  2 --
 22 files changed, 12 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
index f4b5301ea2a0..09dec2561adf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
@@ -498,8 +498,6 @@ static int amdgpu_vkms_sw_init(void *handle)
adev_to_drm(adev)->mode_config.preferred_depth = 24;
adev_to_drm(adev)->mode_config.prefer_shadow = 1;
 
-   adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
-
r = amdgpu_display_modeset_create_props(adev);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index 288fce7dc0ed..05051d5d2ec3 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -2800,8 +2800,6 @@ static int dce_v10_0_sw_init(void *handle)
 
adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
 
-   adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
-
r = amdgpu_display_modeset_create_props(adev);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index cbe5250b31cb..c928bc9eb202 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -2918,8 +2918,6 @@ static int dce_v11_0_sw_init(void *handle)
 
adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
 
-   adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
-
r = amdgpu_display_modeset_create_props(adev);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
index b1c44fab074f..62315fd5a05f 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
@@ -2675,7 +2675,6 @@ static int dce_v6_0_sw_init(void *handle)
adev_to_drm(adev)->mode_config.preferred_depth = 24;
adev_to_drm(adev)->mode_config.prefer_shadow = 1;
adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
-   adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
 
r = amdgpu_display_modeset_create_props(adev);
if (r)
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index a22b45c92792..87d5e4c21cb3 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -2701,8 +2701,6 @@ static int dce_v8_0_sw_init(void *handle)
 
adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
 
-   adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
-
r = amdgpu_display_modeset_create_props(adev);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index c053cb79cd06..0db2a88cd4d7 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -3816,8 +3816,6 @@ static int amdgpu_dm_mode_config_init(s

Re: [PATCH v4 09/17] drm/i915/vm_bind: Add out fence support

[Niranjana Vishwanathapura]

On Tue, Oct 18, 2022 at 04:28:07PM +0100, Matthew Auld wrote:

On 18/10/2022 08:16, Niranjana Vishwanathapura wrote:

Add support for handling out fence for vm_bind call.

v2: Reset vma->vm_bind_fence.syncobj to NULL at the end
of vm_bind call.
v3: Remove vm_unbind out fence uapi which is not supported yet.

Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h   |  4 +
 .../drm/i915/gem/i915_gem_vm_bind_object.c| 82 +++
 drivers/gpu/drm/i915/i915_vma.c   |  7 +-
 drivers/gpu/drm/i915/i915_vma_types.h |  7 ++
 include/uapi/drm/i915_drm.h   | 49 ++-
 5 files changed, 146 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
index 36262a6357b5..b70e900e35ab 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
@@ -8,6 +8,7 @@
 #include 
+struct dma_fence;
 struct drm_device;
 struct drm_file;
 struct i915_address_space;
@@ -23,4 +24,7 @@ int i915_gem_vm_unbind_ioctl(struct drm_device *dev, void 
*data,
 void i915_gem_vm_unbind_all(struct i915_address_space *vm);
+void i915_vm_bind_signal_fence(struct i915_vma *vma,
+  struct dma_fence * const fence);
+
 #endif /* __I915_GEM_VM_BIND_H */
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index 3ea3cb3ed97e..63889ba00183 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -7,6 +7,8 @@
 #include 
+#include 
+
 #include "gem/i915_gem_context.h"
 #include "gem/i915_gem_vm_bind.h"
@@ -100,6 +102,76 @@ static void i915_gem_vm_bind_remove(struct i915_vma *vma, 
bool release_obj)
i915_gem_object_put(vma->obj);
 }
+static int i915_vm_bind_add_fence(struct drm_file *file, struct i915_vma *vma,
+ u32 handle, u64 point)
+{
+   struct drm_syncobj *syncobj;
+
+   syncobj = drm_syncobj_find(file, handle);
+   if (!syncobj) {
+   DRM_DEBUG("Invalid syncobj handle provided\n");
+   return -ENOENT;
+   }
+
+   /*
+* For timeline syncobjs we need to preallocate chains for
+* later signaling.
+*/
+   if (point) {
+   vma->vm_bind_fence.chain_fence = dma_fence_chain_alloc();
+   if (!vma->vm_bind_fence.chain_fence) {
+   drm_syncobj_put(syncobj);
+   return -ENOMEM;
+   }
+   } else {
+   vma->vm_bind_fence.chain_fence = NULL;
+   }
+   vma->vm_bind_fence.syncobj = syncobj;
+   vma->vm_bind_fence.value = point;
+
+   return 0;
+}
+
+static void i915_vm_bind_put_fence(struct i915_vma *vma)
+{
+   if (!vma->vm_bind_fence.syncobj)
+   return;
+
+   drm_syncobj_put(vma->vm_bind_fence.syncobj);
+   dma_fence_chain_free(vma->vm_bind_fence.chain_fence);
+   vma->vm_bind_fence.syncobj = NULL;
+}
+
+/**
+ * i915_vm_bind_signal_fence() - Add fence to vm_bind syncobj
+ * @vma: vma mapping requiring signaling
+ * @fence: fence to be added
+ *
+ * Associate specified @fence with the @vma's syncobj to be
+ * signaled after the @fence work completes.
+ */
+void i915_vm_bind_signal_fence(struct i915_vma *vma,
+  struct dma_fence * const fence)
+{
+   struct drm_syncobj *syncobj = vma->vm_bind_fence.syncobj;
+
+   if (!syncobj)
+   return;
+
+   if (vma->vm_bind_fence.chain_fence) {
+   drm_syncobj_add_point(syncobj,
+ vma->vm_bind_fence.chain_fence,
+ fence, vma->vm_bind_fence.value);
+   /*
+* The chain's ownership is transferred to the
+* timeline.
+*/
+   vma->vm_bind_fence.chain_fence = NULL;
+   } else {
+   drm_syncobj_replace_fence(syncobj, fence);
+   }
+}
+
 static int i915_gem_vm_unbind_vma(struct i915_address_space *vm,
  struct drm_i915_gem_vm_unbind *va)
 {
@@ -237,6 +309,13 @@ static int i915_gem_vm_bind_obj(struct i915_address_space 
*vm,
goto unlock_vm;
}
+   if (va->fence.flags & I915_TIMELINE_FENCE_SIGNAL) {
+   ret = i915_vm_bind_add_fence(file, vma, va->fence.handle,
+va->fence.value);
+   if (ret)
+   goto put_vma;
+   }
+
pin_flags = va->start | PIN_OFFSET_FIXED | PIN_USER | PIN_VALIDATE;
for_i915_gem_ww(&ww, ret, true) {
@@ -258,6 +337,9 @@ static int i915_gem_vm_bind_obj(struct i915_address_space 
*vm,
i915_gem_object_get(vma->obj);
}
+   if (va->fence.flags & I915_TIMELINE_FENCE

Re: [PATCH v12 5/6] drm/imx: Introduce i.MX8qm/qxp DPU DRM

[Liu Ying]

On Wed, 2022-10-19 at 07:41 +0800, kernel test robot wrote:
> Hi Liu,
> 
> I love your patch! Yet something to improve:
> 
> [auto build test ERROR on drm-misc/drm-misc-next]
> [also build test ERROR on drm/drm-next drm-exynos/exynos-drm-next
> drm-intel/for-linux-next drm-tip/drm-tip linus/master v6.1-rc1 next-
> 20221018]

[...]

> All errors (new ones prefixed by >>):
> 
>drivers/gpu/drm/imx/dpu/dpu-drv.c: In function 'dpu_drm_bind':
> > > drivers/gpu/drm/imx/dpu/dpu-drv.c:67:12: error: 'struct
> > > drm_device' has no member named 'irq_enabled'
> 
>   67 | drm->irq_enabled = true;
>  |^~

I've sent v13 to fix the potential build break by removing this line
since drm->irq_enabled should only be used by legacy drm drivers with
userspace modesetting but not imx-dpu drm driver.

Thanks for reporting the issue.

Liu Ying

[...]

[PATCH v13 6/6] MAINTAINERS: add maintainer for i.MX8qxp DPU DRM driver

[Liu Ying]

Add myself as the maintainer of the i.MX8qxp DPU DRM driver.

Acked-by: Laurentiu Palcu 
Signed-off-by: Liu Ying 
---
v11->v13:
* No change.

v10->v11:
* Rebase upon v6.0-rc1.

v9->v10:
* Add Laurentiu's A-b tag.

v1->v9:
* No change.

 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index cf0f18502372..a882de9ed4cb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6902,6 +6902,15 @@ F:   
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml
 F: 
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml
 F: drivers/gpu/drm/bridge/imx/
 
+DRM DRIVERS FOR FREESCALE i.MX8QXP
+M: Liu Ying 
+L: dri-devel@lists.freedesktop.org
+S: Maintained
+F: Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
+F: Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml
+F: Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
+F: drivers/gpu/drm/imx/dpu/
+
 DRM DRIVERS FOR GMA500 (Poulsbo, Moorestown and derivative chipsets)
 M: Patrik Jakobsson 
 L: dri-devel@lists.freedesktop.org
-- 
2.37.1

[PATCH v13 4/6] drm/atomic: Avoid unused-but-set-variable warning on for_each_old_plane_in_state

[Liu Ying]

Artificially use 'plane' and 'old_plane_state' to avoid 'not used' warning.
The precedent has already been set by other macros in the same file.

Acked-by: Daniel Vetter 
Signed-off-by: Liu Ying 
---
v6->v13:
* No change.

v5->v6:
* Fix commit message typo - s/Artifically/Artificially/

v4->v5:
* No change.

v3->v4:
* Add Daniel's A-b tag.

v2->v3:
* Add a missing blank line.

v1->v2:
* No change.

 include/drm/drm_atomic.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index 10b1990bc1f6..bcd6ff9d18e1 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -947,7 +947,10 @@ void drm_state_dump(struct drm_device *dev, struct 
drm_printer *p);
 (__i)++)   \
for_each_if ((__state)->planes[__i].ptr &&  \
 ((plane) = (__state)->planes[__i].ptr, \
- (old_plane_state) = 
(__state)->planes[__i].old_state, 1))
+ (void)(plane) /* Only to avoid 
unused-but-set-variable warning */, \
+ (old_plane_state) = 
(__state)->planes[__i].old_state, \
+ (void)(old_plane_state) /* Only to avoid 
unused-but-set-variable warning */, 1))
+
 /**
  * for_each_new_plane_in_state - iterate over all planes in an atomic update
  * @__state: &struct drm_atomic_state pointer
-- 
2.37.1

[PATCH v13 3/6] dt-bindings: display: imx: Add i.MX8qxp/qm DPR channel binding

[Liu Ying]

This patch adds bindings for i.MX8qxp/qm Display Prefetch Resolve Channel.

Reviewed-by: Rob Herring 
Signed-off-by: Liu Ying 
---
v10->v13:
* No change.

v9->v10:
* Add Rob's R-b tag.

v8->v9:
* Reference 'interrupts-extended' schema instead of 'interrupts' to require
  an additional interrupt(r_rtram_stall) because the reference manual does
  mention it, though the driver doesn't get/use it for now.
  Reference 'interrupt-names' schema to define the two interrupt names -
  'dpr_wrap' and 'r_rtram_stall'.
* Drop Rob's R-b tag, as review is needed.

v4->v8:
* No change.

v3->v4:
* Improve compatible property by using enum instead of oneOf+const. (Rob)
* Add Rob's R-b tag.

v2->v3:
* No change.

v1->v2:
* Use new dt binding way to add clocks in the example.

 .../display/imx/fsl,imx8qxp-dprc.yaml | 100 ++
 1 file changed, 100 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml

diff --git 
a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml 
b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
new file mode 100644
index ..bd94254c1288
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dprc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp Display Prefetch Resolve Channel
+
+maintainers:
+  - Liu Ying 
+
+description: |
+  The i.MX8qm/qxp Display Prefetch Resolve Channel(DPRC) is an engine which
+  fetches display data before the display pipeline needs the data to drive
+  pixels in the active display region.  This data is transformed, or resolved,
+  from a variety of tiled buffer formats into linear format, if needed.
+  The DPR works with a double bank memory structure.  This memory structure is
+  implemented in the Resolve Tile Memory(RTRAM) and the banks are referred to
+  as A and B.  Each bank is either 4 or 8 lines high depending on the source
+  frame buffer format.
+
+properties:
+  compatible:
+enum:
+  - fsl,imx8qxp-dpr-channel
+  - fsl,imx8qm-dpr-channel
+
+  reg:
+maxItems: 1
+
+  interrupts-extended:
+items:
+  - description: DPR wrap interrupt
+  - description: |
+  'r_rtram_stall' interrupt which indicates relevant i.MX8qm/qxp
+  Prefetch Resolve Gasket(PRG) or PRGs are forcing an underflow
+  condition in the RTRAM.
+
+  interrupt-names:
+items:
+  - const: dpr_wrap
+  - const: r_rtram_stall
+
+  clocks:
+items:
+  - description: apb clock
+  - description: b clock
+  - description: rtram clock
+
+  clock-names:
+items:
+  - const: apb
+  - const: b
+  - const: rtram
+
+  fsl,sc-resource:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: The SCU resource ID associated with this DPRC instance.
+
+  fsl,prgs:
+$ref: /schemas/types.yaml#/definitions/phandle-array
+description: |
+  List of phandle which points to PRG or PRGs associated with
+  this DPRC instance.
+
+  power-domains:
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - interrupts-extended
+  - interrupt-names
+  - clocks
+  - clock-names
+  - fsl,sc-resource
+  - fsl,prgs
+  - power-domains
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+#include 
+dpr-channel@5610 {
+compatible = "fsl,imx8qxp-dpr-channel";
+reg = <0x5610 0x1>;
+interrupts-extended = <&gic GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>,
+  <&dc0_irqsteer 324>;
+interrupt-names = "dpr_wrap", "r_rtram_stall";
+clocks = <&dc0_dpr1_lpcg IMX_LPCG_CLK_4>,
+ <&dc0_dpr1_lpcg IMX_LPCG_CLK_5>,
+ <&dc0_rtram1_lpcg IMX_LPCG_CLK_0>;
+clock-names = "apb", "b", "rtram";
+fsl,sc-resource = ;
+fsl,prgs = <&dc0_prg4>, <&dc0_prg5>;
+power-domains = <&pd IMX_SC_R_DC_0>;
+};
-- 
2.37.1

[PATCH v13 1/6] dt-bindings: display: imx: Add i.MX8qxp/qm DPU binding

[Liu Ying]

This patch adds bindings for i.MX8qxp/qm Display Processing Unit.

Reviewed-by: Rob Herring 
Signed-off-by: Liu Ying 
---
v7->v13:
* No change.

v6->v7:
* Add Rob's R-b tag back.

v5->v6:
* Use graph schema. So, drop Rob's R-b tag as review is needed.

v4->v5:
* No change.

v3->v4:
* Improve compatible property by using enum instead of oneOf+const. (Rob)
* Add Rob's R-b tag.

v2->v3:
* No change.

v1->v2:
* Fix yamllint warnings.
* Require bypass0 and bypass1 clocks for both i.MX8qxp and i.MX8qm, as the
  display controller subsystem spec does say that they exist.
* Use new dt binding way to add clocks in the example.
* Trivial tweaks for the example.

 .../bindings/display/imx/fsl,imx8qxp-dpu.yaml | 387 ++
 1 file changed, 387 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml

diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml 
b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml
new file mode 100644
index ..6b05c586cd9d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml
@@ -0,0 +1,387 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp Display Processing Unit
+
+maintainers:
+  - Liu Ying 
+
+description: |
+  The Freescale i.MX8qm/qxp Display Processing Unit(DPU) is comprised of two
+  main components that include a blit engine for 2D graphics accelerations
+  and a display controller for display output processing, as well as a command
+  sequencer.
+
+properties:
+  compatible:
+enum:
+  - fsl,imx8qxp-dpu
+  - fsl,imx8qm-dpu
+
+  reg:
+maxItems: 1
+
+  interrupts:
+items:
+  - description: |
+  store9 shadow load interrupt(blit engine)
+  - description: |
+  store9 frame complete interrupt(blit engine)
+  - description: |
+  store9 sequence complete interrupt(blit engine)
+  - description: |
+  extdst0 shadow load interrupt
+  (display controller, content stream 0)
+  - description: |
+  extdst0 frame complete interrupt
+  (display controller, content stream 0)
+  - description: |
+  extdst0 sequence complete interrupt
+  (display controller, content stream 0)
+  - description: |
+  extdst4 shadow load interrupt
+  (display controller, safety stream 0)
+  - description: |
+  extdst4 frame complete interrupt
+  (display controller, safety stream 0)
+  - description: |
+  extdst4 sequence complete interrupt
+  (display controller, safety stream 0)
+  - description: |
+  extdst1 shadow load interrupt
+  (display controller, content stream 1)
+  - description: |
+  extdst1 frame complete interrupt
+  (display controller, content stream 1)
+  - description: |
+  extdst1 sequence complete interrupt
+  (display controller, content stream 1)
+  - description: |
+  extdst5 shadow load interrupt
+  (display controller, safety stream 1)
+  - description: |
+  extdst5 frame complete interrupt
+  (display controller, safety stream 1)
+  - description: |
+  extdst5 sequence complete interrupt
+  (display controller, safety stream 1)
+  - description: |
+  disengcfg0 shadow load interrupt
+  (display controller, display stream 0)
+  - description: |
+  disengcfg0 frame complete interrupt
+  (display controller, display stream 0)
+  - description: |
+  disengcfg0 sequence complete interrupt
+  (display controller, display stream 0)
+  - description: |
+  framegen0 programmable interrupt0
+  (display controller, display stream 0)
+  - description: |
+  framegen0 programmable interrupt1
+  (display controller, display stream 0)
+  - description: |
+  framegen0 programmable interrupt2
+  (display controller, display stream 0)
+  - description: |
+  framegen0 programmable interrupt3
+  (display controller, display stream 0)
+  - description: |
+  signature0 shadow load interrupt
+  (display controller, display stream 0)
+  - description: |
+  signature0 measurement valid interrupt
+  (display controller, display stream 0)
+  - description: |
+  signature0 error condition interrupt
+  (display controller, display stream 0)
+  - description: |
+  disengcfg1 shadow load interrupt
+  (display controller, display stream 1)
+  - description: |
+  disengcfg1 frame complete interrupt
+  (display controller, display stream 1)
+  - description: |
+  diseng

[PATCH v13 2/6] dt-bindings: display: imx: Add i.MX8qxp/qm PRG binding

[Liu Ying]

This patch adds bindings for i.MX8qxp/qm Display Prefetch Resolve Gasket.

Reviewed-by: Rob Herring 
Signed-off-by: Liu Ying 
---
v4->v13:
* No change.

v3->v4:
* Improve compatible property by using enum instead of oneOf+const. (Rob)
* Add Rob's R-b tag.

v2->v3:
* No change.

v1->v2:
* Use new dt binding way to add clocks in the example.

 .../bindings/display/imx/fsl,imx8qxp-prg.yaml | 60 +++
 1 file changed, 60 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml

diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml 
b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
new file mode 100644
index ..3ff46e0d4e73
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-prg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp Display Prefetch Resolve Gasket
+
+maintainers:
+  - Liu Ying 
+
+description: |
+  The i.MX8qm/qxp Prefetch Resolve Gasket (PRG) is a gasket interface between
+  RTRAM controller and Display Controller.  The main function is to convert
+  the AXI interface to the RTRAM interface, which includes re-mapping the
+  ARADDR to a RTRAM address.
+
+properties:
+  compatible:
+enum:
+  - fsl,imx8qxp-prg
+  - fsl,imx8qm-prg
+
+  reg:
+maxItems: 1
+
+  clocks:
+items:
+  - description: rtram clock
+  - description: apb clock
+
+  clock-names:
+items:
+  - const: rtram
+  - const: apb
+
+  power-domains:
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - power-domains
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+prg@5604 {
+compatible = "fsl,imx8qxp-prg";
+reg = <0x5604 0x1>;
+clocks = <&dc0_prg0_lpcg IMX_LPCG_CLK_0>,
+ <&dc0_prg0_lpcg IMX_LPCG_CLK_4>;
+clock-names = "rtram", "apb";
+power-domains = <&pd IMX_SC_R_DC_0>;
+};
-- 
2.37.1

[PATCH v13 0/6] drm/imx: Introduce i.MX8qm/qxp DPU DRM

[Liu Ying]

Hi,


This is the v13 series to introduce i.MX8qm/qxp Display Processing Unit(DPU)
DRM support.

DPU is comprised of a blit engine for 2D graphics, a display controller
and a command sequencer.  Outside of DPU, optional prefetch engines can
fetch data from memory prior to some DPU fetchunits of blit engine and
display controller.  The pre-fetchers support linear formats and Vivante
GPU tile formats.

Reference manual can be found at:
https://www.nxp.com/webapp/Download?colCode=IMX8DQXPRM


This patch set adds kernel modesetting support for the display controller part.
It supports two CRTCs per display controller, several planes, prefetch
engines and some properties of CRTC and plane.  Currently, the registers of
the controller is accessed without command sequencer involved, instead just by
using CPU.  DRM connectors would be created from the DPU KMS driver.


Patch 1 ~ 3 add dt-bindings for DPU and prefetch engines.
Patch 4 is a minor improvement of a macro to suppress warning as the KMS driver
uses it.
Patch 5 introduces the DPU DRM support.
Patch 6 updates MAINTAINERS.

Welcome comments, thanks.

v12->v13:
* Drop 'drm->irq_enabled = true;' from patch 5/6 to fix a potential build
  break reported by 'kernel test robot '.  drm->irq_enabled
  should not be used by imx-dpu drm as it is only used by legacy drivers
  with userspace modesetting.

v11->v12:
* Rebase the series upon v6.1-rc1.
* Minor update on Kconfigs, struct names and macro names for patch 5/6
  due to the rebase.

v10->v11:
* Rebase the series upon v6.0-rc1.
* Include drm_blend.h and drm_framebuffer.h in dpu-kms.c and dpu-plane.c
  to fix build errors due to the rebase.
* Fix a checkpatch warning for dpu-crtc.c.
* Properly use dev_err_probe() to return it's return value directly where
  possible.

v9->v10:
* Rebase the series upon v5.18-rc1.
* Make 'checkpatch.pl --strict' happier for patch 5/6.
* Add Rob's R-b tag on patch 3/6.
* Add Laurentiu's R-b tag on patch 5/6.
* Add Laurentiu's A-b tag on patch 6/6.

v8->v9:
* Use drm_atomic_get_new_plane_state() in dpu_plane_atomic_update() for
  patch 5/6. (Laurentiu)
* Drop getting DPU DT alias ID for patch 5/6, as it is unused.
* Reference 'interrupts-extended' schema instead of 'interrupts' for patch 3/6
  to require an additional DPR interrupt(r_rtram_stall) because the reference
  manual does mention it, though the driver doesn't get/use it for now.
  Reference 'interrupt-names' schema to define the two DPR interrupt names -
  'dpr_wrap' and 'r_rtram_stall'.  Accordingly, patch 5/6 gets the 'dpr_wrap'
  interrupt by name.
* Drop Rob's R-b tag on patch 3/6, as review is needed.

v7->v8:
* Rebase this series up onto the latest drm-misc-next branch, due to DRM plane
  helper functions API change(atomic_check and atomic_update) from DRM atomic
  core.  So, dpu_plane_atomic_check() and dpu_plane_atomic_update() are updated
  accordingly in patch 5/6.  Also, rename plane->state variables and relevant
  DPU plane state variables in those two functions to reflect they are new
  states, like the patch 'drm: Rename plane->state variables in atomic update
  and disable' recently landed in drm-misc-next.
* Replace drm_gem_fb_prepare_fb() with drm_gem_plane_helper_prepare_fb() in
  patch 5/6, due to DRM core API change.
* Improve DPR burst length for GPU standard tile and 32bpp GPU super tile in
  patch 5/6 to align with the latest version of internal HW documention.

v6->v7:
* Fix return value of dpu_get_irqs() if platform_get_irq() fails. (Laurentiu)
* Use the function array dpu_irq_handler[] to store individual DPU irq handlers.
  (Laurentiu)
* Call get/put() hooks directly to get/put DPU fetchunits for DPU plane groups.
  (Laurentiu)
* Shorten the names of individual DPU irq handlers by using DPU unit abbrev
  names to make writing dpu_irq_handler[] easier.
* Add Rob's R-b tag back on DPU dt-binding patch as change in v6 was reviewed.

v5->v6:
* Use graph schema in the DPU dt-binding.
* Do not use macros where possible in the DPU DRM driver. (Laurentiu)
* Break dpu_plane_atomic_check() into some smaller functions. (Laurentiu)
* Address some minor comments from Laurentiu on the DPU DRM driver.
* Add dpu_crtc_err() helper marco in the DPU DRM driver to tell dmesg
  which CRTC generates error.
* Drop calling dev_set_drvdata() from dpu_drm_bind/unbind() in the DPU DRM
  driver as it is done in dpu_drm_probe().
* Some trivial tweaks.

v4->v5:
* Rebase up onto the latest drm-misc-next branch and remove the hook to
  drm_atomic_helper_legacy_gamma_set() from patch 5/6, because it was dropped
  by the newly landed commit 'drm: automatic legacy gamma support'.
* Remove a redundant blank line from dpu_plane_atomic_update() in patch 5/6.

v3->v4:
* Improve compatible properties in DPU and prefetch engines' dt bindings
  by using enum instead of oneOf+const.
* Add Rob's R-b tags on dt binding patches(patch 1/6, 2/6 and 3/6).
* Add Daniel's A-b tag on patch 4/6.

v2->v3:
* Fix DPU DRM driver build warnings which are

Re: [PATCH v2 5/7] drm/i915/mtl: Handle wopcm per-GT and limit calculations.

[John Harrison]

On 10/12/2022 17:03, Daniele Ceraolo Spurio wrote:

From: Aravind Iddamsetty 

With MTL standalone media architecture the wopcm layout has changed with
separate partitioning in WOPCM for GCD/GT GuC and SA Media GuC. The size

What is GCD?


of WOPCM is 4MB with lower 2MB for SA Media and upper 2MB for GCD/GT.

 +=+===> ++ <== WOPCM TOP
 ^ ^ ||
 | | ||
 |GCD|   GCD RC6 Image|
 |GuC|Power Context   |
 |WOPCM  ||
 |Size   ++
 | | |   GCD GuC Image|
 | | ||
 | v ||
 | +===> ++ <== SA Media GuC WOPCM Top
 | ^ ||
 |   SA Media||
 |GuC| SA Media RC6 Image |
 |   WOPCM   |Power Context   |
 |Size   ||
   WOPCM   | ++
 | | ||
 | | | SA Media GuC Image |
 | v ||
 | +===> ++ <== GuC WOPCM base
 |   | WOPCM RSVD |
 |   +--- + <== HuC Firmware Top
 v   |  HuC FW|
 +=> ++ <== WOPCM Base

Given that MTL has GuC deprivilege, the WOPCM registers are pre-locked
by the bios. Therefore, we can skip all the math for the partitioning
and just limit ourselves to sanity checking the values.

v2: fix makefile file ordering (Jani)

Signed-off-by: Aravind Iddamsetty 
Signed-off-by: Daniele Ceraolo Spurio 
Cc: Matt Roper 
Cc: John Harrison 
Cc: Alan Previn 
Cc: Jani Nikula 
---
  drivers/gpu/drm/i915/Makefile   |  5 ++-
  drivers/gpu/drm/i915/gt/intel_ggtt.c|  2 +-
  drivers/gpu/drm/i915/gt/intel_gt.c  |  1 +
  drivers/gpu/drm/i915/gt/intel_gt_types.h|  2 +
  drivers/gpu/drm/i915/{ => gt}/intel_wopcm.c | 48 +++--
  drivers/gpu/drm/i915/{ => gt}/intel_wopcm.h |  0
  drivers/gpu/drm/i915/gt/uc/intel_uc.c   |  4 +-
  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c| 14 +++---
  drivers/gpu/drm/i915/i915_driver.c  |  2 -
  drivers/gpu/drm/i915/i915_drv.h |  3 --
  drivers/gpu/drm/i915/i915_gem.c |  5 ++-
  11 files changed, 55 insertions(+), 31 deletions(-)
  rename drivers/gpu/drm/i915/{ => gt}/intel_wopcm.c (86%)
  rename drivers/gpu/drm/i915/{ => gt}/intel_wopcm.h (100%)

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index f8cc1eb52626..4101b3507346 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -127,9 +127,11 @@ gt-y += \
gt/intel_sseu.o \
gt/intel_sseu_debugfs.o \
gt/intel_timeline.o \
+   gt/intel_wopcm.o \
gt/intel_workarounds.o \
gt/shmem_utils.o \
gt/sysfs_engines.o
+
  # x86 intel-gtt module support
  gt-$(CONFIG_X86) += gt/intel_ggtt_gmch.o
  # autogenerated null render state
@@ -183,8 +185,7 @@ i915-y += \
  i915_trace_points.o \
  i915_ttm_buddy_manager.o \
  i915_vma.o \
- i915_vma_resource.o \
- intel_wopcm.o
+ i915_vma_resource.o
  
  # general-purpose microcontroller (GuC) support

  i915-y += gt/uc/intel_uc.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 5c67e49aacf6..b30560ab1c1b 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -560,7 +560,7 @@ static int init_ggtt(struct i915_ggtt *ggtt)
 * why.
 */
ggtt->pin_bias = max_t(u32, I915_GTT_PAGE_SIZE,
-  intel_wopcm_guc_size(&ggtt->vm.i915->wopcm));
+  intel_wopcm_guc_size(&ggtt->vm.gt->wopcm));
  
  	ret = intel_vgt_balloon(ggtt);

if (ret)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index b367cfff48d5..a95eb0b656d2 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -56,6 +56,7 @@ void intel_gt_common_init_early(struct intel_gt *gt)
seqcount_mutex_init(>->tlb.seqno, >->tlb.invalidate_lock);
intel_gt_pm_init_early(gt);
  
+	intel_wopcm_init_early(>->wopcm);

intel_uc_init_early(>->uc);
intel_rps_init_early(>->rps);
  }
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h 
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index 30003d68fd51..a23cd3af5bf2 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -30,6 +30,7 @@
  #include "intel_migrate_types.h"
  #include "intel_wakeref.h"
  #include "pxp/intel_pxp_types.h"
+#include "intel_wopcm.h"
  
  struct drm_i915_private;

  struct i915_ggtt;
@@ -98,6 +99,7 @@ struct intel_gt {
  
  	struct intel_uc uc;

struct intel_gsc g

Re: [PATCH 0/2] drm/tiny: add support tft display based on ilitek,ili9488

[Noralf Trønnes]

Den 18.10.2022 23.28, skrev Michael Nazzareno Trimarchi:
> Hi
> 
> On Tue, Oct 18, 2022 at 9:06 PM Noralf Trønnes  wrote:
>>
>>
>>
>> Den 18.10.2022 18.45, skrev Tommaso Merciai:
>>> Hi All,
>>> This series  support for ilitek,ili9488 based displays like
>>> Waveshare-ResTouch-LCD-3.5 display. Tested on Waveshare-ResTouch-LCD-3.5
>>> connected to px30-evb via SPI.
>>
>> There's a generic MIPI DBI SPI driver now that should work with all
>> these panels: drivers/gpu/drm/tiny/panel-mipi-dbi.c
>>
>> More info: https://github.com/notro/panel-mipi-dbi/wiki
>>
> 
> We have seen it but it does not apply to the color output and there is
> no helper. I was a bit surprised
> to have a generic panel for spi and not for standard mipi one.
> 

Yeah, you're right the generic driver doesn't support rgb666 I assumed
it was rgb565.

Noralf.

Re: [PATCH 1/2] drm/sched: add DRM_SCHED_FENCE_DONT_PIPELINE flag

[Luben Tuikov]

On 2022-10-18 11:37, Alex Deucher wrote:
> On Tue, Oct 18, 2022 at 11:11 AM Christian König
>  wrote:
>>
>> Gentle ping to others to get this reviewed.
>>
>> Alex, this is fixing the TLB flush errors and I think we need to get it
>> into -fixes ASAP.
>>
>> Christian.
>>
>> Am 14.10.22 um 10:15 schrieb Christian König:
>>> Setting this flag on a scheduler fence prevents pipelining of jobs
>>> depending on this fence. In other words we always insert a full CPU
>>> round trip before dependen jobs are pushed to the pipeline.
> 
> typo: dependen -> dependent
> 
>>>
>>> Signed-off-by: Christian König 
>>> CC: sta...@vger.kernel.org # 5.19+
> 
> Please add a link to the bug as well for both patches.  With those
> fixed, series is:
> Reviewed-by: Alex Deucher 

Hi Christian,

Thanks for fixing this. You can add my,

Acked-by: Luben Tuikov 

Regards,
Luben

> 
>>> ---
>>>   drivers/gpu/drm/scheduler/sched_entity.c | 3 ++-
>>>   include/drm/gpu_scheduler.h  | 9 +
>>>   2 files changed, 11 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/scheduler/sched_entity.c 
>>> b/drivers/gpu/drm/scheduler/sched_entity.c
>>> index 191c56064f19..43d337d8b153 100644
>>> --- a/drivers/gpu/drm/scheduler/sched_entity.c
>>> +++ b/drivers/gpu/drm/scheduler/sched_entity.c
>>> @@ -385,7 +385,8 @@ static bool drm_sched_entity_add_dependency_cb(struct 
>>> drm_sched_entity *entity)
>>>   }
>>>
>>>   s_fence = to_drm_sched_fence(fence);
>>> - if (s_fence && s_fence->sched == sched) {
>>> + if (s_fence && s_fence->sched == sched &&
>>> + !test_bit(DRM_SCHED_FENCE_DONT_PIPELINE, &fence->flags)) {
>>>
>>>   /*
>>>* Fence is from the same scheduler, only need to wait for
>>> diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
>>> index 0fca8f38bee4..f01d14b231ed 100644
>>> --- a/include/drm/gpu_scheduler.h
>>> +++ b/include/drm/gpu_scheduler.h
>>> @@ -32,6 +32,15 @@
>>>
>>>   #define MAX_WAIT_SCHED_ENTITY_Q_EMPTY msecs_to_jiffies(1000)
>>>
>>> +/**
>>> + * DRM_SCHED_FENCE_DONT_PIPELINE - Prefent dependency pipelining
>>> + *
>>> + * Setting this flag on a scheduler fence prevents pipelining of jobs 
>>> depending
>>> + * on this fence. In other words we always insert a full CPU round trip 
>>> before
>>> + * dependen jobs are pushed to the hw queue.
>>> + */
>>> +#define DRM_SCHED_FENCE_DONT_PIPELINEDMA_FENCE_FLAG_USER_BITS
>>> +
>>>   struct drm_gem_object;
>>>
>>>   struct drm_gpu_scheduler;
>>

[PATCH] drm/i915/slpc: Optmize waitboost for SLPC

[Vinay Belgaumkar]

Waitboost (when SLPC is enabled) results in a H2G message. This can result
in thousands of messages during a stress test and fill up an already full
CTB. There is no need to request for RP0 if GuC is already requesting the
same.

Signed-off-by: Vinay Belgaumkar 
---
 drivers/gpu/drm/i915/gt/intel_rps.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
b/drivers/gpu/drm/i915/gt/intel_rps.c
index fc23c562d9b2..a20ae4fceac8 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -1005,13 +1005,20 @@ void intel_rps_dec_waiters(struct intel_rps *rps)
 void intel_rps_boost(struct i915_request *rq)
 {
struct intel_guc_slpc *slpc;
+   struct intel_rps *rps = &READ_ONCE(rq->engine)->gt->rps;
 
if (i915_request_signaled(rq) || i915_request_has_waitboost(rq))
return;
 
+   /* If GuC is already requesting RP0, skip */
+   if (rps_uses_slpc(rps)) {
+   slpc = rps_to_slpc(rps);
+   if (intel_rps_get_requested_frequency(rps) == slpc->rp0_freq)
+   return;
+   }
+
/* Serializes with i915_request_retire() */
if (!test_and_set_bit(I915_FENCE_FLAG_BOOST, &rq->fence.flags)) {
-   struct intel_rps *rps = &READ_ONCE(rq->engine)->gt->rps;
 
if (rps_uses_slpc(rps)) {
slpc = rps_to_slpc(rps);
-- 
2.35.1

Re: [PATCH] drm/i915/pvc: Update forcewake domain for CCS register ranges

[Chegondi, Harish]

On Fri, 2022-10-14 at 16:30 -0700, Matt Roper wrote:
> The bspec was just updated with a correction to the forcewake domain
> required when accessing registers in the CCS engine ranges (0x1a000 -
> 0x1 and 0x26000 - 0x27fff) on PVC; these ranges require a wake on
> the RENDER domain, not the GT domain.
> 
> Bspec: 67609
> Signed-off-by: Matt Roper 

Reviewed-by: Harish Chegondi 

>  drivers/gpu/drm/i915/intel_uncore.c | 22 --
>  1 file changed, 12 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index c058cdc6d8a0..2a3e2869fe71 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -1682,25 +1682,27 @@ static const struct intel_forcewake_range
> __pvc_fw_ranges[] = {
> GEN_FW_RANGE(0x12000, 0x12fff, 0), /*
> 0x12000 - 0x127ff: always on
> 0x12800 - 0x12fff: reserved */
> -   GEN_FW_RANGE(0x13000, 0x23fff, FORCEWAKE_GT), /*
> +   GEN_FW_RANGE(0x13000, 0x19fff, FORCEWAKE_GT), /*
> 0x13000 - 0x135ff: gt
> 0x13600 - 0x147ff: reserved
> 0x14800 - 0x153ff: gt
> -   0x15400 - 0x19fff: reserved
> -   0x1a000 - 0x1: gt
> -   0x2 - 0x21fff: reserved
> -   0x22000 - 0x23fff: gt */
> +   0x15400 - 0x19fff: reserved */
> +   GEN_FW_RANGE(0x1a000, 0x21fff, FORCEWAKE_RENDER), /*
> +   0x1a000 - 0x1: render
> +   0x2 - 0x21fff: reserved */
> +   GEN_FW_RANGE(0x22000, 0x23fff, FORCEWAKE_GT),
> GEN_FW_RANGE(0x24000, 0x2417f, 0), /*
> 24000 - 0x2407f: always on
> 24080 - 0x2417f: reserved */
> -   GEN_FW_RANGE(0x24180, 0x3, FORCEWAKE_GT), /*
> +   GEN_FW_RANGE(0x24180, 0x25fff, FORCEWAKE_GT), /*
> 0x24180 - 0x241ff: gt
> 0x24200 - 0x251ff: reserved
> 0x25200 - 0x252ff: gt
> -   0x25300 - 0x25fff: reserved
> -   0x26000 - 0x27fff: gt
> -   0x28000 - 0x2: reserved
> -   0x3 - 0x3: gt */
> +   0x25300 - 0x25fff: reserved */
> +   GEN_FW_RANGE(0x26000, 0x2, FORCEWAKE_RENDER), /*
> +   0x26000 - 0x27fff: render
> +   0x28000 - 0x2: reserved */
> +   GEN_FW_RANGE(0x3, 0x3, FORCEWAKE_GT),
> GEN_FW_RANGE(0x4, 0x1b, 0),
> GEN_FW_RANGE(0x1c, 0x1c3fff, FORCEWAKE_MEDIA_VDBOX0), /*
> 0x1c - 0x1c2bff: VD0

Re: [PATCH v5 20/22] drm/vc4: vec: Convert to the new TV mode property

[Mateusz Kwiatkowski]

Hi Maxime,

W dniu 18.10.2022 o 12:00, Maxime Ripard pisze:
> On Mon, Oct 17, 2022 at 12:31:31PM +0200, Noralf Trønnes wrote:
>> Den 16.10.2022 20.52, skrev Mateusz Kwiatkowski:
  static int vc4_vec_connector_get_modes(struct drm_connector *connector)
  {
 -  struct drm_connector_state *state = connector->state;
struct drm_display_mode *mode;
  
 -  mode = drm_mode_duplicate(connector->dev,
 -vc4_vec_tv_modes[state->tv.legacy_mode].mode);
 +  mode = drm_mode_analog_ntsc_480i(connector->dev);
if (!mode) {
DRM_ERROR("Failed to create a new display mode\n");
return -ENOMEM;
}
  
 +  mode->type |= DRM_MODE_TYPE_PREFERRED;
drm_mode_probed_add(connector, mode);
  
 -  return 1;
 +  mode = drm_mode_analog_pal_576i(connector->dev);
 +  if (!mode) {
 +  DRM_ERROR("Failed to create a new display mode\n");
 +  return -ENOMEM;
 +  }
 +
 +  drm_mode_probed_add(connector, mode);
 +
 +  return 2;
 +}
>>>
>>> Referencing those previous discussions:
>>> - 
>>> https://lore.kernel.org/dri-devel/0255f7c6-0484-6456-350d-cf24f3fee...@tronnes.org/
>>> - 
>>> https://lore.kernel.org/dri-devel/c8f8015a-75da-afa8-ca7f-b2b134cac...@gmail.com/
>>>
>>> Unconditionally setting the 480i mode as DRM_MODE_TYPE_PREFERRED causes Xorg
>>> (at least on current Raspberry Pi OS) to display garbage when
>>> video=Composite1:PAL is specified on the command line, so I'm afraid this 
>>> won't
>>> do.
>>>
>>> As I see it, there are three viable solutions for this issue:
>>>
>>> a) Somehow query the video= command line option from this function, and set
>>>DRM_MODE_TYPE_PREFERRED appropriately. This would break the abstraction
>>>provided by global DRM code, but should work fine.
>>>
>>> b) Modify drm_helper_probe_add_cmdline_mode() so that it sets
>>>DRM_MODE_TYPE_PREFERRED in addition to DRM_MODE_TYPE_USERDEF. This seems
>>>pretty robust, but affects the entire DRM subsystem, which may break
>>>userspace in different ways.
>>>
>>>- Maybe this could be mitigated by adding some additional conditions, 
>>> e.g.
>>>  setting the PREFERRED flag only if no modes are already flagged as such
>>>  and/or only if the cmdline mode is a named one (~= analog TV mode)
>>>
>>> c) Forcing userspace (Xorg / Raspberry Pi OS) to get fixed and honor the 
>>> USERDEF
>>>flag.
>>>
>>> Either way, hardcoding 480i as PREFERRED does not seem right.
>>>
>>
>> My solution for this is to look at tv.mode to know which mode to mark as
>> preferred. Maxime didn't like this since it changes things behind
>> userspace's back. I don't see how that can cause any problems for userspace.
>>
>> If userspace uses atomic and sets tv_mode, it has to know which mode to
>> use before hand, so it doesn't look at the preferreded flag.
>>
>> If it uses legacy and sets tv_mode, it can end up with a stale preferred
>> flag, but no worse than not having the flag or that ntsc is always
>> preferred.
>>
>> If it doesn't change tv_mode, there's no problem, the preferred flag
>> doesn't change.
>
> I don't like it because I just see no way to make this reliable. When we
> set tv_mode, we're not only going to change the preferred flag, but also
> the order of the modes to make the preferred mode first.
>
> Since we just changed the mode lists, we also want to send a hotplug
> event to userspace so that it gets notified of it. It will pick up the
> new preferred mode, great.
>
> But what if it doesn't? There's no requirement for userspace to handle
> hotplug events, and Kodi won't for example. So we just changed the TV
> mode but not the actual mode, and that's it. It's just as broken for
> Kodi as it is for X11 right now.
>
> If we can't get a bullet-proof solution, then I'm not convinced it's
> worth addressing. Especially since it's already the current state, and
> it doesn't seem to bother a lot of people.

I wouldn't rely on the "doesn't seem to bother a lot of people" bit too much.
Here's why:

- Analog TV output is a relatively obscure feature in this day and age in the
  first place.

- Out of the people interested in using it with VC4/VEC, many are actually using
  the downstream kernel from https://github.com/raspberrypi/linux instead of the
  upstream kernel, and/or firmware mode-switching instead of proper KMS.

  - The downstream kernel only reports modes that match the TV mode set at boot
either via vc4.tv_norm=, or implied by the resolution set via video=; note
that video= is also set appropriately at boot by Pi firmware, based on the
value of sdtv_mode set in config.txt. See also the
vc4_vec_connector_get_modes() and vc4_vec_get_default_mode() functions in

https://github.com/raspberrypi/linux/blob/dbd073e4028580a09b6ee507e0c137441cb52650/drivers/gpu/drm/vc4/vc4_vec.c

  - When firmware mode-switching is used, it sets the appropriate TV mode

Re: [PATCH 0/2] drm/tiny: add support tft display based on ilitek, ili9488

[Michael Nazzareno Trimarchi]

Hi

On Tue, Oct 18, 2022 at 9:06 PM Noralf Trønnes  wrote:
>
>
>
> Den 18.10.2022 18.45, skrev Tommaso Merciai:
> > Hi All,
> > This series  support for ilitek,ili9488 based displays like
> > Waveshare-ResTouch-LCD-3.5 display. Tested on Waveshare-ResTouch-LCD-3.5
> > connected to px30-evb via SPI.
>
> There's a generic MIPI DBI SPI driver now that should work with all
> these panels: drivers/gpu/drm/tiny/panel-mipi-dbi.c
>
> More info: https://github.com/notro/panel-mipi-dbi/wiki
>

We have seen it but it does not apply to the color output and there is
no helper. I was a bit surprised
to have a generic panel for spi and not for standard mipi one.

Michael

> Noralf.
>
> > This series is based on work done by Kamlesh Gurudasani in 2020:
> >
> >  - "drm/tiny: add support for tft displays based on ilitek, ili9488"
> >
> > (Thanks Kamlesh for your starting point)
> >
> > Tests are done using the following tools coming from Yocto fs:
> >
> >  - modetest -M "ili9488" -s 31:320x480@RG16 -v
> >  - fb-test
> >  - fb-rect
> >
> > References:
> >  - 
> > https://patchwork.kernel.org/project/dri-devel/patch/00719f68aca488a6476b0dda634617606b592823.1592055494.git.kamlesh.gurudas...@gmail.com/
> >  - https://www.hpinfotech.ro/ILI9488.pdf
> >  - https://www.waveshare.com/wiki/Pico-ResTouch-LCD-3.5
> >
> > Regards,
> > Tommaso
> >
> > Tommaso Merciai (2):
> >   dt-bindings: add binding for tft displays based on ilitek,ili9488
> >   drm/tiny: add support for tft displays based on ilitek,ili9488
> >
> >  .../bindings/display/ilitek,ili9488.yaml  |  72 +++
> >  drivers/gpu/drm/tiny/Kconfig  |  13 +
> >  drivers/gpu/drm/tiny/Makefile |   1 +
> >  drivers/gpu/drm/tiny/ili9488.c| 440 ++
> >  4 files changed, 526 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/display/ilitek,ili9488.yaml
> >  create mode 100644 drivers/gpu/drm/tiny/ili9488.c
> >



-- 
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__

Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com

Re: [PATCH v2] drm: Remove drm_mode_config::fb_base

[Andy Shevchenko]

On Tue, Oct 18, 2022 at 08:26:17PM +, Zack Rusin wrote:
> > On Oct 18, 2022, at 4:20 PM, Andy Shevchenko 
> >  wrote:
> > On Tue, Oct 18, 2022 at 12:11:51PM -0400, Zack Rusin wrote:
> >> From: Zack Rusin 
> >> 
> >> v2: Thomas and Laurent noticed that in radeon_fb.c I forgot to set the
> >> info->apertures->ranges[0].base and Laurent noticed a neat little cleanup
> >> in the hisilicon driver as a result of the drm_mode_config::fb_base
> >> removal.
> > 
> > You need to address LKP comment.
> 
> That came after v3, and I fixed it in the meantime. I will wait with sending
> v4 until tomorrow to make sure I give everyone time to look at in case
> there’s something else.

Hmm... Am I missing v3? I answer to v2 and LKP complaint against v1.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] drm/vc4: vec: Add support for PAL-60

[Mateusz Kwiatkowski]

Hi Maxime,

W dniu 18.10.2022 o 10:31, Maxime Ripard pisze:
> Hi,
>
> On Sun, Oct 16, 2022 at 09:46:49PM +0200, Mateusz Kwiatkowski wrote:
>> @@ -308,14 +324,15 @@ static const struct vc4_vec_tv_mode vc4_vec_tv_modes[] 
>> = {
>>  };
>>  
>>  static inline const struct vc4_vec_tv_mode *
>> -vc4_vec_tv_mode_lookup(unsigned int mode)
>> +vc4_vec_tv_mode_lookup(unsigned int mode, u16 htotal)
>>  {
>>  unsigned int i;
>>  
>>  for (i = 0; i < ARRAY_SIZE(vc4_vec_tv_modes); i++) {
>>  const struct vc4_vec_tv_mode *tv_mode = &vc4_vec_tv_modes[i];
>>  
>> -if (tv_mode->mode == mode)
>> +if (tv_mode->mode == mode &&
>> +tv_mode->expected_htotal == htotal)
>>  return tv_mode;
>
> Is there any reason we're not using the refresh rate to filter this? It
> seems more natural to me.

Let me give you an example first.

There are actually two ways to configure PAL-60-ish mode on VC4/VEC:

a) Modeline 13.5 720 734 798 858 480 487 493 525 Interlace, standard registers
   set to VEC_CONFIG0_PAL_M_STD, custom frequency enabled and set to 0x2a098acb;
   Setting the standard registers to "PAL-M" puts the VEC in true 59.94 Hz mode,
   so the video timings are identical as for NTSC (or PAL-M), and the custom
   frequency makes the color subcarrier compatible with regular PAL receivers.
   This is the "true" PAL-60, thanks to the true System M timings.

a) Modeline 13.5 720 740 804 864 480 486 492 525 Interlace, standards registers
   set to VEC_CONFIG0_PAL with standard frequency; This is a "fake" PAL-60 mode,
   the refresh rate is actually ~59.524 Hz. Most "NTSC" sets will be able to
   sync with this mode no problem, but the VEC is actually operating in its
   50 Hz mode - it's just the "premature" vertical sync signal causes it to
   output something that is similar to the 525-line system, however strictly
   speaking non-standard due to lower horizontal sync frequency.

This comes down to the fact that:

- When VEC's standard registers are set to VEC_CONFIG0_NTSC_STD or
  VEC_CONFIG0_PAL_M_STD, it operates in the "CCIR System M" mode, expects htotal
  to be exactly 858 pixels (and it will generate horizontal sync pulse every 858
  pixels on its own regardless of what comes out of the PV - so there will be
  garbage on screen if you set it to anything else), and vtotal to be 525 lines.
  It will not accept vtotal that's any higher (it will generate its own vertical
  sync as demanded by System M if not triggered by the PV), but it can be lower
  - resulting in modes that are non-standard, but otherwise valid.

- Likewise, when the registers are set to VEC_CONFIG0_PAL_BDGHI_STD,
  VEC_CONFIG0_PAL_N_STD or VEC_CONFIG0_SECAM_STD (SECAM is a bit special, but
  that's irrelevant here), it operates in the "CCIR System B/D/G/H/I/N" mode,
  and likewise, expects htotal to be exactly 864 pixels (garbage on screen
  otherwise), vtotal limit is 625 lines, etc.

Checking for the refresh rate would only work for standard-compliant modes and
have the potential of completely breaking on any custom modes. Conversely,
checking for htotal aligns perfectly with the limitations of the hardware, and
allows the user to set any modeline that the hardware is able to output with
any level of sanity.

Footnote: all this information on VEC's behavior comes from my own
experimentation, messing around with its registers and seeing what happens
(both on screen and on an oscilloscope). I've never seen any Broadcom docs on
this chip, so it's by no means official.

Best regards,
Mateusz Kwiatkowski

Re: [PATCH v2] drm: Remove drm_mode_config::fb_base

[Zack Rusin]

> On Oct 18, 2022, at 4:20 PM, Andy Shevchenko 
>  wrote:
> 
> ⚠ External Email
> 
> On Tue, Oct 18, 2022 at 12:11:51PM -0400, Zack Rusin wrote:
>> From: Zack Rusin 
>> 
>> v2: Thomas and Laurent noticed that in radeon_fb.c I forgot to set the
>> info->apertures->ranges[0].base and Laurent noticed a neat little cleanup
>> in the hisilicon driver as a result of the drm_mode_config::fb_base
>> removal.
> 
> You need to address LKP comment.

That came after v3, and I fixed it in the meantime. I will wait with sending v4 
until tomorrow to make sure I give everyone time to look at in case there’s 
something else.

z

Re: [PATCH v2 3/7] drm/i915/uc: use different ggtt pin offsets for uc loads

[Ceraolo Spurio, Daniele]

On 10/17/2022 4:44 PM, John Harrison wrote:

On 10/12/2022 17:03, Daniele Ceraolo Spurio wrote:

Our current FW loading process is the same for all FWs:

- Pin FW to GGTT at the start of the ggtt->uc_fw node
- Load the FW
- Unpin

This worked because we didn't have a case where 2 FWs would be loaded on
the same GGTT at the same time. On MTL, however, this can happend if 
both

GTs are reset at the same time, so we can't pin everything in the same
spot and we need to use separate offset. For simplicity, instead of
calculating the exact required size, we reserve a 2MB slot for each fw.

v2: fail fetch if FW is > 2MBs, improve comments (John)

Signed-off-by: Daniele Ceraolo Spurio 
Cc: John Harrison 
Cc: Alan Previn 
---
  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 30 +---
  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 13 ++
  2 files changed, 40 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c

index de2843dc1307..021290a26195 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -575,6 +575,17 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
  err = firmware_request_nowarn(&fw, uc_fw->file_selected.path, 
dev);

  memcpy(&file_ideal, &uc_fw->file_wanted, sizeof(file_ideal));
  +    if (!err && fw->size > INTEL_UC_RSVD_GGTT_PER_FW) {
+    drm_err(&i915->drm,
+    "%s firmware %s: size (%zuKB) exceeds max supported size 
(%uKB)\n",
+    intel_uc_fw_type_repr(uc_fw->type), 
uc_fw->file_selected.path,

+    fw->size / SZ_1K, INTEL_UC_RSVD_GGTT_PER_FW / SZ_1K);
+
+    /* try to find another blob to load */
+    release_firmware(fw);
+    err = -ENOENT;
+    }
+
  /* Any error is terminal if overriding. Don't bother searching 
for older versions */

  if (err && intel_uc_fw_is_overridden(uc_fw))
  goto fail;
@@ -677,14 +688,28 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
    static u32 uc_fw_ggtt_offset(struct intel_uc_fw *uc_fw)
  {
-    struct i915_ggtt *ggtt = __uc_fw_to_gt(uc_fw)->ggtt;
+    struct intel_gt *gt = __uc_fw_to_gt(uc_fw);
+    struct i915_ggtt *ggtt = gt->ggtt;
  struct drm_mm_node *node = &ggtt->uc_fw;
+    u32 offset = uc_fw->type * INTEL_UC_RSVD_GGTT_PER_FW;
+
+    /*
+ * To keep the math simple, we use 8MB for the root tile and 8MB 
for

+ * the media one. This will need to be updated if we ever have more
+ * than 1 media GT
+ */
+    BUILD_BUG_ON(INTEL_UC_FW_NUM_TYPES * INTEL_UC_RSVD_GGTT_PER_FW > 
SZ_8M);

+    GEM_BUG_ON(gt->type == GT_MEDIA && gt->info.id > 1);
+    if (gt->type == GT_MEDIA)
+    offset += SZ_8M;
This is all because render/media GTs share the same page tables? 
Regular multi-tile is completely separate address spaces and can use a 
single common address? Otherwise, it seems like 'offset = gt->info.id 
* 2M' would be the generic solution and no reference to GT_MEDIA 
required. So maybe add a quick comment to that effect?


Yup this is only because of the GGTT sharing. There is already a comment 
somewhere else, but I'll add one here as well.






GEM_BUG_ON(!drm_mm_node_allocated(node));
  GEM_BUG_ON(upper_32_bits(node->start));
  GEM_BUG_ON(upper_32_bits(node->start + node->size - 1));
+    GEM_BUG_ON(offset + uc_fw->obj->base.size > node->size);
+    GEM_BUG_ON(uc_fw->obj->base.size > INTEL_UC_RSVD_GGTT_PER_FW);
  -    return lower_32_bits(node->start);
+    return lower_32_bits(node->start + offset);
  }
    static void uc_fw_bind_ggtt(struct intel_uc_fw *uc_fw)
@@ -699,7 +724,6 @@ static void uc_fw_bind_ggtt(struct intel_uc_fw 
*uc_fw)

  dummy->bi.pages = obj->mm.pages;
    GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
-    GEM_BUG_ON(dummy->node_size > ggtt->uc_fw.size);
    /* uc_fw->obj cache domains were not controlled across 
suspend */

  if (i915_gem_object_has_struct_page(obj))
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h

index cb586f7df270..7b3db41efa6e 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
@@ -6,6 +6,7 @@
  #ifndef _INTEL_UC_FW_H_
  #define _INTEL_UC_FW_H_
  +#include 
  #include 
  #include "intel_uc_fw_abi.h"
  #include "intel_device_info.h"
@@ -114,6 +115,18 @@ struct intel_uc_fw {
(uc)->fw.file_selected.minor_ver, \
(uc)->fw.file_selected.patch_ver))
  +/*
+ * When we load the uC binaries, we pin them in a reserved section 
at the top of
+ * the GGTT, which is ~18 MBs. On multi-GT systems where the GTs 
share the GGTT,
^^^ meaning only systems with a render GT + media GT as opposed to 
regular multi-GT systems? Would be good to make that explicit either 
here or above (or both).


I'll add a comment above where we reference the media gt.

Daniele



John.

+ * we also need to make sure that each binary is pinned to a unique 
location
+ * during load, becau

Re: [PATCH v2] drm: Remove drm_mode_config::fb_base

[Andy Shevchenko]

On Tue, Oct 18, 2022 at 12:11:51PM -0400, Zack Rusin wrote:
> From: Zack Rusin 
> 
> v2: Thomas and Laurent noticed that in radeon_fb.c I forgot to set the
> info->apertures->ranges[0].base and Laurent noticed a neat little cleanup
> in the hisilicon driver as a result of the drm_mode_config::fb_base
> removal.

You need to address LKP comment.

> The fb_base in struct drm_mode_config has been unused for a long time.

> Some drivers set it and some don't leading to a very confusing state
> where the variable can't be relied upon, because there's no indication
> as to which driver sets it and which doesn't.
> 
> The only usage of fb_base is internal to two drivers so instead of trying
> to force it into all the drivers to get it into a coherent state
> completely remove it.

...

> --- a/drivers/gpu/drm/ast/ast_mode.c
> +++ b/drivers/gpu/drm/ast/ast_mode.c
> @@ -1778,7 +1778,6 @@ int ast_mode_config_init(struct ast_private *ast)
>   dev->mode_config.min_width = 0;
>   dev->mode_config.min_height = 0;
>   dev->mode_config.preferred_depth = 24;
> - dev->mode_config.fb_base = pci_resource_start(pdev, 0);

Unused pdev.

>   if (ast->chip == AST2100 ||
>   ast->chip == AST2200 ||

I suggest to compile with `make W=1 C=1` on your side before sending v3 and
address all compiler complaints.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v4 15/17] drm/i915/vm_bind: Handle persistent vmas in execbuf3

[Niranjana Vishwanathapura]

On Tue, Oct 18, 2022 at 07:01:57PM +0100, Matthew Auld wrote:

On 18/10/2022 08:16, Niranjana Vishwanathapura wrote:

Handle persistent (VM_BIND) mappings during the request submission
in the execbuf3 path.

v2: Ensure requests wait for bindings to complete.
v3: Remove short term pinning with PIN_VALIDATE flag.
Individualize fences before adding to dma_resv obj.

Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Andi Shyti 
---
 .../gpu/drm/i915/gem/i915_gem_execbuffer3.c   | 208 +-
 1 file changed, 207 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
index a9b4cc44bf66..8120e4c6b7da 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
@@ -3,6 +3,7 @@
  * Copyright © 2022 Intel Corporation
  */
+#include 
 #include 
 #include 
@@ -19,6 +20,7 @@
 #include "i915_gem_vm_bind.h"
 #include "i915_trace.h"
+#define __EXEC3_HAS_PINBIT_ULL(33)
 #define __EXEC3_ENGINE_PINNED  BIT_ULL(32)
 #define __EXEC3_INTERNAL_FLAGS (~0ull << 32)
@@ -42,7 +44,9 @@
  * execlist. Hence, no support for implicit sync.
  *
  * The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only
- * works with execbuf3 ioctl for submission.
+ * works with execbuf3 ioctl for submission. All BOs mapped on that VM (through
+ * VM_BIND call) at the time of execbuf3 call are deemed required for that
+ * submission.
  *
  * The execbuf3 ioctl directly specifies the batch addresses instead of as
  * object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not
@@ -58,6 +62,13 @@
  * So, a lot of code supporting execbuf2 ioctl, like relocations, VA evictions,
  * vma lookup table, implicit sync, vma active reference tracking etc., are not
  * applicable for execbuf3 ioctl.
+ *
+ * During each execbuf submission, request fence is added to all VM_BIND mapped
+ * objects with DMA_RESV_USAGE_BOOKKEEP. The DMA_RESV_USAGE_BOOKKEEP usage will
+ * prevent over sync (See enum dma_resv_usage). Note that DRM_I915_GEM_WAIT and
+ * DRM_I915_GEM_BUSY ioctls do not check for DMA_RESV_USAGE_BOOKKEEP usage and
+ * hence should not be used for end of batch check. Instead, the execbuf3
+ * timeline out fence should be used for end of batch check.
  */
 /**
@@ -127,6 +138,23 @@ eb_find_vma(struct i915_address_space *vm, u64 addr)
return i915_gem_vm_bind_lookup_vma(vm, va);
 }
+static void eb_scoop_unbound_vma_all(struct i915_address_space *vm)
+{
+   struct i915_vma *vma, *vn;
+
+   /**
+* Move all unbound vmas back into vm_bind_list so that they are
+* revalidated.
+*/
+   spin_lock(&vm->vm_rebind_lock);
+   list_for_each_entry_safe(vma, vn, &vm->vm_rebind_list, vm_rebind_link) {
+   list_del_init(&vma->vm_rebind_link);
+   if (!list_empty(&vma->vm_bind_link))
+   list_move_tail(&vma->vm_bind_link, &vm->vm_bind_list);
+   }
+   spin_unlock(&vm->vm_rebind_lock);
+}
+
 static int eb_lookup_vma_all(struct i915_execbuffer *eb)
 {
unsigned int i, current_batch = 0;
@@ -141,14 +169,108 @@ static int eb_lookup_vma_all(struct i915_execbuffer *eb)
++current_batch;
}
+   eb_scoop_unbound_vma_all(eb->context->vm);
+
+   return 0;
+}
+
+static int eb_lock_vma_all(struct i915_execbuffer *eb)
+{
+   struct i915_address_space *vm = eb->context->vm;
+   struct i915_vma *vma;
+   int err;
+
+   err = i915_gem_object_lock(eb->context->vm->root_obj, &eb->ww);
+   if (err)
+   return err;
+
+   list_for_each_entry(vma, &vm->non_priv_vm_bind_list,
+   non_priv_vm_bind_link) {
+   err = i915_gem_object_lock(vma->obj, &eb->ww);
+   if (err)
+   return err;
+   }
+
return 0;
 }
+static void eb_release_persistent_vma_all(struct i915_execbuffer *eb)
+{
+   struct i915_address_space *vm = eb->context->vm;
+   struct i915_vma *vma, *vn;
+
+   lockdep_assert_held(&vm->vm_bind_lock);
+
+   if (!(eb->args->flags & __EXEC3_HAS_PIN))
+   return;
+
+   assert_object_held(vm->root_obj);
+
+   list_for_each_entry_safe(vma, vn, &vm->vm_bind_list, vm_bind_link)
+   if (i915_vma_verify_bind_complete(vma))
+   list_move_tail(&vma->vm_bind_link, &vm->vm_bound_list);
+
+   eb->args->flags &= ~__EXEC3_HAS_PIN;
+}
+
 static void eb_release_vma_all(struct i915_execbuffer *eb)
 {
+   eb_release_persistent_vma_all(eb);
eb_unpin_engine(eb);
 }
+static int eb_reserve_fence_for_persistent_vma_all(struct i915_execbuffer *eb)
+{
+   struct i915_address_space *vm = eb->context->vm;
+   u64 num_fences = 1;
+   struct i915_vma *vma;
+   int ret;
+
+   /* Reserve enough slots to accommodate composite fences */
+   if (intel_co

Re: [PATCH 0/2] drm/tiny: add support tft display based on ilitek,ili9488

[Noralf Trønnes]

Den 18.10.2022 18.45, skrev Tommaso Merciai:
> Hi All,
> This series  support for ilitek,ili9488 based displays like
> Waveshare-ResTouch-LCD-3.5 display. Tested on Waveshare-ResTouch-LCD-3.5
> connected to px30-evb via SPI.

There's a generic MIPI DBI SPI driver now that should work with all
these panels: drivers/gpu/drm/tiny/panel-mipi-dbi.c

More info: https://github.com/notro/panel-mipi-dbi/wiki

Noralf.

> This series is based on work done by Kamlesh Gurudasani in 2020:
> 
>  - "drm/tiny: add support for tft displays based on ilitek, ili9488"
> 
> (Thanks Kamlesh for your starting point)
> 
> Tests are done using the following tools coming from Yocto fs:
> 
>  - modetest -M "ili9488" -s 31:320x480@RG16 -v
>  - fb-test
>  - fb-rect
> 
> References:
>  - 
> https://patchwork.kernel.org/project/dri-devel/patch/00719f68aca488a6476b0dda634617606b592823.1592055494.git.kamlesh.gurudas...@gmail.com/
>  - https://www.hpinfotech.ro/ILI9488.pdf
>  - https://www.waveshare.com/wiki/Pico-ResTouch-LCD-3.5
> 
> Regards,
> Tommaso
> 
> Tommaso Merciai (2):
>   dt-bindings: add binding for tft displays based on ilitek,ili9488
>   drm/tiny: add support for tft displays based on ilitek,ili9488
> 
>  .../bindings/display/ilitek,ili9488.yaml  |  72 +++
>  drivers/gpu/drm/tiny/Kconfig  |  13 +
>  drivers/gpu/drm/tiny/Makefile |   1 +
>  drivers/gpu/drm/tiny/ili9488.c| 440 ++
>  4 files changed, 526 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/ilitek,ili9488.yaml
>  create mode 100644 drivers/gpu/drm/tiny/ili9488.c
> 

Re: [PATCH] drm/edid: Parse VRR cap fields from HFVSDB block

[Navare, Manasi]

On Tue, Oct 18, 2022 at 11:01:48AM +0530, Ankit Nautiyal wrote:
> This patch parses HFVSDB fields for VRR capabilities of an
> HDMI2.1 sink and stores the VRR caps in a new structure in
> drm_hdmi_info.
> 
> Signed-off-by: Ankit Nautiyal 

Makes sense to add this VRR info to drm_hdmi_info struct and not combine
with DP VRR info struct in display info since hdmi info has other HDMI
cap info stored here.

Reviewed-by: Manasi Navare 

Manasi

> ---
>  drivers/gpu/drm/drm_edid.c  | 26 --
>  include/drm/drm_connector.h | 27 +++
>  2 files changed, 51 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 47465b9765f1..bb1f7d899580 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -5823,6 +5823,21 @@ static void drm_parse_ycbcr420_deep_color_info(struct 
> drm_connector *connector,
>   hdmi->y420_dc_modes = dc_mask;
>  }
>  
> +static void drm_parse_vrr_info(struct drm_hdmi_vrr_cap *hdmi_vrr,
> +const u8 *hf_scds)
> +{
> + if (hf_scds[8] & DRM_EDID_CNMVRR)
> + hdmi_vrr->cnm_vrr = true;
> + if (hf_scds[8] & DRM_EDID_CINEMA_VRR)
> + hdmi_vrr->cinema_vrr = true;
> + if (hf_scds[8] & DRM_EDID_MDELTA)
> + hdmi_vrr->m_delta = true;
> +
> + hdmi_vrr->vrr_min = hf_scds[9] & DRM_EDID_VRR_MIN_MASK;
> + hdmi_vrr->vrr_max = (hf_scds[9] & DRM_EDID_VRR_MAX_UPPER_MASK) << 2;
> + hdmi_vrr->vrr_max |= hf_scds[10] & DRM_EDID_VRR_MAX_LOWER_MASK;
> +}
> +
>  static void drm_parse_dsc_info(struct drm_hdmi_dsc_cap *hdmi_dsc,
>  const u8 *hf_scds)
>  {
> @@ -5901,9 +5916,11 @@ static void drm_parse_hdmi_forum_scds(struct 
> drm_connector *connector,
>   struct drm_display_info *display = &connector->display_info;
>   struct drm_hdmi_info *hdmi = &display->hdmi;
>   struct drm_hdmi_dsc_cap *hdmi_dsc = &hdmi->dsc_cap;
> + struct drm_hdmi_vrr_cap *hdmi_vrr = &hdmi->vrr_cap;
>   int max_tmds_clock = 0;
>   u8 max_frl_rate = 0;
>   bool dsc_support = false;
> + bool vrr_support = false;
>  
>   display->has_hdmi_infoframe = true;
>  
> @@ -5949,14 +5966,19 @@ static void drm_parse_hdmi_forum_scds(struct 
> drm_connector *connector,
>  
>   drm_parse_ycbcr420_deep_color_info(connector, hf_scds);
>  
> + if (cea_db_payload_len(hf_scds) >= 8 && hf_scds[8]) {
> + drm_parse_vrr_info(hdmi_vrr, hf_scds);
> + vrr_support = true;
> + }
> +
>   if (cea_db_payload_len(hf_scds) >= 11 && hf_scds[11]) {
>   drm_parse_dsc_info(hdmi_dsc, hf_scds);
>   dsc_support = true;
>   }
>  
>   drm_dbg_kms(connector->dev,
> - "HF-VSDB: max TMDS clock: %d KHz, HDMI 2.1 support: %s, DSC 
> 1.2 support: %s\n",
> - max_tmds_clock, str_yes_no(max_frl_rate), 
> str_yes_no(dsc_support));
> + "HF-VSDB: max TMDS clock: %d KHz, HDMI 2.1 support: %s, VRR 
> support: %s, DSC 1.2 support: %s\n",
> + max_tmds_clock, str_yes_no(max_frl_rate), 
> str_yes_no(vrr_support), str_yes_no(dsc_support));
>  }
>  
>  static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index b1b2df48d42c..ec6ef71ab5cd 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -219,6 +219,30 @@ struct drm_hdmi_dsc_cap {
>   u8 total_chunk_kbytes;
>  };
>  
> +
> +/**
> + * struct drm_hdmi_vrr_cap - VRR capabilities of HDMI sink
> + * Describes the VRR support provided by HDMI 2.1 sink.
> + * The information is fetched fom additional HFVSDB blocks defined
> + * for HDMI 2.1.
> + */
> +struct drm_hdmi_vrr_cap {
> + /** @cnm_vrr: sink supports negative Mvrr values*/
> + bool cnm_vrr;
> +
> + /** @cinema_vrr: sink supports fractional and integer media rates < 
> VRRmin*/
> + bool cinema_vrr;
> +
> + /** @m_delta: sink can anticipate and compensate for frame-to-frame 
> variation in Mvrr */
> + bool m_delta;
> +
> + /** @vrr_min: VRRmin - lowest framerate in Hz that sink can support in 
> VRR */
> + u8 vrr_min;
> +
> + /** @vrr_max: VRRmax - highest framerate in Hz that sink can support in 
> VRR */
> + u16 vrr_max;
> +};
> +
>  /**
>   * struct drm_hdmi_info - runtime information about the connected HDMI sink
>   *
> @@ -259,6 +283,9 @@ struct drm_hdmi_info {
>  
>   /** @dsc_cap: DSC capabilities of the sink */
>   struct drm_hdmi_dsc_cap dsc_cap;
> +
> + /** @vrr_cap: VRR capabilities of the sink */
> + struct drm_hdmi_vrr_cap vrr_cap;
>  };
>  
>  /**
> -- 
> 2.25.1
> 

[PATCH v3] drm/i915/slpc: Use platform limits for min/max frequency

[Vinay Belgaumkar]

GuC will set the min/max frequencies to theoretical max on
ATS-M. This will break kernel ABI, so limit min/max frequency
to RP0(platform max) instead.

Also modify the SLPC selftest to update the min frequency
when we have a server part so that we can iterate between
platform min and max.

v2: Check softlimits instead of platform limits (Riana)
v3: More review comments (Ashutosh)

Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/7030

Acked-by: Nirmoy Das 
Reviewed-by: Riana Tauro 
Signed-off-by: Vinay Belgaumkar 
---
 drivers/gpu/drm/i915/gt/selftest_slpc.c   | 40 +--
 drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c   | 30 ++
 drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h   |  2 +
 .../gpu/drm/i915/gt/uc/intel_guc_slpc_types.h |  3 ++
 4 files changed, 63 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_slpc.c 
b/drivers/gpu/drm/i915/gt/selftest_slpc.c
index 4c6e9257e593..e42bc215e54d 100644
--- a/drivers/gpu/drm/i915/gt/selftest_slpc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_slpc.c
@@ -234,6 +234,7 @@ static int run_test(struct intel_gt *gt, int test_type)
enum intel_engine_id id;
struct igt_spinner spin;
u32 slpc_min_freq, slpc_max_freq;
+   u32 saved_min_freq;
int err = 0;
 
if (!intel_uc_uses_guc_slpc(>->uc))
@@ -252,20 +253,35 @@ static int run_test(struct intel_gt *gt, int test_type)
return -EIO;
}
 
-   /*
-* FIXME: With efficient frequency enabled, GuC can request
-* frequencies higher than the SLPC max. While this is fixed
-* in GuC, we level set these tests with RPn as min.
-*/
-   err = slpc_set_min_freq(slpc, slpc->min_freq);
-   if (err)
-   return err;
+   if (slpc_min_freq == slpc_max_freq) {
+   /* Server parts will have min/max clamped to RP0 */
+   if (slpc->min_is_rpmax) {
+   err = slpc_set_min_freq(slpc, slpc->min_freq);
+   if (err) {
+   pr_err("Unable to update min freq on server 
part");
+   return err;
+   }
 
-   if (slpc->min_freq == slpc->rp0_freq) {
-   pr_err("Min/Max are fused to the same value\n");
-   return -EINVAL;
+   } else {
+   pr_err("Min/Max are fused to the same value\n");
+   return -EINVAL;
+   }
+   } else {
+   /*
+* FIXME: With efficient frequency enabled, GuC can request
+* frequencies higher than the SLPC max. While this is fixed
+* in GuC, we level set these tests with RPn as min.
+*/
+   err = slpc_set_min_freq(slpc, slpc->min_freq);
+   if (err)
+   return err;
}
 
+   saved_min_freq = slpc_min_freq;
+
+   /* New temp min freq = RPn */
+   slpc_min_freq = slpc->min_freq;
+
intel_gt_pm_wait_for_idle(gt);
intel_gt_pm_get(gt);
for_each_engine(engine, gt, id) {
@@ -347,7 +363,7 @@ static int run_test(struct intel_gt *gt, int test_type)
 
/* Restore min/max frequencies */
slpc_set_max_freq(slpc, slpc_max_freq);
-   slpc_set_min_freq(slpc, slpc_min_freq);
+   slpc_set_min_freq(slpc, saved_min_freq);
 
if (igt_flush_test(gt->i915))
err = -EIO;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
index fdd895f73f9f..b7cdeec44bd3 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
@@ -263,6 +263,7 @@ int intel_guc_slpc_init(struct intel_guc_slpc *slpc)
 
slpc->max_freq_softlimit = 0;
slpc->min_freq_softlimit = 0;
+   slpc->min_is_rpmax = false;
 
slpc->boost_freq = 0;
atomic_set(&slpc->num_waiters, 0);
@@ -588,6 +589,32 @@ static int slpc_set_softlimits(struct intel_guc_slpc *slpc)
return 0;
 }
 
+static bool is_slpc_min_freq_rpmax(struct intel_guc_slpc *slpc)
+{
+   int slpc_min_freq;
+
+   if (intel_guc_slpc_get_min_freq(slpc, &slpc_min_freq))
+   return false;
+
+   if (slpc_min_freq == SLPC_MAX_FREQ_MHZ)
+   return true;
+   else
+   return false;
+}
+
+static void update_server_min_softlimit(struct intel_guc_slpc *slpc)
+{
+   /* For server parts, SLPC min will be at RPMax.
+* Use min softlimit to clamp it to RP0 instead.
+*/
+   if (is_slpc_min_freq_rpmax(slpc) &&
+   !slpc->min_freq_softlimit) {
+   slpc->min_is_rpmax = true;
+   slpc->min_freq_softlimit = slpc->rp0_freq;
+   (slpc_to_gt(slpc))->defaults.min_freq = 
slpc->min_freq_softlimit;
+   }
+}
+
 static int slpc_use_fused_rp0(struct intel_guc_slpc *slpc)
 {
/* Force SLPC to used platform rp0 */
@@ 

[PATCH v3] drm: Remove drm_mode_config::fb_base

[Zack Rusin]

From: Zack Rusin 

v3: Fix a silly pci_resource_len mistake spotted by Laurent

The fb_base in struct drm_mode_config has been unused for a long time.
Some drivers set it and some don't leading to a very confusing state
where the variable can't be relied upon, because there's no indication
as to which driver sets it and which doesn't.

The only usage of fb_base is internal to two drivers so instead of trying
to force it into all the drivers to get it into a coherent state
completely remove it.

Signed-off-by: Zack Rusin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c |  2 --
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c   |  2 --
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c   |  2 --
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c|  1 -
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c|  2 --
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c|  2 --
 drivers/gpu/drm/ast/ast_mode.c   |  1 -
 drivers/gpu/drm/gma500/framebuffer.c |  6 +++---
 drivers/gpu/drm/gma500/psb_drv.h |  1 +
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c  | 16 +++-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h  |  3 ---
 drivers/gpu/drm/mgag200/mgag200_mode.c   |  1 -
 drivers/gpu/drm/msm/msm_fbdev.c  |  2 --
 drivers/gpu/drm/nouveau/nouveau_display.c|  1 -
 drivers/gpu/drm/nouveau/nv04_fbcon.c |  6 --
 drivers/gpu/drm/omapdrm/omap_fbdev.c |  2 --
 drivers/gpu/drm/qxl/qxl_display.c|  2 --
 drivers/gpu/drm/radeon/radeon_display.c  |  2 --
 drivers/gpu/drm/radeon/radeon_fb.c   |  2 +-
 drivers/gpu/drm/tegra/fb.c   |  1 -
 drivers/gpu/drm/tiny/bochs.c |  1 -
 include/drm/drm_mode_config.h|  2 --
 22 files changed, 12 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
index f4b5301ea2a0..09dec2561adf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
@@ -498,8 +498,6 @@ static int amdgpu_vkms_sw_init(void *handle)
adev_to_drm(adev)->mode_config.preferred_depth = 24;
adev_to_drm(adev)->mode_config.prefer_shadow = 1;
 
-   adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
-
r = amdgpu_display_modeset_create_props(adev);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index 288fce7dc0ed..05051d5d2ec3 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -2800,8 +2800,6 @@ static int dce_v10_0_sw_init(void *handle)
 
adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
 
-   adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
-
r = amdgpu_display_modeset_create_props(adev);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index cbe5250b31cb..c928bc9eb202 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -2918,8 +2918,6 @@ static int dce_v11_0_sw_init(void *handle)
 
adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
 
-   adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
-
r = amdgpu_display_modeset_create_props(adev);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
index b1c44fab074f..62315fd5a05f 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
@@ -2675,7 +2675,6 @@ static int dce_v6_0_sw_init(void *handle)
adev_to_drm(adev)->mode_config.preferred_depth = 24;
adev_to_drm(adev)->mode_config.prefer_shadow = 1;
adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
-   adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
 
r = amdgpu_display_modeset_create_props(adev);
if (r)
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index a22b45c92792..87d5e4c21cb3 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -2701,8 +2701,6 @@ static int dce_v8_0_sw_init(void *handle)
 
adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
 
-   adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
-
r = amdgpu_display_modeset_create_props(adev);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index c053cb79cd06..0db2a88cd4d7 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -3816,8 +3816,6 @@ static int amdgpu_dm_mode_c

Re: [PATCH 2/2] drm/tiny: add support for tft displays based on ilitek, ili9488

[Michael Nazzareno Trimarchi]

Hi

On Tue, Oct 18, 2022 at 6:46 PM Tommaso Merciai
 wrote:
>
> This adds support for ilitek,ili9488 based displays with shift register
> in front of controller. Waveshare,pico-restouch-lcd-3.5 are such displays
>
> Signed-off-by: Tommaso Merciai 
> ---

Because I start to make it working this driver, I think that my
signed-off is missing here

>  drivers/gpu/drm/tiny/Kconfig   |  13 +
>  drivers/gpu/drm/tiny/Makefile  |   1 +
>  drivers/gpu/drm/tiny/ili9488.c | 440 +
>  3 files changed, 454 insertions(+)
>  create mode 100644 drivers/gpu/drm/tiny/ili9488.c
>
> diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
> index 027cd87c3d0d7..6e708e8414806 100644
> --- a/drivers/gpu/drm/tiny/Kconfig
> +++ b/drivers/gpu/drm/tiny/Kconfig
> @@ -148,6 +148,19 @@ config TINYDRM_ILI9486
>
>   If M is selected the module will be called ili9486.
>
> +config TINYDRM_ILI9488
> +   tristate "DRM support for ILI9488 display panels"
> +   depends on DRM && SPI
> +   select DRM_KMS_HELPER
> +   select DRM_GEM_CMA_HELPER
> +   select DRM_MIPI_DBI
> +   select BACKLIGHT_CLASS_DEVICE
> +   help
> + DRM driver for the following Ilitek ILI9488 panels:
> + * LCD 3.5" 320x480 TFT (Waveshare Pico-ResTouch-LCD-3.5")
> +
> + If M is selected the module will be called ili9486.
> +
>  config TINYDRM_MI0283QT
> tristate "DRM support for MI0283QT"
> depends on DRM && SPI
> diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
> index 1d9d6227e7ab7..aad6683b2ac40 100644
> --- a/drivers/gpu/drm/tiny/Makefile
> +++ b/drivers/gpu/drm/tiny/Makefile
> @@ -11,6 +11,7 @@ obj-$(CONFIG_TINYDRM_ILI9163) += ili9163.o
>  obj-$(CONFIG_TINYDRM_ILI9225)  += ili9225.o
>  obj-$(CONFIG_TINYDRM_ILI9341)  += ili9341.o
>  obj-$(CONFIG_TINYDRM_ILI9486)  += ili9486.o
> +obj-$(CONFIG_TINYDRM_ILI9488)  += ili9488.o
>  obj-$(CONFIG_TINYDRM_MI0283QT) += mi0283qt.o
>  obj-$(CONFIG_TINYDRM_REPAPER)  += repaper.o
>  obj-$(CONFIG_TINYDRM_ST7586)   += st7586.o
> diff --git a/drivers/gpu/drm/tiny/ili9488.c b/drivers/gpu/drm/tiny/ili9488.c
> new file mode 100644
> index 0..b94d9d4ff4544
> --- /dev/null
> +++ b/drivers/gpu/drm/tiny/ili9488.c
> @@ -0,0 +1,440 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * DRM driver for Ilitek ILI9488 panels
> + *
> + * Copyright 2020 Kamlesh Gurudasani 
> + */

Code was changed a bit so please add copyright of me and you

> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define ILI9488_VCOM_CONTROL_1 0xC5
> +#define ILI9488_COLUMN_ADDRESS_SET 0x2A
> +#define ILI9488_PAGE_ADDRESS_SET   0x2B
> +#define ILI9488_MEMORY_WRITE   0x2C
> +#define ILI9488_POSITIVE_GAMMA_CORRECTION  0xE0
> +#define ILI9488_NEGATIVE_GAMMA_CORRECTION  0xE1
> +#define ILI9488_POWER_CONTROL_10xC0
> +#define ILI9488_POWER_CONTROL_20xC1
> +#define ILI9488_POWER_CONTROL_30xC2
> +#define ILI9488_MEM_ACCESS_CONTROL 0x36
> +#define ILI9488_COLMOD_PIXEL_FORMAT_SET0x3A
> +#define ILI9488_INTERFACE_MODE_CONTROL 0xB0
> +#define ILI9488_FRAME_RATE_CONTROL_PARTIAL 0xB3
> +#define ILI9488_DISPLAY_INVERSION_ON   0x21
> +#define ILI9488_DISPLAY_INVERSION_CONTROL  0xB4
> +#define ILI9488_DISPLAY_FUNCTION_CONTROL   0xB6
> +#define ILI9488_ENTRY_MODE_SET 0xB7
> +#define ILI9488_HS_LANES_CONTROL   0xBE
> +#define ILI9488_SET_IMAGE_FUNCTION 0xE9
> +#define ILI9488_ADJUST_CONTROL_3   0xF7
> +#define ILI9488_DISPLAY_ON 0x29
> +#define ILI9488_DISPLAY_OFF0x28
> +#define ILI9488_ENTER_SLEEP_MODE   0x10
> +#define ILI9488_DBI_BPP18  0x06
> +#define ILI9488_DBI_BPP16  0x05
> +#define ILI9488_DPI_BPP24  0x70
> +#define ILI9488_DPI_BPP18  0x60
> +#define ILI9488_DPI_BPP16  0x50
> +#define ILI9488_FRAME_RATE_CONTROL_NORMAL  0xB1
> +#define ILI9488_SLEEP_OUT  0x11
> +
> +#define ILI9488_MADCTL_RGB BIT(2)
> +#define ILI9488_MADCTL_BGR BIT(3)
> +#define ILI9488_MADCTL_MV  BIT(5)
> +#define ILI9488_MADCTL_MX  BIT(6)
> +#define ILI9488_MADCTL_MY  BIT(7)
> +
> +static void ili9488_rgb565_to_rgb666_line(u8 *dst, u16 *sbuf,
> + unsigned int pixels)
> +{
> +   unsigned int x;
> +
> +   for (x = 0; x < pixels; x++) {
> +   *dst++ = ((*sbuf & 0xF800) >> 8);
> +   *dst++ = 

Re: [PATCH 1/2] dt-bindings: add binding for tft displays based on ilitek,ili9488

[Krzysztof Kozlowski]

On 18/10/2022 12:45, Tommaso Merciai wrote:
> This binding is for the tft displays based on ilitek,ili9488.
> waveshare,waveshare,pico-rt-lcd-35 (waveshare pico-restouch-lcd-3.5)
> 
> Signed-off-by: Tommaso Merciai 
> ---
>  .../bindings/display/ilitek,ili9488.yaml  | 72 +++
>  1 file changed, 72 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/ilitek,ili9488.yaml
> 
> diff --git a/Documentation/devicetree/bindings/display/ilitek,ili9488.yaml 
> b/Documentation/devicetree/bindings/display/ilitek,ili9488.yaml
> new file mode 100644
> index 0..879ecc42c350c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/ilitek,ili9488.yaml
> @@ -0,0 +1,72 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/ilitek,ili9488.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Ilitek ILI9488 display panels device tree bindings

Drop "device tree bindings"

> +
> +maintainers:
> +  - Kamlesh Gurudasani 
> +  - Michael Trimarchi 
> +  - Tommaso Merciai 
> +
> +description:
> +  This binding is for display panels using an Ilitek ILI9488 controller in 
> SPI

Drop "This binding is for" and instead describe hardware.

> +  mode.
> +
> +allOf:
> +  - $ref: panel/panel-common.yaml#
> +
> +properties:
> +  compatible:
> +items:
> +  - enum:
> +  # Waveshare 3.5" 320x480 Color TFT LCD
> +  - "waveshare,pico-rt-lcd-35"
> +  - const: ilitek,ili9488
> +
> +  spi-max-frequency:
> +maximum: 2000
> +
> +  dc-gpios:
> +maxItems: 1
> +description: Display data/command selection (D/CX)
> +
> +  backlight: true
> +  reg: true
> +  reset-gpios: true
> +  rotation: true
> +
> +required:
> +  - compatible
> +  - reg
> +  - dc-gpios
> +  - reset-gpios
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +#include 
> +
> +backlight: backlight {
> +compatible = "gpio-backlight";
> +gpios = <&gpio 22 GPIO_ACTIVE_HIGH>;

Drop it, no need for this example.


> +};
> +spi {
> +#address-cells = <1>;
> +#size-cells = <0>;

Use 4 spaces for example indentation.

> +
> +

No need for two blank lines.

> +display@0{
> +compatible = "waveshare,pico-rt-lcd-35", 
> "ilitek,ili9488";
> +reg = <0>;
> +spi-max-frequency = <2000>;
> +dc-gpios = <&gpio0 24 GPIO_ACTIVE_HIGH>;
> +reset-gpios = <&gpio0 25 GPIO_ACTIVE_HIGH>;
> +backlight = <&backlight>;
> +};
> +};
> +
> +...

Best regards,
Krzysztof

Re: [PATCH v2] drm_bridge: register content protect property

[Sean Paul]

On Mon, Oct 17, 2022 at 9:49 AM Hsin-Yi Wang  wrote:
>
> On Wed, Oct 12, 2022 at 12:20 PM Hsin-Yi Wang  wrote:
> >
> > Some bridges are able to update HDCP status from userspace request if
> > they support HDCP.
> >
> > HDCP property is the same as other connector properties that need to be
> > created after the connecter is initialized and before the connector is
> > registered.
> >
> anx7625 is a user for this.

I feel like we should not unconditionally attach this property for
bridges, this should be done in the driver which supports it IMO.

Sean

>
>
> > Signed-off-by: Hsin-Yi Wang 
> > Reported-by: kernel test robot 
> > ---
> > v2: Fix compile error when config is not set.
> > ---
> >  drivers/gpu/drm/drm_bridge_connector.c | 3 +++
> >  include/drm/display/drm_hdcp_helper.h  | 8 
> >  2 files changed, 11 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_bridge_connector.c 
> > b/drivers/gpu/drm/drm_bridge_connector.c
> > index 1c7d936523df5..a3b9ef8dc3f0b 100644
> > --- a/drivers/gpu/drm/drm_bridge_connector.c
> > +++ b/drivers/gpu/drm/drm_bridge_connector.c
> > @@ -7,6 +7,7 @@
> >  #include 
> >  #include 
> >
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -398,6 +399,8 @@ struct drm_connector *drm_bridge_connector_init(struct 
> > drm_device *drm,
> > if (panel_bridge)
> > drm_panel_bridge_set_orientation(connector, panel_bridge);
> >
> > +   drm_connector_attach_content_protection_property(connector, true);
> > +
> > return connector;
> >  }
> >  EXPORT_SYMBOL_GPL(drm_bridge_connector_init);
> > diff --git a/include/drm/display/drm_hdcp_helper.h 
> > b/include/drm/display/drm_hdcp_helper.h
> > index 8aaf87bf27351..c65d9f06a2532 100644
> > --- a/include/drm/display/drm_hdcp_helper.h
> > +++ b/include/drm/display/drm_hdcp_helper.h
> > @@ -15,8 +15,16 @@ struct drm_device;
> >  struct drm_connector;
> >
> >  int drm_hdcp_check_ksvs_revoked(struct drm_device *dev, u8 *ksvs, u32 
> > ksv_count);
> > +#if defined(CONFIG_DRM_DISPLAY_HDCP_HELPER)
> >  int drm_connector_attach_content_protection_property(struct drm_connector 
> > *connector,
> >  bool 
> > hdcp_content_type);
> > +#else
> > +static inline int drm_connector_attach_content_protection_property(struct 
> > drm_connector *connector,
> > +  bool 
> > hdcp_content_type)
> > +{
> > +   return 0;
> > +}
> > +#endif
> >  void drm_hdcp_update_content_protection(struct drm_connector *connector, 
> > u64 val);
> >
> >  #endif
> > --
> > 2.38.0.rc1.362.ged0d419d3c-goog
> >

[PATCH] drm: rcar_du: DRM_RCAR_DU optionally depends on RCAR_MIPI_DSI

[Randy Dunlap]

When CONFIG_DRM_RCAR_DU=y and CONFIG_DRM_RCAR_MIPI_DSI=m, calls
from the builtin driver to the mipi driver fail due to linker
errors.
Since the RCAR_MIPI_DSI driver is not always required, fix the
build error by making DRM_RCAR_DU optionally depend on the
RCAR_MIPI_DSI Kconfig symbol. This prevents the problematic
kconfig combination without requiring that RCAR_MIPI_DSI always
be enabled.

aarch64-linux-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function 
`rcar_du_crtc_atomic_enable':
rcar_du_crtc.c:(.text+0x3a18): undefined reference to 
`rcar_mipi_dsi_pclk_enable'
aarch64-linux-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function 
`rcar_du_crtc_atomic_disable':
rcar_du_crtc.c:(.text+0x47cc): undefined reference to 
`rcar_mipi_dsi_pclk_disable'

Fixes: 957fe62d7d15 ("drm: rcar-du: Fix DSI enable & disable sequence")
Signed-off-by: Randy Dunlap 
Cc: Tomi Valkeinen 
Cc: Laurent Pinchart 
Cc: Kieran Bingham 
Cc: LUU HOAI 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-renesas-...@vger.kernel.org
Cc: David Airlie 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/rcar-du/Kconfig |1 +
 1 file changed, 1 insertion(+)

diff -- a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -4,6 +4,7 @@ config DRM_RCAR_DU
depends on DRM && OF
depends on ARM || ARM64
depends on ARCH_RENESAS || COMPILE_TEST
+   depends on DRM_RCAR_MIPI_DSI || DRM_RCAR_MIPI_DSI=n
select DRM_KMS_HELPER
select DRM_GEM_DMA_HELPER
select VIDEOMODE_HELPERS

Re: [PATCH v4 15/17] drm/i915/vm_bind: Handle persistent vmas in execbuf3

[Matthew Auld]

On 18/10/2022 08:16, Niranjana Vishwanathapura wrote:

Handle persistent (VM_BIND) mappings during the request submission
in the execbuf3 path.

v2: Ensure requests wait for bindings to complete.
v3: Remove short term pinning with PIN_VALIDATE flag.
 Individualize fences before adding to dma_resv obj.

Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Andi Shyti 
---
  .../gpu/drm/i915/gem/i915_gem_execbuffer3.c   | 208 +-
  1 file changed, 207 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
index a9b4cc44bf66..8120e4c6b7da 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
@@ -3,6 +3,7 @@
   * Copyright © 2022 Intel Corporation
   */
  
+#include 

  #include 
  #include 
  
@@ -19,6 +20,7 @@

  #include "i915_gem_vm_bind.h"
  #include "i915_trace.h"
  
+#define __EXEC3_HAS_PIN			BIT_ULL(33)

  #define __EXEC3_ENGINE_PINNED BIT_ULL(32)
  #define __EXEC3_INTERNAL_FLAGS(~0ull << 32)
  
@@ -42,7 +44,9 @@

   * execlist. Hence, no support for implicit sync.
   *
   * The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only
- * works with execbuf3 ioctl for submission.
+ * works with execbuf3 ioctl for submission. All BOs mapped on that VM (through
+ * VM_BIND call) at the time of execbuf3 call are deemed required for that
+ * submission.
   *
   * The execbuf3 ioctl directly specifies the batch addresses instead of as
   * object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not
@@ -58,6 +62,13 @@
   * So, a lot of code supporting execbuf2 ioctl, like relocations, VA 
evictions,
   * vma lookup table, implicit sync, vma active reference tracking etc., are 
not
   * applicable for execbuf3 ioctl.
+ *
+ * During each execbuf submission, request fence is added to all VM_BIND mapped
+ * objects with DMA_RESV_USAGE_BOOKKEEP. The DMA_RESV_USAGE_BOOKKEEP usage will
+ * prevent over sync (See enum dma_resv_usage). Note that DRM_I915_GEM_WAIT and
+ * DRM_I915_GEM_BUSY ioctls do not check for DMA_RESV_USAGE_BOOKKEEP usage and
+ * hence should not be used for end of batch check. Instead, the execbuf3
+ * timeline out fence should be used for end of batch check.
   */
  
  /**

@@ -127,6 +138,23 @@ eb_find_vma(struct i915_address_space *vm, u64 addr)
return i915_gem_vm_bind_lookup_vma(vm, va);
  }
  
+static void eb_scoop_unbound_vma_all(struct i915_address_space *vm)

+{
+   struct i915_vma *vma, *vn;
+
+   /**
+* Move all unbound vmas back into vm_bind_list so that they are
+* revalidated.
+*/
+   spin_lock(&vm->vm_rebind_lock);
+   list_for_each_entry_safe(vma, vn, &vm->vm_rebind_list, vm_rebind_link) {
+   list_del_init(&vma->vm_rebind_link);
+   if (!list_empty(&vma->vm_bind_link))
+   list_move_tail(&vma->vm_bind_link, &vm->vm_bind_list);
+   }
+   spin_unlock(&vm->vm_rebind_lock);
+}
+
  static int eb_lookup_vma_all(struct i915_execbuffer *eb)
  {
unsigned int i, current_batch = 0;
@@ -141,14 +169,108 @@ static int eb_lookup_vma_all(struct i915_execbuffer *eb)
++current_batch;
}
  
+	eb_scoop_unbound_vma_all(eb->context->vm);

+
+   return 0;
+}
+
+static int eb_lock_vma_all(struct i915_execbuffer *eb)
+{
+   struct i915_address_space *vm = eb->context->vm;
+   struct i915_vma *vma;
+   int err;
+
+   err = i915_gem_object_lock(eb->context->vm->root_obj, &eb->ww);
+   if (err)
+   return err;
+
+   list_for_each_entry(vma, &vm->non_priv_vm_bind_list,
+   non_priv_vm_bind_link) {
+   err = i915_gem_object_lock(vma->obj, &eb->ww);
+   if (err)
+   return err;
+   }
+
return 0;
  }
  
+static void eb_release_persistent_vma_all(struct i915_execbuffer *eb)

+{
+   struct i915_address_space *vm = eb->context->vm;
+   struct i915_vma *vma, *vn;
+
+   lockdep_assert_held(&vm->vm_bind_lock);
+
+   if (!(eb->args->flags & __EXEC3_HAS_PIN))
+   return;
+
+   assert_object_held(vm->root_obj);
+
+   list_for_each_entry_safe(vma, vn, &vm->vm_bind_list, vm_bind_link)
+   if (i915_vma_verify_bind_complete(vma))
+   list_move_tail(&vma->vm_bind_link, &vm->vm_bound_list);
+
+   eb->args->flags &= ~__EXEC3_HAS_PIN;
+}
+
  static void eb_release_vma_all(struct i915_execbuffer *eb)
  {
+   eb_release_persistent_vma_all(eb);
eb_unpin_engine(eb);
  }
  
+static int eb_reserve_fence_for_persistent_vma_all(struct i915_execbuffer *eb)

+{
+   struct i915_address_space *vm = eb->context->vm;
+   u64 num_fences = 1;
+   struct i915_vma *vma;
+   int ret;
+
+   /* Reserve enough slots to accommodate composite fences */
+   if (intel_context_is_parallel

Re: [PATCH v4 12/17] drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl

[Matthew Auld]

On 18/10/2022 08:16, Niranjana Vishwanathapura wrote:

Implement new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only
works in vm_bind mode. The vm_bind mode only works with
this new execbuf3 ioctl.

The new execbuf3 ioctl will not have any list of objects to validate
bind as all required objects binding would have been requested by the
userspace before submitting the execbuf3.

Legacy features like relocations etc are not supported by execbuf3.

v2: Add more input validity checks.
v3: batch_address is a VA (not an array) if num_batches=1,
 minor cleanup
v4: replace vm->vm_bind_mode check with i915_gem_vm_is_vm_bind_mode()

Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Andi Shyti 
---
  drivers/gpu/drm/i915/Makefile |   1 +
  .../gpu/drm/i915/gem/i915_gem_execbuffer3.c   | 580 ++
  drivers/gpu/drm/i915/gem/i915_gem_ioctls.h|   2 +
  drivers/gpu/drm/i915/i915_driver.c|   1 +
  include/uapi/drm/i915_drm.h   |  61 ++
  5 files changed, 645 insertions(+)
  create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 8d76bb888dc3..6a801684d569 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -150,6 +150,7 @@ gem-y += \
gem/i915_gem_domain.o \
gem/i915_gem_execbuffer_common.o \
gem/i915_gem_execbuffer.o \
+   gem/i915_gem_execbuffer3.o \
gem/i915_gem_internal.o \
gem/i915_gem_object.o \
gem/i915_gem_lmem.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
new file mode 100644
index ..a9b4cc44bf66
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
@@ -0,0 +1,580 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+#include 
+
+#include 
+
+#include "gt/intel_context.h"
+#include "gt/intel_gpu_commands.h"
+#include "gt/intel_gt.h"
+
+#include "i915_drv.h"
+#include "i915_gem_context.h"
+#include "i915_gem_execbuffer_common.h"
+#include "i915_gem_ioctls.h"
+#include "i915_gem_vm_bind.h"
+#include "i915_trace.h"
+
+#define __EXEC3_ENGINE_PINNED  BIT_ULL(32)
+#define __EXEC3_INTERNAL_FLAGS (~0ull << 32)
+
+/* Catch emission of unexpected errors for CI! */
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
+#undef EINVAL
+#define EINVAL ({ \
+   DRM_DEBUG_DRIVER("EINVAL at %s:%d\n", __func__, __LINE__); \
+   22; \
+})
+#endif
+
+/**
+ * DOC: User command execution with execbuf3 ioctl
+ *
+ * A VM in VM_BIND mode will not support older execbuf mode of binding.
+ * The execbuf ioctl handling in VM_BIND mode differs significantly from the
+ * older execbuf2 ioctl (See struct drm_i915_gem_execbuffer2).
+ * Hence, a new execbuf3 ioctl has been added to support VM_BIND mode. (See
+ * struct drm_i915_gem_execbuffer3). The execbuf3 ioctl will not accept any
+ * execlist. Hence, no support for implicit sync.
+ *
+ * The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only
+ * works with execbuf3 ioctl for submission.
+ *
+ * The execbuf3 ioctl directly specifies the batch addresses instead of as
+ * object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not
+ * support many of the older features like in/out/submit fences, fence array,
+ * default gem context etc. (See struct drm_i915_gem_execbuffer3).
+ *
+ * In VM_BIND mode, VA allocation is completely managed by the user instead of
+ * the i915 driver. Hence all VA assignment, eviction are not applicable in
+ * VM_BIND mode. Also, for determining object activeness, VM_BIND mode will not
+ * be using the i915_vma active reference tracking. It will instead check the
+ * dma-resv object's fence list for that.
+ *
+ * So, a lot of code supporting execbuf2 ioctl, like relocations, VA evictions,
+ * vma lookup table, implicit sync, vma active reference tracking etc., are not
+ * applicable for execbuf3 ioctl.
+ */
+
+/**
+ * struct i915_execbuffer - execbuf struct for execbuf3
+ * @i915: reference to the i915 instance we run on
+ * @file: drm file reference
+ * args: execbuf3 ioctl structure
+ * @gt: reference to the gt instance ioctl submitted for
+ * @context: logical state for the request
+ * @gem_context: callers context
+ * @requests: requests to be build
+ * @composite_fence: used for excl fence in dma_resv objects when > 1 BB 
submitted
+ * @ww: i915_gem_ww_ctx instance
+ * @num_batches: number of batches submitted
+ * @batch_addresses: addresses corresponds to the submitted batches
+ * @batches: references to the i915_vmas corresponding to the batches
+ */
+struct i915_execbuffer {
+   struct drm_i915_private *i915;
+   struct drm_file *file;
+   struct drm_i915_gem_execbuffer3 *args;
+
+   struct intel_gt *gt;
+   struct intel_context *context;
+   struct i915_gem_context *gem_context;
+
+   struct i915_request *re

[PATCH v4] drm/sched: Fix kernel NULL pointer dereference error

[Arvind Yadav]

-This is purely a timing issue. Here, sometimes Job free
is happening before the job is done.
To fix this issue moving 'dma_fence_cb' callback from
job(struct drm_sched_job) to scheduler fence (struct drm_sched_fence).

-Added drm_sched_fence_set_parent() and drm_sched_fence_clear_parent()
functions to move fence handling into sched_fence.c and this just cleanup.

BUG: kernel NULL pointer dereference, address: 0088
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x) - not-present page
 PGD 0 P4D 0
 Oops:  [#1] PREEMPT SMP NOPTI
 CPU: 2 PID: 0 Comm: swapper/2 Not tainted 6.0.0-rc2-custom #1
 Hardware name: AMD Dibbler/Dibbler, BIOS RDB1107CC 09/26/2018
 RIP: 0010:drm_sched_job_done.isra.0+0x11/0x140 [gpu_sched]
 Code: 8b fe ff ff be 03 00 00 00 e8 7b da b7 e3 e9 d4 fe ff ff 66 0f 1f 44 00 
00 0f 1f 44 00 00 55 48 89 e5 41 55 41 54 49 89 fc 53 <48> 8b 9f 88 00 00 00 f0 
ff 8b f0 00 00 00 48 8b 83 80 01 00 00 f0
 RSP: 0018:b1b1801d4d38 EFLAGS: 00010087
 RAX: c0aa48b0 RBX: b1b1801d4d70 RCX: 0018
 RDX: 36c70afb7c1d RSI: 8a45ca413c60 RDI: 
 RBP: b1b1801d4d50 R08: 00b5 R09: 
 R10:  R11:  R12: 
 R13: b1b1801d4d70 R14: 8a45c416 R15: 8a45c416a708
 FS:  () GS:8a48a0a8() knlGS:
 CS:  0010 DS:  ES:  CR0: 80050033
 CR2: 0088 CR3: 00014ad5 CR4: 003506e0
 Call Trace:
  
  drm_sched_job_done_cb+0x12/0x20 [gpu_sched]
  dma_fence_signal_timestamp_locked+0x7e/0x110
  dma_fence_signal+0x31/0x60
  amdgpu_fence_process+0xc4/0x140 [amdgpu]
  gfx_v9_0_eop_irq+0x9d/0xd0 [amdgpu]
  amdgpu_irq_dispatch+0xb7/0x210 [amdgpu]
  amdgpu_ih_process+0x86/0x100 [amdgpu]
  amdgpu_irq_handler+0x24/0x60 [amdgpu]
  __handle_irq_event_percpu+0x4b/0x190
  handle_irq_event_percpu+0x15/0x50
  handle_irq_event+0x39/0x60
  handle_edge_irq+0xaf/0x210
  __common_interrupt+0x6e/0x110
  common_interrupt+0xc1/0xe0
  
  

Signed-off-by: Arvind Yadav 
---

Changes in v2: Moving 'dma_fence_cb' callback from
job(struct drm_sched_job) to scheduler fence(struct drm_sched_fence)
instead of adding NULL check for s_fence.

Changes in v3: Added drm_sched_fence_set_parent() function(and others 
*_parent_cb)
in sched_fence.c. Moved parent fence intilization and callback
installation into this (this just cleanup).

Changes in v4 : Add drm_sched_fence_clear_parent() function in sched_fence.c.
and done the changes as per review comments. 
---
 drivers/gpu/drm/scheduler/sched_fence.c | 64 +
 drivers/gpu/drm/scheduler/sched_main.c  | 53 
 include/drm/gpu_scheduler.h | 10 +++-
 3 files changed, 81 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/sched_fence.c 
b/drivers/gpu/drm/scheduler/sched_fence.c
index 7fd869520ef2..68343614f9ed 100644
--- a/drivers/gpu/drm/scheduler/sched_fence.c
+++ b/drivers/gpu/drm/scheduler/sched_fence.c
@@ -78,6 +78,70 @@ static void drm_sched_fence_free_rcu(struct rcu_head *rcu)
kmem_cache_free(sched_fence_slab, fence);
 }
 
+/**
+ * drm_sched_fence_parent_cb - the callback for a done job
+ * @f: fence
+ * @cb: fence callbacks
+ */
+static void drm_sched_fence_parent_cb(struct dma_fence *f, struct dma_fence_cb 
*cb)
+{
+   struct drm_sched_fence *s_fence = container_of(cb, struct 
drm_sched_fence,
+  cb);
+   struct drm_gpu_scheduler *sched = s_fence->sched;
+
+   atomic_dec(&sched->hw_rq_count);
+   atomic_dec(sched->score);
+
+   dma_fence_get(&s_fence->finished);
+   drm_sched_fence_finished(s_fence);
+   dma_fence_put(&s_fence->finished);
+   wake_up_interruptible(&sched->wake_up_worker);
+}
+
+/**
+ * drm_sched_fence_clear_parent -  Remove callbacks from pending list
+ * @s_fence: pointer to the fence
+ *
+ * Remove callbacks from pending list and clear the parent fence.
+ */
+bool drm_sched_fence_clear_parent(struct drm_sched_fence *s_fence)
+{
+   if (s_fence->parent &&
+   dma_fence_remove_callback(s_fence->parent, &s_fence->cb)) {
+   dma_fence_put(s_fence->parent);
+   s_fence->parent = NULL;
+   return true;
+   }
+
+   return false;
+}
+
+/**
+ * drm_sched_fence_set_parent - set the parent fence and add the callback
+ * @s_fence: pointer to the fence
+ * fence: pointer to the hw fence
+ *
+ * Set the parent fence and install the callback for a done job.
+ */
+void drm_sched_fence_set_parent(struct drm_sched_fence *s_fence,
+  struct dma_fence *fence)
+{
+   int r;
+
+   if (s_fence->parent &&
+   dma_fence_remove_callback(s_fence->parent, &s_fence->cb))
+   dma_fence_put(s_fence->parent);
+
+   /* We keep the reference of the parent fence here. */
+   swap(s_fence->parent, f

Re: [PATCH V2 3/4] drm/panel: Add prepare_upstream_first flag to drm_panel

[Dave Stevenson]

Hi Jagan

On Mon, 17 Oct 2022 at 03:44, Jagan Teki  wrote:
>
> Hi Dave,
>
> On Fri, Oct 7, 2022 at 6:26 PM Dave Stevenson
>  wrote:
> >
> > Hi Jagan
> >
> > On Thu, 6 Oct 2022 at 15:25, Jagan Teki  wrote:
> > >
> > > On Fri, Mar 4, 2022 at 8:48 PM Dave Stevenson
> > >  wrote:
> > > >
> > > > Mapping to the drm_bridge flag pre_enable_upstream_first,
> > > > add a new flag prepare_upstream_first to drm_panel to allow
> > > > the panel driver to request that the upstream bridge should
> > > > be pre_enabled before the panel prepare.
> > > >
> > > > Signed-off-by: Dave Stevenson 
> > > > ---
> > > >  drivers/gpu/drm/bridge/panel.c |  3 +++
> > > >  include/drm/drm_panel.h| 10 ++
> > > >  2 files changed, 13 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/bridge/panel.c 
> > > > b/drivers/gpu/drm/bridge/panel.c
> > > > index 5be057575183..2ea08b3ba326 100644
> > > > --- a/drivers/gpu/drm/bridge/panel.c
> > > > +++ b/drivers/gpu/drm/bridge/panel.c
> > > > @@ -234,6 +234,9 @@ struct drm_bridge 
> > > > *drm_panel_bridge_add_typed(struct drm_panel *panel,
> > > > panel_bridge->bridge.ops = DRM_BRIDGE_OP_MODES;
> > > > panel_bridge->bridge.type = connector_type;
> > > >
> > > > +   panel_bridge->bridge.pre_enable_upstream_first =
> > > > +   
> > > > panel->prepare_upstream_first;
> > > > +
> > >
> > > panel_bridge is common for bridge users who used panel and those who
> > > might not need upstream first, so better to handle per bridge user
> > > whoever needs this.
> >
> > Sorry, I don't follow you.
>
> panel_bridge driver is a common bridge for drm_panel_bridge_add
> registered bridges. If we enable pre_enable_upstream_first globally in
> panel_bridge driver then it affects panes that don't require
> pre_enable first for that bridge chain. Hope you understand.

No, sorry, I'm still not getting your point.

It is not enabled globally.
If (and only if) the specific panel driver has set
prepare_upstream_first in the struct drm_panel passed to
drm_panel_add(), then that setting is replicated in the associated
struct drm_bridge pre_enable_upstream_first.

Can you give an example of where you see this being an issue?

You proposed handling this on a per bridge user basis? What exactly
are you calling a bridge user in that case? The DSI host (or
equivalent) source to the panel? Because the panel driver has no idea
it is being wrapped into a drm_bridge.
However that source device can't alter the bridge chain call order
(breaking the chain as Exynos and vc4 do does not work with the atomic
API in "entertaining" ways), and it has no knowledge of the behaviour
the attached panel wants, nor does it know that it's going through
panel_bridge.

As per my previous email, devm_drm_of_get_bridge is the only other
place in the callstack that has both the drm_panel and drm_bridge
handles. Does putting the assignment from drm_panel to drm_bridge in
there solve your concern?

Thanks.
  Dave

Re: [PATCH v4 17/17] drm/i915/vm_bind: Add uapi for user to enable vm_bind_mode

[Niranjana Vishwanathapura]

On Tue, Oct 18, 2022 at 05:03:16PM +0100, Matthew Auld wrote:

On 18/10/2022 08:16, Niranjana Vishwanathapura wrote:

Add getparam support for VM_BIND capability version.
Add VM creation time flag to enable vm_bind_mode for the VM.

v2: update kernel-doc
v3: create vm->root_obj only upon I915_VM_CREATE_FLAGS_USE_VM_BIND
v4: replace vm->vm_bind_mode check with i915_gem_vm_is_vm_bind_mode()

Reviewed-by: Matthew Auld 
Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c | 25 +++--
 drivers/gpu/drm/i915/gem/i915_gem_context.h |  3 +--
 drivers/gpu/drm/i915/gt/intel_gtt.c |  2 ++
 drivers/gpu/drm/i915/i915_drv.h |  2 ++
 drivers/gpu/drm/i915/i915_getparam.c|  3 +++
 include/uapi/drm/i915_drm.h | 22 +-
 6 files changed, 52 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 76c6419b7ae0..0376adbbeecc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1803,9 +1803,13 @@ int i915_gem_vm_create_ioctl(struct drm_device *dev, 
void *data,
if (!HAS_FULL_PPGTT(i915))
return -ENODEV;
-   if (args->flags)
+   if (args->flags & I915_VM_CREATE_FLAGS_UNKNOWN)
return -EINVAL;
+   if ((args->flags & I915_VM_CREATE_FLAGS_USE_VM_BIND) &&
+   !HAS_VM_BIND(i915))
+   return -EOPNOTSUPP;
+
ppgtt = i915_ppgtt_create(to_gt(i915), 0);
if (IS_ERR(ppgtt))
return PTR_ERR(ppgtt);
@@ -1818,15 +1822,32 @@ int i915_gem_vm_create_ioctl(struct drm_device *dev, 
void *data,
goto err_put;
}
+   if (args->flags & I915_VM_CREATE_FLAGS_USE_VM_BIND) {
+   struct drm_i915_gem_object *obj;
+
+   obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
+   if (IS_ERR(obj)) {
+   err = PTR_ERR(obj);
+   goto err_put;
+   }
+
+   ppgtt->vm.root_obj = obj;
+   }
+
err = xa_alloc(&file_priv->vm_xa, &id, &ppgtt->vm,
   xa_limit_32b, GFP_KERNEL);
if (err)
-   goto err_put;
+   goto err_root_obj_put;
GEM_BUG_ON(id == 0); /* reserved for invalid/unassigned ppgtt */
args->vm_id = id;
return 0;
+err_root_obj_put:
+   if (ppgtt->vm.root_obj) {
+   i915_gem_object_put(ppgtt->vm.root_obj);
+   ppgtt->vm.root_obj = NULL;
+   }
 err_put:
i915_vm_put(&ppgtt->vm);
return err;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h 
b/drivers/gpu/drm/i915/gem/i915_gem_context.h
index e8b41aa8f8c4..b53aef2853cb 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
@@ -150,8 +150,7 @@ int i915_gem_context_reset_stats_ioctl(struct drm_device 
*dev, void *data,
  */
 static inline bool i915_gem_vm_is_vm_bind_mode(struct i915_address_space *vm)
 {
-   /* No support to enable vm_bind mode yet */
-   return false;
+   return !!vm->root_obj;
 }
 struct i915_address_space *
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c 
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 50648ab9214a..ae66fdd4bce9 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -178,6 +178,8 @@ int i915_vm_lock_objects(struct i915_address_space *vm,
 void i915_address_space_fini(struct i915_address_space *vm)
 {
drm_mm_takedown(&vm->mm);
+   if (vm->root_obj)
+   i915_gem_object_put(vm->root_obj);
GEM_BUG_ON(!RB_EMPTY_ROOT(&vm->va.rb_root));
mutex_destroy(&vm->vm_bind_lock);
 }
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7c64f8a17493..f4e7f3d4aff9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -972,6 +972,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 #define HAS_BAR2_SMEM_STOLEN(i915) (!HAS_LMEM(i915) && \
GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70))
+#define HAS_VM_BIND(i915) (GRAPHICS_VER(i915) >= 12)
+
 /* intel_device_info.c */
 static inline struct intel_device_info *
 mkwrite_device_info(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_getparam.c 
b/drivers/gpu/drm/i915/i915_getparam.c
index 342c8ca6414e..f45b3c684bcf 100644
--- a/drivers/gpu/drm/i915/i915_getparam.c
+++ b/drivers/gpu/drm/i915/i915_getparam.c
@@ -175,6 +175,9 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data,
case I915_PARAM_PERF_REVISION:
value = i915_perf_ioctl_version();
break;
+   case I915_PARAM_VM_BIND_VERSION:
+   value = HAS_VM_BIND(i915);
+   break;
default:
DRM_DEBUG("Unknown para

[PATCH 2/2] drm/tiny: add support for tft displays based on ilitek, ili9488

[Tommaso Merciai]

This adds support for ilitek,ili9488 based displays with shift register
in front of controller. Waveshare,pico-restouch-lcd-3.5 are such displays

Signed-off-by: Tommaso Merciai 
---
 drivers/gpu/drm/tiny/Kconfig   |  13 +
 drivers/gpu/drm/tiny/Makefile  |   1 +
 drivers/gpu/drm/tiny/ili9488.c | 440 +
 3 files changed, 454 insertions(+)
 create mode 100644 drivers/gpu/drm/tiny/ili9488.c

diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index 027cd87c3d0d7..6e708e8414806 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -148,6 +148,19 @@ config TINYDRM_ILI9486
 
  If M is selected the module will be called ili9486.
 
+config TINYDRM_ILI9488
+   tristate "DRM support for ILI9488 display panels"
+   depends on DRM && SPI
+   select DRM_KMS_HELPER
+   select DRM_GEM_CMA_HELPER
+   select DRM_MIPI_DBI
+   select BACKLIGHT_CLASS_DEVICE
+   help
+ DRM driver for the following Ilitek ILI9488 panels:
+ * LCD 3.5" 320x480 TFT (Waveshare Pico-ResTouch-LCD-3.5")
+
+ If M is selected the module will be called ili9486.
+
 config TINYDRM_MI0283QT
tristate "DRM support for MI0283QT"
depends on DRM && SPI
diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
index 1d9d6227e7ab7..aad6683b2ac40 100644
--- a/drivers/gpu/drm/tiny/Makefile
+++ b/drivers/gpu/drm/tiny/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_TINYDRM_ILI9163) += ili9163.o
 obj-$(CONFIG_TINYDRM_ILI9225)  += ili9225.o
 obj-$(CONFIG_TINYDRM_ILI9341)  += ili9341.o
 obj-$(CONFIG_TINYDRM_ILI9486)  += ili9486.o
+obj-$(CONFIG_TINYDRM_ILI9488)  += ili9488.o
 obj-$(CONFIG_TINYDRM_MI0283QT) += mi0283qt.o
 obj-$(CONFIG_TINYDRM_REPAPER)  += repaper.o
 obj-$(CONFIG_TINYDRM_ST7586)   += st7586.o
diff --git a/drivers/gpu/drm/tiny/ili9488.c b/drivers/gpu/drm/tiny/ili9488.c
new file mode 100644
index 0..b94d9d4ff4544
--- /dev/null
+++ b/drivers/gpu/drm/tiny/ili9488.c
@@ -0,0 +1,440 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * DRM driver for Ilitek ILI9488 panels
+ *
+ * Copyright 2020 Kamlesh Gurudasani 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ILI9488_VCOM_CONTROL_1 0xC5
+#define ILI9488_COLUMN_ADDRESS_SET 0x2A
+#define ILI9488_PAGE_ADDRESS_SET   0x2B
+#define ILI9488_MEMORY_WRITE   0x2C
+#define ILI9488_POSITIVE_GAMMA_CORRECTION  0xE0
+#define ILI9488_NEGATIVE_GAMMA_CORRECTION  0xE1
+#define ILI9488_POWER_CONTROL_10xC0
+#define ILI9488_POWER_CONTROL_20xC1
+#define ILI9488_POWER_CONTROL_30xC2
+#define ILI9488_MEM_ACCESS_CONTROL 0x36
+#define ILI9488_COLMOD_PIXEL_FORMAT_SET0x3A
+#define ILI9488_INTERFACE_MODE_CONTROL 0xB0
+#define ILI9488_FRAME_RATE_CONTROL_PARTIAL 0xB3
+#define ILI9488_DISPLAY_INVERSION_ON   0x21
+#define ILI9488_DISPLAY_INVERSION_CONTROL  0xB4
+#define ILI9488_DISPLAY_FUNCTION_CONTROL   0xB6
+#define ILI9488_ENTRY_MODE_SET 0xB7
+#define ILI9488_HS_LANES_CONTROL   0xBE
+#define ILI9488_SET_IMAGE_FUNCTION 0xE9
+#define ILI9488_ADJUST_CONTROL_3   0xF7
+#define ILI9488_DISPLAY_ON 0x29
+#define ILI9488_DISPLAY_OFF0x28
+#define ILI9488_ENTER_SLEEP_MODE   0x10
+#define ILI9488_DBI_BPP18  0x06
+#define ILI9488_DBI_BPP16  0x05
+#define ILI9488_DPI_BPP24  0x70
+#define ILI9488_DPI_BPP18  0x60
+#define ILI9488_DPI_BPP16  0x50
+#define ILI9488_FRAME_RATE_CONTROL_NORMAL  0xB1
+#define ILI9488_SLEEP_OUT  0x11
+
+#define ILI9488_MADCTL_RGB BIT(2)
+#define ILI9488_MADCTL_BGR BIT(3)
+#define ILI9488_MADCTL_MV  BIT(5)
+#define ILI9488_MADCTL_MX  BIT(6)
+#define ILI9488_MADCTL_MY  BIT(7)
+
+static void ili9488_rgb565_to_rgb666_line(u8 *dst, u16 *sbuf,
+ unsigned int pixels)
+{
+   unsigned int x;
+
+   for (x = 0; x < pixels; x++) {
+   *dst++ = ((*sbuf & 0xF800) >> 8);
+   *dst++ = ((*sbuf & 0x07E0) >> 3);
+   *dst++ = ((*sbuf & 0x001F) << 3);
+   sbuf++;
+   }
+}
+
+static void ili9488_rgb565_to_rgb666(u8 *dst, void *vaddr,
+struct drm_framebuffer *fb,
+struct drm_rect *rect)
+{
+   unsigned long linepixels = drm_rect_width(rect);
+   unsigned long lines = drm_rect_height(rect);
+   size_t dst_len = linepixels * 3;
+   siz

[PATCH 1/2] dt-bindings: add binding for tft displays based on ilitek, ili9488

[Tommaso Merciai]

This binding is for the tft displays based on ilitek,ili9488.
waveshare,waveshare,pico-rt-lcd-35 (waveshare pico-restouch-lcd-3.5)

Signed-off-by: Tommaso Merciai 
---
 .../bindings/display/ilitek,ili9488.yaml  | 72 +++
 1 file changed, 72 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/ilitek,ili9488.yaml

diff --git a/Documentation/devicetree/bindings/display/ilitek,ili9488.yaml 
b/Documentation/devicetree/bindings/display/ilitek,ili9488.yaml
new file mode 100644
index 0..879ecc42c350c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ilitek,ili9488.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/ilitek,ili9488.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ilitek ILI9488 display panels device tree bindings
+
+maintainers:
+  - Kamlesh Gurudasani 
+  - Michael Trimarchi 
+  - Tommaso Merciai 
+
+description:
+  This binding is for display panels using an Ilitek ILI9488 controller in SPI
+  mode.
+
+allOf:
+  - $ref: panel/panel-common.yaml#
+
+properties:
+  compatible:
+items:
+  - enum:
+  # Waveshare 3.5" 320x480 Color TFT LCD
+  - "waveshare,pico-rt-lcd-35"
+  - const: ilitek,ili9488
+
+  spi-max-frequency:
+maximum: 2000
+
+  dc-gpios:
+maxItems: 1
+description: Display data/command selection (D/CX)
+
+  backlight: true
+  reg: true
+  reset-gpios: true
+  rotation: true
+
+required:
+  - compatible
+  - reg
+  - dc-gpios
+  - reset-gpios
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+
+backlight: backlight {
+compatible = "gpio-backlight";
+gpios = <&gpio 22 GPIO_ACTIVE_HIGH>;
+};
+spi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+
+display@0{
+compatible = "waveshare,pico-rt-lcd-35", "ilitek,ili9488";
+reg = <0>;
+spi-max-frequency = <2000>;
+dc-gpios = <&gpio0 24 GPIO_ACTIVE_HIGH>;
+reset-gpios = <&gpio0 25 GPIO_ACTIVE_HIGH>;
+backlight = <&backlight>;
+};
+};
+
+...
-- 
2.25.1

[PATCH 0/2] drm/tiny: add support tft display based on ilitek, ili9488

[Tommaso Merciai]

Hi All,
This series  support for ilitek,ili9488 based displays like
Waveshare-ResTouch-LCD-3.5 display. Tested on Waveshare-ResTouch-LCD-3.5
connected to px30-evb via SPI.
This series is based on work done by Kamlesh Gurudasani in 2020:

 - "drm/tiny: add support for tft displays based on ilitek, ili9488"

(Thanks Kamlesh for your starting point)

Tests are done using the following tools coming from Yocto fs:

 - modetest -M "ili9488" -s 31:320x480@RG16 -v
 - fb-test
 - fb-rect

References:
 - 
https://patchwork.kernel.org/project/dri-devel/patch/00719f68aca488a6476b0dda634617606b592823.1592055494.git.kamlesh.gurudas...@gmail.com/
 - https://www.hpinfotech.ro/ILI9488.pdf
 - https://www.waveshare.com/wiki/Pico-ResTouch-LCD-3.5

Regards,
Tommaso

Tommaso Merciai (2):
  dt-bindings: add binding for tft displays based on ilitek,ili9488
  drm/tiny: add support for tft displays based on ilitek,ili9488

 .../bindings/display/ilitek,ili9488.yaml  |  72 +++
 drivers/gpu/drm/tiny/Kconfig  |  13 +
 drivers/gpu/drm/tiny/Makefile |   1 +
 drivers/gpu/drm/tiny/ili9488.c| 440 ++
 4 files changed, 526 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/ilitek,ili9488.yaml
 create mode 100644 drivers/gpu/drm/tiny/ili9488.c

-- 
2.25.1

Re: [PATCH v2] drm: Remove drm_mode_config::fb_base

[Zack Rusin]

On Tue, 2022-10-18 at 19:28 +0300, Laurent Pinchart wrote:
> > @@ -271,7 +260,8 @@ static int hibmc_load(struct drm_device *dev)
> >    if (ret)
> >    goto err;
> > 
> > - ret = drmm_vram_helper_init(dev, pci_resource_start(pdev, 0), priv-
> > >fb_size);
> > + ret = drmm_vram_helper_init(dev, pci_resource_start(pdev, 0),
> > + pci_resource_len(pdev, 1));
> 
> This should be pci_resource_len(pdev, 0). Apart from that,

Eh, yes, of course. Thanks!

> Reviewed-by: Laurent Pinchart 


z

Re: [PATCH v2] drm: Remove drm_mode_config::fb_base

[Laurent Pinchart]

Hi Zack,

Thank you for the patch.

On Tue, Oct 18, 2022 at 12:11:51PM -0400, Zack Rusin wrote:
> From: Zack Rusin 
> 
> v2: Thomas and Laurent noticed that in radeon_fb.c I forgot to set the
> info->apertures->ranges[0].base and Laurent noticed a neat little cleanup
> in the hisilicon driver as a result of the drm_mode_config::fb_base
> removal.
> 
> The fb_base in struct drm_mode_config has been unused for a long time.
> Some drivers set it and some don't leading to a very confusing state
> where the variable can't be relied upon, because there's no indication
> as to which driver sets it and which doesn't.
> 
> The only usage of fb_base is internal to two drivers so instead of trying
> to force it into all the drivers to get it into a coherent state
> completely remove it.
> 
> Signed-off-by: Zack Rusin 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c |  2 --
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c   |  2 --
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c   |  2 --
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c|  1 -
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c|  2 --
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c|  2 --
>  drivers/gpu/drm/ast/ast_mode.c   |  1 -
>  drivers/gpu/drm/gma500/framebuffer.c |  6 +++---
>  drivers/gpu/drm/gma500/psb_drv.h |  1 +
>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c  | 16 +++-
>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h  |  3 ---
>  drivers/gpu/drm/mgag200/mgag200_mode.c   |  1 -
>  drivers/gpu/drm/msm/msm_fbdev.c  |  2 --
>  drivers/gpu/drm/nouveau/nouveau_display.c|  1 -
>  drivers/gpu/drm/nouveau/nv04_fbcon.c |  6 --
>  drivers/gpu/drm/omapdrm/omap_fbdev.c |  2 --
>  drivers/gpu/drm/qxl/qxl_display.c|  2 --
>  drivers/gpu/drm/radeon/radeon_display.c  |  2 --
>  drivers/gpu/drm/radeon/radeon_fb.c   |  2 +-
>  drivers/gpu/drm/tegra/fb.c   |  1 -
>  drivers/gpu/drm/tiny/bochs.c |  1 -
>  include/drm/drm_mode_config.h|  2 --
>  22 files changed, 12 insertions(+), 48 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
> index f4b5301ea2a0..09dec2561adf 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
> @@ -498,8 +498,6 @@ static int amdgpu_vkms_sw_init(void *handle)
>   adev_to_drm(adev)->mode_config.preferred_depth = 24;
>   adev_to_drm(adev)->mode_config.prefer_shadow = 1;
>  
> - adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
> -
>   r = amdgpu_display_modeset_create_props(adev);
>   if (r)
>   return r;
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> index 288fce7dc0ed..05051d5d2ec3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> @@ -2800,8 +2800,6 @@ static int dce_v10_0_sw_init(void *handle)
>  
>   adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
>  
> - adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
> -
>   r = amdgpu_display_modeset_create_props(adev);
>   if (r)
>   return r;
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> index cbe5250b31cb..c928bc9eb202 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> @@ -2918,8 +2918,6 @@ static int dce_v11_0_sw_init(void *handle)
>  
>   adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
>  
> - adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
> -
>   r = amdgpu_display_modeset_create_props(adev);
>   if (r)
>   return r;
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> index b1c44fab074f..62315fd5a05f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> @@ -2675,7 +2675,6 @@ static int dce_v6_0_sw_init(void *handle)
>   adev_to_drm(adev)->mode_config.preferred_depth = 24;
>   adev_to_drm(adev)->mode_config.prefer_shadow = 1;
>   adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
> - adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
>  
>   r = amdgpu_display_modeset_create_props(adev);
>   if (r)
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> index a22b45c92792..87d5e4c21cb3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> @@ -2701,8 +2701,6 @@ static int dce_v8_0_sw_init(void *handle)
>  
>   adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
>  
> - adev_to_drm(adev)->mode_config.fb_base = adev->gmc.ap

[PATCH v2] drm: Remove drm_mode_config::fb_base

[Zack Rusin]

From: Zack Rusin 

v2: Thomas and Laurent noticed that in radeon_fb.c I forgot to set the
info->apertures->ranges[0].base and Laurent noticed a neat little cleanup
in the hisilicon driver as a result of the drm_mode_config::fb_base
removal.

The fb_base in struct drm_mode_config has been unused for a long time.
Some drivers set it and some don't leading to a very confusing state
where the variable can't be relied upon, because there's no indication
as to which driver sets it and which doesn't.

The only usage of fb_base is internal to two drivers so instead of trying
to force it into all the drivers to get it into a coherent state
completely remove it.

Signed-off-by: Zack Rusin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c |  2 --
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c   |  2 --
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c   |  2 --
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c|  1 -
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c|  2 --
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c|  2 --
 drivers/gpu/drm/ast/ast_mode.c   |  1 -
 drivers/gpu/drm/gma500/framebuffer.c |  6 +++---
 drivers/gpu/drm/gma500/psb_drv.h |  1 +
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c  | 16 +++-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h  |  3 ---
 drivers/gpu/drm/mgag200/mgag200_mode.c   |  1 -
 drivers/gpu/drm/msm/msm_fbdev.c  |  2 --
 drivers/gpu/drm/nouveau/nouveau_display.c|  1 -
 drivers/gpu/drm/nouveau/nv04_fbcon.c |  6 --
 drivers/gpu/drm/omapdrm/omap_fbdev.c |  2 --
 drivers/gpu/drm/qxl/qxl_display.c|  2 --
 drivers/gpu/drm/radeon/radeon_display.c  |  2 --
 drivers/gpu/drm/radeon/radeon_fb.c   |  2 +-
 drivers/gpu/drm/tegra/fb.c   |  1 -
 drivers/gpu/drm/tiny/bochs.c |  1 -
 include/drm/drm_mode_config.h|  2 --
 22 files changed, 12 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
index f4b5301ea2a0..09dec2561adf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
@@ -498,8 +498,6 @@ static int amdgpu_vkms_sw_init(void *handle)
adev_to_drm(adev)->mode_config.preferred_depth = 24;
adev_to_drm(adev)->mode_config.prefer_shadow = 1;
 
-   adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
-
r = amdgpu_display_modeset_create_props(adev);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index 288fce7dc0ed..05051d5d2ec3 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -2800,8 +2800,6 @@ static int dce_v10_0_sw_init(void *handle)
 
adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
 
-   adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
-
r = amdgpu_display_modeset_create_props(adev);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index cbe5250b31cb..c928bc9eb202 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -2918,8 +2918,6 @@ static int dce_v11_0_sw_init(void *handle)
 
adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
 
-   adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
-
r = amdgpu_display_modeset_create_props(adev);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
index b1c44fab074f..62315fd5a05f 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
@@ -2675,7 +2675,6 @@ static int dce_v6_0_sw_init(void *handle)
adev_to_drm(adev)->mode_config.preferred_depth = 24;
adev_to_drm(adev)->mode_config.prefer_shadow = 1;
adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
-   adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
 
r = amdgpu_display_modeset_create_props(adev);
if (r)
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index a22b45c92792..87d5e4c21cb3 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -2701,8 +2701,6 @@ static int dce_v8_0_sw_init(void *handle)
 
adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
 
-   adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
-
r = amdgpu_display_modeset_create_props(adev);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index c053cb79cd06..0db2a88cd4d7 100644

Re: [PATCH v4 17/17] drm/i915/vm_bind: Add uapi for user to enable vm_bind_mode

[Matthew Auld]

On 18/10/2022 08:16, Niranjana Vishwanathapura wrote:

Add getparam support for VM_BIND capability version.
Add VM creation time flag to enable vm_bind_mode for the VM.

v2: update kernel-doc
v3: create vm->root_obj only upon I915_VM_CREATE_FLAGS_USE_VM_BIND
v4: replace vm->vm_bind_mode check with i915_gem_vm_is_vm_bind_mode()

Reviewed-by: Matthew Auld 
Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Andi Shyti 
---
  drivers/gpu/drm/i915/gem/i915_gem_context.c | 25 +++--
  drivers/gpu/drm/i915/gem/i915_gem_context.h |  3 +--
  drivers/gpu/drm/i915/gt/intel_gtt.c |  2 ++
  drivers/gpu/drm/i915/i915_drv.h |  2 ++
  drivers/gpu/drm/i915/i915_getparam.c|  3 +++
  include/uapi/drm/i915_drm.h | 22 +-
  6 files changed, 52 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 76c6419b7ae0..0376adbbeecc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1803,9 +1803,13 @@ int i915_gem_vm_create_ioctl(struct drm_device *dev, 
void *data,
if (!HAS_FULL_PPGTT(i915))
return -ENODEV;
  
-	if (args->flags)

+   if (args->flags & I915_VM_CREATE_FLAGS_UNKNOWN)
return -EINVAL;
  
+	if ((args->flags & I915_VM_CREATE_FLAGS_USE_VM_BIND) &&

+   !HAS_VM_BIND(i915))
+   return -EOPNOTSUPP;
+
ppgtt = i915_ppgtt_create(to_gt(i915), 0);
if (IS_ERR(ppgtt))
return PTR_ERR(ppgtt);
@@ -1818,15 +1822,32 @@ int i915_gem_vm_create_ioctl(struct drm_device *dev, 
void *data,
goto err_put;
}
  
+	if (args->flags & I915_VM_CREATE_FLAGS_USE_VM_BIND) {

+   struct drm_i915_gem_object *obj;
+
+   obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
+   if (IS_ERR(obj)) {
+   err = PTR_ERR(obj);
+   goto err_put;
+   }
+
+   ppgtt->vm.root_obj = obj;
+   }
+
err = xa_alloc(&file_priv->vm_xa, &id, &ppgtt->vm,
   xa_limit_32b, GFP_KERNEL);
if (err)
-   goto err_put;
+   goto err_root_obj_put;
  
  	GEM_BUG_ON(id == 0); /* reserved for invalid/unassigned ppgtt */

args->vm_id = id;
return 0;
  
+err_root_obj_put:

+   if (ppgtt->vm.root_obj) {
+   i915_gem_object_put(ppgtt->vm.root_obj);
+   ppgtt->vm.root_obj = NULL;
+   }
  err_put:
i915_vm_put(&ppgtt->vm);
return err;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h 
b/drivers/gpu/drm/i915/gem/i915_gem_context.h
index e8b41aa8f8c4..b53aef2853cb 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
@@ -150,8 +150,7 @@ int i915_gem_context_reset_stats_ioctl(struct drm_device 
*dev, void *data,
   */
  static inline bool i915_gem_vm_is_vm_bind_mode(struct i915_address_space *vm)
  {
-   /* No support to enable vm_bind mode yet */
-   return false;
+   return !!vm->root_obj;
  }
  
  struct i915_address_space *

diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c 
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 50648ab9214a..ae66fdd4bce9 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -178,6 +178,8 @@ int i915_vm_lock_objects(struct i915_address_space *vm,
  void i915_address_space_fini(struct i915_address_space *vm)
  {
drm_mm_takedown(&vm->mm);
+   if (vm->root_obj)
+   i915_gem_object_put(vm->root_obj);
GEM_BUG_ON(!RB_EMPTY_ROOT(&vm->va.rb_root));
mutex_destroy(&vm->vm_bind_lock);
  }
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7c64f8a17493..f4e7f3d4aff9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -972,6 +972,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
  #define HAS_BAR2_SMEM_STOLEN(i915) (!HAS_LMEM(i915) && \
GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70))
  
+#define HAS_VM_BIND(i915) (GRAPHICS_VER(i915) >= 12)

+
  /* intel_device_info.c */
  static inline struct intel_device_info *
  mkwrite_device_info(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_getparam.c 
b/drivers/gpu/drm/i915/i915_getparam.c
index 342c8ca6414e..f45b3c684bcf 100644
--- a/drivers/gpu/drm/i915/i915_getparam.c
+++ b/drivers/gpu/drm/i915/i915_getparam.c
@@ -175,6 +175,9 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data,
case I915_PARAM_PERF_REVISION:
value = i915_perf_ioctl_version();
break;
+   case I915_PARAM_VM_BIND_VERSION:
+   value = HAS_VM_BIND(i915);
+   break;
default:
DRM_DEBUG("Unknown parameter %d\n", param->param);
  

Re: [PATCH] drm/amdgpu/powerplay/psm: Fix memory leak in power state init

[Alex Deucher]

Applied.  Thanks!

Alex

On Mon, Oct 17, 2022 at 9:07 PM Quan, Evan  wrote:
>
> [AMD Official Use Only - General]
>
> Reviewed-by: Evan Quan 
>
> > -Original Message-
> > From: Rafael Mendonca 
> > Sent: Tuesday, October 18, 2022 8:54 AM
> > To: Quan, Evan ; Deucher, Alexander
> > ; Koenig, Christian
> > ; Pan, Xinhui ; David
> > Airlie ; Daniel Vetter 
> > Cc: Rafael Mendonca ; amd-
> > g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-
> > ker...@vger.kernel.org
> > Subject: [PATCH] drm/amdgpu/powerplay/psm: Fix memory leak in power
> > state init
> >
> > Commit 902bc65de0b3 ("drm/amdgpu/powerplay/psm: return an error in
> > power state init") made the power state init function return early in case 
> > of
> > failure to get an entry from the powerplay table, but it missed to clean up 
> > the
> > allocated memory for the current power state before returning.
> >
> > Fixes: 902bc65de0b3 ("drm/amdgpu/powerplay/psm: return an error in
> > power state init")
> > Signed-off-by: Rafael Mendonca 
> > ---
> >  drivers/gpu/drm/amd/pm/powerplay/hwmgr/pp_psm.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/pp_psm.c
> > b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/pp_psm.c
> > index 67d7da0b6fed..1d829402cd2e 100644
> > --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/pp_psm.c
> > +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/pp_psm.c
> > @@ -75,8 +75,10 @@ int psm_init_power_state_table(struct pp_hwmgr
> > *hwmgr)
> >   for (i = 0; i < table_entries; i++) {
> >   result = hwmgr->hwmgr_func->get_pp_table_entry(hwmgr,
> > i, state);
> >   if (result) {
> > + kfree(hwmgr->current_ps);
> >   kfree(hwmgr->request_ps);
> >   kfree(hwmgr->ps);
> > + hwmgr->current_ps = NULL;
> >   hwmgr->request_ps = NULL;
> >   hwmgr->ps = NULL;
> >   return -EINVAL;
> > --
> > 2.34.1

Re: [PATCH] drm: Remove drm_mode_config::fb_base

[Zack Rusin]

On Tue, 2022-10-18 at 16:05 +0200, Thomas Zimmermann wrote:
> Hi
> 
> Am 18.10.22 um 15:17 schrieb Zack Rusin:
> > From: Zack Rusin 
> > 
> > The fb_base in struct drm_mode_config has been unused for a long time.
> > Some drivers set it and some don't leading to a very confusing state
> > where the variable can't be relied upon, because there's no indication
> > as to which driver sets it and which doesn't.
> > 
> > The only usage of fb_base is internal to two drivers so instead of trying
> > to force it into all the drivers to get it into a coherent state
> > completely remove it.
> 
> Thanks a lot. I wanted to remove that field for some time. Pleaser see 
> my comments below.
> 
> > 
> > Signed-off-by: Zack Rusin 
> > ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c  | 2 --
> >   drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 --
> >   drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 --
> >   drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 1 -
> >   drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 --
> >   drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 --
> >   drivers/gpu/drm/ast/ast_mode.c| 1 -
> >   drivers/gpu/drm/gma500/framebuffer.c  | 6 +++---
> >   drivers/gpu/drm/gma500/psb_drv.h  | 1 +
> >   drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c   | 1 -
> >   drivers/gpu/drm/mgag200/mgag200_mode.c| 1 -
> >   drivers/gpu/drm/msm/msm_fbdev.c   | 2 --
> >   drivers/gpu/drm/nouveau/nouveau_display.c | 1 -
> >   drivers/gpu/drm/nouveau/nv04_fbcon.c  | 6 --
> >   drivers/gpu/drm/omapdrm/omap_fbdev.c  | 2 --
> >   drivers/gpu/drm/qxl/qxl_display.c | 2 --
> >   drivers/gpu/drm/radeon/radeon_display.c   | 2 --
> >   drivers/gpu/drm/radeon/radeon_fb.c| 1 -
> >   drivers/gpu/drm/tegra/fb.c| 1 -
> >   drivers/gpu/drm/tiny/bochs.c  | 1 -
> >   include/drm/drm_mode_config.h | 2 --
> >   21 files changed, 8 insertions(+), 33 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
> > index f4b5301ea2a0..09dec2561adf 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
> > @@ -498,8 +498,6 @@ static int amdgpu_vkms_sw_init(void *handle)
> > adev_to_drm(adev)->mode_config.preferred_depth = 24;
> > adev_to_drm(adev)->mode_config.prefer_shadow = 1;
> >   
> > -   adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
> > -
> > r = amdgpu_display_modeset_create_props(adev);
> > if (r)
> > return r;
> > diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
> > b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> > index 288fce7dc0ed..05051d5d2ec3 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> > @@ -2800,8 +2800,6 @@ static int dce_v10_0_sw_init(void *handle)
> >   
> > adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
> >   
> > -   adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
> > -
> > r = amdgpu_display_modeset_create_props(adev);
> > if (r)
> > return r;
> > diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
> > b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> > index cbe5250b31cb..c928bc9eb202 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> > @@ -2918,8 +2918,6 @@ static int dce_v11_0_sw_init(void *handle)
> >   
> > adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
> >   
> > -   adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
> > -
> > r = amdgpu_display_modeset_create_props(adev);
> > if (r)
> > return r;
> > diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c 
> > b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> > index b1c44fab074f..62315fd5a05f 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> > @@ -2675,7 +2675,6 @@ static int dce_v6_0_sw_init(void *handle)
> > adev_to_drm(adev)->mode_config.preferred_depth = 24;
> > adev_to_drm(adev)->mode_config.prefer_shadow = 1;
> > adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
> > -   adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
> >   
> > r = amdgpu_display_modeset_create_props(adev);
> > if (r)
> > diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
> > b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> > index a22b45c92792..87d5e4c21cb3 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> > @@ -2701,8 +2701,6 @@ static int dce_v8_0_sw_init(void *handle)
> >   
> > adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
> >   
> > -   adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
> 

Re: [PATCH 1/2] drm/sched: add DRM_SCHED_FENCE_DONT_PIPELINE flag

[Alex Deucher]

On Tue, Oct 18, 2022 at 11:11 AM Christian König
 wrote:
>
> Gentle ping to others to get this reviewed.
>
> Alex, this is fixing the TLB flush errors and I think we need to get it
> into -fixes ASAP.
>
> Christian.
>
> Am 14.10.22 um 10:15 schrieb Christian König:
> > Setting this flag on a scheduler fence prevents pipelining of jobs
> > depending on this fence. In other words we always insert a full CPU
> > round trip before dependen jobs are pushed to the pipeline.

typo: dependen -> dependent

> >
> > Signed-off-by: Christian König 
> > CC: sta...@vger.kernel.org # 5.19+

Please add a link to the bug as well for both patches.  With those
fixed, series is:
Reviewed-by: Alex Deucher 

> > ---
> >   drivers/gpu/drm/scheduler/sched_entity.c | 3 ++-
> >   include/drm/gpu_scheduler.h  | 9 +
> >   2 files changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/scheduler/sched_entity.c 
> > b/drivers/gpu/drm/scheduler/sched_entity.c
> > index 191c56064f19..43d337d8b153 100644
> > --- a/drivers/gpu/drm/scheduler/sched_entity.c
> > +++ b/drivers/gpu/drm/scheduler/sched_entity.c
> > @@ -385,7 +385,8 @@ static bool drm_sched_entity_add_dependency_cb(struct 
> > drm_sched_entity *entity)
> >   }
> >
> >   s_fence = to_drm_sched_fence(fence);
> > - if (s_fence && s_fence->sched == sched) {
> > + if (s_fence && s_fence->sched == sched &&
> > + !test_bit(DRM_SCHED_FENCE_DONT_PIPELINE, &fence->flags)) {
> >
> >   /*
> >* Fence is from the same scheduler, only need to wait for
> > diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
> > index 0fca8f38bee4..f01d14b231ed 100644
> > --- a/include/drm/gpu_scheduler.h
> > +++ b/include/drm/gpu_scheduler.h
> > @@ -32,6 +32,15 @@
> >
> >   #define MAX_WAIT_SCHED_ENTITY_Q_EMPTY msecs_to_jiffies(1000)
> >
> > +/**
> > + * DRM_SCHED_FENCE_DONT_PIPELINE - Prefent dependency pipelining
> > + *
> > + * Setting this flag on a scheduler fence prevents pipelining of jobs 
> > depending
> > + * on this fence. In other words we always insert a full CPU round trip 
> > before
> > + * dependen jobs are pushed to the hw queue.
> > + */
> > +#define DRM_SCHED_FENCE_DONT_PIPELINEDMA_FENCE_FLAG_USER_BITS
> > +
> >   struct drm_gem_object;
> >
> >   struct drm_gpu_scheduler;
>

Re: [PATCH v2 4/7] drm/simpledrm: Add support for system memory framebuffers

[Rob Herring]

On Tue, Oct 18, 2022 at 5:47 AM Thierry Reding  wrote:
>
> On Mon, Oct 17, 2022 at 01:15:59PM -0500, Rob Herring wrote:
> > On Mon, Oct 17, 2022 at 9:54 AM Thierry Reding  
> > wrote:
> > >
> > > On Mon, Oct 10, 2022 at 10:12:34AM +0200, Thomas Zimmermann wrote:
> > > > Hi
> > > >
> > > > Am 07.10.22 um 14:49 schrieb Thierry Reding:
> > > > > From: Thierry Reding 
> > > > >
> > > > > Simple framebuffers can be set up in system memory, which cannot be
> > > > > requested and/or I/O remapped using the I/O resource helpers. Add a
> > > > > separate code path that obtains system memory framebuffers from the
> > > > > reserved memory region referenced in the memory-region property.
> > > > >
> > > > > v2: make screen base a struct iosys_map to avoid sparse warnings
> >
> > [...]
> >
> > > > > +static int simple_framebuffer_init(struct reserved_mem *rmem)
> > > > > +{
> > > > > +   pr_info("framebuffer memory at %pa, size %lu bytes\n", 
> > > > > &rmem->base,
> > > > > +   (unsigned long)rmem->size);
> > > > > +
> > > > > +   rmem->ops = &simple_framebuffer_ops;
> > > > > +
> > > > > +   return 0;
> > > > > +}
> > > > > +RESERVEDMEM_OF_DECLARE(simple_framebuffer, "framebuffer", 
> > > > > simple_framebuffer_init);
> > > >
> > > > What's the prupose of these code at all?  I looked through the kernel, 
> > > > but
> > > > there aren't many other examples of it.
> > >
> > > This is a fairly standard construct to deal with early memory
> > > reservations. What happens is roughly this: during early kernel boot,
> > > the reserved-memory core code will iterate over all children of the top-
> > > level reserved-memory node and see if they have a compatible string that
> > > matches one of the entries in the table created by these
> > > RESERVEDMEM_OF_DECLARE entries. It will then call the init function for
> > > a matched entry and register a struct reserved_mem for these. The init
> > > function in this case just dumps an informational message to the boot
> > > log to provide some information about the framebuffer region that was
> > > reserved (which can be used for example for troubleshooting purposes)
> > > and sets the device init/release operations (which will be called when a
> > > device is associated with the reserved memory region, i.e. when the
> > > of_reserved_mem_device_init_by_idx() function is called).
> > >
> > > The reason why there aren't many examples of this is because these are
> > > special memory regions that (at least upstream) kernels seldom support.
> > > Perhaps the most common use-cases are the shared DMA pools (such as
> > > CMA).
> >
> > Also, not all regions need to be handled 'early' before slab allocator
> > or drivers are probed. Do you need early handling here? I can't see
> > why other than if fbcon is up early.
>
> No, I don't think this needs early handling. Obviously we want this to
> be available as soon as possible, but since the framebuffer driver is
> built on top of DRM and that all becomes available fairly late, I don't
> think this could ever run *that* early.
>
> So are you saying that in general if we don't need early handling we
> should avoid RESERVEDMEM_OF_DECLARE and instead manually resolve the
> memory regions and inspect them? In other words, RESERVEDMEM_OF_DECLARE
> should only ever be used when this early handling is needed?

Right. Like all the other *_OF_DECLARE() macros, they are only for
when needed before driver probe time. Lots of shared memory mailbox
drivers use reserved-memory regions if you need examples.

Rob

Re: [PATCH v4 09/17] drm/i915/vm_bind: Add out fence support

[Matthew Auld]

On 18/10/2022 08:16, Niranjana Vishwanathapura wrote:

Add support for handling out fence for vm_bind call.

v2: Reset vma->vm_bind_fence.syncobj to NULL at the end
 of vm_bind call.
v3: Remove vm_unbind out fence uapi which is not supported yet.

Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Andi Shyti 
---
  drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h   |  4 +
  .../drm/i915/gem/i915_gem_vm_bind_object.c| 82 +++
  drivers/gpu/drm/i915/i915_vma.c   |  7 +-
  drivers/gpu/drm/i915/i915_vma_types.h |  7 ++
  include/uapi/drm/i915_drm.h   | 49 ++-
  5 files changed, 146 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
index 36262a6357b5..b70e900e35ab 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
@@ -8,6 +8,7 @@
  
  #include 
  
+struct dma_fence;

  struct drm_device;
  struct drm_file;
  struct i915_address_space;
@@ -23,4 +24,7 @@ int i915_gem_vm_unbind_ioctl(struct drm_device *dev, void 
*data,
  
  void i915_gem_vm_unbind_all(struct i915_address_space *vm);
  
+void i915_vm_bind_signal_fence(struct i915_vma *vma,

+  struct dma_fence * const fence);
+
  #endif /* __I915_GEM_VM_BIND_H */
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index 3ea3cb3ed97e..63889ba00183 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -7,6 +7,8 @@
  
  #include 
  
+#include 

+
  #include "gem/i915_gem_context.h"
  #include "gem/i915_gem_vm_bind.h"
  
@@ -100,6 +102,76 @@ static void i915_gem_vm_bind_remove(struct i915_vma *vma, bool release_obj)

i915_gem_object_put(vma->obj);
  }
  
+static int i915_vm_bind_add_fence(struct drm_file *file, struct i915_vma *vma,

+ u32 handle, u64 point)
+{
+   struct drm_syncobj *syncobj;
+
+   syncobj = drm_syncobj_find(file, handle);
+   if (!syncobj) {
+   DRM_DEBUG("Invalid syncobj handle provided\n");
+   return -ENOENT;
+   }
+
+   /*
+* For timeline syncobjs we need to preallocate chains for
+* later signaling.
+*/
+   if (point) {
+   vma->vm_bind_fence.chain_fence = dma_fence_chain_alloc();
+   if (!vma->vm_bind_fence.chain_fence) {
+   drm_syncobj_put(syncobj);
+   return -ENOMEM;
+   }
+   } else {
+   vma->vm_bind_fence.chain_fence = NULL;
+   }
+   vma->vm_bind_fence.syncobj = syncobj;
+   vma->vm_bind_fence.value = point;
+
+   return 0;
+}
+
+static void i915_vm_bind_put_fence(struct i915_vma *vma)
+{
+   if (!vma->vm_bind_fence.syncobj)
+   return;
+
+   drm_syncobj_put(vma->vm_bind_fence.syncobj);
+   dma_fence_chain_free(vma->vm_bind_fence.chain_fence);
+   vma->vm_bind_fence.syncobj = NULL;
+}
+
+/**
+ * i915_vm_bind_signal_fence() - Add fence to vm_bind syncobj
+ * @vma: vma mapping requiring signaling
+ * @fence: fence to be added
+ *
+ * Associate specified @fence with the @vma's syncobj to be
+ * signaled after the @fence work completes.
+ */
+void i915_vm_bind_signal_fence(struct i915_vma *vma,
+  struct dma_fence * const fence)
+{
+   struct drm_syncobj *syncobj = vma->vm_bind_fence.syncobj;
+
+   if (!syncobj)
+   return;
+
+   if (vma->vm_bind_fence.chain_fence) {
+   drm_syncobj_add_point(syncobj,
+ vma->vm_bind_fence.chain_fence,
+ fence, vma->vm_bind_fence.value);
+   /*
+* The chain's ownership is transferred to the
+* timeline.
+*/
+   vma->vm_bind_fence.chain_fence = NULL;
+   } else {
+   drm_syncobj_replace_fence(syncobj, fence);
+   }
+}
+
  static int i915_gem_vm_unbind_vma(struct i915_address_space *vm,
  struct drm_i915_gem_vm_unbind *va)
  {
@@ -237,6 +309,13 @@ static int i915_gem_vm_bind_obj(struct i915_address_space 
*vm,
goto unlock_vm;
}
  
+	if (va->fence.flags & I915_TIMELINE_FENCE_SIGNAL) {

+   ret = i915_vm_bind_add_fence(file, vma, va->fence.handle,
+va->fence.value);
+   if (ret)
+   goto put_vma;
+   }
+
pin_flags = va->start | PIN_OFFSET_FIXED | PIN_USER | PIN_VALIDATE;
  
  	for_i915_gem_ww(&ww, ret, true) {

@@ -258,6 +337,9 @@ static int i915_gem_vm_bind_obj(struct i915_address_space 
*vm,
i915_gem_object_get(vma->obj);
}
  
+	if (va->fence.flags & I915_TIMELINE_FENCE_SIGNAL)

+   

Re: [PATCH] drm: Remove drm_mode_config::fb_base

[Laurent Pinchart]

Hi Zack,

Thank you for the patch.

On Tue, Oct 18, 2022 at 09:17:45AM -0400, Zack Rusin wrote:
> From: Zack Rusin 
> 
> The fb_base in struct drm_mode_config has been unused for a long time.
> Some drivers set it and some don't leading to a very confusing state
> where the variable can't be relied upon, because there's no indication
> as to which driver sets it and which doesn't.
> 
> The only usage of fb_base is internal to two drivers so instead of trying
> to force it into all the drivers to get it into a coherent state
> completely remove it.
> 
> Signed-off-by: Zack Rusin 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c  | 2 --
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 --
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 --
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 1 -
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 --
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 --
>  drivers/gpu/drm/ast/ast_mode.c| 1 -
>  drivers/gpu/drm/gma500/framebuffer.c  | 6 +++---
>  drivers/gpu/drm/gma500/psb_drv.h  | 1 +
>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c   | 1 -
>  drivers/gpu/drm/mgag200/mgag200_mode.c| 1 -
>  drivers/gpu/drm/msm/msm_fbdev.c   | 2 --
>  drivers/gpu/drm/nouveau/nouveau_display.c | 1 -
>  drivers/gpu/drm/nouveau/nv04_fbcon.c  | 6 --
>  drivers/gpu/drm/omapdrm/omap_fbdev.c  | 2 --
>  drivers/gpu/drm/qxl/qxl_display.c | 2 --
>  drivers/gpu/drm/radeon/radeon_display.c   | 2 --
>  drivers/gpu/drm/radeon/radeon_fb.c| 1 -
>  drivers/gpu/drm/tegra/fb.c| 1 -
>  drivers/gpu/drm/tiny/bochs.c  | 1 -
>  include/drm/drm_mode_config.h | 2 --
>  21 files changed, 8 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
> index f4b5301ea2a0..09dec2561adf 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
> @@ -498,8 +498,6 @@ static int amdgpu_vkms_sw_init(void *handle)
>   adev_to_drm(adev)->mode_config.preferred_depth = 24;
>   adev_to_drm(adev)->mode_config.prefer_shadow = 1;
>  
> - adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
> -
>   r = amdgpu_display_modeset_create_props(adev);
>   if (r)
>   return r;
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> index 288fce7dc0ed..05051d5d2ec3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> @@ -2800,8 +2800,6 @@ static int dce_v10_0_sw_init(void *handle)
>  
>   adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
>  
> - adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
> -
>   r = amdgpu_display_modeset_create_props(adev);
>   if (r)
>   return r;
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> index cbe5250b31cb..c928bc9eb202 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> @@ -2918,8 +2918,6 @@ static int dce_v11_0_sw_init(void *handle)
>  
>   adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
>  
> - adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
> -
>   r = amdgpu_display_modeset_create_props(adev);
>   if (r)
>   return r;
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> index b1c44fab074f..62315fd5a05f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> @@ -2675,7 +2675,6 @@ static int dce_v6_0_sw_init(void *handle)
>   adev_to_drm(adev)->mode_config.preferred_depth = 24;
>   adev_to_drm(adev)->mode_config.prefer_shadow = 1;
>   adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
> - adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
>  
>   r = amdgpu_display_modeset_create_props(adev);
>   if (r)
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> index a22b45c92792..87d5e4c21cb3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> @@ -2701,8 +2701,6 @@ static int dce_v8_0_sw_init(void *handle)
>  
>   adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
>  
> - adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
> -
>   r = amdgpu_display_modeset_create_props(adev);
>   if (r)
>   return r;
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index c053cb79cd06..0db2a88cd4d7 100644
> --- a/drivers/gpu/drm/amd/display/amdg

Re: [PATCH v2 4/7] drm/simpledrm: Add support for system memory framebuffers

[Thierry Reding]

On Tue, Oct 18, 2022 at 01:58:53PM +0200, Thomas Zimmermann wrote:
> Hi Thierry
> 
> Am 17.10.22 um 16:54 schrieb Thierry Reding:
> > On Mon, Oct 10, 2022 at 10:12:34AM +0200, Thomas Zimmermann wrote:
> [...]
> > > 
> > > That whole 'Memory Manangement' block is will be unmaintainable. Before I 
> > > go
> > > into a detailed review, please see my questions about the reservedmem code
> > > at the end of the patch.
> > 
> > It looks reasonably maintainable to me. Given that we only have __iomem
> > and non-__iomem cases, this is about the extent of the complexity that
> > could ever be added.
> 
> I think we should split the detection and usage, as the driver does with
> other properties. It would fit better into the driver's overall design. I'll
> send out another email with a review to illustrate what I have in mind.

Okay, great.

> > > >/*
> > > > * Modesetting
> > > > */
> > > > @@ -491,15 +594,15 @@ static void 
> > > > simpledrm_primary_plane_helper_atomic_update(struct drm_plane *plane
> > > > drm_atomic_helper_damage_iter_init(&iter, old_plane_state, 
> > > > plane_state);
> > > > drm_atomic_for_each_plane_damage(&iter, &damage) {
> > > > -   struct iosys_map dst = 
> > > > IOSYS_MAP_INIT_VADDR(sdev->screen_base);
> > > > struct drm_rect dst_clip = plane_state->dst;
> > > > if (!drm_rect_intersect(&dst_clip, &damage))
> > > > continue;
> > > > -   iosys_map_incr(&dst, drm_fb_clip_offset(sdev->pitch, 
> > > > sdev->format, &dst_clip));
> > > > -   drm_fb_blit(&dst, &sdev->pitch, sdev->format->format, 
> > > > shadow_plane_state->data, fb,
> > > > -   &damage);
> > > > +   iosys_map_incr(&sdev->screen_base, 
> > > > drm_fb_clip_offset(sdev->pitch, sdev->format,
> > > > + 
> > > > &dst_clip));
> > > 
> > > You'll modify screen_base and it'll eventually blow up. You have to keep
> > > initializing the dst variable within the loop.
> > > 
> > > > +   drm_fb_blit(&sdev->screen_base, &sdev->pitch, 
> > > > sdev->format->format,
> > > > +   shadow_plane_state->data, fb, &damage);
> > > > }
> > > > drm_dev_exit(idx);
> > > > @@ -518,7 +621,7 @@ static void 
> > > > simpledrm_primary_plane_helper_atomic_disable(struct drm_plane *plan
> > > > return;
> > > > /* Clear screen to black if disabled */
> > > > -   memset_io(sdev->screen_base, 0, sdev->pitch * 
> > > > sdev->mode.vdisplay);
> > > > +   iosys_map_memset(&sdev->screen_base, 0, 0, sdev->pitch * 
> > > > sdev->mode.vdisplay);
> > > > drm_dev_exit(idx);
> > > >}
> > > > @@ -635,8 +738,6 @@ static struct simpledrm_device 
> > > > *simpledrm_device_create(struct drm_driver *drv,
> > > > struct drm_device *dev;
> > > > int width, height, stride;
> > > > const struct drm_format_info *format;
> > > > -   struct resource *res, *mem;
> > > > -   void __iomem *screen_base;
> > > > struct drm_plane *primary_plane;
> > > > struct drm_crtc *crtc;
> > > > struct drm_encoder *encoder;
> > > > @@ -706,35 +807,9 @@ static struct simpledrm_device 
> > > > *simpledrm_device_create(struct drm_driver *drv,
> > > > drm_dbg(dev, "framebuffer format=%p4cc, size=%dx%d, stride=%d 
> > > > byte\n",
> > > > &format->format, width, height, stride);
> > > > -   /*
> > > > -* Memory management
> > > > -*/
> > > > -
> > > > -   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > > > -   if (!res)
> > > > -   return ERR_PTR(-EINVAL);
> > > > -
> > > > -   ret = devm_aperture_acquire_from_firmware(dev, res->start, 
> > > > resource_size(res));
> > > > -   if (ret) {
> > > > -   drm_err(dev, "could not acquire memory range %pr: error 
> > > > %d\n", res, ret);
> > > > +   ret = simpledrm_device_init_mm(sdev);
> > > > +   if (ret)
> > > > return ERR_PTR(ret);
> > > > -   }
> > > > -
> > > > -   mem = devm_request_mem_region(&pdev->dev, res->start, 
> > > > resource_size(res), drv->name);
> > > > -   if (!mem) {
> > > > -   /*
> > > > -* We cannot make this fatal. Sometimes this comes from 
> > > > magic
> > > > -* spaces our resource handlers simply don't know 
> > > > about. Use
> > > > -* the I/O-memory resource as-is and try to map that 
> > > > instead.
> > > > -*/
> > > > -   drm_warn(dev, "could not acquire memory region %pr\n", 
> > > > res);
> > > > -   mem = res;
> > > > -   }
> > > > -
> > > > -   screen_base = devm_ioremap_wc(&pdev->dev, mem->start, 
> > > > resource_size(mem));
> > > > -   if (!screen_base)
> > > > -   return ERR_PTR(-ENOMEM);
> > > > -   s

Re: [PATCH 1/2] drm/sched: add DRM_SCHED_FENCE_DONT_PIPELINE flag

[Christian König]

Gentle ping to others to get this reviewed.

Alex, this is fixing the TLB flush errors and I think we need to get it 
into -fixes ASAP.


Christian.

Am 14.10.22 um 10:15 schrieb Christian König:

Setting this flag on a scheduler fence prevents pipelining of jobs
depending on this fence. In other words we always insert a full CPU
round trip before dependen jobs are pushed to the pipeline.

Signed-off-by: Christian König 
CC: sta...@vger.kernel.org # 5.19+
---
  drivers/gpu/drm/scheduler/sched_entity.c | 3 ++-
  include/drm/gpu_scheduler.h  | 9 +
  2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/scheduler/sched_entity.c 
b/drivers/gpu/drm/scheduler/sched_entity.c
index 191c56064f19..43d337d8b153 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -385,7 +385,8 @@ static bool drm_sched_entity_add_dependency_cb(struct 
drm_sched_entity *entity)
}
  
  	s_fence = to_drm_sched_fence(fence);

-   if (s_fence && s_fence->sched == sched) {
+   if (s_fence && s_fence->sched == sched &&
+   !test_bit(DRM_SCHED_FENCE_DONT_PIPELINE, &fence->flags)) {
  
  		/*

 * Fence is from the same scheduler, only need to wait for
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index 0fca8f38bee4..f01d14b231ed 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -32,6 +32,15 @@
  
  #define MAX_WAIT_SCHED_ENTITY_Q_EMPTY msecs_to_jiffies(1000)
  
+/**

+ * DRM_SCHED_FENCE_DONT_PIPELINE - Prefent dependency pipelining
+ *
+ * Setting this flag on a scheduler fence prevents pipelining of jobs depending
+ * on this fence. In other words we always insert a full CPU round trip before
+ * dependen jobs are pushed to the hw queue.
+ */
+#define DRM_SCHED_FENCE_DONT_PIPELINE  DMA_FENCE_FLAG_USER_BITS
+
  struct drm_gem_object;
  
  struct drm_gpu_scheduler;

Re: [PATCH v2 0/2] drm/rockchip: dw_hdmi: Add 4k@30 support

[Dan Johansen]

Den 05.10.2022 kl. 13.10 skrev Sascha Hauer:

On Wed, Oct 05, 2022 at 12:51:57PM +0200, Dan Johansen wrote:

Den 05.10.2022 kl. 12.06 skrev Sascha Hauer:

On Wed, Sep 28, 2022 at 10:39:27AM +0200, Dan Johansen wrote:

Den 28.09.2022 kl. 10.37 skrev Sascha Hauer:

On Tue, Sep 27, 2022 at 07:53:54PM +0200, Dan Johansen wrote:

Den 26.09.2022 kl. 12.30 skrev Michael Riesch:

Hi Sascha,

On 9/26/22 10:04, Sascha Hauer wrote:

This series adds support for 4k@30 to the rockchip HDMI controller. This
has been tested on a rk3568 rock3a board. It should be possible to add
4k@60 support the same way, but it doesn't work for me, so let's add
4k@30 as a first step.

 Sascha

Changes since v1:
- Allow non standard clock rates only on Synopsys phy as suggested by
  Robin Murphy

Sascha Hauer (2):
  drm/rockchip: dw_hdmi: relax mode_valid hook
  drm/rockchip: dw_hdmi: Add support for 4k@30 resolution

 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 34 -
 1 file changed, 27 insertions(+), 7 deletions(-)

Thanks for the v2! On a RK3568 EVB1 with a HP 27f 4k monitor

Tested-by: Michael Riesch 

Sadly this still doesn't give my display out on my 2k monitor. Not even just
1080p picture like the old current implementation does.

By "like the old current implementation" you mean that this patchset
introduces a regression for you?

Yes. What currently in the kernel at least shows as 1080p on my 2K monitor,
while this patchset turns off the screen.

Which SoC are you testing this on? I assume RK3568, right? Which patch
introduces that regression, the first or the second one?

I tested on the Odroid M, which is rk3568.
I have only applied them both, as I was under the impression that both are
needed for the 4k support.

Yes, both I needed, but I am interested which one introduces the
regression as I can't reproduce it.


Okay. Here's the result of some more tests of mine.

Patch 1 by itself does not introduce any regressions on either 1080p or 
2k monitors.


Patch 2 by itself does not introduce any regressions on either 1080p or 
2k monitors.


Applying both Patch 1 and 2, _does_ introduce the regression on my 2k 
monitor, but _not_ on my 1080p monitor.


The 2k monitor is a Dell P2418D with up to 2560x1440 resolution.

The 1080p monitor is a Sony Bravia 46" TV with up to 1920x1080 resolution.



Sascha


--
Kind regards
*Dan Johansen*
Project lead of the *Manjaro ARM* project
Manjaro-ARM 

Re: logging:convert dev_info to drm_info

[Thomas Zimmermann]

Hi

Am 18.10.22 um 09:20 schrieb jianengchencool:

Hi,
I want to convert logging dev_info/warn/err to drm_info/warn/err 
  in drivers/gpu/drm/pl111, so I want to ask if this work will be merged？

Thanks!


Well, just send the patches for review.

Best regards
Thomas




TODO list below：


Convert logging to drm_* functions with drm_device paramater¶



For drivers which could have multiple instances, it is necessary to 
differentiate between which is which in the logs. Since 
DRM_INFO/WARN/ERROR don’t do this, drivers used dev_info/warn/err to 
make this differentiation. We now have drm_* variants of the drm print 
functions, so we can start to convert those drivers back to using 
drm-formatted specific log messages.


Before you start this conversion please contact the relevant maintainers 
to make sure your work will be merged - not everyone agrees that the DRM 
dmesg macros are better.




Neil
jianengchenc...@gmail.com




--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH] drm: Remove drm_mode_config::fb_base

[Christian König]

Am 18.10.22 um 15:17 schrieb Zack Rusin:

From: Zack Rusin 

The fb_base in struct drm_mode_config has been unused for a long time.
Some drivers set it and some don't leading to a very confusing state
where the variable can't be relied upon, because there's no indication
as to which driver sets it and which doesn't.

The only usage of fb_base is internal to two drivers so instead of trying
to force it into all the drivers to get it into a coherent state
completely remove it.

Signed-off-by: Zack Rusin 


Since that address is completely driver specific to begin with it 
doesn't make to much sense to keep it int a common structure anyway.


Acked-by: Christian König 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c  | 2 --
  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 --
  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 --
  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 1 -
  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 --
  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 --
  drivers/gpu/drm/ast/ast_mode.c| 1 -
  drivers/gpu/drm/gma500/framebuffer.c  | 6 +++---
  drivers/gpu/drm/gma500/psb_drv.h  | 1 +
  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c   | 1 -
  drivers/gpu/drm/mgag200/mgag200_mode.c| 1 -
  drivers/gpu/drm/msm/msm_fbdev.c   | 2 --
  drivers/gpu/drm/nouveau/nouveau_display.c | 1 -
  drivers/gpu/drm/nouveau/nv04_fbcon.c  | 6 --
  drivers/gpu/drm/omapdrm/omap_fbdev.c  | 2 --
  drivers/gpu/drm/qxl/qxl_display.c | 2 --
  drivers/gpu/drm/radeon/radeon_display.c   | 2 --
  drivers/gpu/drm/radeon/radeon_fb.c| 1 -
  drivers/gpu/drm/tegra/fb.c| 1 -
  drivers/gpu/drm/tiny/bochs.c  | 1 -
  include/drm/drm_mode_config.h | 2 --
  21 files changed, 8 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
index f4b5301ea2a0..09dec2561adf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
@@ -498,8 +498,6 @@ static int amdgpu_vkms_sw_init(void *handle)
adev_to_drm(adev)->mode_config.preferred_depth = 24;
adev_to_drm(adev)->mode_config.prefer_shadow = 1;
  
-	adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;

-
r = amdgpu_display_modeset_create_props(adev);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index 288fce7dc0ed..05051d5d2ec3 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -2800,8 +2800,6 @@ static int dce_v10_0_sw_init(void *handle)
  
  	adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
  
-	adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;

-
r = amdgpu_display_modeset_create_props(adev);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index cbe5250b31cb..c928bc9eb202 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -2918,8 +2918,6 @@ static int dce_v11_0_sw_init(void *handle)
  
  	adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
  
-	adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;

-
r = amdgpu_display_modeset_create_props(adev);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
index b1c44fab074f..62315fd5a05f 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
@@ -2675,7 +2675,6 @@ static int dce_v6_0_sw_init(void *handle)
adev_to_drm(adev)->mode_config.preferred_depth = 24;
adev_to_drm(adev)->mode_config.prefer_shadow = 1;
adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
-   adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
  
  	r = amdgpu_display_modeset_create_props(adev);

if (r)
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index a22b45c92792..87d5e4c21cb3 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -2701,8 +2701,6 @@ static int dce_v8_0_sw_init(void *handle)
  
  	adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
  
-	adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;

-
r = amdgpu_display_modeset_create_props(adev);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index c053cb79cd06..0db2a88cd4d7 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgp

Re: [PATCH v2] drm/mgag200: Fix PLL setup for G200_SE_A rev >=4

[Jocelyn Falempe]

I just pushed it to drm-misc-next.

I also fixed the commit message a bit, the commit moving this line of 
code is in fact:


commit 877507bb954e ("drm/mgag200: Provide per-device callbacks for 
PIXPLLC")


Best Regards

--

Jocelyn

On 13/10/2022 15:55, Thomas Zimmermann wrote:



Am 13.10.22 um 15:28 schrieb Jocelyn Falempe:

For G200_SE_A, PLL M setting is wrong, which leads to blank screen,
or "signal out of range" on VGA display.
previous code had "m |= 0x80" which was changed to
m |= ((pixpllcn & BIT(8)) >> 1);

Tested on G200_SE_A rev 42

This line of code was moved to another file with
commit 85397f6bc4ff ("drm/mgag200: Initialize each model in separate
function") but can be easily backported before this commit.

v2: * put BIT(7) First to respect MSB-to-LSB (Thomas)
 * Add a comment to explain that this bit must be set (Thomas)

Fixes: 2dd040946ecf ("drm/mgag200: Store values (not bits) in struct 
mgag200_pll_values")

Cc: sta...@vger.kernel.org
Signed-off-by: Jocelyn Falempe 


Reviewed-by: Thomas Zimmermann 


---
  drivers/gpu/drm/mgag200/mgag200_g200se.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_g200se.c 
b/drivers/gpu/drm/mgag200/mgag200_g200se.c

index be389ed91cbd..bd6e573c9a1a 100644
--- a/drivers/gpu/drm/mgag200/mgag200_g200se.c
+++ b/drivers/gpu/drm/mgag200/mgag200_g200se.c
@@ -284,7 +284,8 @@ static void 
mgag200_g200se_04_pixpllc_atomic_update(struct drm_crtc *crtc,

  pixpllcp = pixpllc->p - 1;
  pixpllcs = pixpllc->s;
-    xpixpllcm = pixpllcm | ((pixpllcn & BIT(8)) >> 1);
+    // For G200SE A, BIT(7) should be set unconditionally.
+    xpixpllcm = BIT(7) | pixpllcm;
  xpixpllcn = pixpllcn;
  xpixpllcp = (pixpllcs << 3) | pixpllcp;

Re: [Intel-gfx] [PATCH v3 09/17] drm/i915/vm_bind: Add out fence support

[Matthew Auld]

On 14/10/2022 07:48, Niranjana Vishwanathapura wrote:

On Sun, Oct 09, 2022 at 11:58:18PM -0700, Niranjana Vishwanathapura wrote:

Add support for handling out fence for vm_bind call.

v2: Reset vma->vm_bind_fence.syncobj to NULL at the end
   of vm_bind call.

Signed-off-by: Niranjana Vishwanathapura 


Signed-off-by: Andi Shyti 
---
drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h   |  4 +
.../drm/i915/gem/i915_gem_vm_bind_object.c    | 82 +++
drivers/gpu/drm/i915/i915_vma.c   |  7 +-
drivers/gpu/drm/i915/i915_vma_types.h |  7 ++
include/uapi/drm/i915_drm.h   | 63 +-
5 files changed, 158 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h

index 36262a6357b5..b70e900e35ab 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
@@ -8,6 +8,7 @@

#include 

+struct dma_fence;
struct drm_device;
struct drm_file;
struct i915_address_space;
@@ -23,4 +24,7 @@ int i915_gem_vm_unbind_ioctl(struct drm_device *dev, 
void *data,


void i915_gem_vm_unbind_all(struct i915_address_space *vm);

+void i915_vm_bind_signal_fence(struct i915_vma *vma,
+   struct dma_fence * const fence);
+
#endif /* __I915_GEM_VM_BIND_H */
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c

index c435d49af2c8..526d3a6bf671 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -7,6 +7,8 @@

#include 

+#include 
+
#include "gem/i915_gem_context.h"
#include "gem/i915_gem_vm_bind.h"

@@ -100,6 +102,76 @@ static void i915_gem_vm_bind_remove(struct 
i915_vma *vma, bool release_obj)

    i915_gem_object_put(vma->obj);
}

+static int i915_vm_bind_add_fence(struct drm_file *file, struct 
i915_vma *vma,

+  u32 handle, u64 point)
+{
+    struct drm_syncobj *syncobj;
+
+    syncobj = drm_syncobj_find(file, handle);
+    if (!syncobj) {
+    DRM_DEBUG("Invalid syncobj handle provided\n");
+    return -ENOENT;
+    }
+
+    /*
+ * For timeline syncobjs we need to preallocate chains for
+ * later signaling.
+ */
+    if (point) {
+    vma->vm_bind_fence.chain_fence = dma_fence_chain_alloc();
+    if (!vma->vm_bind_fence.chain_fence) {
+    drm_syncobj_put(syncobj);
+    return -ENOMEM;
+    }
+    } else {
+    vma->vm_bind_fence.chain_fence = NULL;
+    }
+    vma->vm_bind_fence.syncobj = syncobj;
+    vma->vm_bind_fence.value = point;
+
+    return 0;
+}
+
+static void i915_vm_bind_put_fence(struct i915_vma *vma)
+{
+    if (!vma->vm_bind_fence.syncobj)
+    return;
+
+    drm_syncobj_put(vma->vm_bind_fence.syncobj);
+    dma_fence_chain_free(vma->vm_bind_fence.chain_fence);
+    vma->vm_bind_fence.syncobj = NULL;
+}
+
+/**
+ * i915_vm_bind_signal_fence() - Add fence to vm_bind syncobj
+ * @vma: vma mapping requiring signaling
+ * @fence: fence to be added
+ *
+ * Associate specified @fence with the @vma's syncobj to be
+ * signaled after the @fence work completes.
+ */
+void i915_vm_bind_signal_fence(struct i915_vma *vma,
+   struct dma_fence * const fence)
+{
+    struct drm_syncobj *syncobj = vma->vm_bind_fence.syncobj;
+
+    if (!syncobj)
+    return;
+
+    if (vma->vm_bind_fence.chain_fence) {
+    drm_syncobj_add_point(syncobj,
+  vma->vm_bind_fence.chain_fence,
+  fence, vma->vm_bind_fence.value);
+    /*
+ * The chain's ownership is transferred to the
+ * timeline.
+ */
+    vma->vm_bind_fence.chain_fence = NULL;
+    } else {
+    drm_syncobj_replace_fence(syncobj, fence);
+    }
+}
+
static int i915_gem_vm_unbind_vma(struct i915_address_space *vm,
  struct drm_i915_gem_vm_unbind *va)
{
@@ -237,6 +309,13 @@ static int i915_gem_vm_bind_obj(struct 
i915_address_space *vm,

    goto unlock_vm;
}

+    if (va->fence.flags & I915_TIMELINE_FENCE_SIGNAL) {
+    ret = i915_vm_bind_add_fence(file, vma, va->fence.handle,
+ va->fence.value);
+    if (ret)
+    goto put_vma;
+    }
+
pin_flags = va->start | PIN_OFFSET_FIXED | PIN_USER | PIN_VALIDATE;

for_i915_gem_ww(&ww, ret, true) {
@@ -258,6 +337,9 @@ static int i915_gem_vm_bind_obj(struct 
i915_address_space *vm,

    i915_gem_object_get(vma->obj);
}

+    if (va->fence.flags & I915_TIMELINE_FENCE_SIGNAL)
+    i915_vm_bind_put_fence(vma);
+put_vma:
if (ret)
    i915_vma_destroy(vma);
unlock_vm:
diff --git a/drivers/gpu/drm/i915/i915_vma.c 
b/drivers/gpu/drm/i915/i915_vma.c

index 88c09e885fec..cb8e718ec46e 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -29,6 +29,7 @@
#include "display/intel_frontbuffer.h"
#include "gem/i915_gem_lmem.h"
#include "gem/i915_ge

Re: i915 "GPU HANG", bisected to a2daa27c0c61 "swiotlb: simplify swiotlb_max_segment"

[Juergen Gross]

On 18.10.22 16:33, Christoph Hellwig wrote:

On Tue, Oct 18, 2022 at 04:21:43PM +0200, Jan Beulich wrote:

Leaving the "i915 abuses" part aside (because I can't tell what exactly the
abuse is), but assuming that "can't cope with bounce buffering" means they
don't actually use the allocated buffers, I'd suggest this:


Except for one odd place i915 never uses dma_alloc_* but always allocates
memory itself and then maps it, but then treats it as if it was a
dma_alloc_coherent allocations, that is never does ownership changes.


I've dropped the TDX related remark because I don't think it's meaningful
for PV guests.


This remark is for TDX in general, not Xen related.  With TDX and other
confidentatial computing schemes, all DMA must be bounce buffered, and
all drivers skipping dma_sync* calls are broken.


Otoh I've left the "abuses ignores" word sequence as is, no
matter that it reads odd to me. Plus, as hinted at before, I'm not
convinced the IS_ENABLED() use is actually necessary or warranted here.


If we don't need the IS_ENABLED is not needed I'm all for dropping it.
But unless I misread the code, on arm/arm64 even PV guests are 1:1
mapped so that all Linux physically contigous memory also is Xen
contigous, so we don't need the hack.


There are no PV guests on arm/arm64.


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: i915 "GPU HANG", bisected to a2daa27c0c61 "swiotlb: simplify swiotlb_max_segment"

[Jan Beulich]

On 18.10.2022 13:02, Christoph Hellwig wrote:
> On Tue, Oct 18, 2022 at 10:57:37AM +0200, Jan Beulich wrote:
>> Shouldn't this then be xen_pv_domain() that you use here, and - if you
>> really want IS_ENABLED() in addition - CONFIG_XEN_PV?
> 
> I'll need help from people that understand Xen better than me what
> the exact conditions (and maybe also comments are).

Leaving the "i915 abuses" part aside (because I can't tell what exactly the
abuse is), but assuming that "can't cope with bounce buffering" means they
don't actually use the allocated buffers, I'd suggest this:

/*
 * For Xen PV guests pages aren't contiguous in DMA (machine) address
 * space.  The DMA API takes care of that both in dma_alloc_* (by
 * calling into the hypervisor to make the pages contiguous) and in
 * dma_map_* (by bounce buffering).  But i915 abuses ignores the
 * coherency aspects of the DMA API and thus can't cope with bounce
 * buffering actually happening, so add a hack here to force small
 * allocations and mappings when running in PV mode on Xen.
 */
if (IS_ENABLED(CONFIG_XEN_PV) && xen_pv_domain())
max = PAGE_SIZE;

I've dropped the TDX related remark because I don't think it's meaningful
for PV guests. Otoh I've left the "abuses ignores" word sequence as is, no
matter that it reads odd to me. Plus, as hinted at before, I'm not
convinced the IS_ENABLED() use is actually necessary or warranted here.

Jan

Re: [PATCH] drm: Remove drm_mode_config::fb_base

[Thomas Zimmermann]

Hi

Am 18.10.22 um 15:17 schrieb Zack Rusin:

From: Zack Rusin 

The fb_base in struct drm_mode_config has been unused for a long time.
Some drivers set it and some don't leading to a very confusing state
where the variable can't be relied upon, because there's no indication
as to which driver sets it and which doesn't.

The only usage of fb_base is internal to two drivers so instead of trying
to force it into all the drivers to get it into a coherent state
completely remove it.


Thanks a lot. I wanted to remove that field for some time. Pleaser see 
my comments below.




Signed-off-by: Zack Rusin 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c  | 2 --
  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 --
  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 --
  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 1 -
  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 --
  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 --
  drivers/gpu/drm/ast/ast_mode.c| 1 -
  drivers/gpu/drm/gma500/framebuffer.c  | 6 +++---
  drivers/gpu/drm/gma500/psb_drv.h  | 1 +
  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c   | 1 -
  drivers/gpu/drm/mgag200/mgag200_mode.c| 1 -
  drivers/gpu/drm/msm/msm_fbdev.c   | 2 --
  drivers/gpu/drm/nouveau/nouveau_display.c | 1 -
  drivers/gpu/drm/nouveau/nv04_fbcon.c  | 6 --
  drivers/gpu/drm/omapdrm/omap_fbdev.c  | 2 --
  drivers/gpu/drm/qxl/qxl_display.c | 2 --
  drivers/gpu/drm/radeon/radeon_display.c   | 2 --
  drivers/gpu/drm/radeon/radeon_fb.c| 1 -
  drivers/gpu/drm/tegra/fb.c| 1 -
  drivers/gpu/drm/tiny/bochs.c  | 1 -
  include/drm/drm_mode_config.h | 2 --
  21 files changed, 8 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
index f4b5301ea2a0..09dec2561adf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
@@ -498,8 +498,6 @@ static int amdgpu_vkms_sw_init(void *handle)
adev_to_drm(adev)->mode_config.preferred_depth = 24;
adev_to_drm(adev)->mode_config.prefer_shadow = 1;
  
-	adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;

-
r = amdgpu_display_modeset_create_props(adev);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index 288fce7dc0ed..05051d5d2ec3 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -2800,8 +2800,6 @@ static int dce_v10_0_sw_init(void *handle)
  
  	adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
  
-	adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;

-
r = amdgpu_display_modeset_create_props(adev);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index cbe5250b31cb..c928bc9eb202 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -2918,8 +2918,6 @@ static int dce_v11_0_sw_init(void *handle)
  
  	adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
  
-	adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;

-
r = amdgpu_display_modeset_create_props(adev);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
index b1c44fab074f..62315fd5a05f 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
@@ -2675,7 +2675,6 @@ static int dce_v6_0_sw_init(void *handle)
adev_to_drm(adev)->mode_config.preferred_depth = 24;
adev_to_drm(adev)->mode_config.prefer_shadow = 1;
adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
-   adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
  
  	r = amdgpu_display_modeset_create_props(adev);

if (r)
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index a22b45c92792..87d5e4c21cb3 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -2701,8 +2701,6 @@ static int dce_v8_0_sw_init(void *handle)
  
  	adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
  
-	adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;

-
r = amdgpu_display_modeset_create_props(adev);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index c053cb79cd06..0db2a88cd4d7 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -3816,8 +3816,6 @@ static int amdgpu_dm_mode_conf

Re: Build regressions/improvements in v6.1-rc1

[Maciej W. Rozycki]

Hi Geert,

> > > .> [1] 
> > > http://kisskb.ellerman.id.au/kisskb/branch/linus/head/9abf2313adc1ca1b6180c508c25f22f9395cc780/
> > >  (all 149 configs)
> 
> > > >  + {standard input}: Error: branch to a symbol in another ISA mode: 
> > > > 1339 =>
> > > > 2616, 2621
> > >
> > > mips-gcc11/micro32r2_defconfig
> > > mips-gcc11/micro32r2el_defconfig
> >
> >  Where can these configs be obtained from?
> 
> By following the links in the URL above you removed while replying? ;-)
> 
> http://kisskb.ellerman.id.au/kisskb/buildresult/14818296/
> http://kisskb.ellerman.id.au/kisskb/buildresult/14818298/

 Thank you.

 The error message is due to the use of MT ASE code in a microMIPS 
compilation, specifically a handwritten machine instruction encoding via 
`.word' in `dmt' from .  A similar construct is made 
from `mftc0', but it isn't at a branch target, so no error is triggered.

 A `.insn' pseudo-op ought to precede such handwritten constructs to tell 
the assembler that what follows is really an instruction rather than data, 
which would then cause any preceding label to be correctly annotated.

 Now the MT ASE has been specified for the microMIPS ISA, but the machine 
instruction encodings are different, so merely adding `.insn' won't do any 
good.  Also we've never added support for the microMIPS MT ASE, and it's 
not clear to me if it's ever been used with real silicon.  Perhaps QEMU 
has it, but I suspect not.  Also no support has ever been added to 
binutils.

 So I think we want to just exclude the offending code from microMIPS 
configurations, perhaps by hardcoding `cpu_has_mipsmt' to 0 if 
CPU_MICROMIPS.

 On the other hand support for the MT ASE with the regular MIPS ISA has 
been added with binutils 2.17:

commit 61cc02671150a81ea68f25b8409b8ace18bda9ae
Author: Chao-ying Fu 
Date:   Tue Sep 6 18:46:57 2005 +

and according to Documentation/process/changes.rst we require version 2.23 
now.  So it looks to me like we want to discard the handwritten hacks and 
use proper assembly instruction mnemonics.  I do believe we did this for 
the DSP ASE already.

  Maciej

[PATCH] drm: Remove drm_mode_config::fb_base

[Zack Rusin]

From: Zack Rusin 

The fb_base in struct drm_mode_config has been unused for a long time.
Some drivers set it and some don't leading to a very confusing state
where the variable can't be relied upon, because there's no indication
as to which driver sets it and which doesn't.

The only usage of fb_base is internal to two drivers so instead of trying
to force it into all the drivers to get it into a coherent state
completely remove it.

Signed-off-by: Zack Rusin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c  | 2 --
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 --
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 --
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 1 -
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 --
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 --
 drivers/gpu/drm/ast/ast_mode.c| 1 -
 drivers/gpu/drm/gma500/framebuffer.c  | 6 +++---
 drivers/gpu/drm/gma500/psb_drv.h  | 1 +
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c   | 1 -
 drivers/gpu/drm/mgag200/mgag200_mode.c| 1 -
 drivers/gpu/drm/msm/msm_fbdev.c   | 2 --
 drivers/gpu/drm/nouveau/nouveau_display.c | 1 -
 drivers/gpu/drm/nouveau/nv04_fbcon.c  | 6 --
 drivers/gpu/drm/omapdrm/omap_fbdev.c  | 2 --
 drivers/gpu/drm/qxl/qxl_display.c | 2 --
 drivers/gpu/drm/radeon/radeon_display.c   | 2 --
 drivers/gpu/drm/radeon/radeon_fb.c| 1 -
 drivers/gpu/drm/tegra/fb.c| 1 -
 drivers/gpu/drm/tiny/bochs.c  | 1 -
 include/drm/drm_mode_config.h | 2 --
 21 files changed, 8 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
index f4b5301ea2a0..09dec2561adf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
@@ -498,8 +498,6 @@ static int amdgpu_vkms_sw_init(void *handle)
adev_to_drm(adev)->mode_config.preferred_depth = 24;
adev_to_drm(adev)->mode_config.prefer_shadow = 1;
 
-   adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
-
r = amdgpu_display_modeset_create_props(adev);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index 288fce7dc0ed..05051d5d2ec3 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -2800,8 +2800,6 @@ static int dce_v10_0_sw_init(void *handle)
 
adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
 
-   adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
-
r = amdgpu_display_modeset_create_props(adev);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index cbe5250b31cb..c928bc9eb202 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -2918,8 +2918,6 @@ static int dce_v11_0_sw_init(void *handle)
 
adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
 
-   adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
-
r = amdgpu_display_modeset_create_props(adev);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
index b1c44fab074f..62315fd5a05f 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
@@ -2675,7 +2675,6 @@ static int dce_v6_0_sw_init(void *handle)
adev_to_drm(adev)->mode_config.preferred_depth = 24;
adev_to_drm(adev)->mode_config.prefer_shadow = 1;
adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
-   adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
 
r = amdgpu_display_modeset_create_props(adev);
if (r)
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index a22b45c92792..87d5e4c21cb3 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -2701,8 +2701,6 @@ static int dce_v8_0_sw_init(void *handle)
 
adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
 
-   adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
-
r = amdgpu_display_modeset_create_props(adev);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index c053cb79cd06..0db2a88cd4d7 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -3816,8 +3816,6 @@ static int amdgpu_dm_mode_config_init(struct 
amdgpu_device *adev)
/* indicates support for immediate flip */
adev_to_drm(adev)->mode_config.async_p

Re: [PATCH v7 00/21] Move all drivers to a common dma-buf locking convention

[Dmitry Osipenko]

On 10/18/22 14:34, Christian König wrote:
> Am 18.10.22 um 01:07 schrieb Dmitry Osipenko:
>> On 10/17/22 20:22, Dmitry Osipenko wrote:
>>> Hello,
>>>
>>> This series moves all drivers to a dynamic dma-buf locking
>>> specification.
>>>  From now on all dma-buf importers are made responsible for holding
>>> dma-buf's reservation lock around all operations performed over dma-bufs
>>> in accordance to the locking specification. This allows us to utilize
>>> reservation lock more broadly around kernel without fearing of a
>>> potential
>>> deadlocks.
>>>
>>> This patchset passes all i915 selftests. It was also tested using
>>> VirtIO,
>>> Panfrost, Lima, Tegra, udmabuf, AMDGPU and Nouveau drivers. I tested
>>> cases
>>> of display+GPU, display+V4L and GPU+V4L dma-buf sharing (where
>>> appropriate),
>>> which covers majority of kernel drivers since rest of the drivers share
>>> same or similar code paths.
>>>
>>> Changelog:
>>>
>>> v7: - Rebased on top of recent drm-misc-next.
>>>
>>>  - Added ack from Jason Gunthorpe to the RDMA patch.
>>>
>>>  - Added iosys_map_clear() to dma_buf_vmap_unlocked(), making it
>>> fully
>>>    consistent with dma_buf_vmap().
>>>
>>> v6: - Added r-b from Michael Ruhl to the i915 patch.
>>>
>>>  - Added acks from Sumit Semwal and updated commit message of the
>>>    "Move dma_buf_vmap() to dynamic locking specification" patch like
>>>    was suggested by Sumit.
>>>
>>>  - Added "!dmabuf" check to dma_buf_vmap_unlocked() to match the
>>> locked
>>>    variant of the function, for consistency.
>>>
>>> v5: - Added acks and r-bs that were given to v4.
>>>
>>>  - Changed i915 preparation patch like was suggested by Michael
>>> Ruhl.
>>>    The scope of reservation locking is smaller now.
>>>
>>> v4: - Added dma_buf_mmap() to the "locking convention" documentation,
>>>    which was missed by accident in v3.
>>>
>>>  - Added acks from Christian König, Tomasz Figa and Hans Verkuil
>>> that
>>>    they gave to couple v3 patches.
>>>
>>>  - Dropped the "_unlocked" postfix from function names that don't
>>> have
>>>    the locked variant, as was requested by Christian König.
>>>
>>>  - Factored out the per-driver preparations into separate patches
>>>    to ease reviewing of the changes, which is now doable without the
>>>    global dma-buf functions renaming.
>>>
>>>  - Factored out the dynamic locking convention enforcements into
>>> separate
>>>    patches which add the final dma_resv_assert_held(dmabuf->resv)
>>> to the
>>>    dma-buf API functions.
>>>
>>> v3: - Factored out dma_buf_mmap_unlocked() and attachment functions
>>>    into aseparate patches, like was suggested by Christian König.
>>>
>>>  - Corrected and factored out dma-buf locking documentation into
>>>    a separate patch, like was suggested by Christian König.
>>>
>>>  - Intel driver dropped the reservation locking fews days ago from
>>>    its BO-release code path, but we need that locking for the
>>> imported
>>>    GEMs because in the end that code path unmaps the imported GEM.
>>>    So I added back the locking needed by the imported GEMs, updating
>>>    the "dma-buf attachment locking specification" patch
>>> appropriately.
>>>
>>>  - Tested Nouveau+Intel dma-buf import/export combo.
>>>
>>>  - Tested udmabuf import to i915/Nouveau/AMDGPU.
>>>
>>>  - Fixed few places in Etnaviv, Panfrost and Lima drivers that I
>>> missed
>>>    to switch to locked dma-buf vmapping in the drm/gem: Take
>>> reservation
>>>    lock for vmap/vunmap operations" patch. In a result
>>> invalidated the
>>>    Christian's r-b that he gave to v2.
>>>
>>>  - Added locked dma-buf vmap/vunmap functions that are needed for
>>> fixing
>>>    vmappping of Etnaviv, Panfrost and Lima drivers mentioned above.
>>>    I actually had this change stashed for the drm-shmem shrinker
>>> patchset,
>>>    but then realized that it's already needed by the dma-buf
>>> patches.
>>>    Also improved my tests to better cover these code paths.
>>>
>>> v2: - Changed locking specification to avoid problems with a
>>> cross-driver
>>>    ww locking, like was suggested by Christian König. Now the
>>> attach/detach
>>>    callbacks are invoked without the held lock and exporter
>>> should take the
>>>    lock.
>>>
>>>  - Added "locking convention" documentation that explains which
>>> dma-buf
>>>    functions and callbacks are locked/unlocked for importers and
>>> exporters,
>>>    which was requested by Christian König.
>>>
>>>  - Added ack from Tomasz Figa to the V4L patches that he gave to v1.
>>>
>>> Dmitry Osipenko (21):
>>>    dma-buf: Add unlocked variant of vmapping functions
>>>    dma-buf: Add unlocked variant of attachment-mapping functions
>>>    drm/gem: Take reservation lock for vmap/vunmap operations
>>>    drm/prime: Prepare to dynamic dma-buf locking specification
>>

Re: [PATCH v3] drm/sched: Fix kernel NULL pointer dereference error

[Christian König]

Am 18.10.22 um 14:20 schrieb Yadav, Arvind:

[SNIP]



+    drm_sched_fence_finished(s_fence);
+    dma_fence_put(&s_fence->finished);
+    wake_up_interruptible(&sched->wake_up_worker);
+}
+
+int drm_sched_fence_add_parent_cb(struct dma_fence *fence,
+  struct drm_sched_fence *s_fence)
+{
+    return dma_fence_add_callback(fence, &s_fence->cb,
+  drm_sched_job_done_cb);
+}
+
+bool drm_sched_fence_remove_parent_cb(struct drm_sched_fence *s_fence)
+{
+    return dma_fence_remove_callback(s_fence->parent,
+ &s_fence->cb);
+}


Do we really need separate functions for that?

We can use  'drm_sched_fence_set_parent' but we need to add extra NULL 
check before


adding in the callback otherwise add-callback will throw the warning 
message every time.


If I add NULL check then will never get any callback warning message 
for setting NULL parent fence.


So I have kept separate functions.


I rather prefer having a single function and allowing the parent fence 
to be set to NULL.


Alternatively we could have a drm_sched_fence_set_parent() and 
drm_sched_fence_clear_parent() function if you really think it's cleaner 
that way.



atomic_dec(&sched->hw_rq_count);
@@ -576,15 +562,14 @@ void drm_sched_start(struct drm_gpu_scheduler 
*sched, bool full_recovery)

  continue;
    if (fence) {
-    r = dma_fence_add_callback(fence, &s_job->cb,
-   drm_sched_job_done_cb);
+    r = drm_sched_fence_add_parent_cb(fence, s_job->s_fence);
  if (r == -ENOENT)
-    drm_sched_job_done(s_job);
+    drm_sched_job_done(s_job->s_fence);
  else if (r)
  DRM_DEV_ERROR(sched->dev, "fence add callback 
failed (%d)\n",


Completely nuke that here. All of this should be done in the single 
drm_sched_fence_set_parent() function.


And an error message is completely superfluous. We just need to 
handle the case that the callback can't be installed because the 
fence is already signaled.


I will do the changes as per your review comments, Thank you for the 
review.


Just to clarify, you should nuke the error message. Error handling is 
rather pointless here.


Thanks,
Christian.



Thanks,

~Arvind


Regards,
Christian.


    r);
  } else
-    drm_sched_job_done(s_job);
+    drm_sched_job_done(s_job->s_fence);
  }
    if (full_recovery) {
@@ -1049,14 +1034,9 @@ static int drm_sched_main(void *param)
  drm_sched_fence_scheduled(s_fence);
    if (!IS_ERR_OR_NULL(fence)) {
-    s_fence->parent = dma_fence_get(fence);
-    /* Drop for original kref_init of the fence */
-    dma_fence_put(fence);
-
-    r = dma_fence_add_callback(fence, &sched_job->cb,
-   drm_sched_job_done_cb);
+    r = drm_sched_fence_set_parent(fence, s_fence);
  if (r == -ENOENT)
-    drm_sched_job_done(sched_job);
+    drm_sched_job_done(s_fence);
  else if (r)
  DRM_DEV_ERROR(sched->dev, "fence add callback 
failed (%d)\n",

    r);
@@ -1064,7 +1044,7 @@ static int drm_sched_main(void *param)
  if (IS_ERR(fence))
dma_fence_set_error(&s_fence->finished, PTR_ERR(fence));
  -    drm_sched_job_done(sched_job);
+    drm_sched_job_done(s_fence);
  }
    wake_up(&sched->job_scheduled);
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index 1f7d9dd1a444..7258e2fa195f 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -281,6 +281,10 @@ struct drm_sched_fence {
   * @owner: job owner for debugging
   */
  void    *owner;
+    /**
+ * @cb: callback
+ */
+    struct dma_fence_cb cb;
  };
    struct drm_sched_fence *to_drm_sched_fence(struct dma_fence *f);
@@ -300,7 +304,6 @@ struct drm_sched_fence 
*to_drm_sched_fence(struct dma_fence *f);

   * be scheduled further.
   * @s_priority: the priority of the job.
   * @entity: the entity to which this job belongs.
- * @cb: the callback for the parent fence in s_fence.
   *
   * A job is created by the driver using drm_sched_job_init(), and
   * should call drm_sched_entity_push_job() once it wants the 
scheduler

@@ -325,7 +328,6 @@ struct drm_sched_job {
  atomic_t    karma;
  enum drm_sched_priority    s_priority;
  struct drm_sched_entity *entity;
-    struct dma_fence_cb    cb;
  /**
   * @dependencies:
   *
@@ -559,6 +561,12 @@ void drm_sched_fence_free(struct 
drm_sched_fence *fence);

  void drm_sched_fence_scheduled(struct drm_sched_fence *fence);
  void drm_sched_fence_finished(struct drm_sched_fence *fence);
  +int drm_sched_fence_add_parent_cb(struct dma_fence *fence,
+  struct drm_sched_fence *s_fence);
+bool drm_sched_fence_remove

Re: Build regressions/improvements in v6.1-rc1

[Geert Uytterhoeven]

Hi Maciej,

On Tue, Oct 18, 2022 at 12:39 PM Maciej W. Rozycki  wrote:
> On Mon, 17 Oct 2022, Geert Uytterhoeven wrote:
> > .> [1] 
> > http://kisskb.ellerman.id.au/kisskb/branch/linus/head/9abf2313adc1ca1b6180c508c25f22f9395cc780/
> >  (all 149 configs)

> > >  + {standard input}: Error: branch to a symbol in another ISA mode: 1339 
> > > =>
> > > 2616, 2621
> >
> > mips-gcc11/micro32r2_defconfig
> > mips-gcc11/micro32r2el_defconfig
>
>  Where can these configs be obtained from?

By following the links in the URL above you removed while replying? ;-)

http://kisskb.ellerman.id.au/kisskb/buildresult/14818296/
http://kisskb.ellerman.id.au/kisskb/buildresult/14818298/

Thanks!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v5 12/22] drm/connector: Add a function to lookup a TV mode by its name

[Noralf Trønnes]

Den 18.10.2022 11.33, skrev Maxime Ripard:
> On Mon, Oct 17, 2022 at 12:44:45PM +0200, Noralf Trønnes wrote:
>> Den 13.10.2022 15.18, skrev Maxime Ripard:
>>> As part of the command line parsing rework coming in the next patches,
>>> we'll need to lookup drm_connector_tv_mode values by their name, already
>>> defined in drm_tv_mode_enum_list.
>>>
>>> In order to avoid any code duplication, let's do a function that will
>>> perform a lookup of a TV mode name and return its value.
>>>
>>> Signed-off-by: Maxime Ripard 
>>> ---
>>>  drivers/gpu/drm/drm_connector.c | 24 
>>>  include/drm/drm_connector.h |  2 ++
>>>  2 files changed, 26 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_connector.c 
>>> b/drivers/gpu/drm/drm_connector.c
>>> index 820f4c730b38..30611c616435 100644
>>> --- a/drivers/gpu/drm/drm_connector.c
>>> +++ b/drivers/gpu/drm/drm_connector.c
>>> @@ -991,6 +991,30 @@ static const struct drm_prop_enum_list 
>>> drm_tv_mode_enum_list[] = {
>>>  };
>>>  DRM_ENUM_NAME_FN(drm_get_tv_mode_name, drm_tv_mode_enum_list)
>>>  
>>> +/**
>>> + * drm_get_tv_mode_from_name - Translates a TV mode name into its enum 
>>> value
>>> + * @name: TV Mode name we want to convert
>>> + * @len: Length of @name
>>> + *
>>> + * Translates @name into an enum drm_connector_tv_mode.
>>> + *
>>> + * Returns: the enum value on success, a negative errno otherwise.
>>> + */
>>> +int drm_get_tv_mode_from_name(const char *name, size_t len)
>>
>> Do we really need to pass in length here? item->name has to always be
>> NUL terminated otherwise things would break elsewhere, so it shouldn't
>> be necessary AFAICS.
> 
> The only user so far is the command-line parsing code, and we might very
> well have an option after the tv_mode, something like
> 720x480i,tv_mode=NTSC,rotate=180
> 
> In this case, we won't get a NULL-terminated name.
> 

My point is that item->name will always be NUL terminated so strcmp()
will never look past that.

Noralf.

Re: [PATCH v3] drm/sched: Fix kernel NULL pointer dereference error

[Yadav, Arvind]

On 10/17/2022 8:20 PM, Christian König wrote:

Am 17.10.22 um 16:30 schrieb Arvind Yadav:

-This is purely a timing issue. Here, sometimes Job free
is happening before the job is done.
To fix this issue moving 'dma_fence_cb' callback from
job(struct drm_sched_job) to scheduler fence (struct drm_sched_fence).

- Added drm_sched_fence_set_parent() function(and others *_parent_cb)
in sched_fence.c. Moved parent fence intilization and callback
installation into this (this just cleanup).


BUG: kernel NULL pointer dereference, address: 0088
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x) - not-present page
  PGD 0 P4D 0
  Oops:  [#1] PREEMPT SMP NOPTI
  CPU: 2 PID: 0 Comm: swapper/2 Not tainted 6.0.0-rc2-custom #1
  Arvind : [dma_fence_default_wait _START] timeout = -1
  Hardware name: AMD Dibbler/Dibbler, BIOS RDB1107CC 09/26/2018
  RIP: 0010:drm_sched_job_done.isra.0+0x11/0x140 [gpu_sched]
  Code: 8b fe ff ff be 03 00 00 00 e8 7b da b7 e3 e9 d4 fe ff ff 66 
0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 41 55 41 54 49 89 fc 53 
<48> 8b 9f 88 00 00 00 f0 ff 8b f0 00 00 00 48 8b 83 80 01 00 00 f0

  RSP: 0018:b1b1801d4d38 EFLAGS: 00010087
  RAX: c0aa48b0 RBX: b1b1801d4d70 RCX: 0018
  RDX: 36c70afb7c1d RSI: 8a45ca413c60 RDI: 
  RBP: b1b1801d4d50 R08: 00b5 R09: 
  R10:  R11:  R12: 
  R13: b1b1801d4d70 R14: 8a45c416 R15: 8a45c416a708
  FS:  () GS:8a48a0a8() 
knlGS:

  CS:  0010 DS:  ES:  CR0: 80050033
  CR2: 0088 CR3: 00014ad5 CR4: 003506e0
  Call Trace:
   
   drm_sched_job_done_cb+0x12/0x20 [gpu_sched]
   dma_fence_signal_timestamp_locked+0x7e/0x110
   dma_fence_signal+0x31/0x60
   amdgpu_fence_process+0xc4/0x140 [amdgpu]
   gfx_v9_0_eop_irq+0x9d/0xd0 [amdgpu]
   amdgpu_irq_dispatch+0xb7/0x210 [amdgpu]
   amdgpu_ih_process+0x86/0x100 [amdgpu]
   amdgpu_irq_handler+0x24/0x60 [amdgpu]
   __handle_irq_event_percpu+0x4b/0x190
   handle_irq_event_percpu+0x15/0x50
   handle_irq_event+0x39/0x60
   handle_edge_irq+0xaf/0x210
   __common_interrupt+0x6e/0x110
   common_interrupt+0xc1/0xe0
   
   

Signed-off-by: Arvind Yadav 
---

Changes in v2: Moving 'dma_fence_cb' callback from
job(struct drm_sched_job) to scheduler fence(struct drm_sched_fence)
instead of adding NULL check for s_fence.

Changes in v3: Added drm_sched_fence_set_parent() function(and others 
*_parent_cb)

in sched_fence.c. Moved parent fence intilization and callback
installation into this (this just cleanup).

---
  drivers/gpu/drm/scheduler/sched_fence.c | 53 +
  drivers/gpu/drm/scheduler/sched_main.c  | 38 +-
  include/drm/gpu_scheduler.h | 12 +-
  3 files changed, 72 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/sched_fence.c 
b/drivers/gpu/drm/scheduler/sched_fence.c

index 7fd869520ef2..f6808f363261 100644
--- a/drivers/gpu/drm/scheduler/sched_fence.c
+++ b/drivers/gpu/drm/scheduler/sched_fence.c
@@ -77,6 +77,59 @@ static void drm_sched_fence_free_rcu(struct 
rcu_head *rcu)

  if (!WARN_ON_ONCE(!fence))
  kmem_cache_free(sched_fence_slab, fence);
  }


Please add an empty line here.

I will fix in the next version of patch.



+/**
+ * drm_sched_job_done_cb - the callback for a done job
+ * @f: fence
+ * @cb: fence callbacks
+ */
+static void drm_sched_job_done_cb(struct dma_fence *f, struct 
dma_fence_cb *cb)


Probably best to rename this to something like 
drm_sched_fence_parent_cb().



I will rename in the next version of patch.

+{
+    struct drm_sched_fence *s_fence = container_of(cb, struct 
drm_sched_fence,

+   cb);
+    struct drm_gpu_scheduler *sched = s_fence->sched;
+
+    atomic_dec(&sched->hw_rq_count);
+    atomic_dec(sched->score);
+
+    dma_fence_get(&s_fence->finished);


We should probably make sure that this reference is taken before 
installing the callback.


Here, we are signaling the finished fence and dma_fence_signal is 
checking the reference.


So we do not need to check here.




+    drm_sched_fence_finished(s_fence);
+    dma_fence_put(&s_fence->finished);
+    wake_up_interruptible(&sched->wake_up_worker);
+}
+
+int drm_sched_fence_add_parent_cb(struct dma_fence *fence,
+  struct drm_sched_fence *s_fence)
+{
+    return dma_fence_add_callback(fence, &s_fence->cb,
+  drm_sched_job_done_cb);
+}
+
+bool drm_sched_fence_remove_parent_cb(struct drm_sched_fence *s_fence)
+{
+    return dma_fence_remove_callback(s_fence->parent,
+ &s_fence->cb);
+}


Do we really need separate functions for that?

We can use  'drm_sched_fence_set_parent' but we need to add extra NULL 
check before


adding in the callback otherwise add-callback will throw the warning 
message every time.

Re: [PATCH v2 4/7] drm/simpledrm: Add support for system memory framebuffers

[Thomas Zimmermann]

Hi Thierry

Am 17.10.22 um 16:54 schrieb Thierry Reding:

On Mon, Oct 10, 2022 at 10:12:34AM +0200, Thomas Zimmermann wrote:

[...]


That whole 'Memory Manangement' block is will be unmaintainable. Before I go
into a detailed review, please see my questions about the reservedmem code
at the end of the patch.


It looks reasonably maintainable to me. Given that we only have __iomem
and non-__iomem cases, this is about the extent of the complexity that
could ever be added.


I think we should split the detection and usage, as the driver does with 
other properties. It would fit better into the driver's overall design. 
I'll send out another email with a review to illustrate what I have in mind.







   /*
* Modesetting
*/
@@ -491,15 +594,15 @@ static void 
simpledrm_primary_plane_helper_atomic_update(struct drm_plane *plane
drm_atomic_helper_damage_iter_init(&iter, old_plane_state, plane_state);
drm_atomic_for_each_plane_damage(&iter, &damage) {
-   struct iosys_map dst = IOSYS_MAP_INIT_VADDR(sdev->screen_base);
struct drm_rect dst_clip = plane_state->dst;
if (!drm_rect_intersect(&dst_clip, &damage))
continue;
-   iosys_map_incr(&dst, drm_fb_clip_offset(sdev->pitch, sdev->format, 
&dst_clip));
-   drm_fb_blit(&dst, &sdev->pitch, sdev->format->format, 
shadow_plane_state->data, fb,
-   &damage);
+   iosys_map_incr(&sdev->screen_base, drm_fb_clip_offset(sdev->pitch, 
sdev->format,
+ 
&dst_clip));


You'll modify screen_base and it'll eventually blow up. You have to keep
initializing the dst variable within the loop.


+   drm_fb_blit(&sdev->screen_base, &sdev->pitch, 
sdev->format->format,
+   shadow_plane_state->data, fb, &damage);
}
drm_dev_exit(idx);
@@ -518,7 +621,7 @@ static void 
simpledrm_primary_plane_helper_atomic_disable(struct drm_plane *plan
return;
/* Clear screen to black if disabled */
-   memset_io(sdev->screen_base, 0, sdev->pitch * sdev->mode.vdisplay);
+   iosys_map_memset(&sdev->screen_base, 0, 0, sdev->pitch * 
sdev->mode.vdisplay);
drm_dev_exit(idx);
   }
@@ -635,8 +738,6 @@ static struct simpledrm_device 
*simpledrm_device_create(struct drm_driver *drv,
struct drm_device *dev;
int width, height, stride;
const struct drm_format_info *format;
-   struct resource *res, *mem;
-   void __iomem *screen_base;
struct drm_plane *primary_plane;
struct drm_crtc *crtc;
struct drm_encoder *encoder;
@@ -706,35 +807,9 @@ static struct simpledrm_device 
*simpledrm_device_create(struct drm_driver *drv,
drm_dbg(dev, "framebuffer format=%p4cc, size=%dx%d, stride=%d byte\n",
&format->format, width, height, stride);
-   /*
-* Memory management
-*/
-
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!res)
-   return ERR_PTR(-EINVAL);
-
-   ret = devm_aperture_acquire_from_firmware(dev, res->start, 
resource_size(res));
-   if (ret) {
-   drm_err(dev, "could not acquire memory range %pr: error %d\n", 
res, ret);
+   ret = simpledrm_device_init_mm(sdev);
+   if (ret)
return ERR_PTR(ret);
-   }
-
-   mem = devm_request_mem_region(&pdev->dev, res->start, resource_size(res), 
drv->name);
-   if (!mem) {
-   /*
-* We cannot make this fatal. Sometimes this comes from magic
-* spaces our resource handlers simply don't know about. Use
-* the I/O-memory resource as-is and try to map that instead.
-*/
-   drm_warn(dev, "could not acquire memory region %pr\n", res);
-   mem = res;
-   }
-
-   screen_base = devm_ioremap_wc(&pdev->dev, mem->start, 
resource_size(mem));
-   if (!screen_base)
-   return ERR_PTR(-ENOMEM);
-   sdev->screen_base = screen_base;
/*
 * Modesetting
@@ -878,5 +953,35 @@ static struct platform_driver simpledrm_platform_driver = {
   module_platform_driver(simpledrm_platform_driver);
+static int simple_framebuffer_device_init(struct reserved_mem *rmem, struct 
device *dev)
+{
+   struct simpledrm_device *sdev = dev_get_drvdata(dev);
+
+   sdev->sysmem_start = rmem->base;
+   sdev->sysmem_size = rmem->size;


 From what I understand, you use the sysmem_ variables in the same code that
allocates the simpledrm_device, which creates a chicken-egg problem. When
does this code run?


This will run as a result of the of_reserved_mem_device_init_by_idx()
call earlier. It might be possible to push more code from the sysmem
initialization code path above into this function. That may also make
the somewhat clunky sysmem_start/size fields unnecessary.

Alternati

Re: [PATCH v2] drm/panel/panel-sitronix-st7701: Fix RTNI calculation

[Linus Walleij]

On Tue, Oct 18, 2022 at 12:01 PM Marek Vasut  wrote:
> On 10/18/22 11:13, Linus Walleij wrote:

> > I've been told to go and poke the DRM git people at IRC to rebase
> > the fixes branch.
>
> That would be #dri-devel on OFTC I think ?

Yups, I pinged and mlankhorst says he will fix it.

Yours,
Linus Walleij

Re: [PATCH v7 00/21] Move all drivers to a common dma-buf locking convention

[Christian König]

Am 18.10.22 um 01:07 schrieb Dmitry Osipenko:

On 10/17/22 20:22, Dmitry Osipenko wrote:

Hello,

This series moves all drivers to a dynamic dma-buf locking specification.
 From now on all dma-buf importers are made responsible for holding
dma-buf's reservation lock around all operations performed over dma-bufs
in accordance to the locking specification. This allows us to utilize
reservation lock more broadly around kernel without fearing of a potential
deadlocks.

This patchset passes all i915 selftests. It was also tested using VirtIO,
Panfrost, Lima, Tegra, udmabuf, AMDGPU and Nouveau drivers. I tested cases
of display+GPU, display+V4L and GPU+V4L dma-buf sharing (where appropriate),
which covers majority of kernel drivers since rest of the drivers share
same or similar code paths.

Changelog:

v7: - Rebased on top of recent drm-misc-next.

 - Added ack from Jason Gunthorpe to the RDMA patch.

 - Added iosys_map_clear() to dma_buf_vmap_unlocked(), making it fully
   consistent with dma_buf_vmap().

v6: - Added r-b from Michael Ruhl to the i915 patch.

 - Added acks from Sumit Semwal and updated commit message of the
   "Move dma_buf_vmap() to dynamic locking specification" patch like
   was suggested by Sumit.

 - Added "!dmabuf" check to dma_buf_vmap_unlocked() to match the locked
   variant of the function, for consistency.

v5: - Added acks and r-bs that were given to v4.

 - Changed i915 preparation patch like was suggested by Michael Ruhl.
   The scope of reservation locking is smaller now.

v4: - Added dma_buf_mmap() to the "locking convention" documentation,
   which was missed by accident in v3.

 - Added acks from Christian König, Tomasz Figa and Hans Verkuil that
   they gave to couple v3 patches.

 - Dropped the "_unlocked" postfix from function names that don't have
   the locked variant, as was requested by Christian König.

 - Factored out the per-driver preparations into separate patches
   to ease reviewing of the changes, which is now doable without the
   global dma-buf functions renaming.

 - Factored out the dynamic locking convention enforcements into separate
   patches which add the final dma_resv_assert_held(dmabuf->resv) to the
   dma-buf API functions.

v3: - Factored out dma_buf_mmap_unlocked() and attachment functions
   into aseparate patches, like was suggested by Christian König.

 - Corrected and factored out dma-buf locking documentation into
   a separate patch, like was suggested by Christian König.

 - Intel driver dropped the reservation locking fews days ago from
   its BO-release code path, but we need that locking for the imported
   GEMs because in the end that code path unmaps the imported GEM.
   So I added back the locking needed by the imported GEMs, updating
   the "dma-buf attachment locking specification" patch appropriately.

 - Tested Nouveau+Intel dma-buf import/export combo.

 - Tested udmabuf import to i915/Nouveau/AMDGPU.

 - Fixed few places in Etnaviv, Panfrost and Lima drivers that I missed
   to switch to locked dma-buf vmapping in the drm/gem: Take reservation
   lock for vmap/vunmap operations" patch. In a result invalidated the
   Christian's r-b that he gave to v2.

 - Added locked dma-buf vmap/vunmap functions that are needed for fixing
   vmappping of Etnaviv, Panfrost and Lima drivers mentioned above.
   I actually had this change stashed for the drm-shmem shrinker patchset,
   but then realized that it's already needed by the dma-buf patches.
   Also improved my tests to better cover these code paths.

v2: - Changed locking specification to avoid problems with a cross-driver
   ww locking, like was suggested by Christian König. Now the attach/detach
   callbacks are invoked without the held lock and exporter should take the
   lock.

 - Added "locking convention" documentation that explains which dma-buf
   functions and callbacks are locked/unlocked for importers and exporters,
   which was requested by Christian König.

 - Added ack from Tomasz Figa to the V4L patches that he gave to v1.

Dmitry Osipenko (21):
   dma-buf: Add unlocked variant of vmapping functions
   dma-buf: Add unlocked variant of attachment-mapping functions
   drm/gem: Take reservation lock for vmap/vunmap operations
   drm/prime: Prepare to dynamic dma-buf locking specification
   drm/armada: Prepare to dynamic dma-buf locking specification
   drm/i915: Prepare to dynamic dma-buf locking specification
   drm/omapdrm: Prepare to dynamic dma-buf locking specification
   drm/tegra: Prepare to dynamic dma-buf locking specification
   drm/etnaviv: Prepare to dynamic dma-buf locking specification
   RDMA/umem: Prepare to dynamic dma-buf locking specification
   misc: fastrpc: Prepare to dynamic dma-buf locking specification
   xen/gntdev: Prepare to dynamic dma-buf locking specificatio

Re: [PATCH 1/2] Revert "drm: hide unregistered connectors from GETCONNECTOR IOCTL"

[Ville Syrjälä]

On Tue, Oct 18, 2022 at 12:07:43PM +0200, Jonas Ådahl wrote:
> On Tue, Oct 18, 2022 at 12:58:53PM +0300, Ville Syrjälä wrote:
> > On Tue, Oct 18, 2022 at 11:27:19AM +0200, Jonas Ådahl wrote:
> > > On Tue, Oct 18, 2022 at 12:14:09PM +0300, Ville Syrjälä wrote:
> > > > On Mon, Oct 17, 2022 at 03:31:57PM +, Simon Ser wrote:
> > > > > This reverts commit 981f09295687f856d5345e19c7084aca481c1395.
> > > > > 
> > > > > It turns out this breaks Mutter.
> > > > 
> > > > A bit more detail would be a good to help future archaeologists.
> > > 
> > > Perhaps a better explanation is
> > > 
> > > It turns out this causes logically active but disconnected MST display
> > > port connectors to disappear from the drmModeGetResources() list,
> > 
> > That was the whole point was it not? So I'd drop the
> > "it turns out" part.
> > 
> > > meaning userspace is made to believe the connector is already disabled.
> > 
> > That wording to me implies its a generic issue affecting all
> > userspace when so far it looks like only mutter is affected.
> 
> Maybe other userspace was? I only found out by testing drm-next, and
> only tried using mutter when bisecting.
> 
> > So apparently mutter (for some reason) assumes that the
> > connector has somehow magically been disabled by someone
> > else if it disappears from the list of resources?
> 
> Mutter makes the assumption that connectors it can interact with are the
> ones that drmModeGetResources() return

I agree that on the face of it that assumption does seem
perfectly reasonable.

> - nothing magic about that.

Well it's expecting a bit magic from the kernel if it decides
that it doesn't need to disable what it already enabled.
But I guess it's more of a case that the code just never
expected this specific situation to happen, and thus the
results are what they are.

I suppose the only concern with the change is what happens
when you replug something back in before the old stuff has
disappeared and you now have two connectors for the same
thing on the list. IIRC the ddxen at least try to reuse
the same xrandr output for the connector when the path
prop matches. I suspect it might work by accident due
to the new connector appearing (hopefully) later in the
list than the old connector. But would probably need to
test this to make sure.

-- 
Ville Syrjälä
Intel

Re: Build regressions/improvements in v6.1-rc1

[Maciej W. Rozycki]

On Mon, 17 Oct 2022, Geert Uytterhoeven wrote:

> >  + {standard input}: Error: branch to a symbol in another ISA mode: 1339 =>
> > 2616, 2621
> 
> mips-gcc11/micro32r2_defconfig
> mips-gcc11/micro32r2el_defconfig

 Where can these configs be obtained from?

  Maciej

Re: [PATCH v2 4/7] drm/simpledrm: Add support for system memory framebuffers

[Thierry Reding]

On Mon, Oct 17, 2022 at 01:15:59PM -0500, Rob Herring wrote:
> On Mon, Oct 17, 2022 at 9:54 AM Thierry Reding  
> wrote:
> >
> > On Mon, Oct 10, 2022 at 10:12:34AM +0200, Thomas Zimmermann wrote:
> > > Hi
> > >
> > > Am 07.10.22 um 14:49 schrieb Thierry Reding:
> > > > From: Thierry Reding 
> > > >
> > > > Simple framebuffers can be set up in system memory, which cannot be
> > > > requested and/or I/O remapped using the I/O resource helpers. Add a
> > > > separate code path that obtains system memory framebuffers from the
> > > > reserved memory region referenced in the memory-region property.
> > > >
> > > > v2: make screen base a struct iosys_map to avoid sparse warnings
> 
> [...]
> 
> > > > +static int simple_framebuffer_init(struct reserved_mem *rmem)
> > > > +{
> > > > +   pr_info("framebuffer memory at %pa, size %lu bytes\n", &rmem->base,
> > > > +   (unsigned long)rmem->size);
> > > > +
> > > > +   rmem->ops = &simple_framebuffer_ops;
> > > > +
> > > > +   return 0;
> > > > +}
> > > > +RESERVEDMEM_OF_DECLARE(simple_framebuffer, "framebuffer", 
> > > > simple_framebuffer_init);
> > >
> > > What's the prupose of these code at all?  I looked through the kernel, but
> > > there aren't many other examples of it.
> >
> > This is a fairly standard construct to deal with early memory
> > reservations. What happens is roughly this: during early kernel boot,
> > the reserved-memory core code will iterate over all children of the top-
> > level reserved-memory node and see if they have a compatible string that
> > matches one of the entries in the table created by these
> > RESERVEDMEM_OF_DECLARE entries. It will then call the init function for
> > a matched entry and register a struct reserved_mem for these. The init
> > function in this case just dumps an informational message to the boot
> > log to provide some information about the framebuffer region that was
> > reserved (which can be used for example for troubleshooting purposes)
> > and sets the device init/release operations (which will be called when a
> > device is associated with the reserved memory region, i.e. when the
> > of_reserved_mem_device_init_by_idx() function is called).
> >
> > The reason why there aren't many examples of this is because these are
> > special memory regions that (at least upstream) kernels seldom support.
> > Perhaps the most common use-cases are the shared DMA pools (such as
> > CMA).
> 
> Also, not all regions need to be handled 'early' before slab allocator
> or drivers are probed. Do you need early handling here? I can't see
> why other than if fbcon is up early.

No, I don't think this needs early handling. Obviously we want this to
be available as soon as possible, but since the framebuffer driver is
built on top of DRM and that all becomes available fairly late, I don't
think this could ever run *that* early.

So are you saying that in general if we don't need early handling we
should avoid RESERVEDMEM_OF_DECLARE and instead manually resolve the
memory regions and inspect them? In other words, RESERVEDMEM_OF_DECLARE
should only ever be used when this early handling is needed?

Thierry


signature.asc
Description: PGP signature

Re: [PATCH] drm/mipi-dsi: fix possible memory leak in mipi_dsi_device_register_full()

[Thierry Reding]

On Tue, Oct 18, 2022 at 04:25:45PM +0800, Yang Yingliang wrote:
> If mipi_dsi_device_add() fails, the refcount of device is not 0, the name
> allocated in dev_set_name() is leaked. Fix this by calling put_device(),
> so that it will be freed in callback function kobject_cleanup().
> 
> Fixes: 068a00233969 ("drm: Add MIPI DSI bus support")
> Signed-off-by: Yang Yingliang 
> ---
>  drivers/gpu/drm/drm_mipi_dsi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Good catch! The device_initialize() function (which is called via
mipi_dsi_device_alloc() earlier in mipi_dsi_device_register_full()) has
a comment that put_device() should be used after it was called.

Reviewed-by: Thierry Reding 


signature.asc
Description: PGP signature

Re: [PATCH 1/2] Revert "drm: hide unregistered connectors from GETCONNECTOR IOCTL"

[Jonas Ådahl]

On Tue, Oct 18, 2022 at 12:58:53PM +0300, Ville Syrjälä wrote:
> On Tue, Oct 18, 2022 at 11:27:19AM +0200, Jonas Ådahl wrote:
> > On Tue, Oct 18, 2022 at 12:14:09PM +0300, Ville Syrjälä wrote:
> > > On Mon, Oct 17, 2022 at 03:31:57PM +, Simon Ser wrote:
> > > > This reverts commit 981f09295687f856d5345e19c7084aca481c1395.
> > > > 
> > > > It turns out this breaks Mutter.
> > > 
> > > A bit more detail would be a good to help future archaeologists.
> > 
> > Perhaps a better explanation is
> > 
> > It turns out this causes logically active but disconnected MST display
> > port connectors to disappear from the drmModeGetResources() list,
> 
> That was the whole point was it not? So I'd drop the
> "it turns out" part.
> 
> > meaning userspace is made to believe the connector is already disabled.
> 
> That wording to me implies its a generic issue affecting all
> userspace when so far it looks like only mutter is affected.

Maybe other userspace was? I only found out by testing drm-next, and
only tried using mutter when bisecting.

> So apparently mutter (for some reason) assumes that the
> connector has somehow magically been disabled by someone
> else if it disappears from the list of resources?

Mutter makes the assumption that connectors it can interact with are the
ones that drmModeGetResources() return - nothing magic about that.


Jonas

> 
> > 
> > When userspace then attempts post a new mode set commit, if that commit
> > uses the same CRTC used to previously drive the disconnected connector,
> > it will fail as that CRTC is logically still tied to the disconnected
> > connector.
> > 
> > This was discovered by a bisecting docking station hot plugging
> > regression using mutter.
> > 
> > 
> > Jonas
> > 
> > > 
> > > > 
> > > > Signed-off-by: Simon Ser 
> > > > Cc: Daniel Vetter 
> > > > Cc: Lyude Paul 
> > > > Cc: Jonas Ådahl 
> > > > ---
> > > >  drivers/gpu/drm/drm_mode_config.c | 3 ---
> > > >  1 file changed, 3 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/drm_mode_config.c 
> > > > b/drivers/gpu/drm/drm_mode_config.c
> > > > index 939d621c9ad4..688c8afe0bf1 100644
> > > > --- a/drivers/gpu/drm/drm_mode_config.c
> > > > +++ b/drivers/gpu/drm/drm_mode_config.c
> > > > @@ -151,9 +151,6 @@ int drm_mode_getresources(struct drm_device *dev, 
> > > > void *data,
> > > > count = 0;
> > > > connector_id = u64_to_user_ptr(card_res->connector_id_ptr);
> > > > drm_for_each_connector_iter(connector, &conn_iter) {
> > > > -   if (connector->registration_state != 
> > > > DRM_CONNECTOR_REGISTERED)
> > > > -   continue;
> > > > -
> > > > /* only expose writeback connectors if userspace 
> > > > understands them */
> > > > if (!file_priv->writeback_connectors &&
> > > > (connector->connector_type == 
> > > > DRM_MODE_CONNECTOR_WRITEBACK))
> > > > -- 
> > > > 2.38.0
> > > > 
> > > 
> > > -- 
> > > Ville Syrjälä
> > > Intel
> > > 
> 
> -- 
> Ville Syrjälä
> Intel
> 

Re: [PATCH v2] drm/panel/panel-sitronix-st7701: Fix RTNI calculation

[Marek Vasut]

On 10/18/22 11:13, Linus Walleij wrote:

On Tue, Oct 18, 2022 at 11:03 AM Marek Vasut  wrote:

On 10/18/22 10:53, Linus Walleij wrote:

On Thu, Oct 13, 2022 at 12:12 AM Marek Vasut  wrote:


The RTNI field is multiplied by 16 and incremented by 512 before being
used as the minimum number of pixel clock per horizontal line, hence
it is necessary to subtract those 512 bytes from htotal and then divide
the result by 16 before writing the value into the RTNI field. Fix the
calculation.

Fixes: de2b4917843c ("drm/panel/panel-sitronix-st7701: Infer horizontal pixel count 
from TFT mode")
Signed-off-by: Marek Vasut 
---
Cc: Guido Günther 
Cc: Jagan Teki 
Cc: Laurent Pinchart 
Cc: Linus Walleij 
Cc: Sam Ravnborg 
Cc: Thierry Reding 
---
V2: Clamp the htotal to range 512...1008, so RTNI always fits the bitfield


I tried to apply this to drm-misc-fixes but the branch has not yet
been moved forward to v6.1-rc1.


Can I maybe get RB until then ?


Reviewed-by: Linus Walleij 


Thank you


I've been told to go and poke the DRM git people at IRC to rebase
the fixes branch.


That would be #dri-devel on OFTC I think ?

Re: [PATCH v5 20/22] drm/vc4: vec: Convert to the new TV mode property

[Maxime Ripard]

On Mon, Oct 17, 2022 at 12:31:31PM +0200, Noralf Trønnes wrote:
> Den 16.10.2022 20.52, skrev Mateusz Kwiatkowski:
> >>  static int vc4_vec_connector_get_modes(struct drm_connector *connector)
> >>  {
> >> -  struct drm_connector_state *state = connector->state;
> >>struct drm_display_mode *mode;
> >>  
> >> -  mode = drm_mode_duplicate(connector->dev,
> >> -vc4_vec_tv_modes[state->tv.legacy_mode].mode);
> >> +  mode = drm_mode_analog_ntsc_480i(connector->dev);
> >>if (!mode) {
> >>DRM_ERROR("Failed to create a new display mode\n");
> >>return -ENOMEM;
> >>}
> >>  
> >> +  mode->type |= DRM_MODE_TYPE_PREFERRED;
> >>drm_mode_probed_add(connector, mode);
> >>  
> >> -  return 1;
> >> +  mode = drm_mode_analog_pal_576i(connector->dev);
> >> +  if (!mode) {
> >> +  DRM_ERROR("Failed to create a new display mode\n");
> >> +  return -ENOMEM;
> >> +  }
> >> +
> >> +  drm_mode_probed_add(connector, mode);
> >> +
> >> +  return 2;
> >> +}
> > 
> > Referencing those previous discussions:
> > - 
> > https://lore.kernel.org/dri-devel/0255f7c6-0484-6456-350d-cf24f3fee...@tronnes.org/
> > - 
> > https://lore.kernel.org/dri-devel/c8f8015a-75da-afa8-ca7f-b2b134cac...@gmail.com/
> > 
> > Unconditionally setting the 480i mode as DRM_MODE_TYPE_PREFERRED causes Xorg
> > (at least on current Raspberry Pi OS) to display garbage when
> > video=Composite1:PAL is specified on the command line, so I'm afraid this 
> > won't
> > do.
> > 
> > As I see it, there are three viable solutions for this issue:
> > 
> > a) Somehow query the video= command line option from this function, and set
> >DRM_MODE_TYPE_PREFERRED appropriately. This would break the abstraction
> >provided by global DRM code, but should work fine.
> > 
> > b) Modify drm_helper_probe_add_cmdline_mode() so that it sets
> >DRM_MODE_TYPE_PREFERRED in addition to DRM_MODE_TYPE_USERDEF. This seems
> >pretty robust, but affects the entire DRM subsystem, which may break
> >userspace in different ways.
> > 
> >- Maybe this could be mitigated by adding some additional conditions, 
> > e.g.
> >  setting the PREFERRED flag only if no modes are already flagged as such
> >  and/or only if the cmdline mode is a named one (~= analog TV mode)
> > 
> > c) Forcing userspace (Xorg / Raspberry Pi OS) to get fixed and honor the 
> > USERDEF
> >flag.
> > 
> > Either way, hardcoding 480i as PREFERRED does not seem right.
> > 
> 
> My solution for this is to look at tv.mode to know which mode to mark as
> preferred. Maxime didn't like this since it changes things behind
> userspace's back. I don't see how that can cause any problems for userspace.
> 
> If userspace uses atomic and sets tv_mode, it has to know which mode to
> use before hand, so it doesn't look at the preferreded flag.
> 
> If it uses legacy and sets tv_mode, it can end up with a stale preferred
> flag, but no worse than not having the flag or that ntsc is always
> preferred.
> 
> If it doesn't change tv_mode, there's no problem, the preferred flag
> doesn't change.

I don't like it because I just see no way to make this reliable. When we
set tv_mode, we're not only going to change the preferred flag, but also
the order of the modes to make the preferred mode first.

Since we just changed the mode lists, we also want to send a hotplug
event to userspace so that it gets notified of it. It will pick up the
new preferred mode, great.

But what if it doesn't? There's no requirement for userspace to handle
hotplug events, and Kodi won't for example. So we just changed the TV
mode but not the actual mode, and that's it. It's just as broken for
Kodi as it is for X11 right now.

If we can't get a bullet-proof solution, then I'm not convinced it's
worth addressing. Especially since it's already the current state, and
it doesn't seem to bother a lot of people.

Maxime


signature.asc
Description: PGP signature

Re: [PATCH 1/2] Revert "drm: hide unregistered connectors from GETCONNECTOR IOCTL"

[Ville Syrjälä]

On Tue, Oct 18, 2022 at 11:27:19AM +0200, Jonas Ådahl wrote:
> On Tue, Oct 18, 2022 at 12:14:09PM +0300, Ville Syrjälä wrote:
> > On Mon, Oct 17, 2022 at 03:31:57PM +, Simon Ser wrote:
> > > This reverts commit 981f09295687f856d5345e19c7084aca481c1395.
> > > 
> > > It turns out this breaks Mutter.
> > 
> > A bit more detail would be a good to help future archaeologists.
> 
> Perhaps a better explanation is
> 
> It turns out this causes logically active but disconnected MST display
> port connectors to disappear from the drmModeGetResources() list,

That was the whole point was it not? So I'd drop the
"it turns out" part.

> meaning userspace is made to believe the connector is already disabled.

That wording to me implies its a generic issue affecting all
userspace when so far it looks like only mutter is affected.
So apparently mutter (for some reason) assumes that the
connector has somehow magically been disabled by someone
else if it disappears from the list of resources?

> 
> When userspace then attempts post a new mode set commit, if that commit
> uses the same CRTC used to previously drive the disconnected connector,
> it will fail as that CRTC is logically still tied to the disconnected
> connector.
> 
> This was discovered by a bisecting docking station hot plugging
> regression using mutter.
> 
> 
> Jonas
> 
> > 
> > > 
> > > Signed-off-by: Simon Ser 
> > > Cc: Daniel Vetter 
> > > Cc: Lyude Paul 
> > > Cc: Jonas Ådahl 
> > > ---
> > >  drivers/gpu/drm/drm_mode_config.c | 3 ---
> > >  1 file changed, 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_mode_config.c 
> > > b/drivers/gpu/drm/drm_mode_config.c
> > > index 939d621c9ad4..688c8afe0bf1 100644
> > > --- a/drivers/gpu/drm/drm_mode_config.c
> > > +++ b/drivers/gpu/drm/drm_mode_config.c
> > > @@ -151,9 +151,6 @@ int drm_mode_getresources(struct drm_device *dev, 
> > > void *data,
> > >   count = 0;
> > >   connector_id = u64_to_user_ptr(card_res->connector_id_ptr);
> > >   drm_for_each_connector_iter(connector, &conn_iter) {
> > > - if (connector->registration_state != DRM_CONNECTOR_REGISTERED)
> > > - continue;
> > > -
> > >   /* only expose writeback connectors if userspace understands 
> > > them */
> > >   if (!file_priv->writeback_connectors &&
> > >   (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK))
> > > -- 
> > > 2.38.0
> > > 
> > 
> > -- 
> > Ville Syrjälä
> > Intel
> > 

-- 
Ville Syrjälä
Intel

Re: [PATCH v5 12/22] drm/connector: Add a function to lookup a TV mode by its name

[Maxime Ripard]

On Mon, Oct 17, 2022 at 12:44:45PM +0200, Noralf Trønnes wrote:
> Den 13.10.2022 15.18, skrev Maxime Ripard:
> > As part of the command line parsing rework coming in the next patches,
> > we'll need to lookup drm_connector_tv_mode values by their name, already
> > defined in drm_tv_mode_enum_list.
> > 
> > In order to avoid any code duplication, let's do a function that will
> > perform a lookup of a TV mode name and return its value.
> > 
> > Signed-off-by: Maxime Ripard 
> > ---
> >  drivers/gpu/drm/drm_connector.c | 24 
> >  include/drm/drm_connector.h |  2 ++
> >  2 files changed, 26 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_connector.c 
> > b/drivers/gpu/drm/drm_connector.c
> > index 820f4c730b38..30611c616435 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -991,6 +991,30 @@ static const struct drm_prop_enum_list 
> > drm_tv_mode_enum_list[] = {
> >  };
> >  DRM_ENUM_NAME_FN(drm_get_tv_mode_name, drm_tv_mode_enum_list)
> >  
> > +/**
> > + * drm_get_tv_mode_from_name - Translates a TV mode name into its enum 
> > value
> > + * @name: TV Mode name we want to convert
> > + * @len: Length of @name
> > + *
> > + * Translates @name into an enum drm_connector_tv_mode.
> > + *
> > + * Returns: the enum value on success, a negative errno otherwise.
> > + */
> > +int drm_get_tv_mode_from_name(const char *name, size_t len)
> 
> Do we really need to pass in length here? item->name has to always be
> NUL terminated otherwise things would break elsewhere, so it shouldn't
> be necessary AFAICS.

The only user so far is the command-line parsing code, and we might very
well have an option after the tv_mode, something like
720x480i,tv_mode=NTSC,rotate=180

In this case, we won't get a NULL-terminated name.

Maxime

Re: [PATCH 1/2] Revert "drm: hide unregistered connectors from GETCONNECTOR IOCTL"

[Jonas Ådahl]

On Tue, Oct 18, 2022 at 12:14:09PM +0300, Ville Syrjälä wrote:
> On Mon, Oct 17, 2022 at 03:31:57PM +, Simon Ser wrote:
> > This reverts commit 981f09295687f856d5345e19c7084aca481c1395.
> > 
> > It turns out this breaks Mutter.
> 
> A bit more detail would be a good to help future archaeologists.

Perhaps a better explanation is

It turns out this causes logically active but disconnected MST display
port connectors to disappear from the drmModeGetResources() list,
meaning userspace is made to believe the connector is already disabled.

When userspace then attempts post a new mode set commit, if that commit
uses the same CRTC used to previously drive the disconnected connector,
it will fail as that CRTC is logically still tied to the disconnected
connector.

This was discovered by a bisecting docking station hot plugging
regression using mutter.


Jonas

> 
> > 
> > Signed-off-by: Simon Ser 
> > Cc: Daniel Vetter 
> > Cc: Lyude Paul 
> > Cc: Jonas Ådahl 
> > ---
> >  drivers/gpu/drm/drm_mode_config.c | 3 ---
> >  1 file changed, 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_mode_config.c 
> > b/drivers/gpu/drm/drm_mode_config.c
> > index 939d621c9ad4..688c8afe0bf1 100644
> > --- a/drivers/gpu/drm/drm_mode_config.c
> > +++ b/drivers/gpu/drm/drm_mode_config.c
> > @@ -151,9 +151,6 @@ int drm_mode_getresources(struct drm_device *dev, void 
> > *data,
> > count = 0;
> > connector_id = u64_to_user_ptr(card_res->connector_id_ptr);
> > drm_for_each_connector_iter(connector, &conn_iter) {
> > -   if (connector->registration_state != DRM_CONNECTOR_REGISTERED)
> > -   continue;
> > -
> > /* only expose writeback connectors if userspace understands 
> > them */
> > if (!file_priv->writeback_connectors &&
> > (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK))
> > -- 
> > 2.38.0
> > 
> 
> -- 
> Ville Syrjälä
> Intel
>