[PATCH v2] ASoC: dt-bindings: maxim,max98371: DT schema improvement
Improve Maxim Integrated MAX98371 audio codec bindings DT schema conversion
Signed-off-by: André Morishita
---
Changes in v2
- Generic node names - codec (Krzysztof)
- Drop label max98371 (Krzysztof)
- Add sound-dai-cells in example (Krzysztof)
.../devicetree/bindings/sound/max98371.txt| 17
.../bindings/sound/maxim,max98371.yaml| 42 +++
2 files changed, 42 insertions(+), 17 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/sound/max98371.txt
create mode 100644 Documentation/devicetree/bindings/sound/maxim,max98371.yaml
diff --git a/Documentation/devicetree/bindings/sound/max98371.txt
b/Documentation/devicetree/bindings/sound/max98371.txt
deleted file mode 100644
index 8b2b2704b574..
--- a/Documentation/devicetree/bindings/sound/max98371.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-max98371 codec
-
-This device supports I2C mode only.
-
-Required properties:
-
-- compatible : "maxim,max98371"
-- reg : The chip select number on the I2C bus
-
-Example:
-
- {
- max98371: max98371@31 {
- compatible = "maxim,max98371";
- reg = <0x31>;
- };
-};
diff --git a/Documentation/devicetree/bindings/sound/maxim,max98371.yaml
b/Documentation/devicetree/bindings/sound/maxim,max98371.yaml
new file mode 100644
index ..14fba34ef81a
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/maxim,max98371.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/maxim,max98371.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim MAX98371 audio codec
+
+maintainers:
+ - anish kumar
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+const: maxim,max98371
+
+ '#sound-dai-cells':
+const: 0
+
+ reg:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+codec@31 {
+compatible = "maxim,max98371";
+reg = <0x31>;
+#sound-dai-cells = <0>;
+};
+};
--
2.40.0
Re: [Intel-gfx] [PATCH v8 10/10] drm/msm: Implement HDCP 1.x using the new drm HDCP helpers
Hi Mark,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next-fixes]
[also build test ERROR on linus/master v6.3-rc4]
[cannot apply to drm-misc/drm-misc-next drm-intel/for-linux-next drm/drm-next
next-20230331]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Mark-Yacoub/drm-hdcp-Add-drm_hdcp_atomic_check/20230401-061425
base: git://anongit.freedesktop.org/drm-intel for-linux-next-fixes
patch link:
https://lore.kernel.org/r/20230331221213.1691997-11-markyacoub%40google.com
patch subject: [Intel-gfx] [PATCH v8 10/10] drm/msm: Implement HDCP 1.x using
the new drm HDCP helpers
config: arc-randconfig-r043-20230329
(https://download.01.org/0day-ci/archive/20230401/202304011152.dsr8g6yx-...@intel.com/config)
compiler: arc-elf-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/697c762c590d862f4f6ed4a8cac97ac2de815f73
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Mark-Yacoub/drm-hdcp-Add-drm_hdcp_atomic_check/20230401-061425
git checkout 697c762c590d862f4f6ed4a8cac97ac2de815f73
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1
O=build_dir ARCH=arc olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1
O=build_dir ARCH=arc SHELL=/bin/bash
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
| Link:
https://lore.kernel.org/oe-kbuild-all/202304011152.dsr8g6yx-...@intel.com/
All errors (new ones prefixed by >>):
arc-elf-ld: drivers/gpu/drm/msm/msm_atomic.o: in function
`msm_atomic_commit_tail':
>> drivers/gpu/drm/msm/msm_atomic.c:193: undefined reference to
>> `dp_drm_is_bridge_msm_dp'
>> arc-elf-ld: drivers/gpu/drm/msm/msm_atomic.c:193: undefined reference to
>> `dp_drm_is_bridge_msm_dp'
>> arc-elf-ld: drivers/gpu/drm/msm/msm_atomic.c:194: undefined reference to
>> `dp_drm_atomic_commit'
>> arc-elf-ld: drivers/gpu/drm/msm/msm_atomic.c:194: undefined reference to
>> `dp_drm_atomic_commit'
arc-elf-ld: drivers/gpu/drm/msm/dp/dp_debug.o: in function
`dp_hdcp_key_write':
>> drivers/gpu/drm/msm/dp/dp_debug.c:219: undefined reference to
>> `dp_hdcp_ingest_key'
>> arc-elf-ld: drivers/gpu/drm/msm/dp/dp_debug.c:219: undefined reference to
>> `dp_hdcp_ingest_key'
vim +193 drivers/gpu/drm/msm/msm_atomic.c
184
185 static void msm_atomic_commit_connectors(struct drm_atomic_state *state)
186 {
187 struct drm_device *dev = state->dev;
188 struct msm_drm_private *priv = dev->dev_private;
189 int i;
190
191 for (i = 0; i < priv->num_bridges; ++i) {
192 struct drm_bridge *bridge = priv->bridges[i];
> 193 if (dp_drm_is_bridge_msm_dp(bridge)) {
> 194 dp_drm_atomic_commit(bridge, state);
195 }
196 }
197 }
198
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
Re: [Intel-gfx] [PATCH] i915/guc/slpc: Provide sysfs for efficient freq
On Fri, 31 Mar 2023 19:00:49 -0700, Vinay Belgaumkar wrote:
>
Hi Vinay,
> @@ -478,20 +507,15 @@ int intel_guc_slpc_set_min_freq(struct intel_guc_slpc
> *slpc, u32 val)
> val > slpc->max_freq_softlimit)
> return -EINVAL;
>
> + /* Ignore efficient freq if lower min freq is requested */
> + ret = intel_guc_slpc_set_ignore_eff_freq(slpc, val < slpc->rp1_freq);
> + if (ret)
> + goto out;
> +
I don't agree with this. If we are now providing an interface explicitly to
ignore RPe, that should be /only/ way to ignore RPe. There should be no
other "under the hood" ignoring of RPe. In other words, ignoring RPe should
be minimized unless explicitly requested.
I don't clearly understand why this was done previously but it makes even
less sense to me now after this patch.
Thanks.
--
Ashutosh
> /* Need a lock now since waitboost can be modifying min as well */
> mutex_lock(>lock);
> wakeref = intel_runtime_pm_get(>runtime_pm);
>
> - /* Ignore efficient freq if lower min freq is requested */
> - ret = slpc_set_param(slpc,
> - SLPC_PARAM_IGNORE_EFFICIENT_FREQUENCY,
> - val < slpc->rp1_freq);
> - if (ret) {
> - guc_probe_error(slpc_to_guc(slpc), "Failed to toggle efficient
> freq: %pe\n",
> - ERR_PTR(ret));
> - goto out;
> - }
> -
> ret = slpc_set_param(slpc,
>SLPC_PARAM_GLOBAL_MIN_GT_UNSLICE_FREQ_MHZ,
>val);
Re: [Intel-gfx] [PATCH v2] drm/i915/hwmon: Use 0 to designate disabled PL1 power limit
On Fri, 31 Mar 2023 03:23:33 -0700, Tvrtko Ursulin wrote:
>
Hi Tvrtko,
> > @@ -385,8 +395,22 @@ static int
> > hwm_power_max_write(struct hwm_drvdata *ddat, long val)
> > {
> > struct i915_hwmon *hwmon = ddat->hwmon;
> > + intel_wakeref_t wakeref;
> > u32 nval;
> > + if (val == PL1_DISABLE) {
> > + /* Disable PL1 limit */
> > + hwm_locked_with_pm_intel_uncore_rmw(ddat,
> > hwmon->rg.pkg_rapl_limit,
> > + PKG_PWR_LIM_1_EN, 0);
> > +
> > + /* Verify, because PL1 limit cannot be disabled on all
> > platforms */
>
> I think there is a race right here, since above grabbed and released the
> hwmon_lock, anyone can modify it at this point before the verification
> below. Not sure if any consequences worse than a wrong -EPERM are possible
> though.
>
> Also, is EPERM correct for something hardware does not support? We usually
> say ENODEV for such things, IIRC at least.
Changed to -ENODEV in v3.
> Anyway, race looks easily solvable by holding the existing mutex and a
> single rpm ref for the whole rmw-r cycle.
Fixed in v3, thanks for catching these.
Ashutosh
> > + with_intel_runtime_pm(ddat->uncore->rpm, wakeref)
> > + nval = intel_uncore_read(ddat->uncore,
> > hwmon->rg.pkg_rapl_limit);
> > + if (nval & PKG_PWR_LIM_1_EN)
> > + return -EPERM;
> > + return 0;
> > + }
> > +
> > /* Computation in 64-bits to avoid overflow. Round to nearest. */
> > nval = DIV_ROUND_CLOSEST_ULL((u64)val << hwmon->scl_shift_power,
> > SF_POWER);
> > nval = PKG_PWR_LIM_1_EN | REG_FIELD_PREP(PKG_PWR_LIM_1, nval);
[PATCH v3] drm/i915/hwmon: Use 0 to designate disabled PL1 power limit
On ATSM the PL1 limit is disabled at power up. The previous uapi assumed
that the PL1 limit is always enabled and therefore did not have a notion of
a disabled PL1 limit. This results in erroneous PL1 limit values when the
PL1 limit is disabled. For example at power up, the disabled ATSM PL1 limit
was previously shown as 0 which means a low PL1 limit whereas the limit
being disabled actually implies a high effective PL1 limit value.
To get round this problem, the PL1 limit uapi is expanded to include a
special value 0 to designate a disabled PL1 limit. A read value of 0 means
that the PL1 power limit is disabled, writing 0 disables the limit.
The link between this patch and the bugs mentioned below is as follows:
* Because on ATSM the PL1 power limit is disabled on power up and there
were no means to enable it, we previously implemented the means to
enable the limit when the PL1 hwmon entry (power1_max) was written to.
* Now there is a IGT igt@i915_hwmon@hwmon_write which (a) reads orig value
from all hwmon sysfs (b) does a bunch of random writes and finally (c)
restores the orig value read. On ATSM since the orig value is 0, when
the IGT restores the 0 value, the PL1 limit is now enabled with a value
of 0.
* PL1 limit of 0 implies a low PL1 limit which causes GPU freq to fall to
100 MHz. This causes GuC FW load and several IGT's to start timing out
and gives rise to these Intel CI bugs. After this patch, writing 0 would
disable the PL1 limit instead of enabling it, avoiding the freq drop
issue.
v2: Add explanation for bugs mentioned below (Rodrigo)
v3: Eliminate race during PL1 disable and verify (Tvrtko)
Change return to -ENODEV if verify fails (Tvrtko)
Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8062
Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8060
Signed-off-by: Ashutosh Dixit
Reviewed-by: Rodrigo Vivi
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 4 ++-
drivers/gpu/drm/i915/i915_hwmon.c | 26 +++
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index 2d6a472eef885..8d7d8f05f6cd0 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -14,7 +14,9 @@ Description: RW. Card reactive sustained (PL1/Tau) power
limit in microwatts.
The power controller will throttle the operating frequency
if the power averaged over a window (typically seconds)
- exceeds this limit.
+ exceeds this limit. A read value of 0 means that the PL1
+ power limit is disabled, writing 0 disables the
+ limit. Writing values > 0 will enable the power limit.
Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index 596dd2c070106..8e7dccc8d3a0e 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -349,6 +349,8 @@ hwm_power_is_visible(const struct hwm_drvdata *ddat, u32
attr, int chan)
}
}
+#define PL1_DISABLE 0
+
/*
* HW allows arbitrary PL1 limits to be set but silently clamps these values to
* "typical but not guaranteed" min/max values in rg.pkg_power_sku. Follow the
@@ -362,6 +364,14 @@ hwm_power_max_read(struct hwm_drvdata *ddat, long *val)
intel_wakeref_t wakeref;
u64 r, min, max;
+ /* Check if PL1 limit is disabled */
+ with_intel_runtime_pm(ddat->uncore->rpm, wakeref)
+ r = intel_uncore_read(ddat->uncore, hwmon->rg.pkg_rapl_limit);
+ if (!(r & PKG_PWR_LIM_1_EN)) {
+ *val = PL1_DISABLE;
+ return 0;
+ }
+
*val = hwm_field_read_and_scale(ddat,
hwmon->rg.pkg_rapl_limit,
PKG_PWR_LIM_1,
@@ -385,8 +395,24 @@ static int
hwm_power_max_write(struct hwm_drvdata *ddat, long val)
{
struct i915_hwmon *hwmon = ddat->hwmon;
+ intel_wakeref_t wakeref;
u32 nval;
+ /* Disable PL1 limit and verify, because the limit cannot be disabled
on all platforms */
+ if (val == PL1_DISABLE) {
+ mutex_lock(>hwmon_lock);
+ with_intel_runtime_pm(ddat->uncore->rpm, wakeref) {
+ intel_uncore_rmw(ddat->uncore, hwmon->rg.pkg_rapl_limit,
+PKG_PWR_LIM_1_EN, 0);
+ nval = intel_uncore_read(ddat->uncore,
hwmon->rg.pkg_rapl_limit);
+ }
+ mutex_unlock(>hwmon_lock);
+
+ if (nval & PKG_PWR_LIM_1_EN)
+ return -ENODEV;
+ return 0;
+ }
+
/* Computation in 64-bits to avoid overflow. Round to nearest. */
nval =
[PATCH] i915/guc/slpc: Provide sysfs for efficient freq
SLPC enables use of efficient freq at init by default. It is
possible for GuC to request frequencies that are higher than
the 'software' max if user has set it lower than the efficient
level.
Scenarios/tests that require strict fixing of freq below the efficient
level will need to disable it through this interface. Another way
to disable it is to set min frequency below the efficient level.
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 35 +
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 49 ++-
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h | 1 +
.../gpu/drm/i915/gt/uc/intel_guc_slpc_types.h | 1 +
4 files changed, 75 insertions(+), 11 deletions(-)
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 28f27091cd3b..7496de5be580 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
@@ -451,6 +451,33 @@ static ssize_t punit_req_freq_mhz_show(struct kobject
*kobj,
return sysfs_emit(buff, "%u\n", preq);
}
+static ssize_t slpc_ignore_eff_freq_show(struct kobject *kobj,
+struct kobj_attribute *attr,
+char *buff)
+{
+ struct intel_gt *gt = intel_gt_sysfs_get_drvdata(kobj, attr->attr.name);
+ struct intel_guc_slpc *slpc = >uc.guc.slpc;
+
+ return sysfs_emit(buff, "%u\n", slpc->ignore_eff_freq);
+}
+
+static ssize_t slpc_ignore_eff_freq_store(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ const char *buff, size_t count)
+{
+ struct intel_gt *gt = intel_gt_sysfs_get_drvdata(kobj, attr->attr.name);
+ struct intel_guc_slpc *slpc = >uc.guc.slpc;
+ int err;
+ uint32_t val;
+
+ err = kstrtou32(buff, 0, );
+ if (err)
+ return err;
+
+ err = intel_guc_slpc_set_ignore_eff_freq(slpc, val);
+ return err ?: count;
+}
+
struct intel_gt_bool_throttle_attr {
struct attribute attr;
ssize_t (*show)(struct kobject *kobj, struct kobj_attribute *attr,
@@ -663,6 +690,8 @@ static struct kobj_attribute attr_media_freq_factor_scale =
INTEL_GT_ATTR_RO(media_RP0_freq_mhz);
INTEL_GT_ATTR_RO(media_RPn_freq_mhz);
+INTEL_GT_ATTR_RW(slpc_ignore_eff_freq);
+
static const struct attribute *media_perf_power_attrs[] = {
_media_freq_factor.attr,
_media_freq_factor_scale.attr,
@@ -744,6 +773,12 @@ void intel_gt_sysfs_pm_init(struct intel_gt *gt, struct
kobject *kobj)
if (ret)
gt_warn(gt, "failed to create punit_req_freq_mhz sysfs (%pe)",
ERR_PTR(ret));
+ if (intel_uc_uses_guc_slpc(>uc)) {
+ ret = sysfs_create_file(kobj, _slpc_ignore_eff_freq.attr);
+ if (ret)
+ gt_warn(gt, "failed to create ignore_eff_freq sysfs
(%pe)", ERR_PTR(ret));
+ }
+
if (i915_mmio_reg_valid(intel_gt_perf_limit_reasons_reg(gt))) {
ret = sysfs_create_files(kobj, throttle_reason_attrs);
if (ret)
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 026d73855f36..eaa73c1fba6d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
@@ -277,6 +277,7 @@ int intel_guc_slpc_init(struct intel_guc_slpc *slpc)
slpc->max_freq_softlimit = 0;
slpc->min_freq_softlimit = 0;
+ slpc->ignore_eff_freq = false;
slpc->min_is_rpmax = false;
slpc->boost_freq = 0;
@@ -457,6 +458,34 @@ int intel_guc_slpc_get_max_freq(struct intel_guc_slpc
*slpc, u32 *val)
return ret;
}
+int intel_guc_slpc_set_ignore_eff_freq(struct intel_guc_slpc *slpc, bool val)
+{
+ struct drm_i915_private *i915 = slpc_to_i915(slpc);
+ intel_wakeref_t wakeref;
+ int ret = 0;
+
+ /* Need a lock now since waitboost can be modifying min as well */
+ mutex_lock(>lock);
+ wakeref = intel_runtime_pm_get(>runtime_pm);
+
+ /* Ignore efficient freq if lower min freq is requested */
+ ret = slpc_set_param(slpc,
+SLPC_PARAM_IGNORE_EFFICIENT_FREQUENCY,
+val);
+ if (ret) {
+ guc_probe_error(slpc_to_guc(slpc), "Failed to set efficient
freq(%d): %pe\n",
+ val, ERR_PTR(ret));
+ goto out;
+ }
+
+ slpc->ignore_eff_freq = val;
+
+out:
+ intel_runtime_pm_put(>runtime_pm, wakeref);
+ mutex_unlock(>lock);
+ return ret;
+}
+
/**
* intel_guc_slpc_set_min_freq() - Set min frequency limit for SLPC.
* @slpc: pointer to intel_guc_slpc.
@@ -478,20 +507,15 @@ int intel_guc_slpc_set_min_freq(struct intel_guc_slpc
*slpc, u32 val)
val > slpc->max_freq_softlimit)
return -EINVAL;
+
[PATCH AUTOSEL 5.4 4/6] drm: panel-orientation-quirks: Add quirk for Lenovo Yoga Book X90F
From: Hans de Goede
[ Upstream commit 03aecb1acbcd7a660f97d645ca6c09d9de27ff9d ]
Like the Windows Lenovo Yoga Book X91F/L the Android Lenovo Yoga Book
X90F/L has a portrait 1200x1920 screen used in landscape mode,
add a quirk for this.
When the quirk for the X91F/L was initially added it was written to
also apply to the X90F/L but this does not work because the Android
version of the Yoga Book uses completely different DMI strings.
Also adjust the X91F/L quirk to reflect that it only applies to
the X91F/L models.
Signed-off-by: Hans de Goede
Reviewed-by: Javier Martinez Canillas
Link:
https://patchwork.freedesktop.org/patch/msgid/20230301095218.28457-1-hdego...@redhat.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 8768073794fbf..6106fa7c43028 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -284,10 +284,17 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "IdeaPad Duet 3 10IGL5"),
},
.driver_data = (void *)_rightside_up,
- }, {/* Lenovo Yoga Book X90F / X91F / X91L */
+ }, {/* Lenovo Yoga Book X90F / X90L */
.matches = {
- /* Non exact match to match all versions */
- DMI_MATCH(DMI_PRODUCT_NAME, "Lenovo YB1-X9"),
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Intel Corporation"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "CHERRYVIEW D1 PLATFORM"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "YETI-11"),
+ },
+ .driver_data = (void *)_rightside_up,
+ }, {/* Lenovo Yoga Book X91F / X91L */
+ .matches = {
+ /* Non exact match to match F + L versions */
+ DMI_MATCH(DMI_PRODUCT_NAME, "Lenovo YB1-X91"),
},
.driver_data = (void *)_rightside_up,
}, {/* OneGX1 Pro */
--
2.39.2
[PATCH AUTOSEL 5.10 5/7] drm: panel-orientation-quirks: Add quirk for Lenovo Yoga Book X90F
From: Hans de Goede
[ Upstream commit 03aecb1acbcd7a660f97d645ca6c09d9de27ff9d ]
Like the Windows Lenovo Yoga Book X91F/L the Android Lenovo Yoga Book
X90F/L has a portrait 1200x1920 screen used in landscape mode,
add a quirk for this.
When the quirk for the X91F/L was initially added it was written to
also apply to the X90F/L but this does not work because the Android
version of the Yoga Book uses completely different DMI strings.
Also adjust the X91F/L quirk to reflect that it only applies to
the X91F/L models.
Signed-off-by: Hans de Goede
Reviewed-by: Javier Martinez Canillas
Link:
https://patchwork.freedesktop.org/patch/msgid/20230301095218.28457-1-hdego...@redhat.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 8768073794fbf..6106fa7c43028 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -284,10 +284,17 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "IdeaPad Duet 3 10IGL5"),
},
.driver_data = (void *)_rightside_up,
- }, {/* Lenovo Yoga Book X90F / X91F / X91L */
+ }, {/* Lenovo Yoga Book X90F / X90L */
.matches = {
- /* Non exact match to match all versions */
- DMI_MATCH(DMI_PRODUCT_NAME, "Lenovo YB1-X9"),
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Intel Corporation"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "CHERRYVIEW D1 PLATFORM"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "YETI-11"),
+ },
+ .driver_data = (void *)_rightside_up,
+ }, {/* Lenovo Yoga Book X91F / X91L */
+ .matches = {
+ /* Non exact match to match F + L versions */
+ DMI_MATCH(DMI_PRODUCT_NAME, "Lenovo YB1-X91"),
},
.driver_data = (void *)_rightside_up,
}, {/* OneGX1 Pro */
--
2.39.2
[PATCH AUTOSEL 5.15 07/11] drm: panel-orientation-quirks: Add quirk for Lenovo Yoga Book X90F
From: Hans de Goede
[ Upstream commit 03aecb1acbcd7a660f97d645ca6c09d9de27ff9d ]
Like the Windows Lenovo Yoga Book X91F/L the Android Lenovo Yoga Book
X90F/L has a portrait 1200x1920 screen used in landscape mode,
add a quirk for this.
When the quirk for the X91F/L was initially added it was written to
also apply to the X90F/L but this does not work because the Android
version of the Yoga Book uses completely different DMI strings.
Also adjust the X91F/L quirk to reflect that it only applies to
the X91F/L models.
Signed-off-by: Hans de Goede
Reviewed-by: Javier Martinez Canillas
Link:
https://patchwork.freedesktop.org/patch/msgid/20230301095218.28457-1-hdego...@redhat.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 8768073794fbf..6106fa7c43028 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -284,10 +284,17 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "IdeaPad Duet 3 10IGL5"),
},
.driver_data = (void *)_rightside_up,
- }, {/* Lenovo Yoga Book X90F / X91F / X91L */
+ }, {/* Lenovo Yoga Book X90F / X90L */
.matches = {
- /* Non exact match to match all versions */
- DMI_MATCH(DMI_PRODUCT_NAME, "Lenovo YB1-X9"),
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Intel Corporation"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "CHERRYVIEW D1 PLATFORM"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "YETI-11"),
+ },
+ .driver_data = (void *)_rightside_up,
+ }, {/* Lenovo Yoga Book X91F / X91L */
+ .matches = {
+ /* Non exact match to match F + L versions */
+ DMI_MATCH(DMI_PRODUCT_NAME, "Lenovo YB1-X91"),
},
.driver_data = (void *)_rightside_up,
}, {/* OneGX1 Pro */
--
2.39.2
[PATCH AUTOSEL 6.1 23/24] drm/amdgpu/gfx: set cg flags to enter/exit safe mode
From: Jane Jian [ Upstream commit e06bfcc1a1c41bcb8c31470d437e147ce9f0acfd ] sriov needs to enter/exit safe mode in update umd p state add the cg flag to let it enter or exit while needed Signed-off-by: Jane Jian Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c index 7a13129842602..0dd2fe4f071e8 100644 --- a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c @@ -1316,6 +1316,11 @@ static int gfx_v11_0_sw_init(void *handle) break; } + /* Enable CG flag in one VF mode for enabling RLC safe mode enter/exit */ + if (adev->ip_versions[GC_HWIP][0] == IP_VERSION(11, 0, 3) && + amdgpu_sriov_is_pp_one_vf(adev)) + adev->cg_flags = AMD_CG_SUPPORT_GFX_CGCG; + /* EOP Event */ r = amdgpu_irq_add_id(adev, SOC21_IH_CLIENTID_GRBM_CP, GFX_11_0_0__SRCID__CP_EOP_INTERRUPT, -- 2.39.2
[PATCH AUTOSEL 6.1 22/24] drm/amdgpu: Force signal hw_fences that are embedded in non-sched jobs
From: YuBiao Wang
[ Upstream commit 033c56474acf567a450f8bafca50e0b610f2b716 ]
[Why]
For engines not supporting soft reset, i.e. VCN, there will be a failed
ib test before mode 1 reset during asic reset. The fences in this case
are never signaled and next time when we try to free the sa_bo, kernel
will hang.
[How]
During pre_asic_reset, driver will clear job fences and afterwards the
fences' refcount will be reduced to 1. For drm_sched_jobs it will be
released in job_free_cb, and for non-sched jobs like ib_test, it's meant
to be released in sa_bo_free but only when the fences are signaled. So
we have to force signal the non_sched bad job's fence during
pre_asic_reset or the clear is not complete.
Signed-off-by: YuBiao Wang
Acked-by: Luben Tuikov
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
index 6fdb679321d0d..3cc1929285fc0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
@@ -624,6 +624,15 @@ void amdgpu_fence_driver_clear_job_fences(struct
amdgpu_ring *ring)
ptr = >fence_drv.fences[i];
old = rcu_dereference_protected(*ptr, 1);
if (old && old->ops == _job_fence_ops) {
+ struct amdgpu_job *job;
+
+ /* For non-scheduler bad job, i.e. failed ib test, we
need to signal
+* it right here or we won't be able to track them in
fence_drv
+* and they will remain unsignaled during sa_bo free.
+*/
+ job = container_of(old, struct amdgpu_job, hw_fence);
+ if (!job->base.s_fence && !dma_fence_is_signaled(old))
+ dma_fence_signal(old);
RCU_INIT_POINTER(*ptr, NULL);
dma_fence_put(old);
}
--
2.39.2
[PATCH AUTOSEL 6.1 21/24] drm/amdgpu: add mes resume when do gfx post soft reset
From: Tong Liu01
[ Upstream commit 4eb0b49a0ad3e004a6a65b84efe37bc7e66d560f ]
[why]
when gfx do soft reset, mes will also do reset, if mes is not
resumed when do recover from soft reset, mes is unable to respond
in later sequence
[how]
resume mes when do gfx post soft reset
Signed-off-by: Tong Liu01
Acked-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
index 90e739d9aeee7..7a13129842602 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
@@ -4625,6 +4625,14 @@ static bool gfx_v11_0_check_soft_reset(void *handle)
return false;
}
+static int gfx_v11_0_post_soft_reset(void *handle)
+{
+ /**
+* GFX soft reset will impact MES, need resume MES when do GFX soft
reset
+*/
+ return amdgpu_mes_resume((struct amdgpu_device *)handle);
+}
+
static uint64_t gfx_v11_0_get_gpu_clock_counter(struct amdgpu_device *adev)
{
uint64_t clock;
@@ -6068,6 +6076,7 @@ static const struct amd_ip_funcs gfx_v11_0_ip_funcs = {
.wait_for_idle = gfx_v11_0_wait_for_idle,
.soft_reset = gfx_v11_0_soft_reset,
.check_soft_reset = gfx_v11_0_check_soft_reset,
+ .post_soft_reset = gfx_v11_0_post_soft_reset,
.set_clockgating_state = gfx_v11_0_set_clockgating_state,
.set_powergating_state = gfx_v11_0_set_powergating_state,
.get_clockgating_state = gfx_v11_0_get_clockgating_state,
--
2.39.2
[PATCH AUTOSEL 6.1 13/24] drm: panel-orientation-quirks: Add quirk for Lenovo Yoga Book X90F
From: Hans de Goede
[ Upstream commit 03aecb1acbcd7a660f97d645ca6c09d9de27ff9d ]
Like the Windows Lenovo Yoga Book X91F/L the Android Lenovo Yoga Book
X90F/L has a portrait 1200x1920 screen used in landscape mode,
add a quirk for this.
When the quirk for the X91F/L was initially added it was written to
also apply to the X90F/L but this does not work because the Android
version of the Yoga Book uses completely different DMI strings.
Also adjust the X91F/L quirk to reflect that it only applies to
the X91F/L models.
Signed-off-by: Hans de Goede
Reviewed-by: Javier Martinez Canillas
Link:
https://patchwork.freedesktop.org/patch/msgid/20230301095218.28457-1-hdego...@redhat.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 5522d610c5cfd..b1a38e6ce2f8f 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -328,10 +328,17 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "IdeaPad Duet 3 10IGL5"),
},
.driver_data = (void *)_rightside_up,
- }, {/* Lenovo Yoga Book X90F / X91F / X91L */
+ }, {/* Lenovo Yoga Book X90F / X90L */
.matches = {
- /* Non exact match to match all versions */
- DMI_MATCH(DMI_PRODUCT_NAME, "Lenovo YB1-X9"),
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Intel Corporation"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "CHERRYVIEW D1 PLATFORM"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "YETI-11"),
+ },
+ .driver_data = (void *)_rightside_up,
+ }, {/* Lenovo Yoga Book X91F / X91L */
+ .matches = {
+ /* Non exact match to match F + L versions */
+ DMI_MATCH(DMI_PRODUCT_NAME, "Lenovo YB1-X91"),
},
.driver_data = (void *)_rightside_up,
}, {/* Lenovo Yoga Tablet 2 830F / 830L */
--
2.39.2
[PATCH AUTOSEL 6.2 24/25] drm/amdgpu/gfx: set cg flags to enter/exit safe mode
From: Jane Jian [ Upstream commit e06bfcc1a1c41bcb8c31470d437e147ce9f0acfd ] sriov needs to enter/exit safe mode in update umd p state add the cg flag to let it enter or exit while needed Signed-off-by: Jane Jian Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c index c748d92cec8e7..ddb7b8651ab4c 100644 --- a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c @@ -1315,6 +1315,11 @@ static int gfx_v11_0_sw_init(void *handle) break; } + /* Enable CG flag in one VF mode for enabling RLC safe mode enter/exit */ + if (adev->ip_versions[GC_HWIP][0] == IP_VERSION(11, 0, 3) && + amdgpu_sriov_is_pp_one_vf(adev)) + adev->cg_flags = AMD_CG_SUPPORT_GFX_CGCG; + /* EOP Event */ r = amdgpu_irq_add_id(adev, SOC21_IH_CLIENTID_GRBM_CP, GFX_11_0_0__SRCID__CP_EOP_INTERRUPT, -- 2.39.2
[PATCH AUTOSEL 6.2 22/25] drm/amdgpu: add mes resume when do gfx post soft reset
From: Tong Liu01
[ Upstream commit 4eb0b49a0ad3e004a6a65b84efe37bc7e66d560f ]
[why]
when gfx do soft reset, mes will also do reset, if mes is not
resumed when do recover from soft reset, mes is unable to respond
in later sequence
[how]
resume mes when do gfx post soft reset
Signed-off-by: Tong Liu01
Acked-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
index 66eb102cd88fb..c748d92cec8e7 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
@@ -4625,6 +4625,14 @@ static bool gfx_v11_0_check_soft_reset(void *handle)
return false;
}
+static int gfx_v11_0_post_soft_reset(void *handle)
+{
+ /**
+* GFX soft reset will impact MES, need resume MES when do GFX soft
reset
+*/
+ return amdgpu_mes_resume((struct amdgpu_device *)handle);
+}
+
static uint64_t gfx_v11_0_get_gpu_clock_counter(struct amdgpu_device *adev)
{
uint64_t clock;
@@ -6096,6 +6104,7 @@ static const struct amd_ip_funcs gfx_v11_0_ip_funcs = {
.wait_for_idle = gfx_v11_0_wait_for_idle,
.soft_reset = gfx_v11_0_soft_reset,
.check_soft_reset = gfx_v11_0_check_soft_reset,
+ .post_soft_reset = gfx_v11_0_post_soft_reset,
.set_clockgating_state = gfx_v11_0_set_clockgating_state,
.set_powergating_state = gfx_v11_0_set_powergating_state,
.get_clockgating_state = gfx_v11_0_get_clockgating_state,
--
2.39.2
[PATCH AUTOSEL 6.2 23/25] drm/amdgpu: Force signal hw_fences that are embedded in non-sched jobs
From: YuBiao Wang
[ Upstream commit 033c56474acf567a450f8bafca50e0b610f2b716 ]
[Why]
For engines not supporting soft reset, i.e. VCN, there will be a failed
ib test before mode 1 reset during asic reset. The fences in this case
are never signaled and next time when we try to free the sa_bo, kernel
will hang.
[How]
During pre_asic_reset, driver will clear job fences and afterwards the
fences' refcount will be reduced to 1. For drm_sched_jobs it will be
released in job_free_cb, and for non-sched jobs like ib_test, it's meant
to be released in sa_bo_free but only when the fences are signaled. So
we have to force signal the non_sched bad job's fence during
pre_asic_reset or the clear is not complete.
Signed-off-by: YuBiao Wang
Acked-by: Luben Tuikov
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
index faff4a3f96e6e..f52d0ba91a770 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
@@ -678,6 +678,15 @@ void amdgpu_fence_driver_clear_job_fences(struct
amdgpu_ring *ring)
ptr = >fence_drv.fences[i];
old = rcu_dereference_protected(*ptr, 1);
if (old && old->ops == _job_fence_ops) {
+ struct amdgpu_job *job;
+
+ /* For non-scheduler bad job, i.e. failed ib test, we
need to signal
+* it right here or we won't be able to track them in
fence_drv
+* and they will remain unsignaled during sa_bo free.
+*/
+ job = container_of(old, struct amdgpu_job, hw_fence);
+ if (!job->base.s_fence && !dma_fence_is_signaled(old))
+ dma_fence_signal(old);
RCU_INIT_POINTER(*ptr, NULL);
dma_fence_put(old);
}
--
2.39.2
[PATCH AUTOSEL 6.2 14/25] drm: panel-orientation-quirks: Add quirk for Lenovo Yoga Book X90F
From: Hans de Goede
[ Upstream commit 03aecb1acbcd7a660f97d645ca6c09d9de27ff9d ]
Like the Windows Lenovo Yoga Book X91F/L the Android Lenovo Yoga Book
X90F/L has a portrait 1200x1920 screen used in landscape mode,
add a quirk for this.
When the quirk for the X91F/L was initially added it was written to
also apply to the X90F/L but this does not work because the Android
version of the Yoga Book uses completely different DMI strings.
Also adjust the X91F/L quirk to reflect that it only applies to
the X91F/L models.
Signed-off-by: Hans de Goede
Reviewed-by: Javier Martinez Canillas
Link:
https://patchwork.freedesktop.org/patch/msgid/20230301095218.28457-1-hdego...@redhat.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 5522d610c5cfd..b1a38e6ce2f8f 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -328,10 +328,17 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "IdeaPad Duet 3 10IGL5"),
},
.driver_data = (void *)_rightside_up,
- }, {/* Lenovo Yoga Book X90F / X91F / X91L */
+ }, {/* Lenovo Yoga Book X90F / X90L */
.matches = {
- /* Non exact match to match all versions */
- DMI_MATCH(DMI_PRODUCT_NAME, "Lenovo YB1-X9"),
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Intel Corporation"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "CHERRYVIEW D1 PLATFORM"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "YETI-11"),
+ },
+ .driver_data = (void *)_rightside_up,
+ }, {/* Lenovo Yoga Book X91F / X91L */
+ .matches = {
+ /* Non exact match to match F + L versions */
+ DMI_MATCH(DMI_PRODUCT_NAME, "Lenovo YB1-X91"),
},
.driver_data = (void *)_rightside_up,
}, {/* Lenovo Yoga Tablet 2 830F / 830L */
--
2.39.2
Re: [PATCH v3 04/38] drm/msm/dpu: move UBWC/memory configuration to separate struct
On 3/30/2023 2:52 PM, Dmitry Baryshkov wrote: UBWC and highest bank settings differ slightly between different DPU units of the same generation, while the dpu_caps and dpu_mdp_cfg are much more stable. To ease configuration reuse move ubwc_swizzle and highest_bank_bit data to separate structure. Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov --- Reviewed-by: Abhinav Kumar
Re: [PATCH v3 03/38] drm/msm/dpu: mark remaining pp data as const
On 3/30/2023 2:52 PM, Dmitry Baryshkov wrote: Fix several leftover _pp strutures and mark them as const, making all hw catalog fit into the rodata section. Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov --- Reviewed-by: Abhinav Kumar
Re: [Freedreno] [PATCH v3 02/38] drm/msm/dpu: constify DSC data structures
On 3/30/2023 2:52 PM, Dmitry Baryshkov wrote: DSC hw catalog data is not supposed to be changed, so mark it as const data. Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov --- Reviewed-by: Abhinav Kumar
Re: [PATCH v3 01/38] drm/msm/dpu: Allow variable SSPP/INTF_BLK size
On 3/30/2023 2:52 PM, Dmitry Baryshkov wrote:
From: Konrad Dybcio
These blocks are of variable length on different SoCs. Set the
correct values where I was able to retrieve it from downstream
DTs and leave the old defaults (0x1c8 for sspp and 0x280 for
intf) otherwise.
Signed-off-by: Konrad Dybcio
[DB: fixed some of lengths]
Signed-off-by: Dmitry Baryshkov
Can you please split this to two changes one for SSPP and one for INTF
block?
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 243 +-
1 file changed, 122 insertions(+), 121 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 6840b22a4159..e44e7455a56e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -1172,11 +1172,11 @@ static const struct dpu_sspp_sub_blks sdm845_dma_sblk_1 =
_DMA_SBLK("9", 2);
static const struct dpu_sspp_sub_blks sdm845_dma_sblk_2 = _DMA_SBLK("10", 3);
static const struct dpu_sspp_sub_blks sdm845_dma_sblk_3 = _DMA_SBLK("11", 4);
-#define SSPP_BLK(_name, _id, _base, _features, \
+#define SSPP_BLK(_name, _id, _base, _len, _features, \
_sblk, _xinid, _type, _clkctrl) \
{ \
.name = _name, .id = _id, \
- .base = _base, .len = 0x1c8, \
+ .base = _base, .len = _len, \
.features = _features, \
.sblk = &_sblk, \
.xin_id = _xinid, \
@@ -1185,40 +1185,40 @@ static const struct dpu_sspp_sub_blks sdm845_dma_sblk_3 =
_DMA_SBLK("11", 4);
}
static const struct dpu_sspp_cfg msm8998_sspp[] = {
- SSPP_BLK("sspp_0", SSPP_VIG0, 0x4000, VIG_MSM8998_MASK,
+ SSPP_BLK("sspp_0", SSPP_VIG0, 0x4000, 0x1ac, VIG_MSM8998_MASK,
msm8998_vig_sblk_0, 0, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG0),
- SSPP_BLK("sspp_1", SSPP_VIG1, 0x6000, VIG_MSM8998_MASK,
+ SSPP_BLK("sspp_1", SSPP_VIG1, 0x6000, 0x1ac, VIG_MSM8998_MASK,
msm8998_vig_sblk_1, 4, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG1),
- SSPP_BLK("sspp_2", SSPP_VIG2, 0x8000, VIG_MSM8998_MASK,
+ SSPP_BLK("sspp_2", SSPP_VIG2, 0x8000, 0x1ac, VIG_MSM8998_MASK,
msm8998_vig_sblk_2, 8, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG2),
- SSPP_BLK("sspp_3", SSPP_VIG3, 0xa000, VIG_MSM8998_MASK,
+ SSPP_BLK("sspp_3", SSPP_VIG3, 0xa000, 0x1ac, VIG_MSM8998_MASK,
msm8998_vig_sblk_3, 12, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG3),
- SSPP_BLK("sspp_8", SSPP_DMA0, 0x24000, DMA_MSM8998_MASK,
+ SSPP_BLK("sspp_8", SSPP_DMA0, 0x24000, 0x1ac, DMA_MSM8998_MASK,
sdm845_dma_sblk_0, 1, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA0),
- SSPP_BLK("sspp_9", SSPP_DMA1, 0x26000, DMA_MSM8998_MASK,
+ SSPP_BLK("sspp_9", SSPP_DMA1, 0x26000, 0x1ac, DMA_MSM8998_MASK,
sdm845_dma_sblk_1, 5, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA1),
- SSPP_BLK("sspp_10", SSPP_DMA2, 0x28000, DMA_CURSOR_MSM8998_MASK,
+ SSPP_BLK("sspp_10", SSPP_DMA2, 0x28000, 0x1ac, DMA_CURSOR_MSM8998_MASK,
sdm845_dma_sblk_2, 9, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA2),
- SSPP_BLK("sspp_11", SSPP_DMA3, 0x2a000, DMA_CURSOR_MSM8998_MASK,
+ SSPP_BLK("sspp_11", SSPP_DMA3, 0x2a000, 0x1ac, DMA_CURSOR_MSM8998_MASK,
sdm845_dma_sblk_3, 13, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA3),
};
static const struct dpu_sspp_cfg sdm845_sspp[] = {
- SSPP_BLK("sspp_0", SSPP_VIG0, 0x4000, VIG_SDM845_MASK_SDMA,
+ SSPP_BLK("sspp_0", SSPP_VIG0, 0x4000, 0x1c8, VIG_SDM845_MASK_SDMA,
sdm845_vig_sblk_0, 0, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG0),
- SSPP_BLK("sspp_1", SSPP_VIG1, 0x6000, VIG_SDM845_MASK_SDMA,
+ SSPP_BLK("sspp_1", SSPP_VIG1, 0x6000, 0x1c8, VIG_SDM845_MASK_SDMA,
sdm845_vig_sblk_1, 4, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG1),
- SSPP_BLK("sspp_2", SSPP_VIG2, 0x8000, VIG_SDM845_MASK_SDMA,
+ SSPP_BLK("sspp_2", SSPP_VIG2, 0x8000, 0x1c8, VIG_SDM845_MASK_SDMA,
sdm845_vig_sblk_2, 8, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG2),
- SSPP_BLK("sspp_3", SSPP_VIG3, 0xa000, VIG_SDM845_MASK_SDMA,
+ SSPP_BLK("sspp_3", SSPP_VIG3, 0xa000, 0x1c8, VIG_SDM845_MASK_SDMA,
sdm845_vig_sblk_3, 12, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG3),
- SSPP_BLK("sspp_8", SSPP_DMA0, 0x24000, DMA_SDM845_MASK_SDMA,
+ SSPP_BLK("sspp_8", SSPP_DMA0, 0x24000, 0x1c8, DMA_SDM845_MASK_SDMA,
sdm845_dma_sblk_0, 1, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA0),
- SSPP_BLK("sspp_9", SSPP_DMA1, 0x26000, DMA_SDM845_MASK_SDMA,
+ SSPP_BLK("sspp_9", SSPP_DMA1, 0x26000, 0x1c8, DMA_SDM845_MASK_SDMA,
sdm845_dma_sblk_1, 5, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA1),
- SSPP_BLK("sspp_10", SSPP_DMA2, 0x28000, DMA_CURSOR_SDM845_MASK_SDMA,
+ SSPP_BLK("sspp_10", SSPP_DMA2, 0x28000, 0x1c8,
DMA_CURSOR_SDM845_MASK_SDMA,
sdm845_dma_sblk_2, 9, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA2),
- SSPP_BLK("sspp_11",
Re: [PATCH v8 04/10] drm/hdcp: Expand HDCP helper library for enable/disable/check
Hi Mark,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next-fixes]
[also build test WARNING on drm/drm-next linus/master v6.3-rc4 next-20230331]
[cannot apply to drm-misc/drm-misc-next drm-intel/for-linux-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Mark-Yacoub/drm-hdcp-Add-drm_hdcp_atomic_check/20230401-061425
base: git://anongit.freedesktop.org/drm-intel for-linux-next-fixes
patch link:
https://lore.kernel.org/r/20230331221213.1691997-5-markyacoub%40google.com
patch subject: [PATCH v8 04/10] drm/hdcp: Expand HDCP helper library for
enable/disable/check
config: riscv-allmodconfig
(https://download.01.org/0day-ci/archive/20230401/202304010815.5ivfi5nv-...@intel.com/config)
compiler: riscv64-linux-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/82a092e7e090cdeb3ff18498e6ad671906268631
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Mark-Yacoub/drm-hdcp-Add-drm_hdcp_atomic_check/20230401-061425
git checkout 82a092e7e090cdeb3ff18498e6ad671906268631
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1
O=build_dir ARCH=riscv olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1
O=build_dir ARCH=riscv SHELL=/bin/bash drivers/gpu/drm/display/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
| Link:
https://lore.kernel.org/oe-kbuild-all/202304010815.5ivfi5nv-...@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/display/drm_hdcp_helper.c:719: warning: This comment starts
>> with '/**', but isn't a kernel-doc comment. Refer
>> Documentation/doc-guide/kernel-doc.rst
* Check if the sink is capable of HDCP 1.x. DisplayPort has a dedicated bit
drivers/gpu/drm/display/drm_hdcp_helper.c:742: warning: This comment starts
with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
* Check if the sink is capable of HDCP 1.x. HDMI spec states that
transmitters
drivers/gpu/drm/display/drm_hdcp_helper.c:1633: warning: Function parameter
or member 'aux' not described in 'drm_hdcp_helper_initialize_dp'
vim +719 drivers/gpu/drm/display/drm_hdcp_helper.c
717
718 /**
> 719 * Check if the sink is capable of HDCP 1.x. DisplayPort has a
> dedicated bit
720 * for this in DPCD.
721 *
722 * @data: pointer to the HDCP helper data.
723 * @capable: pointer to a bool which will contain true if the sink is
capable.
724 *
725 * Returns:
726 * -errno if the transacation between source and sink fails.
727 */
728 int drm_hdcp_helper_hdcp1_capable_dp(struct drm_hdcp_helper_data *data,
729 bool *capable)
730 {
731 int ret;
732 u8 bcaps;
733
734 ret = data->funcs->remote_read(data, data->hdcp1_lut->bcaps,
, 1);
735 *capable = !ret && (bcaps & DP_BCAPS_HDCP_CAPABLE);
736
737 return 0;
738 }
739 EXPORT_SYMBOL(drm_hdcp_helper_hdcp1_capable_dp);
740
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
Re: [PATCH] drm/nouveau/disp: Support more modes by checking with lower bpc
On Fri, Mar 31, 2023 at 12:39 AM Karol Herbst wrote:
>
> This allows us to advertise more modes especially on HDR displays.
>
> Fixes using 4K@60 modes on my TV and main display both using a HDMI to DP
> adapter. Also fixes similiar issues for users running into this.
>
> Cc: sta...@vger.kernel.org # 5.10+
> Signed-off-by: Karol Herbst
> ---
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 32 +
> drivers/gpu/drm/nouveau/nouveau_dp.c| 8 ---
> 2 files changed, 37 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index ed9d374147b8d..f28e47c161dd9 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -363,6 +363,35 @@ nv50_outp_atomic_check_view(struct drm_encoder *encoder,
> return 0;
> }
>
> +static void
> +nv50_outp_atomic_fix_depth(struct drm_encoder *encoder, struct
> drm_crtc_state *crtc_state)
> +{
> + struct nv50_head_atom *asyh = nv50_head_atom(crtc_state);
> + struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
> + struct drm_display_mode *mode = >state.adjusted_mode;
> + unsigned int max_rate, mode_rate;
> +
> + switch (nv_encoder->dcb->type) {
> + case DCB_OUTPUT_DP:
> + max_rate = nv_encoder->dp.link_nr * nv_encoder->dp.link_bw;
> +
> +/* we don't support more than 10 anyway */
> + asyh->or.bpc = max_t(u8, asyh->or.bpc, 10);
luckily I didn't push yet, but this has to be `min_t` :)
> +
> + /* reduce the bpc until it works out */
> + while (asyh->or.bpc > 6) {
> + mode_rate = DIV_ROUND_UP(mode->clock * asyh->or.bpc *
> 3, 8);
> + if (mode_rate <= max_rate)
> + break;
> +
> + asyh->or.bpc -= 2;
> + }
> + break;
> + default:
> + break;
> + }
> +}
> +
> static int
> nv50_outp_atomic_check(struct drm_encoder *encoder,
>struct drm_crtc_state *crtc_state,
> @@ -381,6 +410,9 @@ nv50_outp_atomic_check(struct drm_encoder *encoder,
> if (crtc_state->mode_changed || crtc_state->connectors_changed)
> asyh->or.bpc = connector->display_info.bpc;
>
> + /* We might have to reduce the bpc */
> + nv50_outp_atomic_fix_depth(encoder, crtc_state);
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
> b/drivers/gpu/drm/nouveau/nouveau_dp.c
> index e00876f92aeea..d49b4875fc3c9 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_dp.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
> @@ -263,8 +263,6 @@ nouveau_dp_irq(struct work_struct *work)
> }
>
> /* TODO:
> - * - Use the minimum possible BPC here, once we add support for the max bpc
> - * property.
> * - Validate against the DP caps advertised by the GPU (we don't check these
> * yet)
> */
> @@ -276,7 +274,11 @@ nv50_dp_mode_valid(struct drm_connector *connector,
> {
> const unsigned int min_clock = 25000;
> unsigned int max_rate, mode_rate, ds_max_dotclock, clock =
> mode->clock;
> - const u8 bpp = connector->display_info.bpc * 3;
> + /* Check with the minmum bpc always, so we can advertise better modes.
> +* In particlar not doing this causes modes to be dropped on HDR
> +* displays as we might check with a bpc of 16 even.
> +*/
> + const u8 bpp = 6 * 3;
>
> if (mode->flags & DRM_MODE_FLAG_INTERLACE && !outp->caps.dp_interlace)
> return MODE_NO_INTERLACE;
> --
> 2.39.2
>
Re: [PATCH v10 11/15] drm/atomic-helper: Set fence deadline for vblank
> [ 20.550946] drm_atomic_helper_commit+0xb0/0x188 > > [ 20.550949] drm_atomic_commit+0xb0/0xf0 > > [ 20.550953] drm_client_modeset_commit_atomic+0x218/0x280 > > [ 20.550957] drm_client_modeset_commit_locked+0x64/0x1a0 > > [ 20.550961] drm_client_modeset_commit+0x38/0x68 > > [ 20.550965] __drm_fb_helper_restore_fbdev_mode_unlocked+0xb0/0xf8 > > [ 20.550970] drm_fb_helper_set_par+0x44/0x88 > > [ 20.550973] fbcon_init+0x1e0/0x4a8 > > [ 20.550976] visual_init+0xbc/0x118 > > [ 20.550981] do_bind_con_driver.isra.0+0x194/0x3a0 > > [ 20.550984] do_take_over_console+0x50/0x70 > > [ 20.550987] do_fbcon_takeover+0x74/0xf8 > > [ 20.550989] do_fb_registered+0x13c/0x158 > > [ 20.550992] fbcon_register_existing_fbs+0x78/0xc0 > > [ 20.550995] process_one_work+0x1ec/0x478 > > [ 20.551000] worker_thread+0x74/0x418 > > [ 20.551002] kthread+0xec/0x100 > > [ 20.551005] ret_from_fork+0x10/0x20 > > [ 20.551011] Code: f944 b9409013 f940a082 9ba30a73 (b9407662) > > [ 20.551013] ---[ end trace ]--- > > > > If there is any additional information that I can provide or patches I > > can test, I am more than happy to do so. > > > > Cheers, > > Nathan > > > > # bad: [4b0f4525dc4fe8af17b3daefe585f0c2eb0fe0a5] Add linux-next specific > > files for 20230331 > > # good: [b2bc47e9b2011a183f9d3d3454a294a938082fb9] Merge tag 'net-6.3-rc5' > > of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net > > git bisect start '4b0f4525dc4fe8af17b3daefe585f0c2eb0fe0a5' > > 'b2bc47e9b2011a183f9d3d3454a294a938082fb9' > > # good: [ed5f95f3349003d74a4a11b27b0f05d6794c382a] Merge branch 'master' of > > git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git > > git bisect good ed5f95f3349003d74a4a11b27b0f05d6794c382a > > # bad: [85f7d1bfa30a05df2c9d8a0e9f6b1f23b4a6f13b] Merge branch 'for-next' > > of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-dt.git > > git bisect bad 85f7d1bfa30a05df2c9d8a0e9f6b1f23b4a6f13b > > # bad: [fbd0f79f200f8e5cb73fb3d7b788de09a8f33a6f] Merge branch 'msm-next' > > of https://gitlab.freedesktop.org/drm/msm.git > > git bisect bad fbd0f79f200f8e5cb73fb3d7b788de09a8f33a6f > > # good: [90031bc33f7525f0cc7a9ef0b1df62a1a4463382] Merge tag > > 'amd-drm-next-6.4-2023-03-17' of https://gitlab.freedesktop.org/agd5f/linux > > into drm-next > > git bisect good 90031bc33f7525f0cc7a9ef0b1df62a1a4463382 > > # good: [d4e04817db670083aed73de1fadd3b21758e69ba] drm/amdgpu: Return from > > switch early for EEPROM I2C address > > git bisect good d4e04817db670083aed73de1fadd3b21758e69ba > > # good: [70e360f9b548d99f959668d4f047d1363d42fe8e] drm: exynos: dsi: > > Consolidate component and bridge > > git bisect good 70e360f9b548d99f959668d4f047d1363d42fe8e > > # bad: [0b43595d0cbb06736d1e572e79e29a410a273573] Merge branch 'drm-next' > > of https://gitlab.freedesktop.org/agd5f/linux > > git bisect bad 0b43595d0cbb06736d1e572e79e29a410a273573 > > # good: [fbb3b3500f76ec8b741bd2d0e761ca3e856ad924] dt-bindings: display: > > boe,tv101wum-nl6: document rotation > > git bisect good fbb3b3500f76ec8b741bd2d0e761ca3e856ad924 > > # bad: [82bbec189ab34873688484cd14189a5392946fbb] Merge v6.3-rc4 into > > drm-next > > git bisect bad 82bbec189ab34873688484cd14189a5392946fbb > > # bad: [d39e48ca80c0960b039cb38633957f0040f63e1a] drm/atomic-helper: Set > > fence deadline for vblank > > git bisect bad d39e48ca80c0960b039cb38633957f0040f63e1a > > # good: [d7d5a21dd6b4706c04fbba5d25db8da5f25aab68] dma-buf/dma-resv: Add a > > way to set fence deadline > > git bisect good d7d5a21dd6b4706c04fbba5d25db8da5f25aab68 > > # good: [f3823da7e4ba7d4781375c2bb786a8a78efc6591] drm/scheduler: Add fence > > deadline support > > git bisect good f3823da7e4ba7d4781375c2bb786a8a78efc6591 > > # good: [b2c077d001b612b1f34f7e528b2dc6072bd6794e] drm/vblank: Add helper > > to get next vblank time > > git bisect good b2c077d001b612b1f34f7e528b2dc6072bd6794e > > # first bad commit: [d39e48ca80c0960b039cb38633957f0040f63e1a] > > drm/atomic-helper: Set fence deadline for vblank
[CI] drm/i915/mtl: Define GuC firmware version for MTL
From: John Harrison First release of GuC for Meteorlake. NB: As this is still pre-release and likely to change, use explicit versioning for now. The official, full release will use reduced version naming. Signed-off-by: John Harrison --- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 + 1 file changed, 1 insertion(+) 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 264c952f777bb..1ac6f9f340e31 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c @@ -79,6 +79,7 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw, * security fixes, etc. to be enabled. */ #define INTEL_GUC_FIRMWARE_DEFS(fw_def, guc_maj, guc_mmp) \ + fw_def(METEORLAKE, 0, guc_mmp(mtl, 70, 6, 5)) \ fw_def(DG2, 0, guc_maj(dg2, 70, 5)) \ fw_def(ALDERLAKE_P, 0, guc_maj(adlp, 70, 5)) \ fw_def(ALDERLAKE_P, 0, guc_mmp(adlp, 70, 1, 1)) \ -- 2.39.1
[pull] amdgpu, amdkfd, radeon drm-next-6.4
Hi Dave, Daniel, More new stuff for 6.4. The following changes since commit d36d68fd1925d33066d52468b7c7c6aca6521248: Merge tag 'drm-habanalabs-next-2023-03-20' of https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/linux into drm-next (2023-03-22 10:35:46 +1000) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-next-6.4-2023-03-31 for you to fetch changes up to feae1bd80ec69a3a0011ba1fb88994785f705e3e: drm/amd/pm: enable sysfs node vclk1 and dclk1 for NV3X (2023-03-31 11:18:55 -0400) amd-drm-next-6.4-2023-03-31: amdgpu: - Misc code cleanups - S4 fixes - MES fixes - SR-IOV fixes - Link DC backlight to connector device rather than PCI device - W=1 fixes - ASPM quirk - RAS fixes - DC dynamic split fixes and enablement for remaining chips - Navi1x SMU fix - Initial NBIO 7.9 support - Initial GC 9.4.3 support - Initial GFXHUB 1.2 support - Initial MMHUB 1.8 support - DCN 3.1.5 fixes - Initial DC FAMs infrastructure - Add support for 6.75Gbps link rates - Add sysfs nodes for secondary VCN clocks amdkfd: - Initial support for GC 9.4.3 radeon: - Convert to client-based fbdev emulation Alex Deucher (3): drm/amdgpu: drop the extra sign extension Revert "drm/amdgpu/display: change pipe policy for DCN 2.0" drm/amd/pm: enable TEMP_DEPENDENT_VMIN for navi1x Alex Hung (1): drm/amd/display: remove outdated 8bpc comments Alvin Lee (6): drm/amd/display: Enable FPO for configs that could reduce vlevel drm/amd/display: Update FCLK change latency drm/amd/display: Use per pipe P-State force for FPO drm/amd/display: Only keep cursor p-state force for FPO drm/amd/display: Enable FPO optimization drm/amd/display: Uncomment assignments after HW headers are promoted Amber Lin (2): drm/amdkfd: Set noretry/xnack for GC 9.4.3 drm/amdkfd: Set TG_CHUNK_SIZE for GC 9.4.3 Anthony Koo (1): drm/amd/display: [FW Promotion] Release 0.0.160.0 Aric Cyr (2): drm/amd/display: 3.2.228 drm/amd/display: Promote DAL to 3.2.229 Artem Grishin (2): drm/amd/display: Add support for 6.75 GBps link rate drm/amd/display: Conditionally enable 6.75 GBps link rate Ayush Gupta (1): drm/amd/display: fixed dcn30+ underflow issue Bill Liu (1): drm/amdgpu: Adding CAP firmware initialization Caio Novais (2): drm/amd/display: Remove unused variable 'scl_enable' drm/amd/display: Mark function 'optc3_wait_drr_doublebuffer_pending_clear' as static Charlene Liu (4): drm/amd/display: update dio for two pixel per container case drm/amd/display: Add CRC and DMUB test support drm/amd/display: add missing code change init pix_per_cycle drm/amd/display: update dig enable sequence Christophe JAILLET (1): drm/amd/display: Slightly optimize dm_dmub_outbox1_low_irq() Dmytro Laktyushkin (1): drm/amd/display: w/a for dcn315 inconsistent smu clock table Hans de Goede (6): drm/amd/display/amdgpu_dm: Fix backlight_device_register() error handling drm/amd/display/amdgpu_dm: Refactor register_backlight_device() drm/amd/display/amdgpu_dm: Add a bl_idx to amdgpu_dm_connector drm/amd/display/amdgpu_dm: Move most backlight setup into setup_backlight_device() drm/amd/display/amdgpu_dm: Make amdgpu_dm_register_backlight_device() take an amdgpu_dm_connector drm/amd/display/amdgpu_dm: Pass proper parent for backlight device registration v3 Hawking Zhang (14): drm/amdgpu: Initialize umc ras callback drm/amdgpu: Add fatal error handling in nbio v4_3 drm/amdgpu: add nbio v7_9_0 ip headers drm/amdgpu: add nbio v7_9 support drm/amdgpu: init nbio v7_9 callbacks drm/amdgpu: Set family for GC 9.4.3 drm/amdgpu: add athub v1_8_0 ip headers drm/amdgpu: add osssys v4_4_2 ip headers drm/amdgpu: add gc v9_4_3 ip headers drm/amdgpu: add gmc ip block support for GC 9.4.3 drm/amdgpu: add mmhub v1_8_0 ip headers drm/amdgpu: add GMC ip block for GC 9.4.3 drm/amdgpu: Correct xgmi_wafl block name drm/amdkfd: Add GC 9.4.3 KFD support Hersen Wu (3): drm/amd/display: align commit_planes_for_stream to latest dc code drm/amd/display: fix wrong index used in dccg32_set_dpstreamclk drm/amd/display: Set dcn32 caps.seamless_odm Jack Xiao (1): drm/amd/amdgpu: limit one queue per gang Jane Jian (2): drm/amdgpu/gfx: set cg flags to enter/exit safe mode drm/amdgpu/jpeg: enable jpeg v4_0 for sriov Jay Cornwall (1): drm/amdkfd: Trap handler changes for GC 9.4.3 v2 Jiapeng Chong (4): drm/amd/display: make is_synaptics_cascaded_panamera static drm/amd/display: Remove the unused function link_timing_bandwidth_kbps() drm/amd/display: Clean up some inconsistent indenting
[CI] drm/i915/mtl: Define GuC firmware version for MTL
From: John Harrison First release of GuC for Meteorlake. NB: As this is still pre-release and likely to change, use explicit versioning for now. The official, full release will use reduced version naming. Signed-off-by: John Harrison --- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 + 1 file changed, 1 insertion(+) 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 264c952f777bb..ae25cfbdc697e 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c @@ -79,6 +79,7 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw, * security fixes, etc. to be enabled. */ #define INTEL_GUC_FIRMWARE_DEFS(fw_def, guc_maj, guc_mmp) \ + fw_def(METEORLAKE, 0, guc_mmp(mtl, 70, 6, 4)) \ fw_def(DG2, 0, guc_maj(dg2, 70, 5)) \ fw_def(ALDERLAKE_P, 0, guc_maj(adlp, 70, 5)) \ fw_def(ALDERLAKE_P, 0, guc_mmp(adlp, 70, 1, 1)) \ -- 2.39.1
Re: [PATCH v10 11/15] drm/atomic-helper: Set fence deadline for vblank
a0 > [ 20.550984] do_take_over_console+0x50/0x70 > [ 20.550987] do_fbcon_takeover+0x74/0xf8 > [ 20.550989] do_fb_registered+0x13c/0x158 > [ 20.550992] fbcon_register_existing_fbs+0x78/0xc0 > [ 20.550995] process_one_work+0x1ec/0x478 > [ 20.551000] worker_thread+0x74/0x418 > [ 20.551002] kthread+0xec/0x100 > [ 20.551005] ret_from_fork+0x10/0x20 > [ 20.551011] Code: f944 b9409013 f940a082 9ba30a73 (b9407662) > [ 20.551013] ---[ end trace ]--- > > If there is any additional information that I can provide or patches I > can test, I am more than happy to do so. > > Cheers, > Nathan > > # bad: [4b0f4525dc4fe8af17b3daefe585f0c2eb0fe0a5] Add linux-next specific > files for 20230331 > # good: [b2bc47e9b2011a183f9d3d3454a294a938082fb9] Merge tag 'net-6.3-rc5' of > git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net > git bisect start '4b0f4525dc4fe8af17b3daefe585f0c2eb0fe0a5' > 'b2bc47e9b2011a183f9d3d3454a294a938082fb9' > # good: [ed5f95f3349003d74a4a11b27b0f05d6794c382a] Merge branch 'master' of > git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git > git bisect good ed5f95f3349003d74a4a11b27b0f05d6794c382a > # bad: [85f7d1bfa30a05df2c9d8a0e9f6b1f23b4a6f13b] Merge branch 'for-next' of > git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-dt.git > git bisect bad 85f7d1bfa30a05df2c9d8a0e9f6b1f23b4a6f13b > # bad: [fbd0f79f200f8e5cb73fb3d7b788de09a8f33a6f] Merge branch 'msm-next' of > https://gitlab.freedesktop.org/drm/msm.git > git bisect bad fbd0f79f200f8e5cb73fb3d7b788de09a8f33a6f > # good: [90031bc33f7525f0cc7a9ef0b1df62a1a4463382] Merge tag > 'amd-drm-next-6.4-2023-03-17' of https://gitlab.freedesktop.org/agd5f/linux > into drm-next > git bisect good 90031bc33f7525f0cc7a9ef0b1df62a1a4463382 > # good: [d4e04817db670083aed73de1fadd3b21758e69ba] drm/amdgpu: Return from > switch early for EEPROM I2C address > git bisect good d4e04817db670083aed73de1fadd3b21758e69ba > # good: [70e360f9b548d99f959668d4f047d1363d42fe8e] drm: exynos: dsi: > Consolidate component and bridge > git bisect good 70e360f9b548d99f959668d4f047d1363d42fe8e > # bad: [0b43595d0cbb06736d1e572e79e29a410a273573] Merge branch 'drm-next' of > https://gitlab.freedesktop.org/agd5f/linux > git bisect bad 0b43595d0cbb06736d1e572e79e29a410a273573 > # good: [fbb3b3500f76ec8b741bd2d0e761ca3e856ad924] dt-bindings: display: > boe,tv101wum-nl6: document rotation > git bisect good fbb3b3500f76ec8b741bd2d0e761ca3e856ad924 > # bad: [82bbec189ab34873688484cd14189a5392946fbb] Merge v6.3-rc4 into drm-next > git bisect bad 82bbec189ab34873688484cd14189a5392946fbb > # bad: [d39e48ca80c0960b039cb38633957f0040f63e1a] drm/atomic-helper: Set > fence deadline for vblank > git bisect bad d39e48ca80c0960b039cb38633957f0040f63e1a > # good: [d7d5a21dd6b4706c04fbba5d25db8da5f25aab68] dma-buf/dma-resv: Add a > way to set fence deadline > git bisect good d7d5a21dd6b4706c04fbba5d25db8da5f25aab68 > # good: [f3823da7e4ba7d4781375c2bb786a8a78efc6591] drm/scheduler: Add fence > deadline support > git bisect good f3823da7e4ba7d4781375c2bb786a8a78efc6591 > # good: [b2c077d001b612b1f34f7e528b2dc6072bd6794e] drm/vblank: Add helper to > get next vblank time > git bisect good b2c077d001b612b1f34f7e528b2dc6072bd6794e > # first bad commit: [d39e48ca80c0960b039cb38633957f0040f63e1a] > drm/atomic-helper: Set fence deadline for vblank
[PATCH v8 09/10] arm64: dts: qcom: sc7180: Add support for HDCP in dp-controller
From: Sean Paul
Add the register ranges required for HDCP key injection and
HDCP TrustZone interaction as described in the dt-bindings for the
sc7180 dp controller.
Reviewed-by: Douglas Anderson
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
---
Changes in v3:
-Split off into a new patch containing just the dts change (Stephen)
-Add hdcp compatible string (Stephen)
Changes in v4:
-Rebase on Bjorn's multi-dp patchset
Changes in v5:
-Put the tz register offsets in trogdor dtsi (Rob C)
Changes in v6:
-Rebased: Removed modifications in sc7180.dtsi as it's already upstream
Changes in v7:
-Change registers offset
Changes in v8:
-None
arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
index 423630c4d02c7..89d913fa6e3eb 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
@@ -822,6 +822,14 @@ _dp {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_hot_plug_det>;
+
+ reg = <0 0x0ae9 0 0x200>,
+ <0 0x0ae90200 0 0x200>,
+ <0 0x0ae90400 0 0xc00>,
+ <0 0x0ae91000 0 0x400>,
+ <0 0x0ae91400 0 0x400>,
+ <0 0x0aed1000 0 0x174>,
+ <0 0x0aee1000 0 0x2c>;
};
_dp_out {
--
2.40.0.348.gf938b09366-goog
[PATCH v8 10/10] drm/msm: Implement HDCP 1.x using the new drm HDCP helpers
From: Sean Paul
Add HDCP 1.x support to msm DP bridges using the new HDCP
helpers.
Cc: Stephen Boyd
Reviewed-by: Stephen Boyd
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
---
Changes in v2:
-Squash [1] into this patch with the following changes (Stephen)
-Update the sc7180 dtsi file
-Remove resource names and just use index (Stephen)
Changes in v3:
-Split out the dtsi change from v2 (Stephen)
-Fix set-but-unused warning identified by 0-day
-Fix up a couple of style nits (Stephen)
-Store HDCP key directly in dp_hdcp struct (Stephen)
-Remove wmb in HDCP key initialization, move an_seed (Stephen)
-Use FIELD_PREP for bstatus/bcaps (Stephen)
-#define read_poll_timeout values (Stephen)
-Remove unnecessary parentheses in dp_hdcp_store_ksv_fifo (Stephen)
-Add compatible string for hdcp (Stephen)
-Rename dp_hdcp_write_* functions (Abhinav)
-Add 1us delay between An reads (Abhinav)
-Delete unused dp_hdcp_read_* functions
Changes in v4:
-Rebase on Bjorn's multi-dp patchset
Changes in v5:
-Change return check of drm_hdcp_helper_initialize_dp() (Stephen)
Changes in v6:
-Change the tracking of the state from connector state to bridge as
state as drm_connector_state is no longer tracked and the functionality
has moved to msm_dp_bridge
Changes in v7:
-Use dp bridge to maintain the state with no use for connector
Changes in v8:
-Move the hdcp read/write to dp_catalog
drivers/gpu/drm/msm/Kconfig | 1 +
drivers/gpu/drm/msm/Makefile| 1 +
drivers/gpu/drm/msm/dp/dp_catalog.c | 156 +++
drivers/gpu/drm/msm/dp/dp_catalog.h | 18 ++
drivers/gpu/drm/msm/dp/dp_debug.c | 46 +++-
drivers/gpu/drm/msm/dp/dp_debug.h | 11 +-
drivers/gpu/drm/msm/dp/dp_display.c | 39 ++-
drivers/gpu/drm/msm/dp/dp_display.h | 5 +
drivers/gpu/drm/msm/dp/dp_drm.c | 39 ++-
drivers/gpu/drm/msm/dp/dp_drm.h | 7 +
drivers/gpu/drm/msm/dp/dp_hdcp.c| 397
drivers/gpu/drm/msm/dp/dp_hdcp.h| 33 +++
drivers/gpu/drm/msm/dp/dp_parser.c | 14 +
drivers/gpu/drm/msm/dp/dp_parser.h | 4 +
drivers/gpu/drm/msm/dp/dp_reg.h | 30 ++-
drivers/gpu/drm/msm/msm_atomic.c| 19 ++
16 files changed, 808 insertions(+), 12 deletions(-)
create mode 100644 drivers/gpu/drm/msm/dp/dp_hdcp.c
create mode 100644 drivers/gpu/drm/msm/dp/dp_hdcp.h
diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 4d8fddbdcd9e0..1c369ca2ea6e3 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -15,6 +15,7 @@ config DRM_MSM
select REGULATOR
select DRM_DP_AUX_BUS
select DRM_DISPLAY_DP_HELPER
+ select DRM_DISPLAY_HDCP_HELPER
select DRM_DISPLAY_HELPER
select DRM_KMS_HELPER
select DRM_PANEL
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 7274c41228ed9..a73e7b858af27 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -122,6 +122,7 @@ msm-$(CONFIG_DRM_MSM_DP)+= dp/dp_aux.o \
dp/dp_ctrl.o \
dp/dp_display.o \
dp/dp_drm.o \
+ dp/dp_hdcp.o \
dp/dp_hpd.o \
dp/dp_link.o \
dp/dp_panel.o \
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index 676279d0ca8d9..a1395e0c67d56 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -16,6 +16,8 @@
#include "dp_catalog.h"
#include "dp_reg.h"
+#include
+
#define POLLING_SLEEP_US 1000
#define POLLING_TIMEOUT_US 1
@@ -47,6 +49,14 @@
#define DP_INTERRUPT_STATUS2_MASK \
(DP_INTERRUPT_STATUS2 << DP_INTERRUPT_STATUS_MASK_SHIFT)
+#define DP_AN_READ_DELAY_US 1
+/* Key offsets based on hdcp_key mmio */
+#define DP_HDCP_KEY_BASE 0x30
+#define DP_HDCP_KEY_MSB(x) (DP_HDCP_KEY_BASE + (x * 8))
+#define DP_HDCP_KEY_LSB(x) (DP_HDCP_KEY_MSB(x) + 4)
+#define DP_HDCP_KEY_VALID 0x170
+#define DP_HDCP_SW_KEY_VALID BIT(0)
+
struct dp_catalog_private {
struct device *dev;
struct drm_device *drm_dev;
@@ -133,6 +143,18 @@ static inline void dp_write_link(struct dp_catalog_private
*catalog,
writel(data, catalog->io->dp_controller.link.base + offset);
}
+static inline void dp_write_hdcp_key(struct dp_catalog_private *catalog,
+u32 offset, u32 val)
+{
+ writel(val, catalog->io->dp_controller.hdcp_key.base + offset);
+}
+
+static inline void dp_write_hdcp_tz(struct dp_catalog_private *catalog,
+ u32 offset, u32 val)
+{
+ writel(val, catalog->io->dp_controller.hdcp_tz.base + offset);
+}
+
/* aux related catalog functions */
u32 dp_catalog_aux_read_data(struct dp_catalog *dp_catalog)
{
@@ -1094,3 +1116,137 @@ void dp_catalog_audio_sfe_level(struct dp_catalog
*dp_catalog)
dp_write_link(catalog, REG_DP_MAINLINK_LEVELS, mainlink_levels);
}
+
+u32 dp_catalog_hdcp_read_ahb(struct dp_catalog *dp_catalog, u32
[PATCH v8 06/10] drm/i915/hdcp: Retain hdcp_capable return codes
From: Sean Paul
The shim functions return error codes, but they are discarded in
intel_hdcp.c. This patch plumbs the return codes through so they are
properly handled.
Acked-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
---
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-Rebased
Changes in v7:
-None
Changes in v8:
-None
.../drm/i915/display/intel_display_debugfs.c | 9 +++-
drivers/gpu/drm/i915/display/intel_hdcp.c | 51 ++-
drivers/gpu/drm/i915/display/intel_hdcp.h | 4 +-
3 files changed, 37 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 7bcd90384a46d..a14b86a07e545 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -494,6 +494,7 @@ static void intel_panel_info(struct seq_file *m,
static void intel_hdcp_info(struct seq_file *m,
struct intel_connector *intel_connector)
{
+ int ret;
bool hdcp_cap, hdcp2_cap;
if (!intel_connector->hdcp.shim) {
@@ -501,8 +502,12 @@ static void intel_hdcp_info(struct seq_file *m,
goto out;
}
- hdcp_cap = intel_hdcp_capable(intel_connector);
- hdcp2_cap = intel_hdcp2_capable(intel_connector);
+ ret = intel_hdcp_capable(intel_connector, _cap);
+ if (ret)
+ hdcp_cap = false;
+ ret = intel_hdcp2_capable(intel_connector, _cap);
+ if (ret)
+ hdcp2_cap = false;
if (hdcp_cap)
seq_puts(m, "HDCP1.4 ");
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 0a20bc41be55d..61a862ae1f286 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -177,50 +177,49 @@ int intel_hdcp_read_valid_bksv(struct intel_digital_port
*dig_port,
}
/* Is HDCP1.4 capable on Platform and Sink */
-bool intel_hdcp_capable(struct intel_connector *connector)
+int intel_hdcp_capable(struct intel_connector *connector, bool *capable)
{
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
const struct intel_hdcp_shim *shim = connector->hdcp.shim;
- bool capable = false;
u8 bksv[5];
+ *capable = false;
+
if (!shim)
- return capable;
+ return 0;
- if (shim->hdcp_capable) {
- shim->hdcp_capable(dig_port, );
- } else {
- if (!intel_hdcp_read_valid_bksv(dig_port, shim, bksv))
- capable = true;
- }
+ if (shim->hdcp_capable)
+ return shim->hdcp_capable(dig_port, capable);
+
+ if (!intel_hdcp_read_valid_bksv(dig_port, shim, bksv))
+ *capable = true;
- return capable;
+ return 0;
}
/* Is HDCP2.2 capable on Platform and Sink */
-bool intel_hdcp2_capable(struct intel_connector *connector)
+int intel_hdcp2_capable(struct intel_connector *connector, bool *capable)
{
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_hdcp *hdcp = >hdcp;
- bool capable = false;
+
+ *capable = false;
/* I915 support for HDCP2.2 */
if (!hdcp->hdcp2_supported)
- return false;
+ return 0;
/* MEI interface is solid */
mutex_lock(_priv->display.hdcp.comp_mutex);
if (!dev_priv->display.hdcp.comp_added ||
!dev_priv->display.hdcp.master) {
mutex_unlock(_priv->display.hdcp.comp_mutex);
- return false;
+ return 0;
}
mutex_unlock(_priv->display.hdcp.comp_mutex);
/* Sink's capability for HDCP2.2 */
- hdcp->shim->hdcp_2_2_capable(dig_port, );
-
- return capable;
+ return hdcp->shim->hdcp_2_2_capable(dig_port, capable);
}
static bool intel_hdcp_in_use(struct drm_i915_private *dev_priv,
@@ -2355,6 +2354,7 @@ int intel_hdcp_enable(struct intel_connector *connector,
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
struct intel_hdcp *hdcp = >hdcp;
unsigned long check_link_interval = DRM_HDCP_CHECK_PERIOD_MS;
+ bool capable;
int ret = -EINVAL;
if (!hdcp->shim)
@@ -2373,21 +2373,27 @@ int intel_hdcp_enable(struct intel_connector *connector,
* Considering that HDCP2.2 is more secure than HDCP1.4, If the setup
* is capable of HDCP2.2, it is preferred to use HDCP2.2.
*/
- if (intel_hdcp2_capable(connector)) {
+ ret = intel_hdcp2_capable(connector, );
+ if (capable) {
ret = _intel_hdcp2_enable(connector);
- if
[PATCH v8 07/10] drm/i915/hdcp: Use HDCP helpers for i915
From: Sean Paul
Now that all of the HDCP 1.x logic has been migrated to the central HDCP
helpers, use it in the i915 driver.
The majority of the driver code for HDCP 1.x will live in intel_hdcp.c,
however there are a few helper hooks which are connector-specific and
need to be partially or fully implemented in the intel_dp_hdcp.c or
intel_hdmi.c.
We'll leave most of the HDCP 2.x code alone since we don't have another
implementation of HDCP 2.x to use as reference for what should and
should not live in the drm helpers. The helper will call the overly
general enable/disable/is_capable HDCP 2.x callbacks and leave the
interesting stuff for the driver. Once we have another HDCP 2.x
implementation, we should do a similar migration.
Acked-by: Jani Nikula
Acked-by: Rodrigo Vivi
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
---
Changes in v2:
-Fix mst helper function pointer reported by 0-day
Changes in v3:
-Add forward declaration for drm_atomic_state in intel_hdcp.h identified
by 0-day
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-Rebased.
Changes in v7:
-Added to drm_hdcp_helper_funcs new functions that are unique between DP
and HDMI
-Adjusted the function signatures to take "driver data"
Changes in v8:
-None
drivers/gpu/drm/i915/display/intel_ddi.c | 32 +-
.../drm/i915/display/intel_display_debugfs.c | 6 +-
.../drm/i915/display/intel_display_types.h| 51 +-
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 368 +++
drivers/gpu/drm/i915/display/intel_dp_mst.c | 16 +-
drivers/gpu/drm/i915/display/intel_hdcp.c | 960 --
drivers/gpu/drm/i915/display/intel_hdcp.h | 37 +-
drivers/gpu/drm/i915/display/intel_hdmi.c | 276 ++---
8 files changed, 484 insertions(+), 1262 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 254559abedfba..8a2f20c929e9c 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -28,6 +28,7 @@
#include
#include
+#include
#include
#include "i915_drv.h"
@@ -2956,6 +2957,10 @@ static void intel_enable_ddi(struct intel_atomic_state
*state,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
{
+ struct intel_connector *connector =
+ to_intel_connector(conn_state->connector);
+ struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
+
drm_WARN_ON(state->base.dev, crtc_state->has_pch_encoder);
if (!intel_crtc_is_bigjoiner_slave(crtc_state))
@@ -2975,12 +2980,10 @@ static void intel_enable_ddi(struct intel_atomic_state
*state,
else
intel_enable_ddi_dp(state, encoder, crtc_state, conn_state);
- /* Enable hdcp if it's desired */
- if (conn_state->content_protection ==
- DRM_MODE_CONTENT_PROTECTION_DESIRED)
- intel_hdcp_enable(to_intel_connector(conn_state->connector),
- crtc_state,
- (u8)conn_state->hdcp_content_type);
+ if (connector->hdcp_helper_data)
+ drm_hdcp_helper_atomic_commit(connector->hdcp_helper_data,
+ >base,
+ _port->hdcp_mutex);
}
static void intel_disable_ddi_dp(struct intel_atomic_state *state,
@@ -3026,7 +3029,14 @@ static void intel_disable_ddi(struct intel_atomic_state
*state,
const struct intel_crtc_state *old_crtc_state,
const struct drm_connector_state *old_conn_state)
{
- intel_hdcp_disable(to_intel_connector(old_conn_state->connector));
+ struct intel_connector *connector =
+ to_intel_connector(old_conn_state->connector);
+ struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
+
+ if (connector->hdcp_helper_data)
+ drm_hdcp_helper_atomic_commit(connector->hdcp_helper_data,
+ >base,
+ _port->hdcp_mutex);
if (intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_HDMI))
intel_disable_ddi_hdmi(state, encoder, old_crtc_state,
@@ -3054,13 +3064,19 @@ void intel_ddi_update_pipe(struct intel_atomic_state
*state,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
{
+ struct intel_connector *connector =
+ to_intel_connector(conn_state->connector);
+ struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI) &&
!intel_encoder_is_mst(encoder))
intel_ddi_update_pipe_dp(state, encoder, crtc_state,
conn_state);
-
[PATCH v8 08/10] dt-bindings: msm/dp: Add bindings for HDCP registers
From: Sean Paul Add the bindings for the MSM DisplayPort HDCP registers which are required to write the HDCP key into the display controller as well as the registers to enable HDCP authentication/key exchange/encryption. Cc: Rob Herring Cc: Stephen Boyd Reviewed-by: Rob Herring Reviewed-by: Douglas Anderson Signed-off-by: Sean Paul Signed-off-by: Mark Yacoub --- Changes in v2: -Drop register range names (Stephen) -Fix yaml errors (Rob) Changes in v3: -Add new compatible string for dp-hdcp -Add descriptions to reg -Add minItems/maxItems to reg -Make reg depend on the new hdcp compatible string Changes in v4: -Rebase on Bjorn's multi-dp patchset Changes in v4.5: -Remove maxItems from reg (Rob) -Remove leading zeros in example (Rob) Changes in v5: -None Changes in v6: -Rebased: modify minItems instead of adding it as new line. Changes in v7: -Revert the change to minItems -Added the maxItems to Reg Changes in v8: -None .../devicetree/bindings/display/msm/dp-controller.yaml | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml index 0e8d8df686dc9..4763a2ff12fb7 100644 --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml @@ -34,6 +34,8 @@ properties: - description: link register block - description: p0 register block - description: p1 register block + - description: (Optional) Registers for HDCP device key injection + - description: (Optional) Registers for HDCP TrustZone interaction interrupts: maxItems: 1 @@ -159,6 +161,7 @@ allOf: aux-bus: false reg: minItems: 5 + maxItems: 7 required: - "#sound-dai-cells" @@ -176,7 +179,9 @@ examples: <0xae90200 0x200>, <0xae90400 0xc00>, <0xae91000 0x400>, - <0xae91400 0x400>; + <0xae91400 0x400>, + <0xaed1000 0x174>, + <0xaee1000 0x2c>; interrupt-parent = <>; interrupts = <12>; clocks = < DISP_CC_MDSS_AHB_CLK>, -- 2.40.0.348.gf938b09366-goog
[PATCH v8 02/10] drm/hdcp: Avoid changing crtc state in hdcp atomic check
From: Sean Paul
Instead of forcing a modeset in the hdcp atomic check, rename to
drm_hdcp_has_changed and return true if the content protection value
is changing and let the driver decide whether a modeset is required or not.
Acked-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
---
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-Rebase: modifications in drm_hdcp_helper.c instead of drm_hdcp.c
Changes in v7:
-Renamed the function from drm_hdcp_atomic_check to drm_hdcp_has_changed
(Dmitry Baryshkov)
Changes in v8:
-None
drivers/gpu/drm/display/drm_hdcp_helper.c | 39 ++---
drivers/gpu/drm/i915/display/intel_atomic.c | 6 ++--
include/drm/display/drm_hdcp_helper.h | 2 +-
3 files changed, 30 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_hdcp_helper.c
b/drivers/gpu/drm/display/drm_hdcp_helper.c
index 7ca390b3ea106..34baf2b97cd87 100644
--- a/drivers/gpu/drm/display/drm_hdcp_helper.c
+++ b/drivers/gpu/drm/display/drm_hdcp_helper.c
@@ -422,18 +422,21 @@ void drm_hdcp_update_content_protection(struct
drm_connector *connector,
EXPORT_SYMBOL(drm_hdcp_update_content_protection);
/**
- * drm_hdcp_atomic_check - Helper for drivers to call during
connector->atomic_check
+ * drm_hdcp_has_changed - Helper for drivers to call during
connector->atomic_check
*
* @state: pointer to the atomic state being checked
* @connector: drm_connector on which content protection state needs an update
*
* This function can be used by display drivers to perform an atomic check on
the
- * hdcp state elements. If hdcp state has changed, this function will set
- * mode_changed on the crtc driving the connector so it can update its hardware
- * to match the hdcp state.
+ * hdcp state elements. If hdcp state has changed in a manner which requires
the
+ * driver to enable or disable content protection, this function will return
+ * true.
+ *
+ * Returns:
+ * true if the driver must enable/disable hdcp, false otherwise
*/
-void drm_hdcp_atomic_check(struct drm_connector *connector,
- struct drm_atomic_state *state)
+bool drm_hdcp_has_changed(struct drm_connector *connector,
+ struct drm_atomic_state *state)
{
struct drm_connector_state *new_conn_state, *old_conn_state;
struct drm_crtc_state *new_crtc_state;
@@ -450,19 +453,31 @@ void drm_hdcp_atomic_check(struct drm_connector
*connector,
* If the connector is being disabled with CP enabled, mark it
* desired so it's re-enabled when the connector is brought back
*/
- if (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED)
+ if (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED) {
new_conn_state->content_protection =
DRM_MODE_CONTENT_PROTECTION_DESIRED;
- return;
+ return true;
+ }
+ return false;
}
new_crtc_state =
drm_atomic_get_new_crtc_state(state, new_conn_state->crtc);
if (drm_atomic_crtc_needs_modeset(new_crtc_state) &&
(old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
-new_hdcp != DRM_MODE_CONTENT_PROTECTION_UNDESIRED))
+new_hdcp != DRM_MODE_CONTENT_PROTECTION_UNDESIRED)) {
new_conn_state->content_protection =
DRM_MODE_CONTENT_PROTECTION_DESIRED;
+ return true;
+ }
+
+ /*
+* Coming back from UNDESIRED state, CRTC change or re-enablement
requires
+* the driver to try CP enable.
+*/
+ if (new_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
+ new_conn_state->crtc != old_conn_state->crtc)
+ return true;
/*
* Nothing to do if content type is unchanged and one of:
@@ -477,9 +492,9 @@ void drm_hdcp_atomic_check(struct drm_connector *connector,
new_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED)) {
if (old_conn_state->hdcp_content_type ==
new_conn_state->hdcp_content_type)
- return;
+ return false;
}
- new_crtc_state->mode_changed = true;
+ return true;
}
-EXPORT_SYMBOL(drm_hdcp_atomic_check);
+EXPORT_SYMBOL(drm_hdcp_has_changed);
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index e9d00b6a63d39..23a6ba315a22e 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -124,8 +124,6 @@ int intel_digital_connector_atomic_check(struct
drm_connector *conn,
to_intel_digital_connector_state(old_state);
struct drm_crtc_state *crtc_state;
- drm_hdcp_atomic_check(conn, state);
-
if
[PATCH v8 04/10] drm/hdcp: Expand HDCP helper library for enable/disable/check
From: Sean Paul
Expand upon the HDCP helper library to manage HDCP enable, disable, and check.
Previous to this patch, the majority of the state management and sink
interaction is tucked inside the Intel driver with the understanding
that once a new platform supported HDCP we could make good decisions
about what should be centralized. With the addition of HDCP support
for Qualcomm, it's time to migrate the protocol-specific bits of HDCP
authentication, key exchange, and link checks to the HDCP helper.
In terms of functionality, this migration is 1:1 with the Intel driver,
however things are laid out a bit differently than with intel_hdcp.c,
which is why this is a separate patch from the i915 transition to the
helper. On i915, the shim vtable is used to account for HDMI vs. DP
vs. DP-MST differences whereas the helper library uses a LUT to
account for the register offsets and a remote read function to route
the messages. On i915, storing the sink information in the source is
done inline whereas now we use the new drm_hdcp_helper_funcs vtable
to store and fetch information to/from source hw. Finally, instead of
calling enable/disable directly from the driver, we'll leave that
decision to the helper and by calling drm_hdcp_helper_atomic_commit()
from the driver. All told, this will centralize the protocol and state
handling in the helper, ensuring we collect all of our bugs^Wlogic
in one place.
Acked-by: Jani Nikula
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
---
Changes in v2:
-Fixed set-but-unused variable identified by 0-day
Changes in v3:
-Fixed uninitialized variable warning identified by 0-day
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-Fixed typo in function descriptions
-Rebased: Moved the new code between drm_hdcp.h and drm_hdcp_helper.c/h
-Add missing headers. Reported-by: kernel test robot
Changes in v7:
- Add a |driver_data| field to some functions in drm_hdcp_helper_funcs
that are called by the driver so drivers can pass anything they such
as bridges
- Isolate all non-common code between HDMI and DP into separate
functions instead of manually checking for datra->aux
Changes in v8 (suraj):
-Try hdcp 1.x if hdcp2_capable returns an error instead of goto out.
-set the enabled type to either 1 or 0 depending on the prop as hdcp2
can support either.
drivers/gpu/drm/display/drm_hdcp_helper.c | 1215 +
include/drm/display/drm_hdcp.h| 287 +
include/drm/display/drm_hdcp_helper.h | 51 +-
3 files changed, 1552 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/display/drm_hdcp_helper.c
b/drivers/gpu/drm/display/drm_hdcp_helper.c
index 3ee1a6ae26c53..3bc0308cc95d8 100644
--- a/drivers/gpu/drm/display/drm_hdcp_helper.c
+++ b/drivers/gpu/drm/display/drm_hdcp_helper.c
@@ -6,13 +6,18 @@
* Ramalingam C
*/
+#include
#include
#include
#include
+#include
+#include
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -507,3 +512,1213 @@ bool drm_hdcp_has_changed(struct drm_connector
*connector,
return old_hdcp != new_hdcp;
}
EXPORT_SYMBOL(drm_hdcp_has_changed);
+
+struct drm_hdcp_hdcp1_receiver_reg_lut {
+ unsigned int bksv;
+ unsigned int ri;
+ unsigned int aksv;
+ unsigned int an;
+ unsigned int ainfo;
+ unsigned int v[5];
+ unsigned int bcaps;
+ unsigned int bcaps_mask_repeater_present;
+ unsigned int bstatus;
+};
+
+static const struct drm_hdcp_hdcp1_receiver_reg_lut drm_hdcp_hdcp1_ddc_lut = {
+ .bksv = DRM_HDCP_DDC_BKSV,
+ .ri = DRM_HDCP_DDC_RI_PRIME,
+ .aksv = DRM_HDCP_DDC_AKSV,
+ .an = DRM_HDCP_DDC_AN,
+ .ainfo = DRM_HDCP_DDC_AINFO,
+ .v = { DRM_HDCP_DDC_V_PRIME(0), DRM_HDCP_DDC_V_PRIME(1),
+ DRM_HDCP_DDC_V_PRIME(2), DRM_HDCP_DDC_V_PRIME(3),
+ DRM_HDCP_DDC_V_PRIME(4) },
+ .bcaps = DRM_HDCP_DDC_BCAPS,
+ .bcaps_mask_repeater_present = DRM_HDCP_DDC_BCAPS_REPEATER_PRESENT,
+ .bstatus = DRM_HDCP_DDC_BSTATUS,
+};
+
+static const struct drm_hdcp_hdcp1_receiver_reg_lut drm_hdcp_hdcp1_dpcd_lut = {
+ .bksv = DP_AUX_HDCP_BKSV,
+ .ri = DP_AUX_HDCP_RI_PRIME,
+ .aksv = DP_AUX_HDCP_AKSV,
+ .an = DP_AUX_HDCP_AN,
+ .ainfo = DP_AUX_HDCP_AINFO,
+ .v = { DP_AUX_HDCP_V_PRIME(0), DP_AUX_HDCP_V_PRIME(1),
+ DP_AUX_HDCP_V_PRIME(2), DP_AUX_HDCP_V_PRIME(3),
+ DP_AUX_HDCP_V_PRIME(4) },
+ .bcaps = DP_AUX_HDCP_BCAPS,
+ .bcaps_mask_repeater_present = DP_BCAPS_REPEATER_PRESENT,
+
+ /*
+* For some reason the HDMI and DP HDCP specs call this register
+* definition by different names. In the HDMI spec, it's called BSTATUS,
+* but in DP it's called BINFO.
+*/
+ .bstatus = DP_AUX_HDCP_BINFO,
+};
+
+/*
+ * Read a DPCD register.
+ *
+ * @data: drm_hdcp_helper_data containing the DisplayPort AUX channel (SST or
MST)
+ * @offset: address of
[PATCH v8 05/10] drm/i915/hdcp: Consolidate HDCP setup/state cache
From: Sean Paul
Stick all of the setup for HDCP into a dedicated function. No functional
change, but this will facilitate moving HDCP logic into helpers.
Acked-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
Change-Id: Ib358a503fa4520d072e477f708f1705b19f1c4fc
Signed-off-by: Sean Paul
---
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
- None
Changes in v8:
-None
drivers/gpu/drm/i915/display/intel_hdcp.c | 52 +++
1 file changed, 35 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 396d2cef000aa..0a20bc41be55d 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -2190,6 +2190,37 @@ static enum mei_fw_tc intel_get_mei_fw_tc(enum
transcoder cpu_transcoder)
}
}
+static int
+_intel_hdcp_setup(struct intel_connector *connector,
+ const struct intel_crtc_state *pipe_config, u8 content_type)
+{
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
+ struct intel_hdcp *hdcp = >hdcp;
+ int ret = 0;
+
+ if (!connector->encoder) {
+ drm_err(_priv->drm, "[%s:%d] encoder is not initialized\n",
+ connector->base.name, connector->base.base.id);
+ return -ENODEV;
+ }
+
+ hdcp->content_type = content_type;
+
+ if (intel_crtc_has_type(pipe_config, INTEL_OUTPUT_DP_MST)) {
+ hdcp->cpu_transcoder = pipe_config->mst_master_transcoder;
+ hdcp->stream_transcoder = pipe_config->cpu_transcoder;
+ } else {
+ hdcp->cpu_transcoder = pipe_config->cpu_transcoder;
+ hdcp->stream_transcoder = INVALID_TRANSCODER;
+ }
+
+ if (DISPLAY_VER(dev_priv) >= 12)
+ dig_port->hdcp_port_data.fw_tc =
intel_get_mei_fw_tc(hdcp->cpu_transcoder);
+
+ return ret;
+}
+
static int initialize_hdcp_port_data(struct intel_connector *connector,
struct intel_digital_port *dig_port,
const struct intel_hdcp_shim *shim)
@@ -2329,28 +2360,14 @@ int intel_hdcp_enable(struct intel_connector *connector,
if (!hdcp->shim)
return -ENOENT;
- if (!connector->encoder) {
- drm_err(_priv->drm, "[%s:%d] encoder is not initialized\n",
- connector->base.name, connector->base.base.id);
- return -ENODEV;
- }
-
mutex_lock(>mutex);
mutex_lock(_port->hdcp_mutex);
drm_WARN_ON(_priv->drm,
hdcp->value == DRM_MODE_CONTENT_PROTECTION_ENABLED);
- hdcp->content_type = content_type;
-
- if (intel_crtc_has_type(pipe_config, INTEL_OUTPUT_DP_MST)) {
- hdcp->cpu_transcoder = pipe_config->mst_master_transcoder;
- hdcp->stream_transcoder = pipe_config->cpu_transcoder;
- } else {
- hdcp->cpu_transcoder = pipe_config->cpu_transcoder;
- hdcp->stream_transcoder = INVALID_TRANSCODER;
- }
- if (DISPLAY_VER(dev_priv) >= 12)
- dig_port->hdcp_port_data.fw_tc =
intel_get_mei_fw_tc(hdcp->cpu_transcoder);
+ ret = _intel_hdcp_setup(connector, pipe_config, content_type);
+ if (ret)
+ goto out;
/*
* Considering that HDCP2.2 is more secure than HDCP1.4, If the setup
@@ -2378,6 +2395,7 @@ int intel_hdcp_enable(struct intel_connector *connector,
true);
}
+out:
mutex_unlock(_port->hdcp_mutex);
mutex_unlock(>mutex);
return ret;
--
2.40.0.348.gf938b09366-goog
[PATCH v8 03/10] drm/hdcp: Update property value on content type and user changes
From: Sean Paul
Update the connector's property value in 2 cases which were
previously missed:
1- Content type changes. The value should revert back to DESIRED from
ENABLED in case the driver must re-authenticate the link due to the
new content type.
2- Userspace sets value to DESIRED while ENABLED. In this case, the
value should be reset immediately to ENABLED since the link is
actively being encrypted.
To accommodate these changes, I've split up the conditionals to make
things a bit more clear (as much as one can with this mess of state).
Acked-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
---
Changes in v2:
-None
Changes in v3:
-Fixed indentation issue identified by 0-day
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-Rebased: modifications in drm_hdcp_helper.c instead of drm_hdcp.c
Changes in v7:
-Rebased as function name has changed.
Changes in v8:
-None
drivers/gpu/drm/display/drm_hdcp_helper.c | 29 +++
1 file changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_hdcp_helper.c
b/drivers/gpu/drm/display/drm_hdcp_helper.c
index 34baf2b97cd87..3ee1a6ae26c53 100644
--- a/drivers/gpu/drm/display/drm_hdcp_helper.c
+++ b/drivers/gpu/drm/display/drm_hdcp_helper.c
@@ -480,21 +480,30 @@ bool drm_hdcp_has_changed(struct drm_connector *connector,
return true;
/*
-* Nothing to do if content type is unchanged and one of:
-* - state didn't change
-* - HDCP was activated since the last commit
-* - attempting to set to desired while already enabled
+* Content type changes require an HDCP disable/enable cycle.
*/
- if (old_hdcp == new_hdcp ||
- (old_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
+ if (new_conn_state->hdcp_content_type !=
+ old_conn_state->hdcp_content_type) {
+ new_conn_state->content_protection =
+ DRM_MODE_CONTENT_PROTECTION_DESIRED;
+ return true;
+ }
+
+ /*
+* Ignore meaningless state changes:
+* - HDCP was activated since the last commit
+* - Attempting to set to desired while already enabled
+*/
+ if ((old_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
new_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED) ||
(old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
new_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED)) {
- if (old_conn_state->hdcp_content_type ==
- new_conn_state->hdcp_content_type)
- return false;
+ new_conn_state->content_protection =
+ DRM_MODE_CONTENT_PROTECTION_ENABLED;
+ return false;
}
- return true;
+ /* Finally, if state changes, we need action */
+ return old_hdcp != new_hdcp;
}
EXPORT_SYMBOL(drm_hdcp_has_changed);
--
2.40.0.348.gf938b09366-goog
[PATCH v8 01/10] drm/hdcp: Add drm_hdcp_atomic_check()
From: Sean Paul
Move the hdcp atomic check from i915 to drm_hdcp so other
drivers can use it. No functional changes, just cleaned up some of the
code when moving it over.
Acked-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
---
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-Rebase: move helper from drm_hdcp.c to drm_hdcp_helper.c
Changes in v7:
-Removed links to patch from commit msg (Dmitry Baryshkov)
Changes in v8:
-None
drivers/gpu/drm/display/drm_hdcp_helper.c | 64 +
drivers/gpu/drm/i915/display/intel_atomic.c | 4 +-
drivers/gpu/drm/i915/display/intel_hdcp.c | 47 ---
drivers/gpu/drm/i915/display/intel_hdcp.h | 3 -
include/drm/display/drm_hdcp_helper.h | 3 +
5 files changed, 69 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_hdcp_helper.c
b/drivers/gpu/drm/display/drm_hdcp_helper.c
index e78999c72bd77..7ca390b3ea106 100644
--- a/drivers/gpu/drm/display/drm_hdcp_helper.c
+++ b/drivers/gpu/drm/display/drm_hdcp_helper.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
static inline void drm_hdcp_print_ksv(const u8 *ksv)
{
@@ -419,3 +420,66 @@ void drm_hdcp_update_content_protection(struct
drm_connector *connector,
dev->mode_config.content_protection_property);
}
EXPORT_SYMBOL(drm_hdcp_update_content_protection);
+
+/**
+ * drm_hdcp_atomic_check - Helper for drivers to call during
connector->atomic_check
+ *
+ * @state: pointer to the atomic state being checked
+ * @connector: drm_connector on which content protection state needs an update
+ *
+ * This function can be used by display drivers to perform an atomic check on
the
+ * hdcp state elements. If hdcp state has changed, this function will set
+ * mode_changed on the crtc driving the connector so it can update its hardware
+ * to match the hdcp state.
+ */
+void drm_hdcp_atomic_check(struct drm_connector *connector,
+ struct drm_atomic_state *state)
+{
+ struct drm_connector_state *new_conn_state, *old_conn_state;
+ struct drm_crtc_state *new_crtc_state;
+ u64 old_hdcp, new_hdcp;
+
+ old_conn_state = drm_atomic_get_old_connector_state(state, connector);
+ old_hdcp = old_conn_state->content_protection;
+
+ new_conn_state = drm_atomic_get_new_connector_state(state, connector);
+ new_hdcp = new_conn_state->content_protection;
+
+ if (!new_conn_state->crtc) {
+ /*
+* If the connector is being disabled with CP enabled, mark it
+* desired so it's re-enabled when the connector is brought back
+*/
+ if (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED)
+ new_conn_state->content_protection =
+ DRM_MODE_CONTENT_PROTECTION_DESIRED;
+ return;
+ }
+
+ new_crtc_state =
+ drm_atomic_get_new_crtc_state(state, new_conn_state->crtc);
+ if (drm_atomic_crtc_needs_modeset(new_crtc_state) &&
+ (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
+new_hdcp != DRM_MODE_CONTENT_PROTECTION_UNDESIRED))
+ new_conn_state->content_protection =
+ DRM_MODE_CONTENT_PROTECTION_DESIRED;
+
+ /*
+* Nothing to do if content type is unchanged and one of:
+* - state didn't change
+* - HDCP was activated since the last commit
+* - attempting to set to desired while already enabled
+*/
+ if (old_hdcp == new_hdcp ||
+ (old_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
+new_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED) ||
+ (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
+new_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED)) {
+ if (old_conn_state->hdcp_content_type ==
+ new_conn_state->hdcp_content_type)
+ return;
+ }
+
+ new_crtc_state->mode_changed = true;
+}
+EXPORT_SYMBOL(drm_hdcp_atomic_check);
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index a9a3f3715279d..e9d00b6a63d39 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include "i915_drv.h"
#include "i915_reg.h"
@@ -39,7 +40,6 @@
#include "intel_cdclk.h"
#include "intel_display_types.h"
#include "intel_global_state.h"
-#include "intel_hdcp.h"
#include "intel_psr.h"
#include "intel_fb.h"
#include "skl_universal_plane.h"
@@ -124,7 +124,7 @@ int intel_digital_connector_atomic_check(struct
drm_connector *conn,
to_intel_digital_connector_state(old_state);
struct drm_crtc_state *crtc_state;
-
[PATCH v8 00/10] drm/hdcp: Pull HDCP auth/exchange/check into helpers
Hi all, This is v7 of the HDCP patches. The patches are authored by Sean Paul. I rebased and addressed the review comments in v6-v8. Patches 1-4 focus on moving the common HDCP helpers to common DRM. This introduces a slight change in the original intel flow as it splits the unique driver protocol from the generic implementation. Patches 5-7 split the HDCP flow on the i915 driver to make use of the common DRM helpers. Patches 8-10 implement HDCP on MSM driver. Thanks, -Mark Yacoub Sean Paul (10): drm/hdcp: Add drm_hdcp_atomic_check() drm/hdcp: Avoid changing crtc state in hdcp atomic check drm/hdcp: Update property value on content type and user changes drm/hdcp: Expand HDCP helper library for enable/disable/check drm/i915/hdcp: Consolidate HDCP setup/state cache drm/i915/hdcp: Retain hdcp_capable return codes drm/i915/hdcp: Use HDCP helpers for i915 dt-bindings: msm/dp: Add bindings for HDCP registers arm64: dts: qcom: sc7180: Add support for HDCP in dp-controller drm/msm: Implement HDCP 1.x using the new drm HDCP helpers .../bindings/display/msm/dp-controller.yaml |7 +- arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi |8 + drivers/gpu/drm/display/drm_hdcp_helper.c | 1303 + drivers/gpu/drm/i915/display/intel_atomic.c |8 +- drivers/gpu/drm/i915/display/intel_ddi.c | 32 +- .../drm/i915/display/intel_display_debugfs.c | 11 +- .../drm/i915/display/intel_display_types.h| 51 +- drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 368 ++--- drivers/gpu/drm/i915/display/intel_dp_mst.c | 16 +- drivers/gpu/drm/i915/display/intel_hdcp.c | 1036 +++-- drivers/gpu/drm/i915/display/intel_hdcp.h | 42 +- drivers/gpu/drm/i915/display/intel_hdmi.c | 276 ++-- drivers/gpu/drm/msm/Kconfig |1 + drivers/gpu/drm/msm/Makefile |1 + drivers/gpu/drm/msm/dp/dp_catalog.c | 156 ++ drivers/gpu/drm/msm/dp/dp_catalog.h | 18 + drivers/gpu/drm/msm/dp/dp_debug.c | 46 +- drivers/gpu/drm/msm/dp/dp_debug.h | 11 +- drivers/gpu/drm/msm/dp/dp_display.c | 39 +- drivers/gpu/drm/msm/dp/dp_display.h |5 + drivers/gpu/drm/msm/dp/dp_drm.c | 39 +- drivers/gpu/drm/msm/dp/dp_drm.h |7 + drivers/gpu/drm/msm/dp/dp_hdcp.c | 397 + drivers/gpu/drm/msm/dp/dp_hdcp.h | 33 + drivers/gpu/drm/msm/dp/dp_parser.c| 14 + drivers/gpu/drm/msm/dp/dp_parser.h|4 + drivers/gpu/drm/msm/dp/dp_reg.h | 30 +- drivers/gpu/drm/msm/msm_atomic.c | 19 + include/drm/display/drm_hdcp.h| 287 include/drm/display/drm_hdcp_helper.h | 52 + 30 files changed, 2983 insertions(+), 1334 deletions(-) create mode 100644 drivers/gpu/drm/msm/dp/dp_hdcp.c create mode 100644 drivers/gpu/drm/msm/dp/dp_hdcp.h -- 2.40.0.348.gf938b09366-goog
Re: [Intel-xe] [PATCH 1/3] drm/xe: Remove unused revid from firmware name
On Mon, Mar 27, 2023 at 09:59:55AM -0700, Matt Roper wrote: On Thu, Mar 23, 2023 at 10:17:52PM -0700, Lucas De Marchi wrote: The rev field is always 0 so it ends up never used. In i915 it was introduced because of CML: up to rev 5 it reuses the guc and huc firmware blobs from KBL. After that there is a specific firmware for that platform. This can be reintroduced later if ever needed. I doubt we'd ever need the revid again; more likely we'd want a way to select different firmwares for a given subplatform (which is something I think we need to add anyway for ADL-N). Reviewed-by: Matt Roper thanks, applied this first patch. Lucas De Marchi
Re: [PATCH] drm/ttm: add NUMA node id to the pool
On Fri, Mar 31, 2023 at 4:02 PM Felix Kuehling wrote:
>
> There is a subsequent patch where amdgpu directly calls ttm_pool_init to
> create pools per NUMA node. That will depend on the updated function
> signature.
Then we probably want to take this through amdgpu then.
Alex
>
> Regards,
>Felix
>
>
> On 2023-03-31 15:17, Alex Deucher wrote:
> > On Fri, Mar 31, 2023 at 2:54 AM Christian König
> > wrote:
> >> Should I push this to drm-misc-next or do we take it through
> >> amd-staging-drm-next?
> > I think either way is fine. We can carry it internally as needed for
> > testing if you want to commit it to drm-misc-next. I don't think
> > there are any direct code dependencies, but you or Rajneesh can
> > correct me if I'm wrong.
> >
> > Alex
> >
> >> Christian.
> >>
> >> Am 30.03.23 um 21:50 schrieb Alex Deucher:
> >>> From: Rajneesh Bhardwaj
> >>>
> >>> This allows backing ttm_tt structure with pages from different NUMA
> >>> pools.
> >>>
> >>> Tested-by: Graham Sider
> >>> Reviewed-by: Felix Kuehling
> >>> Signed-off-by: Christian König
> >>> Signed-off-by: Rajneesh Bhardwaj
> >>> Signed-off-by: Alex Deucher
> >>> ---
> >>>drivers/gpu/drm/ttm/ttm_device.c | 2 +-
> >>>drivers/gpu/drm/ttm/ttm_pool.c | 13 -
> >>>include/drm/ttm/ttm_pool.h | 4 +++-
> >>>3 files changed, 12 insertions(+), 7 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/ttm/ttm_device.c
> >>> b/drivers/gpu/drm/ttm/ttm_device.c
> >>> index e7147e304637..4a8164a5320f 100644
> >>> --- a/drivers/gpu/drm/ttm/ttm_device.c
> >>> +++ b/drivers/gpu/drm/ttm/ttm_device.c
> >>> @@ -218,7 +218,7 @@ int ttm_device_init(struct ttm_device *bdev, struct
> >>> ttm_device_funcs *funcs,
> >>>bdev->funcs = funcs;
> >>>
> >>>ttm_sys_man_init(bdev);
> >>> - ttm_pool_init(>pool, dev, use_dma_alloc, use_dma32);
> >>> + ttm_pool_init(>pool, dev, NUMA_NO_NODE, use_dma_alloc,
> >>> use_dma32);
> >>>
> >>>bdev->vma_manager = vma_manager;
> >>>INIT_DELAYED_WORK(>wq, ttm_device_delayed_workqueue);
> >>> diff --git a/drivers/gpu/drm/ttm/ttm_pool.c
> >>> b/drivers/gpu/drm/ttm/ttm_pool.c
> >>> index 9f6764bf3b15..1068a41cded1 100644
> >>> --- a/drivers/gpu/drm/ttm/ttm_pool.c
> >>> +++ b/drivers/gpu/drm/ttm/ttm_pool.c
> >>> @@ -92,7 +92,7 @@ static struct page *ttm_pool_alloc_page(struct ttm_pool
> >>> *pool, gfp_t gfp_flags,
> >>>__GFP_KSWAPD_RECLAIM;
> >>>
> >>>if (!pool->use_dma_alloc) {
> >>> - p = alloc_pages(gfp_flags, order);
> >>> + p = alloc_pages_node(pool->nid, gfp_flags, order);
> >>>if (p)
> >>>p->private = order;
> >>>return p;
> >>> @@ -286,7 +286,7 @@ static struct ttm_pool_type
> >>> *ttm_pool_select_type(struct ttm_pool *pool,
> >>> enum ttm_caching caching,
> >>> unsigned int order)
> >>>{
> >>> - if (pool->use_dma_alloc)
> >>> + if (pool->use_dma_alloc || pool->nid != NUMA_NO_NODE)
> >>>return >caching[caching].orders[order];
> >>>
> >>>#ifdef CONFIG_X86
> >>> @@ -523,29 +523,32 @@ EXPORT_SYMBOL(ttm_pool_free);
> >>> *
> >>> * @pool: the pool to initialize
> >>> * @dev: device for DMA allocations and mappings
> >>> + * @nid: NUMA node to use for allocations
> >>> * @use_dma_alloc: true if coherent DMA alloc should be used
> >>> * @use_dma32: true if GFP_DMA32 should be used
> >>> *
> >>> * Initialize the pool and its pool types.
> >>> */
> >>>void ttm_pool_init(struct ttm_pool *pool, struct device *dev,
> >>> -bool use_dma_alloc, bool use_dma32)
> >>> +int nid, bool use_dma_alloc, bool use_dma32)
> >>>{
> >>>unsigned int i, j;
> >>>
> >>>WARN_ON(!dev && use_dma_alloc);
> >>>
> >>>pool->dev = dev;
> >>> + pool->nid = nid;
> >>>pool->use_dma_alloc = use_dma_alloc;
> >>>pool->use_dma32 = use_dma32;
> >>>
> >>> - if (use_dma_alloc) {
> >>> + if (use_dma_alloc || nid != NUMA_NO_NODE) {
> >>>for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
> >>>for (j = 0; j < MAX_ORDER; ++j)
> >>>
> >>> ttm_pool_type_init(>caching[i].orders[j],
> >>> pool, i, j);
> >>>}
> >>>}
> >>> +EXPORT_SYMBOL(ttm_pool_init);
> >>>
> >>>/**
> >>> * ttm_pool_fini - Cleanup a pool
> >>> @@ -559,7 +562,7 @@ void ttm_pool_fini(struct ttm_pool *pool)
> >>>{
> >>>unsigned int i, j;
> >>>
> >>> - if (pool->use_dma_alloc) {
> >>> + if (pool->use_dma_alloc || pool->nid != NUMA_NO_NODE) {
> >>>for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
> >>>for (j = 0; j < MAX_ORDER; ++j)
> >>>
> >>>
Re: [Intel-xe] [PATCH 2/3] drm/xe: Fix platform order
On Fri, Mar 31, 2023 at 01:47:20PM -0700, Matt Roper wrote:
On Fri, Mar 31, 2023 at 07:22:06AM -0600, Lucas De Marchi wrote:
On Mon, Mar 27, 2023 at 10:02:38AM -0700, Matt Roper wrote:
> On Thu, Mar 23, 2023 at 10:17:53PM -0700, Lucas De Marchi wrote:
> > Platform order is important when looping through the list of guc
> > firmware blobs since we use it to prevent loading a blob for a newer
> > platform onto an older one. Move PVC after ADL.
>
> Shouldn't we be moving the ADL platforms (graphics versions 12.0) higher
> than DG1 (12.10) and DG2 (12.50) too?
question then would be: would we be ordering them by gt
version? Or by when they were introduced?
Since all of the platforms here have the GuC inside the
graphics IP[*], then the graphics IP version seems natural to me.
The order in drivers/gpu/drm/xe/xe_platform_types.h is unrelated to
anything GuC is doing though. It's the firmware loading code that
decided to use the platform enum value to stop early the iteration on
the table.
"When they were introduced" would be identical for all of these
platforms for the Xe driver (since we just dumped a big megapatch that
contained all of these platforms at once). But if you want to match
when they were introduced *in i915* that would be reasonable too,
I was meaning more in the sense of "the HW being introduced", not the
support in i915 or xe. My main goal was actually to have the order
in XE_GUC_FIRMWARE_DEFS on the third patch be so that the platforms
using the full version are the top ones.
As you also mention, whatever we do it's sufficient to keep the same
order (for now) in the both the enum and XE_GUC_FIRMWARE_DEFS. I will
send a new version just using graphics version (and updating the comment
on xe_platform, so it's easier to see from the xe driver alone what
order to use.
thanks
Lucas De Marchi
although the ADLs would still need to come before DG2 in that case.
Matt
[*] MTL has a GuC in both the graphics IP and the media IP. One of our
questions early on was whether the GuC IP itself would differ between
the two GTs (requiring different firmwares for each). The response that
came back from the hardware team was that that's technically possible
with standalone media, but at least for MTL they'd keep them identical.
So for now, just basing 100% on the graphics IP version seems fine. In
the future we may need to stop tying GuC to platform at all and instead
match on the appropriate IP version for whichever GT we're loading on.
But that's a problem for the future...
I think it makes more sense to be by when they were introduced as a
platform in the driver.
1) what about media/display?
2) allow us to always be appending in the enum and elsewhere in
the driver.
Lucas De Marchi
>
>
> Matt
>
> >
> > Signed-off-by: Lucas De Marchi
> > ---
> > drivers/gpu/drm/xe/xe_platform_types.h | 3 +--
> > drivers/gpu/drm/xe/xe_uc_fw.c | 2 +-
> > 2 files changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/xe/xe_platform_types.h
b/drivers/gpu/drm/xe/xe_platform_types.h
> > index 72612c832e88..10367f6cc75a 100644
> > --- a/drivers/gpu/drm/xe/xe_platform_types.h
> > +++ b/drivers/gpu/drm/xe/xe_platform_types.h
> > @@ -9,14 +9,13 @@
> > /* Keep in gen based order, and chronological order within a gen */
> > enum xe_platform {
> > XE_PLATFORM_UNINITIALIZED = 0,
> > - /* gen12 */
> > XE_TIGERLAKE,
> > XE_ROCKETLAKE,
> > XE_DG1,
> > XE_DG2,
> > - XE_PVC,
> > XE_ALDERLAKE_S,
> > XE_ALDERLAKE_P,
> > + XE_PVC,
> > XE_METEORLAKE,
> > };
> >
> > diff --git a/drivers/gpu/drm/xe/xe_uc_fw.c b/drivers/gpu/drm/xe/xe_uc_fw.c
> > index e2c982b37e87..174c42873ebb 100644
> > --- a/drivers/gpu/drm/xe/xe_uc_fw.c
> > +++ b/drivers/gpu/drm/xe/xe_uc_fw.c
> > @@ -43,9 +43,9 @@ static struct xe_device *uc_fw_to_xe(struct xe_uc_fw
*uc_fw)
> > */
> > #define XE_GUC_FIRMWARE_DEFS(fw_def, guc_def) \
> > fw_def(METEORLAKE, guc_def(mtl, 70, 5, 2)) \
> > + fw_def(PVC, guc_def(pvc, 70, 5, 2)) \
> > fw_def(ALDERLAKE_P, guc_def(adlp, 70, 5, 2)) \
> > fw_def(ALDERLAKE_S, guc_def(tgl, 70, 5, 2)) \
> > - fw_def(PVC, guc_def(pvc, 70, 5, 2)) \
> > fw_def(DG2, guc_def(dg2, 70, 5, 2)) \
> > fw_def(DG1, guc_def(dg1, 70, 5, 2)) \
> > fw_def(TIGERLAKE,guc_def(tgl, 70, 5, 2))
> > --
> > 2.39.0
> >
>
> --
> Matt Roper
> Graphics Software Engineer
> Linux GPU Platform Enablement
> Intel Corporation
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH] drm/nouveau/disp: Support more modes by checking with lower bpc
Reviewed-by: Lyude Paul
On Fri, 2023-03-31 at 00:39 +0200, Karol Herbst wrote:
> This allows us to advertise more modes especially on HDR displays.
>
> Fixes using 4K@60 modes on my TV and main display both using a HDMI to DP
> adapter. Also fixes similiar issues for users running into this.
>
> Cc: sta...@vger.kernel.org # 5.10+
> Signed-off-by: Karol Herbst
> ---
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 32 +
> drivers/gpu/drm/nouveau/nouveau_dp.c| 8 ---
> 2 files changed, 37 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index ed9d374147b8d..f28e47c161dd9 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -363,6 +363,35 @@ nv50_outp_atomic_check_view(struct drm_encoder *encoder,
> return 0;
> }
>
> +static void
> +nv50_outp_atomic_fix_depth(struct drm_encoder *encoder, struct
> drm_crtc_state *crtc_state)
> +{
> + struct nv50_head_atom *asyh = nv50_head_atom(crtc_state);
> + struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
> + struct drm_display_mode *mode = >state.adjusted_mode;
> + unsigned int max_rate, mode_rate;
> +
> + switch (nv_encoder->dcb->type) {
> + case DCB_OUTPUT_DP:
> + max_rate = nv_encoder->dp.link_nr * nv_encoder->dp.link_bw;
> +
> +/* we don't support more than 10 anyway */
> + asyh->or.bpc = max_t(u8, asyh->or.bpc, 10);
> +
> + /* reduce the bpc until it works out */
> + while (asyh->or.bpc > 6) {
> + mode_rate = DIV_ROUND_UP(mode->clock * asyh->or.bpc *
> 3, 8);
> + if (mode_rate <= max_rate)
> + break;
> +
> + asyh->or.bpc -= 2;
> + }
> + break;
> + default:
> + break;
> + }
> +}
> +
> static int
> nv50_outp_atomic_check(struct drm_encoder *encoder,
> struct drm_crtc_state *crtc_state,
> @@ -381,6 +410,9 @@ nv50_outp_atomic_check(struct drm_encoder *encoder,
> if (crtc_state->mode_changed || crtc_state->connectors_changed)
> asyh->or.bpc = connector->display_info.bpc;
>
> + /* We might have to reduce the bpc */
> + nv50_outp_atomic_fix_depth(encoder, crtc_state);
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
> b/drivers/gpu/drm/nouveau/nouveau_dp.c
> index e00876f92aeea..d49b4875fc3c9 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_dp.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
> @@ -263,8 +263,6 @@ nouveau_dp_irq(struct work_struct *work)
> }
>
> /* TODO:
> - * - Use the minimum possible BPC here, once we add support for the max bpc
> - * property.
> * - Validate against the DP caps advertised by the GPU (we don't check these
> * yet)
> */
> @@ -276,7 +274,11 @@ nv50_dp_mode_valid(struct drm_connector *connector,
> {
> const unsigned int min_clock = 25000;
> unsigned int max_rate, mode_rate, ds_max_dotclock, clock = mode->clock;
> - const u8 bpp = connector->display_info.bpc * 3;
> + /* Check with the minmum bpc always, so we can advertise better modes.
> + * In particlar not doing this causes modes to be dropped on HDR
> + * displays as we might check with a bpc of 16 even.
> + */
> + const u8 bpp = 6 * 3;
>
> if (mode->flags & DRM_MODE_FLAG_INTERLACE && !outp->caps.dp_interlace)
> return MODE_NO_INTERLACE;
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [Intel-xe] [PATCH 2/3] drm/xe: Fix platform order
On Fri, Mar 31, 2023 at 07:22:06AM -0600, Lucas De Marchi wrote:
> On Mon, Mar 27, 2023 at 10:02:38AM -0700, Matt Roper wrote:
> > On Thu, Mar 23, 2023 at 10:17:53PM -0700, Lucas De Marchi wrote:
> > > Platform order is important when looping through the list of guc
> > > firmware blobs since we use it to prevent loading a blob for a newer
> > > platform onto an older one. Move PVC after ADL.
> >
> > Shouldn't we be moving the ADL platforms (graphics versions 12.0) higher
> > than DG1 (12.10) and DG2 (12.50) too?
>
> question then would be: would we be ordering them by gt
> version? Or by when they were introduced?
Since all of the platforms here have the GuC inside the
graphics IP[*], then the graphics IP version seems natural to me.
"When they were introduced" would be identical for all of these
platforms for the Xe driver (since we just dumped a big megapatch that
contained all of these platforms at once). But if you want to match
when they were introduced *in i915* that would be reasonable too,
although the ADLs would still need to come before DG2 in that case.
Matt
[*] MTL has a GuC in both the graphics IP and the media IP. One of our
questions early on was whether the GuC IP itself would differ between
the two GTs (requiring different firmwares for each). The response that
came back from the hardware team was that that's technically possible
with standalone media, but at least for MTL they'd keep them identical.
So for now, just basing 100% on the graphics IP version seems fine. In
the future we may need to stop tying GuC to platform at all and instead
match on the appropriate IP version for whichever GT we're loading on.
But that's a problem for the future...
>
> I think it makes more sense to be by when they were introduced as a
> platform in the driver.
>
> 1) what about media/display?
> 2) allow us to always be appending in the enum and elsewhere in
> the driver.
>
> Lucas De Marchi
>
> >
> >
> > Matt
> >
> > >
> > > Signed-off-by: Lucas De Marchi
> > > ---
> > > drivers/gpu/drm/xe/xe_platform_types.h | 3 +--
> > > drivers/gpu/drm/xe/xe_uc_fw.c | 2 +-
> > > 2 files changed, 2 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/xe/xe_platform_types.h
> > > b/drivers/gpu/drm/xe/xe_platform_types.h
> > > index 72612c832e88..10367f6cc75a 100644
> > > --- a/drivers/gpu/drm/xe/xe_platform_types.h
> > > +++ b/drivers/gpu/drm/xe/xe_platform_types.h
> > > @@ -9,14 +9,13 @@
> > > /* Keep in gen based order, and chronological order within a gen */
> > > enum xe_platform {
> > > XE_PLATFORM_UNINITIALIZED = 0,
> > > - /* gen12 */
> > > XE_TIGERLAKE,
> > > XE_ROCKETLAKE,
> > > XE_DG1,
> > > XE_DG2,
> > > - XE_PVC,
> > > XE_ALDERLAKE_S,
> > > XE_ALDERLAKE_P,
> > > + XE_PVC,
> > > XE_METEORLAKE,
> > > };
> > >
> > > diff --git a/drivers/gpu/drm/xe/xe_uc_fw.c b/drivers/gpu/drm/xe/xe_uc_fw.c
> > > index e2c982b37e87..174c42873ebb 100644
> > > --- a/drivers/gpu/drm/xe/xe_uc_fw.c
> > > +++ b/drivers/gpu/drm/xe/xe_uc_fw.c
> > > @@ -43,9 +43,9 @@ static struct xe_device *uc_fw_to_xe(struct xe_uc_fw
> > > *uc_fw)
> > > */
> > > #define XE_GUC_FIRMWARE_DEFS(fw_def, guc_def) \
> > > fw_def(METEORLAKE, guc_def(mtl, 70, 5, 2)) \
> > > + fw_def(PVC, guc_def(pvc, 70, 5, 2)) \
> > > fw_def(ALDERLAKE_P, guc_def(adlp, 70, 5, 2)) \
> > > fw_def(ALDERLAKE_S, guc_def(tgl, 70, 5, 2)) \
> > > - fw_def(PVC, guc_def(pvc, 70, 5, 2)) \
> > > fw_def(DG2, guc_def(dg2, 70, 5, 2)) \
> > > fw_def(DG1, guc_def(dg1, 70, 5, 2)) \
> > > fw_def(TIGERLAKE,guc_def(tgl, 70, 5, 2))
> > > --
> > > 2.39.0
> > >
> >
> > --
> > Matt Roper
> > Graphics Software Engineer
> > Linux GPU Platform Enablement
> > Intel Corporation
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH v10 11/15] drm/atomic-helper: Set fence deadline for vblank
f0c2eb0fe0a5] Add linux-next specific files for 20230331 # good: [b2bc47e9b2011a183f9d3d3454a294a938082fb9] Merge tag 'net-6.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net git bisect start '4b0f4525dc4fe8af17b3daefe585f0c2eb0fe0a5' 'b2bc47e9b2011a183f9d3d3454a294a938082fb9' # good: [ed5f95f3349003d74a4a11b27b0f05d6794c382a] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git git bisect good ed5f95f3349003d74a4a11b27b0f05d6794c382a # bad: [85f7d1bfa30a05df2c9d8a0e9f6b1f23b4a6f13b] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-dt.git git bisect bad 85f7d1bfa30a05df2c9d8a0e9f6b1f23b4a6f13b # bad: [fbd0f79f200f8e5cb73fb3d7b788de09a8f33a6f] Merge branch 'msm-next' of https://gitlab.freedesktop.org/drm/msm.git git bisect bad fbd0f79f200f8e5cb73fb3d7b788de09a8f33a6f # good: [90031bc33f7525f0cc7a9ef0b1df62a1a4463382] Merge tag 'amd-drm-next-6.4-2023-03-17' of https://gitlab.freedesktop.org/agd5f/linux into drm-next git bisect good 90031bc33f7525f0cc7a9ef0b1df62a1a4463382 # good: [d4e04817db670083aed73de1fadd3b21758e69ba] drm/amdgpu: Return from switch early for EEPROM I2C address git bisect good d4e04817db670083aed73de1fadd3b21758e69ba # good: [70e360f9b548d99f959668d4f047d1363d42fe8e] drm: exynos: dsi: Consolidate component and bridge git bisect good 70e360f9b548d99f959668d4f047d1363d42fe8e # bad: [0b43595d0cbb06736d1e572e79e29a410a273573] Merge branch 'drm-next' of https://gitlab.freedesktop.org/agd5f/linux git bisect bad 0b43595d0cbb06736d1e572e79e29a410a273573 # good: [fbb3b3500f76ec8b741bd2d0e761ca3e856ad924] dt-bindings: display: boe,tv101wum-nl6: document rotation git bisect good fbb3b3500f76ec8b741bd2d0e761ca3e856ad924 # bad: [82bbec189ab34873688484cd14189a5392946fbb] Merge v6.3-rc4 into drm-next git bisect bad 82bbec189ab34873688484cd14189a5392946fbb # bad: [d39e48ca80c0960b039cb38633957f0040f63e1a] drm/atomic-helper: Set fence deadline for vblank git bisect bad d39e48ca80c0960b039cb38633957f0040f63e1a # good: [d7d5a21dd6b4706c04fbba5d25db8da5f25aab68] dma-buf/dma-resv: Add a way to set fence deadline git bisect good d7d5a21dd6b4706c04fbba5d25db8da5f25aab68 # good: [f3823da7e4ba7d4781375c2bb786a8a78efc6591] drm/scheduler: Add fence deadline support git bisect good f3823da7e4ba7d4781375c2bb786a8a78efc6591 # good: [b2c077d001b612b1f34f7e528b2dc6072bd6794e] drm/vblank: Add helper to get next vblank time git bisect good b2c077d001b612b1f34f7e528b2dc6072bd6794e # first bad commit: [d39e48ca80c0960b039cb38633957f0040f63e1a] drm/atomic-helper: Set fence deadline for vblank
[PATCH] drm/nouveau/acr: remove unused loc variable
clang with W=1 reports drivers/gpu/drm/nouveau/nvkm/subdev/acr/lsfw.c:221:7: error: variable 'loc' set but not used [-Werror,-Wunused-but-set-variable] u32 loc, sig, cnt, *meta; ^ This variable is not used so remove it. Signed-off-by: Tom Rix --- drivers/gpu/drm/nouveau/nvkm/subdev/acr/lsfw.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/acr/lsfw.c b/drivers/gpu/drm/nouveau/nvkm/subdev/acr/lsfw.c index f36a359d4531..bd104a030243 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/acr/lsfw.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/acr/lsfw.c @@ -218,7 +218,7 @@ nvkm_acr_lsfw_load_sig_image_desc_v2(struct nvkm_subdev *subdev, const struct firmware *hsbl; const struct nvfw_ls_hsbl_bin_hdr *hdr; const struct nvfw_ls_hsbl_hdr *hshdr; - u32 loc, sig, cnt, *meta; + u32 sig, cnt, *meta; ret = nvkm_firmware_load_name(subdev, path, "hs_bl_sig", ver, ); if (ret) @@ -227,7 +227,6 @@ nvkm_acr_lsfw_load_sig_image_desc_v2(struct nvkm_subdev *subdev, hdr = nvfw_ls_hsbl_bin_hdr(subdev, hsbl->data); hshdr = nvfw_ls_hsbl_hdr(subdev, hsbl->data + hdr->header_offset); meta = (u32 *)(hsbl->data + hshdr->meta_data_offset); - loc = *(u32 *)(hsbl->data + hshdr->patch_loc); sig = *(u32 *)(hsbl->data + hshdr->patch_sig); cnt = *(u32 *)(hsbl->data + hshdr->num_sig); -- 2.27.0
Re: [PATCH] drm/bridge: ps8640: Use constant sleep time for polling hpd
Hi, On Thu, Mar 30, 2023 at 8:02 PM Pin-yen Lin wrote: > > The default hpd_wait_us in panel_edp.c is 2 seconds. This makes the > sleep time in the polling of _ps8640_wait_hpd_asserted become 200ms. > Change it to a constant 20ms to speed up the function. Ah, I see why I never ran into this. All the panels I worked with specified "hpd_absent" of 200 and thus I've always been using 20. > Signed-off-by: Pin-yen Lin > --- > > drivers/gpu/drm/bridge/parade-ps8640.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c > b/drivers/gpu/drm/bridge/parade-ps8640.c > index b823e55650b1..c3eb45179405 100644 > --- a/drivers/gpu/drm/bridge/parade-ps8640.c > +++ b/drivers/gpu/drm/bridge/parade-ps8640.c > @@ -184,7 +184,7 @@ static int _ps8640_wait_hpd_asserted(struct ps8640 > *ps_bridge, unsigned long wai > * actually connected to GPIO9). > */ > ret = regmap_read_poll_timeout(map, PAGE2_GPIO_H, status, > - status & PS_GPIO9, wait_us / 10, > wait_us); > + status & PS_GPIO9, 2, wait_us); I'd have been tempted to go even lower at 10ms. Waiting for HPD isn't something that we do all the time during a normal running system and thus it's not something we have to optimize every last bit of power out of. The user would generally rather have the system boot up or switch modes 10ms faster. ;-) In any case, either at 10ms or 20ms: Reviewed-by: Douglas Anderson -Doug
Re: [PATCH] drm/ttm: add NUMA node id to the pool
There is a subsequent patch where amdgpu directly calls ttm_pool_init to
create pools per NUMA node. That will depend on the updated function
signature.
Regards,
Felix
On 2023-03-31 15:17, Alex Deucher wrote:
On Fri, Mar 31, 2023 at 2:54 AM Christian König
wrote:
Should I push this to drm-misc-next or do we take it through
amd-staging-drm-next?
I think either way is fine. We can carry it internally as needed for
testing if you want to commit it to drm-misc-next. I don't think
there are any direct code dependencies, but you or Rajneesh can
correct me if I'm wrong.
Alex
Christian.
Am 30.03.23 um 21:50 schrieb Alex Deucher:
From: Rajneesh Bhardwaj
This allows backing ttm_tt structure with pages from different NUMA
pools.
Tested-by: Graham Sider
Reviewed-by: Felix Kuehling
Signed-off-by: Christian König
Signed-off-by: Rajneesh Bhardwaj
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/ttm/ttm_device.c | 2 +-
drivers/gpu/drm/ttm/ttm_pool.c | 13 -
include/drm/ttm/ttm_pool.h | 4 +++-
3 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c
index e7147e304637..4a8164a5320f 100644
--- a/drivers/gpu/drm/ttm/ttm_device.c
+++ b/drivers/gpu/drm/ttm/ttm_device.c
@@ -218,7 +218,7 @@ int ttm_device_init(struct ttm_device *bdev, struct
ttm_device_funcs *funcs,
bdev->funcs = funcs;
ttm_sys_man_init(bdev);
- ttm_pool_init(>pool, dev, use_dma_alloc, use_dma32);
+ ttm_pool_init(>pool, dev, NUMA_NO_NODE, use_dma_alloc, use_dma32);
bdev->vma_manager = vma_manager;
INIT_DELAYED_WORK(>wq, ttm_device_delayed_workqueue);
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index 9f6764bf3b15..1068a41cded1 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -92,7 +92,7 @@ static struct page *ttm_pool_alloc_page(struct ttm_pool
*pool, gfp_t gfp_flags,
__GFP_KSWAPD_RECLAIM;
if (!pool->use_dma_alloc) {
- p = alloc_pages(gfp_flags, order);
+ p = alloc_pages_node(pool->nid, gfp_flags, order);
if (p)
p->private = order;
return p;
@@ -286,7 +286,7 @@ static struct ttm_pool_type *ttm_pool_select_type(struct
ttm_pool *pool,
enum ttm_caching caching,
unsigned int order)
{
- if (pool->use_dma_alloc)
+ if (pool->use_dma_alloc || pool->nid != NUMA_NO_NODE)
return >caching[caching].orders[order];
#ifdef CONFIG_X86
@@ -523,29 +523,32 @@ EXPORT_SYMBOL(ttm_pool_free);
*
* @pool: the pool to initialize
* @dev: device for DMA allocations and mappings
+ * @nid: NUMA node to use for allocations
* @use_dma_alloc: true if coherent DMA alloc should be used
* @use_dma32: true if GFP_DMA32 should be used
*
* Initialize the pool and its pool types.
*/
void ttm_pool_init(struct ttm_pool *pool, struct device *dev,
-bool use_dma_alloc, bool use_dma32)
+int nid, bool use_dma_alloc, bool use_dma32)
{
unsigned int i, j;
WARN_ON(!dev && use_dma_alloc);
pool->dev = dev;
+ pool->nid = nid;
pool->use_dma_alloc = use_dma_alloc;
pool->use_dma32 = use_dma32;
- if (use_dma_alloc) {
+ if (use_dma_alloc || nid != NUMA_NO_NODE) {
for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
for (j = 0; j < MAX_ORDER; ++j)
ttm_pool_type_init(>caching[i].orders[j],
pool, i, j);
}
}
+EXPORT_SYMBOL(ttm_pool_init);
/**
* ttm_pool_fini - Cleanup a pool
@@ -559,7 +562,7 @@ void ttm_pool_fini(struct ttm_pool *pool)
{
unsigned int i, j;
- if (pool->use_dma_alloc) {
+ if (pool->use_dma_alloc || pool->nid != NUMA_NO_NODE) {
for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
for (j = 0; j < MAX_ORDER; ++j)
ttm_pool_type_fini(>caching[i].orders[j]);
diff --git a/include/drm/ttm/ttm_pool.h b/include/drm/ttm/ttm_pool.h
index ef09b23d29e3..23bd8be6d4f8 100644
--- a/include/drm/ttm/ttm_pool.h
+++ b/include/drm/ttm/ttm_pool.h
@@ -61,12 +61,14 @@ struct ttm_pool_type {
* struct ttm_pool - Pool for all caching and orders
*
* @dev: the device we allocate pages for
+ * @nid: which numa node to use
* @use_dma_alloc: if coherent DMA allocations should be used
* @use_dma32: if GFP_DMA32 should be used
* @caching: pools for each caching/order
*/
struct ttm_pool {
struct device *dev;
+ int nid;
bool use_dma_alloc;
bool use_dma32;
@@ -81,7 +83,7 @@ int ttm_pool_alloc(struct ttm_pool *pool, struct ttm_tt *tt,
void ttm_pool_free(struct ttm_pool *pool, struct ttm_tt *tt);
[PATCH] dt-bindings: bridge: Convert Samsung MIPI DSIM bridge to yaml
From: Jagan Teki Samsung MIPI DSIM bridge can be found on Exynos and NXP's i.MX8M Mini and Nano SoC's. Convert exynos_dsim.txt to yaml. Used the example node from latest Exynos SoC instead of the one used in legacy exynos_dsim.txt. Signed-off-by: Jagan Teki Signed-off-by: Fabio Estevam --- .../display/bridge/samsung,mipi-dsim.yaml | 275 ++ .../bindings/display/exynos/exynos_dsim.txt | 92 -- 2 files changed, 275 insertions(+), 92 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml delete mode 100644 Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt diff --git a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml new file mode 100644 index ..c131bd879caf --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml @@ -0,0 +1,275 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/samsung,mipi-dsim.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung MIPI DSIM bridge controller + +maintainers: + - Inki Dae + - Jagan Teki + +description: | + Samsung MIPI DSIM bridge controller can be found it on Exynos + and i.MX8M Mini and Nano SoC's. + +properties: + compatible: +enum: + - samsung,exynos3250-mipi-dsi + - samsung,exynos4210-mipi-dsi + - samsung,exynos5410-mipi-dsi + - samsung,exynos5422-mipi-dsi + - samsung,exynos5433-mipi-dsi + - fsl,imx8mm-mipi-dsim + - fsl,imx8mp-mipi-dsim + + reg: +maxItems: 1 + + interrupts: +maxItems: 1 + + '#address-cells': +const: 1 + + '#size-cells': +const: 0 + + clocks: +minItems: 2 +maxItems: 5 + + clock-names: +minItems: 2 +maxItems: 5 + + phys: +maxItems: 1 +description: phandle to the phy module representing the DPHY + + phy-names: +items: + - const: dsim + + samsung,phy-type: +$ref: /schemas/types.yaml#/definitions/uint32 +description: phandle to the samsung phy-type + + power-domains: +description: phandle to the associated power domain +maxItems: 1 + + samsung,power-domain: +$ref: /schemas/types.yaml#/definitions/phandle +description: phandle to the associated samsung power domain + + vddcore-supply: +description: MIPI DSIM Core voltage supply (e.g. 1.1V) + + vddio-supply: +description: MIPI DSIM I/O and PLL voltage supply (e.g. 1.8V) + + samsung,burst-clock-frequency: +$ref: /schemas/types.yaml#/definitions/uint32 +description: + DSIM high speed burst mode frequency. + + samsung,esc-clock-frequency: +$ref: /schemas/types.yaml#/definitions/uint32 +description: + DSIM escape mode frequency. + + samsung,pll-clock-frequency: +$ref: /schemas/types.yaml#/definitions/uint32 +description: + DSIM oscillator clock frequency. + + ports: +$ref: /schemas/graph.yaml#/properties/ports + +properties: + port@0: +$ref: /schemas/graph.yaml#/$defs/port-base +description: + Input port node to receive pixel data from the + display controller. Exactly one endpoint must be + specified. +properties: + endpoint@0: +$ref: /schemas/graph.yaml#/properties/endpoint +description: sub-node describing the input from MIC + +unevaluatedProperties: false + + port@1: +$ref: /schemas/graph.yaml#/properties/port +description: + DSI output port node to the panel or the next bridge + in the chain + +required: + - '#address-cells' + - '#size-cells' + - clock-names + - clocks + - compatible + - interrupts + - phy-names + - phys + - reg + - samsung,burst-clock-frequency + - samsung,esc-clock-frequency + - samsung,pll-clock-frequency + +allOf: + - $ref: ../dsi-controller.yaml# + - if: + properties: +compatible: + contains: +const: samsung,exynos5433-mipi-dsi + +then: + properties: +clocks: + minItems: 5 + +clock-names: + items: +- const: bus_clk +- const: phyclk_mipidphy0_bitclkdiv8 +- const: phyclk_mipidphy0_rxclkesc0 +- const: sclk_rgb_vclk_to_dsim0 +- const: sclk_mipi + +ports: + required: +- port@0 + + required: +- ports +- vddcore-supply +- vddio-supply + + - if: + properties: +compatible: + contains: +const: samsung,exynos5410-mipi-dsi + +then: + properties: +clocks: + minItems: 2 + +clock-names: + items: +- const: bus_clk +- const: pll_clk + + required: +- vddcore-supply +- vddio-supply + + - if: + properties: +
Re: [PATCH 1/4] dt-bindings: display: xinpeng,xpp055c272: document port
On Sun, Mar 26, 2023 at 10:42:21PM +0200, Krzysztof Kozlowski wrote: > Panels are supposed to have one port (defined in panel-common.yaml > binding): > > px30-evb.dtb: panel@0: 'port' does not match any of the regexes: > 'pinctrl-[0-9]+' > > Signed-off-by: Krzysztof Kozlowski > --- > .../bindings/display/panel/xinpeng,xpp055c272.yaml| 8 > 1 file changed, 8 insertions(+) Applied series to drm-misc. Rob
Re: [PATCH] dt-bindings: display: sitronix, st7789v: document dc-gpios
On Sun, 26 Mar 2023 18:47:00 +0200, Krzysztof Kozlowski wrote: > The device comes with DCX pin which is already used in > canaan/sipeed_maixduino.dts (although not in Linux driver). > > Signed-off-by: Krzysztof Kozlowski > --- > .../devicetree/bindings/display/panel/sitronix,st7789v.yaml | 4 > 1 file changed, 4 insertions(+) > Applied, thanks!
Re: [PATCH] accel/ivpu: Remove D3hot delay for Meteorlake
On Fri, Mar 31, 2023 at 01:40:27PM +0200, Stanislaw Gruszka wrote:
> From: Karol Wachowski
>
> VPU on MTL has hardware optimizations and does not require 10ms
> D0 - D3hot transition delay imposed by PCI specification.
PCIe r6.0, sec 5.9.
> The delay removal is traditionally done by adding PCI ID to
> quirk_remove_dhot_delay() in drivers/pci/quirks.c . But since
quirk_remove_d3hot_delay()
> we do not need that optimization before driver probe and we
> can better specify in the ivpu driver on what (future) hardware
> use the optimization, we do not use quirk_remove_dhot_delay()
Again.
> for that.
>
> Signed-off-by: Karol Wachowski
> Signed-off-by: Stanislaw Gruszka
> ---
> drivers/accel/ivpu/ivpu_drv.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c
> index 3be4a5a2b07a..cf9925c0a8ad 100644
> --- a/drivers/accel/ivpu/ivpu_drv.c
> +++ b/drivers/accel/ivpu/ivpu_drv.c
> @@ -442,6 +442,10 @@ static int ivpu_pci_init(struct ivpu_device *vdev)
> /* Clear any pending errors */
> pcie_capability_clear_word(pdev, PCI_EXP_DEVSTA, 0x3f);
>
> + /* VPU MTL does not require PCI spec 10m D3hot delay */
> + if (ivpu_is_mtl(vdev))
> + pdev->d3hot_delay = 0;
d3hot_delay is used after a D0->D3hot transition, after a D3hot->D0
transition, and after the D0->D3hot and D3hot->D0 transitions in
pci_pm_reset().
I assume this device can tolerate removing *all* of those delays,
right?
> ret = pcim_enable_device(pdev);
> if (ret) {
> ivpu_err(vdev, "Failed to enable PCI device: %d\n", ret);
> --
> 2.25.1
>
Re: [PATCH] drm/ttm: add NUMA node id to the pool
On Fri, Mar 31, 2023 at 2:54 AM Christian König
wrote:
>
> Should I push this to drm-misc-next or do we take it through
> amd-staging-drm-next?
I think either way is fine. We can carry it internally as needed for
testing if you want to commit it to drm-misc-next. I don't think
there are any direct code dependencies, but you or Rajneesh can
correct me if I'm wrong.
Alex
>
> Christian.
>
> Am 30.03.23 um 21:50 schrieb Alex Deucher:
> > From: Rajneesh Bhardwaj
> >
> > This allows backing ttm_tt structure with pages from different NUMA
> > pools.
> >
> > Tested-by: Graham Sider
> > Reviewed-by: Felix Kuehling
> > Signed-off-by: Christian König
> > Signed-off-by: Rajneesh Bhardwaj
> > Signed-off-by: Alex Deucher
> > ---
> > drivers/gpu/drm/ttm/ttm_device.c | 2 +-
> > drivers/gpu/drm/ttm/ttm_pool.c | 13 -
> > include/drm/ttm/ttm_pool.h | 4 +++-
> > 3 files changed, 12 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/ttm/ttm_device.c
> > b/drivers/gpu/drm/ttm/ttm_device.c
> > index e7147e304637..4a8164a5320f 100644
> > --- a/drivers/gpu/drm/ttm/ttm_device.c
> > +++ b/drivers/gpu/drm/ttm/ttm_device.c
> > @@ -218,7 +218,7 @@ int ttm_device_init(struct ttm_device *bdev, struct
> > ttm_device_funcs *funcs,
> > bdev->funcs = funcs;
> >
> > ttm_sys_man_init(bdev);
> > - ttm_pool_init(>pool, dev, use_dma_alloc, use_dma32);
> > + ttm_pool_init(>pool, dev, NUMA_NO_NODE, use_dma_alloc,
> > use_dma32);
> >
> > bdev->vma_manager = vma_manager;
> > INIT_DELAYED_WORK(>wq, ttm_device_delayed_workqueue);
> > diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
> > index 9f6764bf3b15..1068a41cded1 100644
> > --- a/drivers/gpu/drm/ttm/ttm_pool.c
> > +++ b/drivers/gpu/drm/ttm/ttm_pool.c
> > @@ -92,7 +92,7 @@ static struct page *ttm_pool_alloc_page(struct ttm_pool
> > *pool, gfp_t gfp_flags,
> > __GFP_KSWAPD_RECLAIM;
> >
> > if (!pool->use_dma_alloc) {
> > - p = alloc_pages(gfp_flags, order);
> > + p = alloc_pages_node(pool->nid, gfp_flags, order);
> > if (p)
> > p->private = order;
> > return p;
> > @@ -286,7 +286,7 @@ static struct ttm_pool_type
> > *ttm_pool_select_type(struct ttm_pool *pool,
> > enum ttm_caching caching,
> > unsigned int order)
> > {
> > - if (pool->use_dma_alloc)
> > + if (pool->use_dma_alloc || pool->nid != NUMA_NO_NODE)
> > return >caching[caching].orders[order];
> >
> > #ifdef CONFIG_X86
> > @@ -523,29 +523,32 @@ EXPORT_SYMBOL(ttm_pool_free);
> >*
> >* @pool: the pool to initialize
> >* @dev: device for DMA allocations and mappings
> > + * @nid: NUMA node to use for allocations
> >* @use_dma_alloc: true if coherent DMA alloc should be used
> >* @use_dma32: true if GFP_DMA32 should be used
> >*
> >* Initialize the pool and its pool types.
> >*/
> > void ttm_pool_init(struct ttm_pool *pool, struct device *dev,
> > -bool use_dma_alloc, bool use_dma32)
> > +int nid, bool use_dma_alloc, bool use_dma32)
> > {
> > unsigned int i, j;
> >
> > WARN_ON(!dev && use_dma_alloc);
> >
> > pool->dev = dev;
> > + pool->nid = nid;
> > pool->use_dma_alloc = use_dma_alloc;
> > pool->use_dma32 = use_dma32;
> >
> > - if (use_dma_alloc) {
> > + if (use_dma_alloc || nid != NUMA_NO_NODE) {
> > for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
> > for (j = 0; j < MAX_ORDER; ++j)
> >
> > ttm_pool_type_init(>caching[i].orders[j],
> > pool, i, j);
> > }
> > }
> > +EXPORT_SYMBOL(ttm_pool_init);
> >
> > /**
> >* ttm_pool_fini - Cleanup a pool
> > @@ -559,7 +562,7 @@ void ttm_pool_fini(struct ttm_pool *pool)
> > {
> > unsigned int i, j;
> >
> > - if (pool->use_dma_alloc) {
> > + if (pool->use_dma_alloc || pool->nid != NUMA_NO_NODE) {
> > for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
> > for (j = 0; j < MAX_ORDER; ++j)
> >
> > ttm_pool_type_fini(>caching[i].orders[j]);
> > diff --git a/include/drm/ttm/ttm_pool.h b/include/drm/ttm/ttm_pool.h
> > index ef09b23d29e3..23bd8be6d4f8 100644
> > --- a/include/drm/ttm/ttm_pool.h
> > +++ b/include/drm/ttm/ttm_pool.h
> > @@ -61,12 +61,14 @@ struct ttm_pool_type {
> >* struct ttm_pool - Pool for all caching and orders
> >*
> >* @dev: the device we allocate pages for
> > + * @nid: which numa node to use
> >* @use_dma_alloc: if coherent DMA allocations should be used
> >* @use_dma32: if GFP_DMA32 should be used
> >* @caching: pools for each caching/order
> >*/
> > struct ttm_pool {
> > struct device *dev;
> > + int
[PATCH RFC v2 6/6] drm/msm/dsi: Fix calculations for eol_byte_num and pkt_per_line
Use the correct calculations for eol_byte_num and pkt_per_line.
Currently, pkt_per_line is calculated by dividing slice_per_intf by
slice_count. This is incorrect, as slice_per_intf should be divided by
slice_per_pkt, which is not always equivalent to slice_count as it is
possible for there to be multiple soft slices per interface even though
a panel only specifies one slice per packet.
For eol_byte_num, the current calculation describes the size of the
trailing bytes in the line. Change the calculation so that it describes
the number of padding bytes instead.
Fixes: 08802f515c3c ("drm/msm/dsi: Add support for DSC configuration")
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index b7ab81737473..613ec19f4383 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -842,7 +842,7 @@ static void dsi_update_dsc_timing(struct msm_dsi_host
*msm_host, bool is_cmd_mod
{
struct drm_dsc_config *dsc = msm_host->dsc;
u32 reg, reg_ctrl, reg_ctrl2;
- u32 slice_per_intf, total_bytes_per_intf;
+ u32 slice_per_intf;
u32 pkt_per_line;
u32 eol_byte_num;
@@ -859,10 +859,12 @@ static void dsi_update_dsc_timing(struct msm_dsi_host
*msm_host, bool is_cmd_mod
if (dsc->slice_count > slice_per_intf)
dsc->slice_count = 1;
- total_bytes_per_intf = dsc->slice_chunk_size * slice_per_intf;
+ eol_byte_num = msm_dsc_get_eol_byte_num(dsc, hdisplay,
dsi_get_bpp(msm_host->format));
- eol_byte_num = total_bytes_per_intf % 3;
- pkt_per_line = slice_per_intf / dsc->slice_count;
+ /* Default to 1 slice_per_pkt, so pkt_per_line will be equal to
+* slice per intf.
+*/
+ pkt_per_line = slice_per_intf;
if (is_cmd_mode) /* packet data type */
reg =
DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_DATATYPE(MIPI_DSI_DCS_LONG_WRITE);
--
2.39.2
[PATCH RFC v2 5/6] drm/msm/dsi: Use MSM and DRM DSC helper methods
Use MSM and DRM DSC helper methods to configure DSC for DSI. Changes in V2: - *_calculate_initial_scale_value --> *_set_initial_scale_value - Split pkt_per_line and eol_byte_num changes to a separate patch - Moved pclk_per_line calculation to hdisplay adjustment in `if (dsc)` block of dsi_update_dsc_timing() Signed-off-by: Jessica Zhang --- drivers/gpu/drm/msm/dsi/dsi_host.c | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c b/drivers/gpu/drm/msm/dsi/dsi_host.c index 74d38f90398a..b7ab81737473 100644 --- a/drivers/gpu/drm/msm/dsi/dsi_host.c +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c @@ -28,6 +28,7 @@ #include "dsi.xml.h" #include "sfpb.xml.h" #include "dsi_cfg.h" +#include "msm_dsc_helper.h" #include "msm_kms.h" #include "msm_gem.h" #include "phy/dsi_phy.h" @@ -848,7 +849,7 @@ static void dsi_update_dsc_timing(struct msm_dsi_host *msm_host, bool is_cmd_mod /* first calculate dsc parameters and then program * compress mode registers */ - slice_per_intf = DIV_ROUND_UP(hdisplay, dsc->slice_width); + slice_per_intf = msm_dsc_get_slice_per_intf(dsc, hdisplay); /* * If slice_count is greater than slice_per_intf @@ -951,7 +952,11 @@ static void dsi_timing_setup(struct msm_dsi_host *msm_host, bool is_bonded_dsi) * pulse width same */ h_total -= hdisplay; - hdisplay /= 3; + if (msm_host->mode_flags & MIPI_DSI_MODE_VIDEO) + hdisplay = msm_dsc_get_uncompressed_pclk_per_line(dsc, hdisplay, + dsi_get_bpp(msm_host->format)) / 3; + else + hdisplay /= 3; h_total += hdisplay; ha_end = ha_start + hdisplay; } @@ -1759,7 +1764,7 @@ static int dsi_populate_dsc_params(struct msm_dsi_host *msm_host, struct drm_dsc return ret; } - dsc->initial_scale_value = 32; + drm_dsc_set_initial_scale_value(dsc); dsc->line_buf_depth = dsc->bits_per_component + 1; return drm_dsc_compute_rc_parameters(dsc); -- 2.39.2
[PATCH RFC v2 2/6] drm/msm: Add MSM-specific DSC helper methods
Introduce MSM-specific DSC helper methods, as some calculations are
common between DP and DSC.
Changes in v2:
- Moved files up to msm/ directory
- Dropped get_comp_ratio() helper
- Used drm_int2fixp() to convert to integers to fp
- Style changes to improve readability
- Dropped unused bpp variable in msm_dsc_get_dce_bytes_per_line()
- Changed msm_dsc_get_slice_per_intf() to a static inline method
- Dropped last division step of msm_dsc_get_pclk_per_line() and changed
method name accordingly
- Changed DSC_BPP macro to drm_dsc_get_bpp_int() helper method
- Fixed some math issues caused by passing in incorrect types to
drm_fixed methods in get_bytes_per_soft_slice()
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/Makefile | 1 +
drivers/gpu/drm/msm/msm_dsc_helper.c | 53
drivers/gpu/drm/msm/msm_dsc_helper.h | 42
3 files changed, 96 insertions(+)
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 7274c41228ed..b814fc80e2d5 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -94,6 +94,7 @@ msm-y += \
msm_atomic_tracepoints.o \
msm_debugfs.o \
msm_drv.o \
+ msm_dsc_helper.o \
msm_fb.o \
msm_fence.o \
msm_gem.o \
diff --git a/drivers/gpu/drm/msm/msm_dsc_helper.c
b/drivers/gpu/drm/msm/msm_dsc_helper.c
new file mode 100644
index ..60b73e17e6eb
--- /dev/null
+++ b/drivers/gpu/drm/msm/msm_dsc_helper.c
@@ -0,0 +1,53 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved
+ */
+
+#include
+#include
+#include
+
+#include "msm_drv.h"
+#include "msm_dsc_helper.h"
+
+static s64 get_bytes_per_soft_slice(struct drm_dsc_config *dsc, int
intf_width, u32 src_bpp)
+{
+ int bpp = msm_dsc_get_bpp_int(dsc);
+ s64 numerator_fp, denominator_fp;
+ s64 comp_ratio_fp = drm_fixp_from_fraction(src_bpp, bpp);
+
+ numerator_fp = drm_int2fixp(dsc->slice_width * 3);
+ denominator_fp = drm_fixp_from_fraction(comp_ratio_fp * 8,
drm_int2fixp(bpp));
+
+ return drm_fixp_div(numerator_fp, denominator_fp);
+}
+
+u32 msm_dsc_get_eol_byte_num(struct drm_dsc_config *dsc, int intf_width, u32
src_bpp)
+{
+ u32 bytes_per_soft_slice, extra_eol_bytes, bytes_per_intf;
+ s64 bytes_per_soft_slice_fp;
+ int slice_per_intf = msm_dsc_get_slice_per_intf(dsc, intf_width);
+
+ bytes_per_soft_slice_fp = get_bytes_per_soft_slice(dsc, intf_width,
src_bpp);
+ bytes_per_soft_slice = drm_fixp2int_ceil(bytes_per_soft_slice_fp);
+
+ bytes_per_intf = bytes_per_soft_slice * slice_per_intf;
+ extra_eol_bytes = bytes_per_intf % 3;
+ if (extra_eol_bytes != 0)
+ extra_eol_bytes = 3 - extra_eol_bytes;
+
+ return extra_eol_bytes;
+}
+
+int msm_dsc_get_uncompressed_pclk_per_line(struct drm_dsc_config *dsc, int
intf_width, u32 src_bpp)
+{
+ s64 data_width;
+
+ if (!dsc->slice_width || (intf_width < dsc->slice_width))
+ return -EINVAL;
+
+ data_width = drm_fixp_mul(dsc->slice_count,
+ get_bytes_per_soft_slice(dsc, intf_width, src_bpp));
+
+ return drm_fixp2int_ceil(data_width);
+}
diff --git a/drivers/gpu/drm/msm/msm_dsc_helper.h
b/drivers/gpu/drm/msm/msm_dsc_helper.h
new file mode 100644
index ..743cd324b7d9
--- /dev/null
+++ b/drivers/gpu/drm/msm/msm_dsc_helper.h
@@ -0,0 +1,42 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved
+ */
+
+#ifndef MSM_DSC_HELPER_H_
+#define MSM_DSC_HELPER_H_
+
+#include
+#include
+
+/*
+ * Helper methods for MSM specific DSC calculations that are common between
timing engine,
+ * DSI, and DP.
+ */
+
+static inline int msm_dsc_get_bpp_int(struct drm_dsc_config *dsc)
+{
+ WARN_ON_ONCE(dsc->bits_per_pixel & 0xf);
+ return dsc->bits_per_pixel >> 4;
+}
+
+static inline int msm_dsc_get_slice_per_intf(struct drm_dsc_config *dsc, int
intf_width)
+{
+ return DIV_ROUND_UP(intf_width, dsc->slice_width);
+}
+
+static inline u32 msm_dsc_get_dce_bytes_per_line(struct drm_dsc_config *dsc,
int intf_width)
+{
+ return DIV_ROUND_UP(msm_dsc_get_bpp_int(dsc) * intf_width, 8);
+}
+
+u32 msm_dsc_get_eol_byte_num(struct drm_dsc_config *dsc, int intf_width, u32
src_bpp);
+u32 msm_dsc_get_dce_bytes_per_line(struct drm_dsc_config *dsc, int intf_width);
+
+/* Calculate uncompressed pclk per line. This value will then be passed along
to
+ * DSI and DP to calculate pclk_per_line. This is because DSI and DP divide the
+ * uncompressed pclk_per_line by different values depending on if widebus is
enabled.
+ */
+int msm_dsc_get_uncompressed_pclk_per_line(struct drm_dsc_config *dsc,
+ int intf_width, u32 src_bpp);
+#endif /* MSM_DSC_HELPER_H_ */
--
2.39.2
[PATCH RFC v2 3/6] drm/msm/dpu: Use DRM DSC helper for det_thresh_flatness
Use the DRM DSC helper for det_thresh_flatness to match downstream
implementation and the DSC spec.
Changes in V2:
- Added a Fixes tag
Fixes: c110cfd1753e ("drm/msm/disp/dpu1: Add support for DSC")
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
index 619926da1441..b952f7d2b7f5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
@@ -3,6 +3,8 @@
* Copyright (c) 2020-2022, Linaro Limited
*/
+#include
+
#include "dpu_kms.h"
#include "dpu_hw_catalog.h"
#include "dpu_hwio.h"
@@ -102,7 +104,7 @@ static void dpu_hw_dsc_config(struct dpu_hw_dsc *hw_dsc,
data |= dsc->final_offset;
DPU_REG_WRITE(c, DSC_DSC_OFFSET, data);
- det_thresh_flatness = 7 + 2 * (dsc->bits_per_component - 8);
+ det_thresh_flatness = drm_dsc_calculate_flatness_det_thresh(dsc);
data = det_thresh_flatness << 10;
data |= dsc->flatness_max_qp << 5;
data |= dsc->flatness_min_qp;
--
2.39.2
[PATCH RFC v2 0/6] Introduce MSM-specific DSC helpers
There are some overlap in calculations for MSM-specific DSC variables between DP and DSI. In addition, the calculations for initial_scale_value and det_thresh_flatness that are defined within the DSC 1.2 specifications, but aren't yet included in drm_dsc_helper.c. This series moves these calculations to a shared msm_dsc_helper.c file and defines drm_dsc_helper methods for initial_scale_value and det_thresh_flatness. Note: For now, the MSM specific helper methods are only called for the DSI path, but will called for DP once DSC 1.2 support for DP has been added. Depends on: "drm/i915: move DSC RC tables to drm_dsc_helper.c" [1] [1] https://patchwork.freedesktop.org/series/114472/ --- Changes in v2: - Changed det_thresh_flatness to flatness_det_thresh - Moved msm_dsc_helper files to msm/ directory - Fixed type mismatch issues in MSM DSC helpers - Dropped MSM_DSC_SLICE_PER_PKT macro - Removed get_comp_ratio() helper - Style changes to improve readability - Use drm_dsc_get_bpp_int() instead of DSC_BPP macro - Picked up Fixes tags for patches 3/5 and 4/5 - Picked up Reviewed-by for patch 4/5 - Split eol_byte_num and pkt_per_line calculation into a separate patch - Moved pclk_per_line calculation into `if (dsc)` block in dsi_timing_setup() - Link to v1: https://lore.kernel.org/r/20230329-rfc-msm-dsc-helper-v1-0-f3e479f59...@quicinc.com --- Jessica Zhang (6): drm/display/dsc: Add flatness and initial scale value calculations drm/msm: Add MSM-specific DSC helper methods drm/msm/dpu: Use DRM DSC helper for det_thresh_flatness drm/msm/dpu: Fix slice_last_group_size calculation drm/msm/dsi: Use MSM and DRM DSC helper methods drm/msm/dsi: Fix calculations for eol_byte_num and pkt_per_line drivers/gpu/drm/msm/Makefile | 1 + drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 10 -- drivers/gpu/drm/msm/dsi/dsi_host.c | 21 drivers/gpu/drm/msm/msm_dsc_helper.c | 53 ++ drivers/gpu/drm/msm/msm_dsc_helper.h | 42 +++ include/drm/display/drm_dsc_helper.h | 11 +++ 6 files changed, 129 insertions(+), 9 deletions(-) --- base-commit: 56777fc93a145afcf71b92ba4281250f59ba6d9b change-id: 20230329-rfc-msm-dsc-helper-981a95edfbd0 Best regards, -- Jessica Zhang
[PATCH RFC v2 4/6] drm/msm/dpu: Fix slice_last_group_size calculation
Correct the math for slice_last_group_size so that it matches the
calculations downstream.
Fixes: c110cfd1753e ("drm/msm/disp/dpu1: Add support for DSC")
Signed-off-by: Jessica Zhang
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
index b952f7d2b7f5..9312a8d7fbd9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
@@ -56,7 +56,11 @@ static void dpu_hw_dsc_config(struct dpu_hw_dsc *hw_dsc,
if (is_cmd_mode)
initial_lines += 1;
- slice_last_group_size = 3 - (dsc->slice_width % 3);
+ slice_last_group_size = dsc->slice_width % 3;
+
+ if (slice_last_group_size == 0)
+ slice_last_group_size = 3;
+
data = (initial_lines << 20);
data |= ((slice_last_group_size - 1) << 18);
/* bpp is 6.4 format, 4 LSBs bits are for fractional part */
--
2.39.2
[PATCH RFC v2 1/6] drm/display/dsc: Add flatness and initial scale value calculations
Add helpers to calculate det_thresh_flatness and initial_scale_value as
these calculations are defined within the DSC spec.
Changes in v2:
- Renamed det_thresh_flatness to flatness_det_thresh
- Set initial_scale_value directly in helper
Signed-off-by: Jessica Zhang
---
include/drm/display/drm_dsc_helper.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/include/drm/display/drm_dsc_helper.h
b/include/drm/display/drm_dsc_helper.h
index 4448c482b092..f6bc268c1719 100644
--- a/include/drm/display/drm_dsc_helper.h
+++ b/include/drm/display/drm_dsc_helper.h
@@ -17,6 +17,17 @@ enum drm_dsc_params_kind {
DRM_DSC_1_2_420,
};
+static inline void drm_dsc_set_initial_scale_value(struct drm_dsc_config *dsc)
+{
+ dsc->initial_scale_value = 8 * dsc->rc_model_size /
+ (dsc->rc_model_size - dsc->initial_offset);
+}
+
+static inline int drm_dsc_calculate_flatness_det_thresh(struct drm_dsc_config
*dsc)
+{
+ return 2 << (dsc->bits_per_component - 8);
+}
+
void drm_dsc_dp_pps_header_init(struct dp_sdp_header *pps_header);
int drm_dsc_dp_rc_buffer_size(u8 rc_buffer_block_size, u8 rc_buffer_size);
void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set *pps_sdp,
--
2.39.2
Re: [RFC PATCH v8] media: mediatek: vcodec: support stateless AV1 decoder
Hi Xiao, Le lundi 30 janvier 2023 à 20:38 +0800, Xiaoyong Lu a écrit : > Add mediatek av1 decoder linux driver which use the stateless API in > MT8195. > I think this no longer needs an RFC tag. While at it, it would be nice for the maintainer to rebase on top if latest media stage (you still have to pull the uAPI of course). > > Signed-off-by: Xiaoyong Lu Tested-by: Nicolas Dufresne Reviewed-by: Nicolas Dufresne > --- > Changes from v7: Please, don't forget to include your fluster test result here too. Fluster has 3 test suites, you should provide the score for each of them, and perhaps explain the failures if any (I think 10bit/422/444 is what remains, and is unsupported atm). Also, don't forget to double check with checkpatch (with --strict) to make sure you have no style issue. > > - change V4L2_CID_STATELESS_AV1_PROFILE to V4L2_CID_MPEG_VIDEO_AV1_PROFILE, > V4L2_CID_STATELESS_AV1_LEVEL to V4L2_CID_MPEG_VIDEO_AV1_LEVEL to match av1 > uAPI V4. > - remove vsi and ctx null check in vdec_av1_slice_init_cdf_table, > vdec_av1_slice_init_iq_table for the never true condition. > - add inline in function vdec_av1_slice_clear_fb, > vdec_av1_slice_vsi_from_remote, > vdec_av1_slice_vsi_to_remote, vdec_av1_slice_setup_state, > vdec_av1_slice_setup_operating_mode and vdec_av1_slice_get_dpb_size. > - remove fb_idx check in vdec_av1_slice_decrease_ref_count. > - add define AV1_CDF_TABLE_BUFFER_SIZE for magic number 16384. > - remove intermediate variable "size" at the end of > vdec_av1_slice_alloc_working_buffer. > - use define V4L2_AV1_WARP_MODEL_AFFINE to replace magic number 3 in > vdec_av1_slice_setup_gm. > - change api name vdec_av1_slice_get_relative_dist to > vdec_av1_slice_get_sign_bias and return 0 or 1 for the caller directly use. > - add define AV1_PRIMARY_REF_NONE for magic number 7. > - remove TODO comment in vdec_av1_slice_update_core. > - change name irq to irq_enabled in struct vdec_av1_slice_instance. > - Add newline before return statememt in vdec_av1_slice_init and > vdec_av1_slice_flush. > - remove work_buffer assignment and merge 3 loops with one in > vdec_av1_slice_alloc_working_buffer. > - remove va null check in vdec_av1_slice_free_working_buffer. > - swap order between vdec_av1_slice_clear_fb and > vdec_msg_queue_wait_lat_buf_full in vdec_av1_slice_flush. > - test by av1 fluster, result is 173/239 > > Changes from v6: > > - change slot_id type from u8 to s8 > - test by av1 fluster, result is 173/239 > > Changes from v5: > > - change av1 PROFILE and LEVEL cfg > - test by av1 fluster, result is 173/239 > > Changes from v4: > > - convert vb2_find_timestamp to vb2_find_buffer > - test by av1 fluster, result is 173/239 > > Changes from v3: > > - modify comment for struct vdec_av1_slice_slot > - add define SEG_LVL_ALT_Q > - change use_lr/use_chroma_lr parse from av1 spec > - use ARRAY_SIZE to replace size for loop_filter_level and > loop_filter_mode_deltas > - change array size of loop_filter_mode_deltas from 4 to 2 > - add define SECONDARY_FILTER_STRENGTH_NUM_BITS > - change some hex values from upper case to lower case > - change *dpb_sz equal to V4L2_AV1_TOTAL_REFS_PER_FRAME + 1 > - test by av1 fluster, result is 173/239 > > Changes from v2: > > - Match with av1 uapi v3 modify > - test by av1 fluster, result is 173/239 > > --- > Reference series: > [1]: v4 of this series is presend by Daniel Almeida. > message-id: 20230103154832.6982-1-daniel.alme...@collabora.com > > .../media/platform/mediatek/vcodec/Makefile |1 + > .../vcodec/mtk_vcodec_dec_stateless.c | 47 +- > .../platform/mediatek/vcodec/mtk_vcodec_drv.h |1 + > .../vcodec/vdec/vdec_av1_req_lat_if.c | 2203 + > .../platform/mediatek/vcodec/vdec_drv_if.c|4 + > .../platform/mediatek/vcodec/vdec_drv_if.h|1 + > .../platform/mediatek/vcodec/vdec_msg_queue.c | 27 + > .../platform/mediatek/vcodec/vdec_msg_queue.h |4 + > 8 files changed, 2287 insertions(+), 1 deletion(-) > create mode 100644 > drivers/media/platform/mediatek/vcodec/vdec/vdec_av1_req_lat_if.c > > diff --git a/drivers/media/platform/mediatek/vcodec/Makefile > b/drivers/media/platform/mediatek/vcodec/Makefile > index 93e7a343b5b0e..7537259130072 100644 > --- a/drivers/media/platform/mediatek/vcodec/Makefile > +++ b/drivers/media/platform/mediatek/vcodec/Makefile > @@ -10,6 +10,7 @@ mtk-vcodec-dec-y := vdec/vdec_h264_if.o \ > vdec/vdec_vp8_req_if.o \ > vdec/vdec_vp9_if.o \ > vdec/vdec_vp9_req_lat_if.o \ > + vdec/vdec_av1_req_lat_if.o \ > vdec/vdec_h264_req_if.o \ > vdec/vdec_h264_req_common.o \ > vdec/vdec_h264_req_multi_if.o \ > diff --git > a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec_stateless.c > b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec_stateless.c > index 04beb3f08eead..dbed52a5430de 100644 > ---
[PATCH] dt-bindings: arm: nvidia: Drop unneeded quotes
Cleanup bindings dropping unneeded quotes. Once all these are fixed, checking for this can be enabled in yamllint. Signed-off-by: Rob Herring --- .../devicetree/bindings/arm/nvidia,tegra194-ccplex.yaml | 6 +++--- .../bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml | 6 +++--- .../bindings/arm/tegra/nvidia,tegra194-axi2apb.yaml | 4 ++-- .../bindings/arm/tegra/nvidia,tegra194-cbb.yaml | 8 .../bindings/arm/tegra/nvidia,tegra234-cbb.yaml | 4 ++-- .../bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml| 4 ++-- .../bindings/gpu/host1x/nvidia,tegra210-nvenc.yaml| 4 ++-- .../bindings/gpu/host1x/nvidia,tegra210-nvjpg.yaml| 4 ++-- .../bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml| 4 ++-- 9 files changed, 22 insertions(+), 22 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/nvidia,tegra194-ccplex.yaml b/Documentation/devicetree/bindings/arm/nvidia,tegra194-ccplex.yaml index b6f57d79a753..84dc6b7512af 100644 --- a/Documentation/devicetree/bindings/arm/nvidia,tegra194-ccplex.yaml +++ b/Documentation/devicetree/bindings/arm/nvidia,tegra194-ccplex.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/nvidia,tegra194-ccplex.yaml#; -$schema: "http://devicetree.org/meta-schemas/core.yaml#; +$id: http://devicetree.org/schemas/arm/nvidia,tegra194-ccplex.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: NVIDIA Tegra194 CPU Complex @@ -25,7 +25,7 @@ properties: - nvidia,tegra194-ccplex nvidia,bpmp: -$ref: '/schemas/types.yaml#/definitions/phandle' +$ref: /schemas/types.yaml#/definitions/phandle description: | Specifies the bpmp node that needs to be queried to get operating point data for all CPUs. diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml index 6089a96eae4f..36dbd0838f2d 100644 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/tegra/nvidia,tegra-ccplex-cluster.yaml#; -$schema: "http://devicetree.org/meta-schemas/core.yaml#; +$id: http://devicetree.org/schemas/arm/tegra/nvidia,tegra-ccplex-cluster.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: NVIDIA Tegra CPU COMPLEX CLUSTER area @@ -29,7 +29,7 @@ properties: maxItems: 1 nvidia,bpmp: -$ref: '/schemas/types.yaml#/definitions/phandle' +$ref: /schemas/types.yaml#/definitions/phandle description: | Specifies the BPMP node that needs to be queried to get operating point data for all CPUs. diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-axi2apb.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-axi2apb.yaml index 788a13f8aa93..5e0f1dc542b0 100644 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-axi2apb.yaml +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-axi2apb.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/tegra/nvidia,tegra194-axi2apb.yaml#; -$schema: "http://devicetree.org/meta-schemas/core.yaml#; +$id: http://devicetree.org/schemas/arm/tegra/nvidia,tegra194-axi2apb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: NVIDIA Tegra194 AXI2APB bridge diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-cbb.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-cbb.yaml index dd3a4770c6a1..d9c54c32c6b9 100644 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-cbb.yaml +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-cbb.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/tegra/nvidia,tegra194-cbb.yaml#; -$schema: "http://devicetree.org/meta-schemas/core.yaml#; +$id: http://devicetree.org/schemas/arm/tegra/nvidia,tegra194-cbb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: NVIDIA Tegra194 CBB 1.0 @@ -64,13 +64,13 @@ properties: - description: secure interrupt nvidia,axi2apb: -$ref: '/schemas/types.yaml#/definitions/phandle' +$ref: /schemas/types.yaml#/definitions/phandle description: Specifies the node having all axi2apb bridges which need to be checked for any error logged in their status register. nvidia,apbmisc: -$ref: '/schemas/types.yaml#/definitions/phandle' +$ref: /schemas/types.yaml#/definitions/phandle description: Specifies the apbmisc node which need to be used for reading
Re: [PATCH 14/19] drm/i915/i915_gem: Provide function names to complete the expected kerneldoc format
Hi Lee,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-misc/drm-misc-next next-20230331]
[cannot apply to drm-intel/for-linux-next-fixes lee-leds/for-leds-next
linus/master v6.3-rc4]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Lee-Jones/drm-i915-i915_scatterlist-Fix-kerneldoc-formatting-issue-missing/20230331-173046
base: git://anongit.freedesktop.org/drm-intel for-linux-next
patch link:
https://lore.kernel.org/r/20230331092607.700644-15-lee%40kernel.org
patch subject: [PATCH 14/19] drm/i915/i915_gem: Provide function names to
complete the expected kerneldoc format
config: i386-defconfig
(https://download.01.org/0day-ci/archive/20230401/202304010108.zhceycjv-...@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-8) 11.3.0
reproduce (this is a W=1 build):
#
https://github.com/intel-lab-lkp/linux/commit/6fa884d5ec2846c7d9b54c4895c7114b363c4389
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Lee-Jones/drm-i915-i915_scatterlist-Fix-kerneldoc-formatting-issue-missing/20230331-173046
git checkout 6fa884d5ec2846c7d9b54c4895c7114b363c4389
# save the config file
mkdir build_dir && cp config build_dir/.config
make W=1 O=build_dir ARCH=i386 olddefconfig
make W=1 O=build_dir ARCH=i386 SHELL=/bin/bash
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
| Link:
https://lore.kernel.org/oe-kbuild-all/202304010108.zhceycjv-...@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/i915/i915_gem.c:819: warning: expecting prototype for
>> i915_gem_sw_finish_ioct(). Prototype was for i915_gem_sw_finish_ioctl()
>> instead
vim +819 drivers/gpu/drm/i915/i915_gem.c
673a394b1e3b69 Eric Anholt2008-07-30 809
673a394b1e3b69 Eric Anholt2008-07-30 810 /**
6fa884d5ec2846 Lee Jones 2023-03-31 811 * i915_gem_sw_finish_ioct -
Called when user space has done writes to this buffer
14bb2c11796d70 Tvrtko Ursulin 2016-06-03 812 * @dev: drm device
14bb2c11796d70 Tvrtko Ursulin 2016-06-03 813 * @data: ioctl data blob
14bb2c11796d70 Tvrtko Ursulin 2016-06-03 814 * @file: drm file
673a394b1e3b69 Eric Anholt2008-07-30 815 */
673a394b1e3b69 Eric Anholt2008-07-30 816 int
673a394b1e3b69 Eric Anholt2008-07-30 817 i915_gem_sw_finish_ioctl(struct
drm_device *dev, void *data,
05394f3975dceb Chris Wilson 2010-11-08 818struct
drm_file *file)
673a394b1e3b69 Eric Anholt2008-07-30 @819 {
673a394b1e3b69 Eric Anholt2008-07-30 820 struct drm_i915_gem_sw_finish
*args = data;
05394f3975dceb Chris Wilson 2010-11-08 821 struct drm_i915_gem_object *obj;
1d7cfea152cae6 Chris Wilson 2010-10-17 822
03ac0642f67a3a Chris Wilson 2016-07-20 823 obj =
i915_gem_object_lookup(file, args->handle);
c21724cc4d3d5c Chris Wilson 2016-08-05 824 if (!obj)
c21724cc4d3d5c Chris Wilson 2016-08-05 825 return -ENOENT;
673a394b1e3b69 Eric Anholt2008-07-30 826
a03f395ad78f88 Tina Zhang 2017-11-14 827 /*
a03f395ad78f88 Tina Zhang 2017-11-14 828* Proxy objects are barred
from CPU access, so there is no
a03f395ad78f88 Tina Zhang 2017-11-14 829* need to ban sw_finish as it
is a nop.
a03f395ad78f88 Tina Zhang 2017-11-14 830*/
a03f395ad78f88 Tina Zhang 2017-11-14 831
673a394b1e3b69 Eric Anholt2008-07-30 832 /* Pinned buffers may be
scanout, so flush the cache */
5a97bcc69cc02d Chris Wilson 2017-02-22 833
i915_gem_object_flush_if_display(obj);
f0cd518206e1a4 Chris Wilson 2016-10-28 834 i915_gem_object_put(obj);
5a97bcc69cc02d Chris Wilson 2017-02-22 835
5a97bcc69cc02d Chris Wilson 2017-02-22 836 return 0;
673a394b1e3b69 Eric Anholt2008-07-30 837 }
673a394b1e3b69 Eric Anholt2008-07-30 838
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
Re: [PATCH 15/21] dt-bindings: soc: mediatek: add display mutex for MT8365 SoC
On 09/03/2023 15:23, Alexandre Mergnat wrote: Add compatible for the MT8365 SoC. Signed-off-by: Alexandre Mergnat Applied, thanks! --- Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml b/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml index ca0ca549257d..931d66893dff 100644 --- a/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml +++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml @@ -34,6 +34,7 @@ properties: - mediatek,mt8186-mdp3-mutex - mediatek,mt8192-disp-mutex - mediatek,mt8195-disp-mutex + - mediatek,mt8365-disp-mutex reg: maxItems: 1
[PATCH] drm/qxl: remove unused num_relocs variable
clang with W=1 reports
drivers/gpu/drm/qxl/qxl_ioctl.c:149:14: error: variable
'num_relocs' set but not used [-Werror,-Wunused-but-set-variable]
int i, ret, num_relocs;
^
This variable is not used so remove it.
Signed-off-by: Tom Rix
---
drivers/gpu/drm/qxl/qxl_ioctl.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_ioctl.c b/drivers/gpu/drm/qxl/qxl_ioctl.c
index 30f58b21372a..3422206d59d4 100644
--- a/drivers/gpu/drm/qxl/qxl_ioctl.c
+++ b/drivers/gpu/drm/qxl/qxl_ioctl.c
@@ -146,7 +146,7 @@ static int qxl_process_single_command(struct qxl_device
*qdev,
struct qxl_release *release;
struct qxl_bo *cmd_bo;
void *fb_cmd;
- int i, ret, num_relocs;
+ int i, ret;
int unwritten;
switch (cmd->type) {
@@ -201,7 +201,6 @@ static int qxl_process_single_command(struct qxl_device
*qdev,
}
/* fill out reloc info structs */
- num_relocs = 0;
for (i = 0; i < cmd->relocs_num; ++i) {
struct drm_qxl_reloc reloc;
struct drm_qxl_reloc __user *u = u64_to_user_ptr(cmd->relocs);
@@ -231,7 +230,6 @@ static int qxl_process_single_command(struct qxl_device
*qdev,
reloc_info[i].dst_bo = cmd_bo;
reloc_info[i].dst_offset = reloc.dst_offset +
release->release_offset;
}
- num_relocs++;
/* reserve and validate the reloc dst bo */
if (reloc.reloc_type == QXL_RELOC_TYPE_BO || reloc.src_handle) {
--
2.27.0
Re: [PATCH] Revert "drm/sched: Use parent fence instead of finished"
On Fri, Dec 2, 2022 at 9:24 AM Arvind Yadav wrote:
>
> This reverts commit e4dc45b1848bc6bcac31eb1b4ccdd7f6718b3c86.
>
> This is causing instability on Linus' desktop, and Observed System
> hung when running MesaGL benchmark or VK CTS runs.
>
> netconsole got me the following oops:
> [ 1234.778760] BUG: kernel NULL pointer dereference, address:
> 0088
> [ 1234.778782] #PF: supervisor read access in kernel mode
> [ 1234.778787] #PF: error_code(0x) - not-present page
> [ 1234.778791] PGD 0 P4D 0
> [ 1234.778798] Oops: [#1] PREEMPT SMP NOPTI
> [ 1234.778803] CPU: 7 PID: 805 Comm: systemd-journal Not tainted 6.0.0+ #2
> [ 1234.778809] Hardware name: System manufacturer System Product
> Name/PRIME X370-PRO, BIOS 5603 07/28/2020
> [ 1234.778813] RIP: 0010:drm_sched_job_done.isra.0+0xc/0x140 [gpu_sched]
> [ 1234.778828] Code: aa 0f 1d ce e9 57 ff ff ff 48 89 d7 e8 9d 8f 3f
> ce e9 4a ff ff ff 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 54 55 53
> 48 89 fb <48> 8b af 88 00 00 00 f0 ff 8d f0 00 00 00 48 8b 85 80 01 00
> 00 f0
> [ 1234.778834] RSP: :abe680380de0 EFLAGS: 00010087
> [ 1234.778839] RAX: c04e9230 RBX: RCX:
> 0018
> [ 1234.778897] RDX: 0ba278e8977a RSI: 953fb288b460 RDI:
>
> [ 1234.778901] RBP: 953fb288b598 R08: 00e0 R09:
> 953fbd98b808
> [ 1234.778905] R10: R11: abe680380ff8 R12:
> abe680380e00
> [ 1234.778908] R13: 0001 R14: R15:
> 953fbd9ec458
> [ 1234.778912] FS: 7f35e7008580() GS:95428ebc()
> knlGS:
> [ 1234.778916] CS: 0010 DS: ES: CR0: 80050033
> [ 1234.778919] CR2: 0088 CR3: 00010147c000 CR4:
> 003506e0
> [ 1234.778924] Call Trace:
> [ 1234.778981]
> [ 1234.778989] dma_fence_signal_timestamp_locked+0x6a/0xe0
> [ 1234.778999] dma_fence_signal+0x2c/0x50
> [ 1234.779005] amdgpu_fence_process+0xc8/0x140 [amdgpu]
> [ 1234.779234] sdma_v3_0_process_trap_irq+0x70/0x80 [amdgpu]
> [ 1234.779395] amdgpu_irq_dispatch+0xa9/0x1d0 [amdgpu]
> [ 1234.779609] amdgpu_ih_process+0x80/0x100 [amdgpu]
> [ 1234.779783] amdgpu_irq_handler+0x1f/0x60 [amdgpu]
> [ 1234.779940] __handle_irq_event_percpu+0x46/0x190
> [ 1234.779946] handle_irq_event+0x34/0x70
> [ 1234.779949] handle_edge_irq+0x9f/0x240
> [ 1234.779954] __common_interrupt+0x66/0x100
> [ 1234.779960] common_interrupt+0xa0/0xc0
> [ 1234.779965]
> [ 1234.779968]
> [ 1234.779971] asm_common_interrupt+0x22/0x40
> [ 1234.779976] RIP: 0010:finish_mkwrite_fault+0x22/0x110
> [ 1234.779981] Code: 1f 84 00 00 00 00 00 90 0f 1f 44 00 00 41 55 41
> 54 55 48 89 fd 53 48 8b 07 f6 40 50 08 0f 84 eb 00 00 00 48 8b 45 30
> 48 8b 18 <48> 89 df e8 66 bd ff ff 48 85 c0 74 0d 48 89 c2 83 e2 01 48
> 83 ea
> [ 1234.779985] RSP: :abe680bcfd78 EFLAGS: 0202
>
> Revert it for now and figure it out later.
Just fwiw, the issue here is a race against sched_main observing that
the hw fence is signaled and doing job_cleanup and the driver retiring
the job. I don't think there is a sane way to use the parent fence
without having this race condition so the "figure it out later" is
"don't do that" ;-)
BR,
-R
> Signed-off-by: Arvind Yadav
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> b/drivers/gpu/drm/scheduler/sched_main.c
> index 820c0c5544e1..ea7bfa99d6c9 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -790,7 +790,7 @@ drm_sched_get_cleanup_job(struct drm_gpu_scheduler *sched)
> job = list_first_entry_or_null(>pending_list,
>struct drm_sched_job, list);
>
> - if (job && dma_fence_is_signaled(job->s_fence->parent)) {
> + if (job && dma_fence_is_signaled(>s_fence->finished)) {
> /* remove job from pending_list */
> list_del_init(>list);
>
> @@ -802,7 +802,7 @@ drm_sched_get_cleanup_job(struct drm_gpu_scheduler *sched)
>
> if (next) {
> next->s_fence->scheduled.timestamp =
> - job->s_fence->parent->timestamp;
> + job->s_fence->finished.timestamp;
> /* start TO timer for next job */
> drm_sched_start_timeout(sched);
> }
> --
> 2.25.1
>
[PATCH] drm/amd/pm: remove unused num_of_active_display variable
clang with W=1 reports
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/amdgpu_smu.c:1700:6: error: variable
'num_of_active_display' set but not used [-Werror,-Wunused-but-set-variable]
int num_of_active_display = 0;
^
This variable is not used so remove it.
Signed-off-by: Tom Rix
---
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
index b5d64749990e..f93f7a9ed631 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
@@ -1696,8 +1696,6 @@ static int smu_display_configuration_change(void *handle,
const struct
amd_pp_display_configuration *display_config)
{
struct smu_context *smu = handle;
- int index = 0;
- int num_of_active_display = 0;
if (!smu->pm_enabled || !smu->adev->pm.dpm_enabled)
return -EOPNOTSUPP;
@@ -1708,11 +1706,6 @@ static int smu_display_configuration_change(void *handle,
smu_set_min_dcef_deep_sleep(smu,
display_config->min_dcef_deep_sleep_set_clk
/ 100);
- for (index = 0; index < display_config->num_path_including_non_display;
index++) {
- if (display_config->displays[index].controller_id != 0)
- num_of_active_display++;
- }
-
return 0;
}
--
2.27.0
[PULL] drm-misc-next
Hi Dave, Daniel, Small update. Slow week. Felt like sending a pull request regardless. drm-misc-next-2023-03-31: drm-misc-next for v6.4-rc1: Cross-subsystem Changes: - DT bindings update for adding Mali MT81xx devices. - Assorted DT binding updates. Core Changes: - Documentation update to scheduler. Driver Changes: - Add support for the same mali devices. - Add support for speed binning to panfrost. - Add B133UAN01.0 eDP panel. - Assorted small fixes to bridge/ps8640, bridge/it6505, panel/magnachip. - Use of_property_read_bool in ps8622 and ofdrm. The following changes since commit 82bbec189ab34873688484cd14189a5392946fbb: Merge v6.3-rc4 into drm-next (2023-03-29 16:00:23 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2023-03-31 for you to fetch changes up to 7d690f936e9bc9fbd6394fb3d4ad181af03ee393: drm/panfrost: Add basic support for speed binning (2023-03-31 11:44:11 +0200) drm-misc-next for v6.4-rc1: Cross-subsystem Changes: - DT bindings update for adding Mali MT81xx devices. - Assorted DT binding updates. Core Changes: - Documentation update to scheduler. Driver Changes: - Add support for the same mali devices. - Add support for speed binning to panfrost. - Add B133UAN01.0 eDP panel. - Assorted small fixes to bridge/ps8640, bridge/it6505, panel/magnachip. - Use of_property_read_bool in ps8622 and ofdrm. Alyssa Rosenzweig (3): drm/panfrost: Increase MAX_PM_DOMAINS to 5 drm/panfrost: Add the MT8192 GPU ID drm/panfrost: Add mediatek,mt8192-mali compatible AngeloGioacchino Del Regno (11): dt-bindings: gpu: mali-bifrost: Split out MediaTek power-domains variation dt-bindings: gpu: mali-bifrost: Set power-domains maxItems to 5 dt-bindings: gpu: mali-bifrost: Fix power-domain-names validation dt-bindings: gpu: mali-bifrost: Add sub-schema for MT8192's power domains dt-bindings: gpu: mali-bifrost: Add new MT8183 compatible dt-bindings: gpu: mali-bifrost: Add support for MediaTek MT8186 dt-bindings: gpu: mali-bifrost: Add compatible for MT8195 SoC drm/panfrost: Add new compatible for Mali on the MT8183 SoC drm/panfrost: Add support for Mali on the MT8186 SoC dt-bindings: gpu: mali-bifrost: Document nvmem for speedbin support drm/panfrost: Add basic support for speed binning Bjorn Andersson (1): drm/panel-edp: Add B133UAN01.0 edp panel entry Caio Novais (1): drm/scheduler: Fix variable name in function description Dan Carpenter (1): drm/panel: magnachip: Prevent error pointer dereference in probe Fabio Estevam (1): dt-bindings: display: seiko,43wvf1g: Change the maintainer's contact Hsin-Yi Wang (1): drm/bridge: it6505: Add range and selector_reg Krzysztof Kozlowski (6): dt-bindings: display: panel-simple: merge Innolux p120zdg-bf1 dt-bindings: display: novatek,nt36672a: correct VDDIO supply dt-bindings: display: panel-simple-dsi: allow vddio variant dt-bindings: display: panel-simple-dsi: document port dt-bindings: display: visionox,rm69299: document reg dt-bindings: display: boe,tv101wum-nl6: document rotation Maarten Lankhorst (1): Merge remote-tracking branch 'drm/drm-next' into drm-misc-next Pin-yen Lin (3): drm/bridge: ps8640: Skip redundant bridge enable drm/bridge: ps8640: Add a cache for EDID drm/bridge: ps8640: Return NULL immediately when EDID read fail Rob Herring (3): dt-bindings: display: Drop unneeded quotes drm: Use of_property_present() for testing DT property presence drm: Use of_property_read_bool() for boolean properties .../bindings/auxdisplay/holtek,ht16k33.yaml| 2 +- .../bindings/display/amlogic,meson-dw-hdmi.yaml| 4 +- .../bindings/display/amlogic,meson-vpu.yaml| 4 +- .../bindings/display/bridge/analogix,anx7625.yaml | 4 +- .../bindings/display/bridge/cdns,mhdp8546.yaml | 4 +- .../bindings/display/bridge/nxp,ptn3460.yaml | 2 +- .../bindings/display/bridge/toshiba,tc358767.yaml | 2 +- .../devicetree/bindings/display/dp-aux-bus.yaml| 2 +- .../bindings/display/imx/nxp,imx8mq-dcss.yaml | 4 +- .../bindings/display/mediatek/mediatek,hdmi.yaml | 2 +- .../bindings/display/msm/dsi-controller-main.yaml | 8 +- .../bindings/display/msm/dsi-phy-10nm.yaml | 2 +- .../devicetree/bindings/display/msm/gmu.yaml | 4 +- .../devicetree/bindings/display/msm/gpu.yaml | 4 +- .../devicetree/bindings/display/msm/mdp4.yaml | 4 +- .../bindings/display/panel/boe,tv101wum-nl6.yaml | 1 + .../display/panel/innolux,p120zdg-bf1.yaml | 43 --- .../bindings/display/panel/novatek,nt36672a.yaml | 6 +- .../bindings/display/panel/panel-simple-dsi.yaml | 24 +-
Re: [PATCH 0/5] drm: shmobile: Fixes and enhancements
Hi Reviewed-by: Thomas Zimmermann for the whole patchset. Best regards Thomas Am 31.03.23 um 16:48 schrieb Geert Uytterhoeven: Hi all, Currently, there are two drivers for the LCD controller on Renesas SuperH-based and ARM-based SH-Mobile and R-Mobile SoCs: 1. sh_mobile_lcdcfb, using the fbdev framework, 2. shmob_drm, using the DRM framework. However, only the former driver can be used, as all platform support integrates the former. None of these drivers support DT-based systems. This patch series is a first step to enable the SH-Mobile DRM driver for Renesas ARM-based SH-Mobile and R-Mobile SoCs. The next step planned is to add DT support. This has been tested on the R-Mobile A1-based Atmark Techno Armadillo-800-EVA development board, using a temporary platform-enablement patch[1]. Thanks for your comments! [1] https://lore.kernel.org/r/c03d4edbd650836bf6a96504df82338ec6d800ff.1680272980.git.geert+rene...@glider.be Geert Uytterhoeven (5): drm: shmobile: Use %p4cc to print fourcc codes drm: shmobile: Add support for DRM_FORMAT_XRGB drm: shmobile: Switch to drm_crtc_init_with_planes() drm: shmobile: Add missing call to drm_fbdev_generic_setup() drm: shmobile: Make DRM_SHMOBILE visible on Renesas SoC platforms drivers/gpu/drm/shmobile/Kconfig | 2 +- drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 35 +++--- drivers/gpu/drm/shmobile/shmob_drm_drv.c | 3 ++ drivers/gpu/drm/shmobile/shmob_drm_kms.c | 9 -- drivers/gpu/drm/shmobile/shmob_drm_plane.c | 5 5 files changed, 47 insertions(+), 7 deletions(-) -- 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 v2 9/9] drm/i915: Use kmap_local_page() in gem/i915_gem_execbuffer.c
On venerdì 31 marzo 2023 13:30:20 CEST Tvrtko Ursulin wrote: > On 31/03/2023 05:18, Ira Weiny wrote: > > Zhao Liu wrote: > >> From: Zhao Liu > >> > >> The use of kmap_atomic() is being deprecated in favor of > >> kmap_local_page()[1], and this patch converts the calls from > >> kmap_atomic() to kmap_local_page(). > >> > >> The main difference between atomic and local mappings is that local > >> mappings doesn't disable page faults or preemption (the preemption is > >> disabled for !PREEMPT_RT case, otherwise it only disables migration). > >> > >> With kmap_local_page(), we can avoid the often unwanted side effect of > >> unnecessary page faults and preemption disables. > >> > >> In i915_gem_execbuffer.c, eb->reloc_cache.vaddr is mapped by > >> kmap_atomic() in eb_relocate_entry(), and is unmapped by > >> kunmap_atomic() in reloc_cache_reset(). > > > > First off thanks for the series and sticking with this. That said this > > patch kind of threw me for a loop because tracing the map/unmap calls did > > not make sense to me. See below. > > > >> And this mapping/unmapping occurs in two places: one is in > >> eb_relocate_vma(), and another is in eb_relocate_vma_slow(). > >> > >> The function eb_relocate_vma() or eb_relocate_vma_slow() doesn't > >> need to disable pagefaults and preemption during the above mapping/ > >> unmapping. > >> > >> So it can simply use kmap_local_page() / kunmap_local() that can > >> instead do the mapping / unmapping regardless of the context. > >> > >> Convert the calls of kmap_atomic() / kunmap_atomic() to > >> kmap_local_page() / kunmap_local(). > >> > >> [1]: > >> https://lore.kernel.org/all/20220813220034.806698-1-ira.we...@intel.com > >> > >> v2: No code change since v1. Added description of the motivation of > >> > >> using kmap_local_page() and "Suggested-by" tag of Fabio. > >> > >> Suggested-by: Ira Weiny > >> Suggested-by: Fabio M. De Francesco > >> Signed-off-by: Zhao Liu > >> --- > >> > >> Suggested by credits: > >>Ira: Referred to his task document, review comments. > >>Fabio: Referred to his boiler plate commit message and his description > >> > >> about why kmap_local_page() should be preferred. > >> > >> --- > >> > >> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 10 +- > >> 1 file changed, 5 insertions(+), 5 deletions(-) > >> [snip] > However I am unsure if disabling pagefaulting is needed or not. Thomas, > Matt, being the last to touch this area, perhaps you could have a look? > Because I notice we have a fallback iomap path which still uses > io_mapping_map_atomic_wc. So if kmap_atomic to kmap_local conversion is > safe, does the iomap side also needs converting to > io_mapping_map_local_wc? Or they have separate requirements? AFAIK, the requirements for io_mapping_map_local_wc() are the same as for kmap_local_page(): the kernel virtual address is _only_ valid in the caller context, and map/unmap nesting must be done in stack-based ordering (LIFO). I think a follow up patch could safely switch to io_mapping_map_local_wc() / io_mapping_unmap_local_wc since the address is local to context. However, not being an expert, reading your note now I suspect that I'm missing something. Can I ask why you think that page-faults disabling might be necessary? Thanks, Fabio > Regards, > > Tvrtko
Re: [PATCH 07/19] drm/i915/gem/i915_gem_create: Provide the function names for proper kerneldoc headers
Hi Lee,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-misc/drm-misc-next next-20230331]
[cannot apply to drm-intel/for-linux-next-fixes lee-leds/for-leds-next
linus/master v6.3-rc4]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Lee-Jones/drm-i915-i915_scatterlist-Fix-kerneldoc-formatting-issue-missing/20230331-173046
base: git://anongit.freedesktop.org/drm-intel for-linux-next
patch link:
https://lore.kernel.org/r/20230331092607.700644-8-lee%40kernel.org
patch subject: [PATCH 07/19] drm/i915/gem/i915_gem_create: Provide the function
names for proper kerneldoc headers
config: i386-defconfig
(https://download.01.org/0day-ci/archive/20230331/202303312304.lmo1kstb-...@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-8) 11.3.0
reproduce (this is a W=1 build):
#
https://github.com/intel-lab-lkp/linux/commit/7c87f97c7f11c1a2b3931d46ae1382c5ee0c14f7
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Lee-Jones/drm-i915-i915_scatterlist-Fix-kerneldoc-formatting-issue-missing/20230331-173046
git checkout 7c87f97c7f11c1a2b3931d46ae1382c5ee0c14f7
# save the config file
mkdir build_dir && cp config build_dir/.config
make W=1 O=build_dir ARCH=i386 olddefconfig
make W=1 O=build_dir ARCH=i386 SHELL=/bin/bash
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
| Link:
https://lore.kernel.org/oe-kbuild-all/202303312304.lmo1kstb-...@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/i915/gem/i915_gem_create.c:411: warning: expecting prototype
>> for i915_gem_create_ext_ioct(). Prototype was for
>> i915_gem_create_ext_ioctl() instead
vim +411 drivers/gpu/drm/i915/gem/i915_gem_create.c
ebcb40298947bdb Matthew Auld 2021-04-29 401
ebcb40298947bdb Matthew Auld 2021-04-29 402 /**
7c87f97c7f11c1a Lee Jones2023-03-31 403 * i915_gem_create_ext_ioct -
Creates a new mm object and returns a handle to it.
ebcb40298947bdb Matthew Auld 2021-04-29 404 * @dev: drm device pointer
ebcb40298947bdb Matthew Auld 2021-04-29 405 * @data: ioctl data blob
ebcb40298947bdb Matthew Auld 2021-04-29 406 * @file: drm file pointer
ebcb40298947bdb Matthew Auld 2021-04-29 407 */
ebcb40298947bdb Matthew Auld 2021-04-29 408 int
ebcb40298947bdb Matthew Auld 2021-04-29 409 i915_gem_create_ext_ioctl(struct
drm_device *dev, void *data,
ebcb40298947bdb Matthew Auld 2021-04-29 410 struct
drm_file *file)
ebcb40298947bdb Matthew Auld 2021-04-29 @411 {
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
Re: [PING] drm/bochs: replace ioremap with devm_ioremap to avoid immo leak
Hi,
I'm noticed you patch, interesting!
On 2023/3/29 13:26, Gencen Gan wrote:
From: Gan Gecen
Smatch reports:
drivers/gpu/drm/tiny/bochs.c:290 bochs_hw_init()
warn: 'bochs->mmio' from ioremap() not released on
lines: 246,250,254.
In the function bochs_load() that calls bochs_hw_init()
only, if bochs_hw_init(dev) returns -ENODEV(-19), it
will jumps to err_free_dev instead of err_hw_fini, so
bochs->immo won't be freed.
`mmio`, not `immo`, you should also fix the typos in you patch's
commit title.
We would prefer to replace ioremap with devm_ioremap
to avoid adding lengthy error handling. The function
`devm_ioremap` will automatically release the allocated
resources after use.
Yet, I notice that there is iounmap in bochs_hw_fini() function, does
double free will happen?
static void bochs_hw_fini(struct drm_device *dev)
{
struct bochs_device *bochs = dev->dev_private;
// ...
if (bochs->mmio)
iounmap(bochs->mmio);
// ...
}
I still advise you free it by adding error handling code, free it manually.
Because still there other ioremap() function in the driver.
But you can choose to heard other reviewer's voice, I can only help to
review.
Signed-off-by: Gan Gecen
---
drivers/gpu/drm/tiny/bochs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tiny/bochs.c b/drivers/gpu/drm/tiny/bochs.c
index 024346054c70..0d7e119a732f 100644
--- a/drivers/gpu/drm/tiny/bochs.c
+++ b/drivers/gpu/drm/tiny/bochs.c
@@ -223,7 +223,7 @@ static int bochs_hw_init(struct drm_device *dev)
}
ioaddr = pci_resource_start(pdev, 2);
iosize = pci_resource_len(pdev, 2);
- bochs->mmio = ioremap(ioaddr, iosize);
+ bochs->mmio = devm_ioremap(>dev, ioaddr, iosize);
if (bochs->mmio == NULL) {
DRM_ERROR("Cannot map mmio region\n");
return -ENOMEM;
Re: [PATCH] drm/amd/display: remove unused average_render_time_in_us and i variables
On 3/30/23 20:10, Tom Rix wrote:
clang with W=1 reports
drivers/gpu/drm/amd/amdgpu/../display/modules/freesync/freesync.c:1132:15:
error: variable
'average_render_time_in_us' set but not used
[-Werror,-Wunused-but-set-variable]
unsigned int average_render_time_in_us = 0;
^
This variable is not used so remove it, which caused i to be unused so remove
that as well.
Signed-off-by: Tom Rix
Applied, thanks!
---
.../drm/amd/display/modules/freesync/freesync.c| 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
index 315da61ee897..5c41a4751db4 100644
--- a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
+++ b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
@@ -1129,7 +1129,6 @@ void mod_freesync_handle_preflip(struct mod_freesync
*mod_freesync,
{
struct core_freesync *core_freesync = NULL;
unsigned int last_render_time_in_us = 0;
- unsigned int average_render_time_in_us = 0;
if (mod_freesync == NULL)
return;
@@ -1138,7 +1137,6 @@ void mod_freesync_handle_preflip(struct mod_freesync
*mod_freesync,
if (in_out_vrr->supported &&
in_out_vrr->state == VRR_STATE_ACTIVE_VARIABLE) {
- unsigned int i = 0;
unsigned int oldest_index = plane->time.index + 1;
if (oldest_index >= DC_PLANE_UPDATE_TIMES_MAX)
@@ -1147,18 +1145,6 @@ void mod_freesync_handle_preflip(struct mod_freesync
*mod_freesync,
last_render_time_in_us = curr_time_stamp_in_us -
plane->time.prev_update_time_in_us;
- /* Sum off all entries except oldest one */
- for (i = 0; i < DC_PLANE_UPDATE_TIMES_MAX; i++) {
- average_render_time_in_us +=
- plane->time.time_elapsed_in_us[i];
- }
- average_render_time_in_us -=
- plane->time.time_elapsed_in_us[oldest_index];
-
- /* Add render time for current flip */
- average_render_time_in_us += last_render_time_in_us;
- average_render_time_in_us /= DC_PLANE_UPDATE_TIMES_MAX;
-
if (in_out_vrr->btr.btr_enabled) {
apply_below_the_range(core_freesync,
stream,
--
Hamza
Re: [PATCH v1 3/3] msm: skip the atomic commit of self refresh while PSR running
On Fri, 31 Mar 2023 at 16:59, Vinod Polimera wrote: > > In certain CPU stress conditions, there can be a delay in scheduling commit > work and it was observed that PSR commit from a different work queue was > scheduled. Avoid these commits as display is already in PSR mode. > > Signed-off-by: Vinod Polimera > --- > drivers/gpu/drm/msm/msm_atomic.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/msm/msm_atomic.c > b/drivers/gpu/drm/msm/msm_atomic.c > index 645fe53..f8141bb 100644 > --- a/drivers/gpu/drm/msm/msm_atomic.c > +++ b/drivers/gpu/drm/msm/msm_atomic.c > @@ -192,6 +192,9 @@ int msm_atomic_check(struct drm_device *dev, struct > drm_atomic_state *state) > new_crtc_state->mode_changed = true; > state->allow_modeset = true; > } > + > + if (old_crtc_state->self_refresh_active && > new_crtc_state->self_refresh_active) > + return -EINVAL; EINVAL here means that atomic_check will fail if both old and new states are in SR mode. For example, there might be a mode set for another CRTC (while keeping this one in SR mode). I don't think this is correct. We should skip/shortcut the commit, that's true. But I doubt that returning an error here is a proper way to do this. Please correct me if I'm wrong. > } > > return drm_atomic_helper_check(dev, state); > -- > 2.7.4 > -- With best wishes Dmitry
Re: [PATCH 01/21] dt-bindings: display: mediatek: aal: add binding for MT8365 SoC
Hi Chun-Kuang Hu, On 13/03/2023 16:02, Chun-Kuang Hu wrote: Hi, Alexandre: Alexandre Mergnat 於 2023年3月9日 週四 下午10:23寫道： Display Adaptive Ambient Light for MT8365 is compatible with another SoC. Then, add MT8365 binding along with MT8183 SoC. Reviewed-by: Chun-Kuang Hu I'm a bit puzzled that you give your reviewed by while I would have expected that you will take the display binding patches. Will you take these or do you want someone else to take them? Regards, Matthias Signed-off-by: Alexandre Mergnat --- Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml index d4d585485e7b..d47bc72f09c0 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml @@ -33,6 +33,7 @@ properties: - mediatek,mt8186-disp-aal - mediatek,mt8192-disp-aal - mediatek,mt8195-disp-aal + - mediatek,mt8365-disp-aal - const: mediatek,mt8183-disp-aal reg: -- b4 0.10.1
[PATCH 1/5] drm: shmobile: Use %p4cc to print fourcc codes
Replace the printing of hexadecimal fourcc format codes by
pretty-printed format names, using the "%p4cc" format specifier.
Signed-off-by: Geert Uytterhoeven
---
drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 4 ++--
drivers/gpu/drm/shmobile/shmob_drm_kms.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
index d354ab3077cecf94..713a7612244c647a 100644
--- a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
+++ b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
@@ -355,8 +355,8 @@ static int shmob_drm_crtc_mode_set(struct drm_crtc *crtc,
format = shmob_drm_format_info(crtc->primary->fb->format->format);
if (format == NULL) {
- dev_dbg(sdev->dev, "mode_set: unsupported format %08x\n",
- crtc->primary->fb->format->format);
+ dev_dbg(sdev->dev, "mode_set: unsupported format %p4cc\n",
+ >primary->fb->format->format);
return -EINVAL;
}
diff --git a/drivers/gpu/drm/shmobile/shmob_drm_kms.c
b/drivers/gpu/drm/shmobile/shmob_drm_kms.c
index 60a2c8d8a0d947d2..3c5fe3bc183c7c13 100644
--- a/drivers/gpu/drm/shmobile/shmob_drm_kms.c
+++ b/drivers/gpu/drm/shmobile/shmob_drm_kms.c
@@ -96,8 +96,8 @@ shmob_drm_fb_create(struct drm_device *dev, struct drm_file
*file_priv,
format = shmob_drm_format_info(mode_cmd->pixel_format);
if (format == NULL) {
- dev_dbg(dev->dev, "unsupported pixel format %08x\n",
- mode_cmd->pixel_format);
+ dev_dbg(dev->dev, "unsupported pixel format %p4cc\n",
+ _cmd->pixel_format);
return ERR_PTR(-EINVAL);
}
--
2.34.1
[PATCH 4/5] drm: shmobile: Add missing call to drm_fbdev_generic_setup()
Set up generic fbdev emulation, to enable support for the Linux console. Use 16 as the preferred depth, as that is a good compromise between colorfulness and resource utilization, and the default of the fbdev driver. Suggested-by: Laurent Pinchart Signed-off-by: Geert Uytterhoeven --- drivers/gpu/drm/shmobile/shmob_drm_drv.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c b/drivers/gpu/drm/shmobile/shmob_drm_drv.c index faacfee24763b1d4..30493ce874192e3e 100644 --- a/drivers/gpu/drm/shmobile/shmob_drm_drv.c +++ b/drivers/gpu/drm/shmobile/shmob_drm_drv.c @@ -16,6 +16,7 @@ #include #include +#include #include #include #include @@ -271,6 +272,8 @@ static int shmob_drm_probe(struct platform_device *pdev) if (ret < 0) goto err_irq_uninstall; + drm_fbdev_generic_setup(ddev, 16); + return 0; err_irq_uninstall: -- 2.34.1
[PATCH 5/5] drm: shmobile: Make DRM_SHMOBILE visible on Renesas SoC platforms
The LCD Controller supported by the drm-shmob driver is not only present on SuperH SH-Mobile SoCs, but also on Renesas ARM SH/R-Mobile SoCs. Make its option visible, so the user can enable support for it. Signed-off-by: Geert Uytterhoeven --- drivers/gpu/drm/shmobile/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/shmobile/Kconfig b/drivers/gpu/drm/shmobile/Kconfig index 4ec5dc74a6b0b880..719d4e7a5cd75aad 100644 --- a/drivers/gpu/drm/shmobile/Kconfig +++ b/drivers/gpu/drm/shmobile/Kconfig @@ -2,7 +2,7 @@ config DRM_SHMOBILE tristate "DRM Support for SH Mobile" depends on DRM && ARM - depends on ARCH_SHMOBILE || COMPILE_TEST + depends on ARCH_RENESAS || ARCH_SHMOBILE || COMPILE_TEST select BACKLIGHT_CLASS_DEVICE select DRM_KMS_HELPER select DRM_GEM_DMA_HELPER -- 2.34.1
[PATCH 2/5] drm: shmobile: Add support for DRM_FORMAT_XRGB8888
DRM_FORMAT_XRGB aka XR24 is the modus francus of DRM, and should be
supported by all drivers.
The handling for DRM_FORMAT_XRGB is similar to DRM_FORMAT_ARGB,
just ignore the alpha channel.
Signed-off-by: Geert Uytterhoeven
---
drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 1 +
drivers/gpu/drm/shmobile/shmob_drm_kms.c | 5 +
drivers/gpu/drm/shmobile/shmob_drm_plane.c | 5 +
3 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
index 713a7612244c647a..08dc1428aa16caf0 100644
--- a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
+++ b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
@@ -232,6 +232,7 @@ static void shmob_drm_crtc_start(struct shmob_drm_crtc
*scrtc)
value = LDDDSR_LS | LDDDSR_WS | LDDDSR_BS;
break;
case DRM_FORMAT_ARGB:
+ case DRM_FORMAT_XRGB:
default:
value = LDDDSR_LS;
break;
diff --git a/drivers/gpu/drm/shmobile/shmob_drm_kms.c
b/drivers/gpu/drm/shmobile/shmob_drm_kms.c
index 3c5fe3bc183c7c13..99381cc0abf3ae1f 100644
--- a/drivers/gpu/drm/shmobile/shmob_drm_kms.c
+++ b/drivers/gpu/drm/shmobile/shmob_drm_kms.c
@@ -39,6 +39,11 @@ static const struct shmob_drm_format_info
shmob_drm_format_infos[] = {
.bpp = 32,
.yuv = false,
.lddfr = LDDFR_PKF_ARGB32,
+ }, {
+ .fourcc = DRM_FORMAT_XRGB,
+ .bpp = 32,
+ .yuv = false,
+ .lddfr = LDDFR_PKF_ARGB32,
}, {
.fourcc = DRM_FORMAT_NV12,
.bpp = 12,
diff --git a/drivers/gpu/drm/shmobile/shmob_drm_plane.c
b/drivers/gpu/drm/shmobile/shmob_drm_plane.c
index 604ae23825daaafd..850986cee848226a 100644
--- a/drivers/gpu/drm/shmobile/shmob_drm_plane.c
+++ b/drivers/gpu/drm/shmobile/shmob_drm_plane.c
@@ -80,6 +80,7 @@ static void __shmob_drm_plane_setup(struct shmob_drm_plane
*splane,
format |= LDBBSIFR_SWPL | LDBBSIFR_SWPW | LDBBSIFR_SWPB;
break;
case DRM_FORMAT_ARGB:
+ case DRM_FORMAT_XRGB:
default:
format |= LDBBSIFR_SWPL;
break;
@@ -95,6 +96,9 @@ static void __shmob_drm_plane_setup(struct shmob_drm_plane
*splane,
case DRM_FORMAT_ARGB:
format |= LDBBSIFR_AL_PK | LDBBSIFR_RY | LDDFR_PKF_ARGB32;
break;
+ case DRM_FORMAT_XRGB:
+ format |= LDBBSIFR_AL_1 | LDBBSIFR_RY | LDDFR_PKF_ARGB32;
+ break;
case DRM_FORMAT_NV12:
case DRM_FORMAT_NV21:
format |= LDBBSIFR_AL_1 | LDBBSIFR_CHRR_420;
@@ -231,6 +235,7 @@ static const uint32_t formats[] = {
DRM_FORMAT_RGB565,
DRM_FORMAT_RGB888,
DRM_FORMAT_ARGB,
+ DRM_FORMAT_XRGB,
DRM_FORMAT_NV12,
DRM_FORMAT_NV21,
DRM_FORMAT_NV16,
--
2.34.1
[PATCH 3/5] drm: shmobile: Switch to drm_crtc_init_with_planes()
The SH-Mobile DRM driver uses the legacy drm_crtc_init(), which
advertizes only the formats in safe_modeset_formats[] (XR24 and AR24) as
being supported.
Switch to drm_crtc_init_with_planes(), and advertize all supported
(A)RGB modes, so we can use RGB565 as the default mode for the console.
Signed-off-by: Geert Uytterhoeven
---
drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 30 +--
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
index 08dc1428aa16caf0..11dd2bc803e7cb62 100644
--- a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
+++ b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -478,16 +479,41 @@ static const struct drm_crtc_funcs crtc_funcs = {
.disable_vblank = shmob_drm_disable_vblank,
};
+static const uint32_t modeset_formats[] = {
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_RGB888,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_XRGB,
+};
+
+static const struct drm_plane_funcs primary_plane_funcs = {
+ DRM_PLANE_NON_ATOMIC_FUNCS,
+};
+
int shmob_drm_crtc_create(struct shmob_drm_device *sdev)
{
struct drm_crtc *crtc = >crtc.crtc;
+ struct drm_plane *primary;
int ret;
sdev->crtc.dpms = DRM_MODE_DPMS_OFF;
- ret = drm_crtc_init(sdev->ddev, crtc, _funcs);
- if (ret < 0)
+ primary = __drm_universal_plane_alloc(sdev->ddev, sizeof(*primary), 0,
+ 0, _plane_funcs,
+ modeset_formats,
+ ARRAY_SIZE(modeset_formats),
+ NULL, DRM_PLANE_TYPE_PRIMARY,
+ NULL);
+ if (IS_ERR(primary))
+ return PTR_ERR(primary);
+
+ ret = drm_crtc_init_with_planes(sdev->ddev, crtc, primary, NULL,
+ _funcs, NULL);
+ if (ret < 0) {
+ drm_plane_cleanup(primary);
+ kfree(primary);
return ret;
+ }
drm_crtc_helper_add(crtc, _helper_funcs);
--
2.34.1
[PATCH 0/5] drm: shmobile: Fixes and enhancements
Hi all,
Currently, there are two drivers for the LCD controller on Renesas
SuperH-based and ARM-based SH-Mobile and R-Mobile SoCs:
1. sh_mobile_lcdcfb, using the fbdev framework,
2. shmob_drm, using the DRM framework.
However, only the former driver can be used, as all platform support
integrates the former. None of these drivers support DT-based systems.
This patch series is a first step to enable the SH-Mobile DRM driver for
Renesas ARM-based SH-Mobile and R-Mobile SoCs. The next step planned is
to add DT support.
This has been tested on the R-Mobile A1-based Atmark Techno
Armadillo-800-EVA development board, using a temporary
platform-enablement patch[1].
Thanks for your comments!
[1]
https://lore.kernel.org/r/c03d4edbd650836bf6a96504df82338ec6d800ff.1680272980.git.geert+rene...@glider.be
Geert Uytterhoeven (5):
drm: shmobile: Use %p4cc to print fourcc codes
drm: shmobile: Add support for DRM_FORMAT_XRGB
drm: shmobile: Switch to drm_crtc_init_with_planes()
drm: shmobile: Add missing call to drm_fbdev_generic_setup()
drm: shmobile: Make DRM_SHMOBILE visible on Renesas SoC platforms
drivers/gpu/drm/shmobile/Kconfig | 2 +-
drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 35 +++---
drivers/gpu/drm/shmobile/shmob_drm_drv.c | 3 ++
drivers/gpu/drm/shmobile/shmob_drm_kms.c | 9 --
drivers/gpu/drm/shmobile/shmob_drm_plane.c | 5
5 files changed, 47 insertions(+), 7 deletions(-)
--
2.34.1
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 v2] drm/i915/gt: Hold a wakeref for the active VM
On 31/03/2023 15:16, Andrzej Hajda wrote:
From: Chris Wilson
There may be a disconnect between the GT used by the engine and the GT
used for the VM, requiring us to hold a wakeref on both while the GPU is
active with this request.
v2: added explanation to __queue_and_release_pm
Signed-off-by: Chris Wilson
[ahajda: removed not-yet-upstremed wakeref tracking bits]
Signed-off-by: Andrzej Hajda
---
Changes in v2:
- Link to v1:
https://lore.kernel.org/r/20230330-hold_wakeref_for_active_vm-v1-1-baca71269...@intel.com
---
drivers/gpu/drm/i915/gt/intel_context.h | 15 +++
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 9 +
2 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index 0a8d553da3f439..48f888c3da083b 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -14,6 +14,7 @@
#include "i915_drv.h"
#include "intel_context_types.h"
#include "intel_engine_types.h"
+#include "intel_gt_pm.h"
#include "intel_ring_types.h"
#include "intel_timeline_types.h"
#include "i915_trace.h"
@@ -207,8 +208,11 @@ void intel_context_exit_engine(struct intel_context *ce);
static inline void intel_context_enter(struct intel_context *ce)
{
lockdep_assert_held(>timeline->mutex);
- if (!ce->active_count++)
- ce->ops->enter(ce);
+ if (ce->active_count++)
+ return;
+
+ ce->ops->enter(ce);
+ intel_gt_pm_get(ce->vm->gt);
}
static inline void intel_context_mark_active(struct intel_context *ce)
@@ -222,8 +226,11 @@ static inline void intel_context_exit(struct intel_context
*ce)
{
lockdep_assert_held(>timeline->mutex);
GEM_BUG_ON(!ce->active_count);
- if (!--ce->active_count)
- ce->ops->exit(ce);
+ if (--ce->active_count)
+ return;
+
+ intel_gt_pm_put_async(ce->vm->gt);
+ ce->ops->exit(ce);
}
static inline struct intel_context *intel_context_get(struct intel_context *ce)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index e971b153fda976..ee531a5c142c77 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -114,6 +114,15 @@ __queue_and_release_pm(struct i915_request *rq,
ENGINE_TRACE(engine, "parking\n");
+ /*
+* Open coded one half of intel_context_enter, which we have to omit
+* here (see the large comment below) and because the other part must
+* not be called due constructing directly with __i915_request_create
+* which increments active count via intel_context_mark_active.
+*/
+ GEM_BUG_ON(rq->context->active_count != 1);
+ __intel_gt_pm_get(engine->gt);
+
/*
* We have to serialise all potential retirement paths with our
* submission, as we don't want to underflow either the
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
Re: [PATCH v1 2/3] msm/disp/dpu: allow atomic_check in PSR usecase
On Fri, 31 Mar 2023 at 16:59, Vinod Polimera wrote: > > Certain flags like dirty_fb will be updated into the plane state > during crtc atomic_check. Allow those updates during PSR commit. > > Reported-by: Bjorn Andersson > Link: https://lore.kernel.org/all/20230326162723.3lo6pnsfdwzsvbhj@ripper/ > Signed-off-by: Vinod Polimera > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v1 1/3] drm/msm/dpu: set dirty_fb flag while in self refresh mode
On Fri, 31 Mar 2023 at 16:59, Vinod Polimera wrote:
>
> While in virtual terminal mode with PSR enabled, there will be
> no atomic commits triggered without dirty_fb being set. This
> will create a notion of no screen update. Allow atomic commit
> when dirty_fb ioctl is issued, so that it can trigger a PSR exit
> and shows update on the screen.
Will this impact non-VT workloads? If I remember correctly, we added
dirty_fb handling to prevent the framework from limiting the page
flips to vblank events (in DSI video mode).
>
> Reported-by: Bjorn Andersson
> Link: https://lore.kernel.org/all/20230326162723.3lo6pnsfdwzsvbhj@ripper/
> Signed-off-by: Vinod Polimera
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index ab636da..96f645e 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -1158,6 +1158,9 @@ static bool dpu_crtc_needs_dirtyfb(struct
> drm_crtc_state *cstate)
> struct drm_crtc *crtc = cstate->crtc;
> struct drm_encoder *encoder;
>
> + if (cstate->self_refresh_active)
> + return true;
> +
> drm_for_each_encoder_mask (encoder, crtc->dev, cstate->encoder_mask) {
> if (dpu_encoder_get_intf_mode(encoder) == INTF_MODE_CMD) {
> return true;
> --
> 2.7.4
>
--
With best wishes
Dmitry
Re: [PATCH 14/21] dt-bindings: soc: mediatek: specify which compatible requires clocks property
On 09/03/2023 15:23, Alexandre Mergnat wrote: According to the mtk-mutex.c driver and the SoC DTS, the clock isn't required to work properly for some of MTK SoC. Improve the clock requirement by adding a condition which is function to the compatible. Signed-off-by: Alexandre Mergnat Applied, thanks. Now I think we can get rid of the no_clk variable in struct mtk_mutex_data, as this should be mandated by the device-tree. Regards, Matthias --- .../bindings/soc/mediatek/mediatek,mutex.yaml| 20 +++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml b/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml index 9241e5fc7cff..ca0ca549257d 100644 --- a/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml +++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml @@ -69,12 +69,30 @@ properties: 4 arguments defined in this property. Each GCE subsys id is mapping to a client defined in the header include/dt-bindings/gce/-gce.h. +allOf: + - if: + properties: +compatible: + contains: +enum: + - mediatek,mt2701-disp-mutex + - mediatek,mt2712-disp-mutex + - mediatek,mt6795-disp-mutex + - mediatek,mt8173-disp-mutex + - mediatek,mt8186-disp-mutex + - mediatek,mt8186-mdp3-mutex + - mediatek,mt8192-disp-mutex + - mediatek,mt8195-disp-mutex +then: + required: +- clocks + + required: - compatible - reg - interrupts - power-domains - - clocks additionalProperties: false
[PATCH v2] drm/i915/gt: Hold a wakeref for the active VM
From: Chris Wilson
There may be a disconnect between the GT used by the engine and the GT
used for the VM, requiring us to hold a wakeref on both while the GPU is
active with this request.
v2: added explanation to __queue_and_release_pm
Signed-off-by: Chris Wilson
[ahajda: removed not-yet-upstremed wakeref tracking bits]
Signed-off-by: Andrzej Hajda
---
Changes in v2:
- Link to v1:
https://lore.kernel.org/r/20230330-hold_wakeref_for_active_vm-v1-1-baca71269...@intel.com
---
drivers/gpu/drm/i915/gt/intel_context.h | 15 +++
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 9 +
2 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index 0a8d553da3f439..48f888c3da083b 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -14,6 +14,7 @@
#include "i915_drv.h"
#include "intel_context_types.h"
#include "intel_engine_types.h"
+#include "intel_gt_pm.h"
#include "intel_ring_types.h"
#include "intel_timeline_types.h"
#include "i915_trace.h"
@@ -207,8 +208,11 @@ void intel_context_exit_engine(struct intel_context *ce);
static inline void intel_context_enter(struct intel_context *ce)
{
lockdep_assert_held(>timeline->mutex);
- if (!ce->active_count++)
- ce->ops->enter(ce);
+ if (ce->active_count++)
+ return;
+
+ ce->ops->enter(ce);
+ intel_gt_pm_get(ce->vm->gt);
}
static inline void intel_context_mark_active(struct intel_context *ce)
@@ -222,8 +226,11 @@ static inline void intel_context_exit(struct intel_context
*ce)
{
lockdep_assert_held(>timeline->mutex);
GEM_BUG_ON(!ce->active_count);
- if (!--ce->active_count)
- ce->ops->exit(ce);
+ if (--ce->active_count)
+ return;
+
+ intel_gt_pm_put_async(ce->vm->gt);
+ ce->ops->exit(ce);
}
static inline struct intel_context *intel_context_get(struct intel_context *ce)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index e971b153fda976..ee531a5c142c77 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -114,6 +114,15 @@ __queue_and_release_pm(struct i915_request *rq,
ENGINE_TRACE(engine, "parking\n");
+ /*
+* Open coded one half of intel_context_enter, which we have to omit
+* here (see the large comment below) and because the other part must
+* not be called due constructing directly with __i915_request_create
+* which increments active count via intel_context_mark_active.
+*/
+ GEM_BUG_ON(rq->context->active_count != 1);
+ __intel_gt_pm_get(engine->gt);
+
/*
* We have to serialise all potential retirement paths with our
* submission, as we don't want to underflow either the
---
base-commit: 3385d6482cd60f2a0bbb0fa97b70ae7dbba4f95c
change-id: 20230330-hold_wakeref_for_active_vm-7f013a449ef3
Best regards,
--
Andrzej Hajda
[PATCH v1 3/3] msm: skip the atomic commit of self refresh while PSR running
In certain CPU stress conditions, there can be a delay in scheduling commit work and it was observed that PSR commit from a different work queue was scheduled. Avoid these commits as display is already in PSR mode. Signed-off-by: Vinod Polimera --- drivers/gpu/drm/msm/msm_atomic.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c index 645fe53..f8141bb 100644 --- a/drivers/gpu/drm/msm/msm_atomic.c +++ b/drivers/gpu/drm/msm/msm_atomic.c @@ -192,6 +192,9 @@ int msm_atomic_check(struct drm_device *dev, struct drm_atomic_state *state) new_crtc_state->mode_changed = true; state->allow_modeset = true; } + + if (old_crtc_state->self_refresh_active && new_crtc_state->self_refresh_active) + return -EINVAL; } return drm_atomic_helper_check(dev, state); -- 2.7.4
[PATCH v1 2/3] msm/disp/dpu: allow atomic_check in PSR usecase
Certain flags like dirty_fb will be updated into the plane state
during crtc atomic_check. Allow those updates during PSR commit.
Reported-by: Bjorn Andersson
Link: https://lore.kernel.org/all/20230326162723.3lo6pnsfdwzsvbhj@ripper/
Signed-off-by: Vinod Polimera
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 96f645e..a02c7f4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1185,7 +1185,7 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
bool needs_dirtyfb = dpu_crtc_needs_dirtyfb(crtc_state);
- if (!crtc_state->enable || !crtc_state->active) {
+ if (!crtc_state->enable ||
!drm_atomic_crtc_effectively_active(crtc_state)) {
DRM_DEBUG_ATOMIC("crtc%d -> enable %d, active %d, skip
atomic_check\n",
crtc->base.id, crtc_state->enable,
crtc_state->active);
--
2.7.4
[PATCH v1 1/3] drm/msm/dpu: set dirty_fb flag while in self refresh mode
While in virtual terminal mode with PSR enabled, there will be
no atomic commits triggered without dirty_fb being set. This
will create a notion of no screen update. Allow atomic commit
when dirty_fb ioctl is issued, so that it can trigger a PSR exit
and shows update on the screen.
Reported-by: Bjorn Andersson
Link: https://lore.kernel.org/all/20230326162723.3lo6pnsfdwzsvbhj@ripper/
Signed-off-by: Vinod Polimera
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index ab636da..96f645e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1158,6 +1158,9 @@ static bool dpu_crtc_needs_dirtyfb(struct drm_crtc_state
*cstate)
struct drm_crtc *crtc = cstate->crtc;
struct drm_encoder *encoder;
+ if (cstate->self_refresh_active)
+ return true;
+
drm_for_each_encoder_mask (encoder, crtc->dev, cstate->encoder_mask) {
if (dpu_encoder_get_intf_mode(encoder) == INTF_MODE_CMD) {
return true;
--
2.7.4
[PATCH v1 0/3] Fixes for PSR
while in virtual terminal with PSR enabled, there will be no atomic commits triggered resulting in no screen update. Update the dirtyfb flag into plane state during atomic check to flush the pixel data explicitly. Avoid scheduling PSR commits from different work queues while running in PSR mode already. Vinod Polimera (3): drm/msm/dpu: set dirty_fb flag while in self refresh mode msm/disp/dpu: allow atomic_check in PSR usecase msm: skip the atomic commit of self refresh while PSR running drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 5 - drivers/gpu/drm/msm/msm_atomic.c | 3 +++ 2 files changed, 7 insertions(+), 1 deletion(-) -- 2.7.4
Re: [Intel-xe] [PATCH 2/3] drm/xe: Fix platform order
On Mon, Mar 27, 2023 at 10:02:38AM -0700, Matt Roper wrote:
On Thu, Mar 23, 2023 at 10:17:53PM -0700, Lucas De Marchi wrote:
Platform order is important when looping through the list of guc
firmware blobs since we use it to prevent loading a blob for a newer
platform onto an older one. Move PVC after ADL.
Shouldn't we be moving the ADL platforms (graphics versions 12.0) higher
than DG1 (12.10) and DG2 (12.50) too?
question then would be: would we be ordering them by gt
version? Or by when they were introduced?
I think it makes more sense to be by when they were introduced as a
platform in the driver.
1) what about media/display?
2) allow us to always be appending in the enum and elsewhere in
the driver.
Lucas De Marchi
Matt
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/xe/xe_platform_types.h | 3 +--
drivers/gpu/drm/xe/xe_uc_fw.c | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_platform_types.h
b/drivers/gpu/drm/xe/xe_platform_types.h
index 72612c832e88..10367f6cc75a 100644
--- a/drivers/gpu/drm/xe/xe_platform_types.h
+++ b/drivers/gpu/drm/xe/xe_platform_types.h
@@ -9,14 +9,13 @@
/* Keep in gen based order, and chronological order within a gen */
enum xe_platform {
XE_PLATFORM_UNINITIALIZED = 0,
- /* gen12 */
XE_TIGERLAKE,
XE_ROCKETLAKE,
XE_DG1,
XE_DG2,
- XE_PVC,
XE_ALDERLAKE_S,
XE_ALDERLAKE_P,
+ XE_PVC,
XE_METEORLAKE,
};
diff --git a/drivers/gpu/drm/xe/xe_uc_fw.c b/drivers/gpu/drm/xe/xe_uc_fw.c
index e2c982b37e87..174c42873ebb 100644
--- a/drivers/gpu/drm/xe/xe_uc_fw.c
+++ b/drivers/gpu/drm/xe/xe_uc_fw.c
@@ -43,9 +43,9 @@ static struct xe_device *uc_fw_to_xe(struct xe_uc_fw *uc_fw)
*/
#define XE_GUC_FIRMWARE_DEFS(fw_def, guc_def) \
fw_def(METEORLAKE, guc_def(mtl, 70, 5, 2)) \
+ fw_def(PVC, guc_def(pvc, 70, 5, 2)) \
fw_def(ALDERLAKE_P, guc_def(adlp, 70, 5, 2)) \
fw_def(ALDERLAKE_S, guc_def(tgl, 70, 5, 2)) \
- fw_def(PVC, guc_def(pvc, 70, 5, 2)) \
fw_def(DG2, guc_def(dg2, 70, 5, 2)) \
fw_def(DG1, guc_def(dg1, 70, 5, 2)) \
fw_def(TIGERLAKE,guc_def(tgl, 70, 5, 2))
--
2.39.0
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH] drm/scheduler: set entity to NULL in drm_sched_entity_pop_job()
On 2023-03-31 01:59, Christian König wrote: > Am 31.03.23 um 02:06 schrieb Danilo Krummrich: >> It already happend a few times that patches slipped through which >> implemented access to an entity through a job that was already removed >> from the entities queue. Since jobs and entities might have different >> lifecycles, this can potentially cause UAF bugs. >> >> In order to make it obvious that a jobs entity pointer shouldn't be >> accessed after drm_sched_entity_pop_job() was called successfully, set >> the jobs entity pointer to NULL once the job is removed from the entity >> queue. >> >> Moreover, debugging a potential NULL pointer dereference is way easier >> than potentially corrupted memory through a UAF. >> >> Signed-off-by: Danilo Krummrich > > In general "YES PLEASE!", but I fear that this will break amdgpus reset > sequence. > > On the other hand when amdgpu still relies on that pointer it's clearly > a bug (which I pointed out tons of times before). > > Luben any opinion on that? Could you drive cleaning that up as well? Hi Christian, No worries, yes, I'll take a look at this after breakfast. > > Thanks, > Christian. > >> --- >> I'm aware that drivers could already use job->entity in arbitrary places, >> since >> they in control of when the entity is actually freed. A quick grep didn't >> give >> me any results where this would actually be the case, however maybe I also >> just >> didn't catch it. >> >> If, therefore, we don't want to set job->entity to NULL I think we should at >> least add a comment somewhere. I agree with the sentiment of this patch. I'll have to take a closer look at this because there was some indirect pointer dependency due to the way the FIFO was implemented, and I review the code every 3-6 months to remind me of that--maybe it's related, maybe not. But this looks like a something we can delve into and at best come up with a comment explaining what's going on and why. We haven't seen any oopses so far the way this is, and any new patches which evoke an oops, may be doing something they shouldn't. I'll take a look. Any indication of what these new patches were doing? Regards, Luben >> --- >> >> drivers/gpu/drm/scheduler/sched_entity.c | 6 ++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/drivers/gpu/drm/scheduler/sched_entity.c >> b/drivers/gpu/drm/scheduler/sched_entity.c >> index 15d04a0ec623..a9c6118e534b 100644 >> --- a/drivers/gpu/drm/scheduler/sched_entity.c >> +++ b/drivers/gpu/drm/scheduler/sched_entity.c >> @@ -448,6 +448,12 @@ struct drm_sched_job *drm_sched_entity_pop_job(struct >> drm_sched_entity *entity) >> drm_sched_rq_update_fifo(entity, next->submit_ts); >> } >> >> +/* Jobs and entities might have different lifecycles. Since we're >> + * removing the job from the entities queue, set the jobs entity pointer >> + * to NULL to prevent any future access of the entity through this job. >> + */ >> +sched_job->entity = NULL; >> + >> return sched_job; >> } >> >
Re: [Intel-gfx] [PATCH v6 5/8] drm/i915/pxp: Add ARB session creation and cleanup
On 30/03/2023 20:44, Teres Alexis, Alan Previn wrote: On Thu, 2023-03-30 at 13:25 +0100, Tvrtko Ursulin wrote: On 30/03/2023 01:10, Teres Alexis, Alan Previn wrote: On Wed, 2023-03-29 at 08:43 +0100, Tvrtko Ursulin wrote: On 28/03/2023 18:52, Rodrigo Vivi wrote: On Tue, Mar 28, 2023 at 05:01:36PM +, Teres Alexis, Alan Previn wrote: On Mon, 2023-03-27 at 17:15 +0100, Tvrtko Ursulin wrote: alan:snip (excuse my snips - my evolution keeps inserting CRs - still looking for solution) But intuitively I thought that what Mesa wants is a no-cost getparam which would somewhat reliably tell it if the feature is supposed to be there and context create at a later stage, with the protected flag set, is supposed to work. AFAIU it can still fail at that point or probably block until the required setup is done. Yes - that's right - i had another round of discussions with Daniele about a cleaner approach - below.. alan:snip Even 200ms is possibly not good enough since boot time targets (to UI AFAIR) are pretty tight. Don't know... Maybe I'd need a timeline diagram showing the involved components to understand this properly. Absolutely, my experiences in i915 on embedded products even had PORs of <1000milisec to first-fully-renderered-display from cold-boot so yes, we need to work with this requirement in mind and do testing on real customer stack. I spoke to Daniele and we have another idea - but would also impact mesa, for the better: 1. Introduce get-param (is_PXP_avail) - will return a simple yes or no - yes means : i915-device-info supports it, kernel configs supports it and required-firmwares were found (not necessarily loaded/init yet). (NOTE: this would be made to hook up to pxp helpers such as intel_pxp_is_supported) 2. Gem-pxp-context-creation continues blocking like today with minor tweak: (same)- success = all dependencies are in place, all firmware init completed, pxp arb session successfully completed. (same)- non-success -ENODEV = if any dependency wasnt available or fw failed to create arb-session due to fw-init-failure/BIOS/platform config. (tweak)- non-success -ENXIO (or some other -E'FOO') if component-driver-init or firmware-init is still pending after brief timeout. - on timeout - TBD - need testing/debug on real world stack. - UAPI spec needs update but pxp implementation currently uses -ENXIO for similiar reason inheritted first merge. Thus, with this: Get param would always be immediate. Pxp-context-creation would only block when all dependencies are in place and we attempt to create the pxp arb session. (firmware can take up to 200-milisecs, according to MTL spec, so I'd say ~210 given other overheads between i915 and fw and back). We would need to change MESA-get-caps to use get-param (and not pxp-context-creation) as it would always return immediately with kernel side support. And if application explicitly requires PXP support, then it needs to call pxp-context-creation that may block or require retry. The above sounds good to me. I am only not 100% clear on the ENODEV option from context create, does it include even things which can be detected without any timeouts at probe time, or just failures which take time to learn about. WRT to fast-boot-to-first-frame, I am hoping real customer stack doesn't require PXP on the compositor and first mesa instance works fine without PXP caps. And when customer apps that needs PXP starts, it would create pxp context which would block but the app would not have a choice. Yeah that sounds like an unlikely use case and one that we cannot improve on the kernel or uapi side. (I can imagine resuming directly into a full screen video playback post suspend, but a cold boot into it is a stretch.) Regards, Tvrtko
Re: [PATCHv1 3/7] drm/panel: sitronix-st7789v: add SPI ID table
Hi Sebastian,
On 3/18/23 00:23, Sebastian Reichel wrote:
> SPI device drivers should also have a SPI ID table.
>
> Signed-off-by: Sebastian Reichel
> ---
> drivers/gpu/drm/panel/panel-sitronix-st7789v.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
> b/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
> index bbc4569cbcdc..e4d8dea1db36 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
> @@ -394,6 +394,12 @@ static void st7789v_remove(struct spi_device *spi)
> drm_panel_remove(>panel);
> }
>
> +static const struct spi_device_id st7789v_spi_id[] = {
> + { "st7789v" },
Minor suggestion: The format
static const struct spi_device_id st7789v_spi_id[] = {
{
.name = "st7789v",
},
{ }
};
is more verbose, but can be extended easily.
> + { }
> +};
> +MODULE_DEVICE_TABLE(spi, st7789v_spi_id);
> +
> static const struct of_device_id st7789v_of_match[] = {
> { .compatible = "sitronix,st7789v" },
> { }
The same holds for this structure here (you may want to consider this
when adding the .data field in patch 6/7.
Best regards,
Michael
> @@ -403,6 +409,7 @@ MODULE_DEVICE_TABLE(of, st7789v_of_match);
> static struct spi_driver st7789v_driver = {
> .probe = st7789v_probe,
> .remove = st7789v_remove,
> + .id_table = st7789v_spi_id,
> .driver = {
> .name = "st7789v",
> .of_match_table = st7789v_of_match,
Re: [PATCHv1 7/7] drm/panel: sitronix-st7789v: add Inanbo T28CP45TN89 support
Hi Sebastian,
Thanks for your work and for the beautiful timing :-)
On 3/18/23 00:23, Sebastian Reichel wrote:
> UNI-T UTi260b has a Inanbo T28CP45TN89 v17 panel. I could not find
> proper documentation for the panel apart from a technical drawing, but
> according to the vendor U-Boot it is based on a Sitronix st7789v chip.
> I generated the init sequence by modifying the default one until proper
> graphics output has been seen on the device.
I can spot only a few differences:
- bits per pixel: 18 (RGB666) vs. 16 (RGB565)
- invert mode
- sync/clk signal polarity
The init sequences are largely the same, which leads to vast code
duplication. Instead, the st7789v_prepare could be adjusted to consider
the st7789v_panel_info and apply the required settings accordingly.
For example, the polarities could be embedded into the drm_display_mode
structure...
> Signed-off-by: Sebastian Reichel
> ---
> .../gpu/drm/panel/panel-sitronix-st7789v.c| 137 ++
> 1 file changed, 137 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
> b/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
> index a62a2f5737e4..90f70eb84f11 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
> @@ -10,6 +10,7 @@
> #include
>
> #include
> +#include
>
> #include
> #include
> @@ -113,6 +114,8 @@ struct st7789v;
> struct st7789_panel_info {
> const struct drm_display_mode *mode;
> int (*init_sequence)(struct st7789v *ctx);
> + unsigned int bpc;
> + u32 bus_format;
... and here you introduce fields for the bits per pixel. Just a field
for the invert mode is missing.
BTW, I would introduce these fields in the previous patch. This patch
should be only about filling out the already existing fields for the new
panel.
> };
>
> struct st7789v {
> @@ -174,6 +177,20 @@ static const struct drm_display_mode default_mode = {
> .height_mm = 103,
> };
>
> +static const struct drm_display_mode t28cp45tn89_mode = {
> + .clock = 6008,
> + .hdisplay = 240,
> + .hsync_start = 240 + 38,
> + .hsync_end = 240 + 38 + 10,
> + .htotal = 240 + 38 + 10 + 10,
> + .vdisplay = 320,
> + .vsync_start = 320 + 8,
> + .vsync_end = 320 + 8 + 4,
> + .vtotal = 320 + 8 + 4 + 4,
> + .width_mm = 43,
> + .height_mm = 57,
> +};
> +
> static int init_sequence_default(struct st7789v *ctx) {
> int ret;
>
> @@ -283,11 +300,125 @@ static int init_sequence_default(struct st7789v *ctx) {
> return 0;
> }
>
> +static int init_sequence_t28cp45tn89(struct st7789v *ctx) {
> + int ret;
> +
> + ST7789V_TEST(ret, st7789v_write_command(ctx,
> + MIPI_DCS_SET_ADDRESS_MODE));
> + ST7789V_TEST(ret, st7789v_write_data(ctx, 0));
> +
> + ST7789V_TEST(ret, st7789v_write_command(ctx,
> + MIPI_DCS_SET_PIXEL_FORMAT));
> + ST7789V_TEST(ret, st7789v_write_data(ctx,
> + (MIPI_DCS_PIXEL_FMT_16BIT << 4) |
> + (MIPI_DCS_PIXEL_FMT_16BIT)));
> +
> + ST7789V_TEST(ret, st7789v_write_command(ctx, ST7789V_PORCTRL_CMD));
> + ST7789V_TEST(ret, st7789v_write_data(ctx, 0xc));
> + ST7789V_TEST(ret, st7789v_write_data(ctx, 0xc));
> + ST7789V_TEST(ret, st7789v_write_data(ctx, 0));
> + ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_PORCTRL_IDLE_BP(3) |
> + ST7789V_PORCTRL_IDLE_FP(3)));
> + ST7789V_TEST(ret, st7789v_write_data(ctx,
> + ST7789V_PORCTRL_PARTIAL_BP(3) |
> + ST7789V_PORCTRL_PARTIAL_FP(3)));
> +
> + ST7789V_TEST(ret, st7789v_write_command(ctx, ST7789V_GCTRL_CMD));
> + ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_GCTRL_VGLS(5) |
> + ST7789V_GCTRL_VGHS(3)));
> +
> + ST7789V_TEST(ret, st7789v_write_command(ctx, ST7789V_VCOMS_CMD));
> + ST7789V_TEST(ret, st7789v_write_data(ctx, 0x2b));
> +
> + ST7789V_TEST(ret, st7789v_write_command(ctx, ST7789V_LCMCTRL_CMD));
> + ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_LCMCTRL_XMH |
> + ST7789V_LCMCTRL_XMX |
> + ST7789V_LCMCTRL_XBGR));
> +
> + ST7789V_TEST(ret, st7789v_write_command(ctx, ST7789V_VDVVRHEN_CMD));
> + ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_VDVVRHEN_CMDEN));
> +
> + ST7789V_TEST(ret, st7789v_write_command(ctx, ST7789V_VRHS_CMD));
> + ST7789V_TEST(ret, st7789v_write_data(ctx, 0xf));
> +
> + ST7789V_TEST(ret, st7789v_write_command(ctx, ST7789V_VDVS_CMD));
> + ST7789V_TEST(ret, st7789v_write_data(ctx, 0x20));
> +
> + ST7789V_TEST(ret, st7789v_write_command(ctx, ST7789V_FRCTRL2_CMD));
> + ST7789V_TEST(ret,
[PATCH] accel/ivpu: Remove D3hot delay for Meteorlake
From: Karol Wachowski
VPU on MTL has hardware optimizations and does not require 10ms
D0 - D3hot transition delay imposed by PCI specification.
The delay removal is traditionally done by adding PCI ID to
quirk_remove_dhot_delay() in drivers/pci/quirks.c . But since
we do not need that optimization before driver probe and we
can better specify in the ivpu driver on what (future) hardware
use the optimization, we do not use quirk_remove_dhot_delay()
for that.
Signed-off-by: Karol Wachowski
Signed-off-by: Stanislaw Gruszka
---
drivers/accel/ivpu/ivpu_drv.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c
index 3be4a5a2b07a..cf9925c0a8ad 100644
--- a/drivers/accel/ivpu/ivpu_drv.c
+++ b/drivers/accel/ivpu/ivpu_drv.c
@@ -442,6 +442,10 @@ static int ivpu_pci_init(struct ivpu_device *vdev)
/* Clear any pending errors */
pcie_capability_clear_word(pdev, PCI_EXP_DEVSTA, 0x3f);
+ /* VPU MTL does not require PCI spec 10m D3hot delay */
+ if (ivpu_is_mtl(vdev))
+ pdev->d3hot_delay = 0;
+
ret = pcim_enable_device(pdev);
if (ret) {
ivpu_err(vdev, "Failed to enable PCI device: %d\n", ret);
--
2.25.1
[PATCH 2/2] accel/ivpu: Fix S3 system suspend when not idle
From: Jacek Lawrynowicz
Wait for VPU to be idle in ivpu_pm_suspend_cb() before powering off
the device, so jobs are not lost and TDRs are not triggered after
resume.
Fixes: 852be13f3bd3 ("accel/ivpu: Add PM support")
Signed-off-by: Jacek Lawrynowicz
Signed-off-by: Stanislaw Gruszka
---
drivers/accel/ivpu/ivpu_pm.c | 26 +++---
1 file changed, 11 insertions(+), 15 deletions(-)
diff --git a/drivers/accel/ivpu/ivpu_pm.c b/drivers/accel/ivpu/ivpu_pm.c
index da0bbc46a024..aa4d56dc52b3 100644
--- a/drivers/accel/ivpu/ivpu_pm.c
+++ b/drivers/accel/ivpu/ivpu_pm.c
@@ -140,32 +140,28 @@ int ivpu_pm_suspend_cb(struct device *dev)
{
struct drm_device *drm = dev_get_drvdata(dev);
struct ivpu_device *vdev = to_ivpu_device(drm);
- int ret;
+ unsigned long timeout;
ivpu_dbg(vdev, PM, "Suspend..\n");
- ret = ivpu_suspend(vdev);
- if (ret && vdev->pm->suspend_reschedule_counter) {
- ivpu_dbg(vdev, PM, "Failed to enter idle, rescheduling suspend,
retries left %d\n",
-vdev->pm->suspend_reschedule_counter);
- pm_schedule_suspend(dev, vdev->timeout.reschedule_suspend);
- vdev->pm->suspend_reschedule_counter--;
- return -EBUSY;
- } else if (!vdev->pm->suspend_reschedule_counter) {
- ivpu_warn(vdev, "Failed to enter idle, force suspend\n");
- ivpu_pm_prepare_cold_boot(vdev);
- } else {
- ivpu_pm_prepare_warm_boot(vdev);
+ timeout = jiffies + msecs_to_jiffies(vdev->timeout.tdr);
+ while (!ivpu_hw_is_idle(vdev)) {
+ cond_resched();
+ if (time_after_eq(jiffies, timeout)) {
+ ivpu_err(vdev, "Failed to enter idle on system
suspend\n");
+ return -EBUSY;
+ }
}
- vdev->pm->suspend_reschedule_counter = PM_RESCHEDULE_LIMIT;
+ ivpu_suspend(vdev);
+ ivpu_pm_prepare_warm_boot(vdev);
pci_save_state(to_pci_dev(dev));
pci_set_power_state(to_pci_dev(dev), PCI_D3hot);
ivpu_dbg(vdev, PM, "Suspend done.\n");
- return ret;
+ return 0;
}
int ivpu_pm_resume_cb(struct device *dev)
--
2.25.1
[PATCH 1/2] accel/ivpu: Add dma fence to command buffers only
From: Karol Wachowski
Currently job->done_fence is added to every BO handle within a job. If job
handle (command buffer) is shared between multiple submits, KMD will add
the fence in each of them. Then bo_wait_ioctl() executed on command buffer
will exit only when all jobs containing that handle are done.
This creates deadlock scenario for user mode driver in case when job handle
is added as dependency of another job, because bo_wait_ioctl() of first job
will wait until second job finishes, and second job can not finish before
first one.
Having fences added only to job buffer handle allows user space to execute
bo_wait_ioctl() on the job even if it's handle is submitted with other job.
Fixes: cd7272215c44 ("accel/ivpu: Add command buffer submission logic")
Signed-off-by: Karol Wachowski
Signed-off-by: Stanislaw Gruszka
---
drivers/accel/ivpu/ivpu_job.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/accel/ivpu/ivpu_job.c b/drivers/accel/ivpu/ivpu_job.c
index 910301fae435..3c6f1e16cf2f 100644
--- a/drivers/accel/ivpu/ivpu_job.c
+++ b/drivers/accel/ivpu/ivpu_job.c
@@ -461,26 +461,22 @@ ivpu_job_prepare_bos_for_submit(struct drm_file *file,
struct ivpu_job *job, u32
job->cmd_buf_vpu_addr = bo->vpu_addr + commands_offset;
- ret = drm_gem_lock_reservations((struct drm_gem_object **)job->bos,
buf_count,
- _ctx);
+ ret = drm_gem_lock_reservations((struct drm_gem_object **)job->bos, 1,
_ctx);
if (ret) {
ivpu_warn(vdev, "Failed to lock reservations: %d\n", ret);
return ret;
}
- for (i = 0; i < buf_count; i++) {
- ret = dma_resv_reserve_fences(job->bos[i]->base.resv, 1);
- if (ret) {
- ivpu_warn(vdev, "Failed to reserve fences: %d\n", ret);
- goto unlock_reservations;
- }
+ ret = dma_resv_reserve_fences(bo->base.resv, 1);
+ if (ret) {
+ ivpu_warn(vdev, "Failed to reserve fences: %d\n", ret);
+ goto unlock_reservations;
}
- for (i = 0; i < buf_count; i++)
- dma_resv_add_fence(job->bos[i]->base.resv, job->done_fence,
DMA_RESV_USAGE_WRITE);
+ dma_resv_add_fence(bo->base.resv, job->done_fence,
DMA_RESV_USAGE_WRITE);
unlock_reservations:
- drm_gem_unlock_reservations((struct drm_gem_object **)job->bos,
buf_count, _ctx);
+ drm_gem_unlock_reservations((struct drm_gem_object **)job->bos, 1,
_ctx);
wmb(); /* Flush write combining buffers */
--
2.25.1
[PATCH 0/2] accel/ivpu: Fixes for linux-6.3-rc6
Jacek Lawrynowicz (1): accel/ivpu: Fix S3 system suspend when not idle Karol Wachowski (1): accel/ivpu: Add dma fence to command buffers only drivers/accel/ivpu/ivpu_job.c | 18 +++--- drivers/accel/ivpu/ivpu_pm.c | 26 +++--- 2 files changed, 18 insertions(+), 26 deletions(-) -- 2.25.1
Re: [PATCH v2 9/9] drm/i915: Use kmap_local_page() in gem/i915_gem_execbuffer.c
On 31/03/2023 05:18, Ira Weiny wrote:
Zhao Liu wrote:
From: Zhao Liu
The use of kmap_atomic() is being deprecated in favor of
kmap_local_page()[1], and this patch converts the calls from
kmap_atomic() to kmap_local_page().
The main difference between atomic and local mappings is that local
mappings doesn't disable page faults or preemption (the preemption is
disabled for !PREEMPT_RT case, otherwise it only disables migration).
With kmap_local_page(), we can avoid the often unwanted side effect of
unnecessary page faults and preemption disables.
In i915_gem_execbuffer.c, eb->reloc_cache.vaddr is mapped by
kmap_atomic() in eb_relocate_entry(), and is unmapped by
kunmap_atomic() in reloc_cache_reset().
First off thanks for the series and sticking with this. That said this
patch kind of threw me for a loop because tracing the map/unmap calls did
not make sense to me. See below.
And this mapping/unmapping occurs in two places: one is in
eb_relocate_vma(), and another is in eb_relocate_vma_slow().
The function eb_relocate_vma() or eb_relocate_vma_slow() doesn't
need to disable pagefaults and preemption during the above mapping/
unmapping.
So it can simply use kmap_local_page() / kunmap_local() that can
instead do the mapping / unmapping regardless of the context.
Convert the calls of kmap_atomic() / kunmap_atomic() to
kmap_local_page() / kunmap_local().
[1]: https://lore.kernel.org/all/20220813220034.806698-1-ira.we...@intel.com
v2: No code change since v1. Added description of the motivation of
using kmap_local_page() and "Suggested-by" tag of Fabio.
Suggested-by: Ira Weiny
Suggested-by: Fabio M. De Francesco
Signed-off-by: Zhao Liu
---
Suggested by credits:
Ira: Referred to his task document, review comments.
Fabio: Referred to his boiler plate commit message and his description
about why kmap_local_page() should be preferred.
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 9dce2957b4e5..805565edd148 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1151,7 +1151,7 @@ static void reloc_cache_unmap(struct reloc_cache *cache)
vaddr = unmask_page(cache->vaddr);
if (cache->vaddr & KMAP)
- kunmap_atomic(vaddr);
+ kunmap_local(vaddr);
In the cover letter you don't mention this unmap path. Rather you mention
only reloc_cache_reset().
After digging into this and considering these are kmap_atomic() calls I
_think_ what you have is ok. But I think I'd like to see the call paths
documented a bit more clearly. Or perhaps cleaned up a lot.
For example I see the following call possibility from a user ioctl. In
this trace I see 2 examples where something is unmapped first. I don't
understand why that is required? I would assume reloc_cache_unmap() and
reloc_kmap() are helpers called from somewhere else requiring a remapping
of the cache but I don't see it.
Reloc_cache_unmap is called from eb_relocate_entry.
The confusing part unmap appears first is just because reloc_cache is a
stateful setup. The previous mapping is kept around until reset (callers
moves to a different parent object), and unampped/remapped once moved to
a different page within that object.
However I am unsure if disabling pagefaulting is needed or not. Thomas,
Matt, being the last to touch this area, perhaps you could have a look?
Because I notice we have a fallback iomap path which still uses
io_mapping_map_atomic_wc. So if kmap_atomic to kmap_local conversion is
safe, does the iomap side also needs converting to
io_mapping_map_local_wc? Or they have separate requirements?
Regards,
Tvrtko
i915_gem_execbuffer2_ioctl()
eb_relocate_parse()
eb_relocate_parse_slow()
eb_relocate_vma_slow()
eb_relocate_entry()
reloc_cache_unmap()
kunmap_atomic() <=== HERE!
reloc_cache_remap()
kmap_atomic()
relocate_entry()
reloc_vaddr()
reloc_kmap()
kunmap_atomic() <== HERE!
kmap_atomic()
reloc_cache_reset()
kunmap_atomic()
Could these mappings be cleaned up a lot more? Perhaps by removing some
of the helper functions which AFAICT are left over from older versions of
the code?
Also as an aside I think it is really bad that eb_relocate_entry() returns
negative errors in a u64. Better to get the types right IMO.
Thanks for the series!
Ira
else
io_mapping_unmap_atomic((void __iomem *)vaddr);
}
@@ -1167,7 +1167,7 @@ static void reloc_cache_remap(struct reloc_cache *cache,
if (cache->vaddr & KMAP) {
