Re: [Intel-gfx] [PATCH] pwm: Rename pwm_get_state() to better reflect its semantic
On Tue, 06 Apr 2021, Uwe Kleine-König wrote: > Given that lowlevel drivers usually cannot implement exactly what a > consumer requests with pwm_apply_state() there is some rounding involved. > > pwm_get_state() traditionally returned the setting that was requested most > recently by the consumer (opposed to what was actually implemented in > hardware in reply to the last request). To make this semantic obvious > rename the function. > > Signed-off-by: Uwe Kleine-König > --- > drivers/gpu/drm/i915/display/intel_panel.c | 4 +-- Acked-by: Jani Nikula -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/hdcp: Fix uninitialized symbol 'msg_end'
Fix static analysis tool uninitialized symbol error. Reported-by: kernel test robot Reported-by: Dan Carpenter Signed-off-by: Anshuman Gupta --- drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c index 90868e156c69..a4373fb2817b 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c @@ -532,7 +532,7 @@ int intel_dp_hdcp2_read_msg(struct intel_digital_port *dig_port, u8 *byte = buf; ssize_t ret, bytes_to_recv, len; const struct hdcp2_dp_msg_data *hdcp2_msg_data; - ktime_t msg_end; + ktime_t msg_end = 0; bool msg_expired; hdcp2_msg_data = get_hdcp2_dp_msg_data(msg_id); -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] pwm: Rename pwm_get_state() to better reflect its semantic
On Tue, Apr 06, 2021 at 09:30:36AM +0200, Uwe Kleine-König wrote: > Given that lowlevel drivers usually cannot implement exactly what a > consumer requests with pwm_apply_state() there is some rounding involved. > > pwm_get_state() traditionally returned the setting that was requested most > recently by the consumer (opposed to what was actually implemented in > hardware in reply to the last request). To make this semantic obvious > rename the function. > > Signed-off-by: Uwe Kleine-König > --- > Documentation/driver-api/pwm.rst | 6 +++- > drivers/clk/clk-pwm.c | 2 +- > drivers/gpu/drm/i915/display/intel_panel.c | 4 +-- > drivers/input/misc/da7280.c| 2 +- > drivers/input/misc/pwm-beeper.c| 2 +- > drivers/input/misc/pwm-vibra.c | 4 +-- > drivers/pwm/core.c | 4 +-- > drivers/pwm/pwm-atmel-hlcdc.c | 2 +- > drivers/pwm/pwm-atmel.c| 2 +- > drivers/pwm/pwm-imx27.c| 2 +- > drivers/pwm/pwm-rockchip.c | 2 +- > drivers/pwm/pwm-stm32-lp.c | 4 +-- > drivers/pwm/pwm-sun4i.c| 2 +- > drivers/pwm/sysfs.c| 18 ++-- > drivers/regulator/pwm-regulator.c | 4 +-- > drivers/video/backlight/pwm_bl.c | 10 +++ > include/linux/pwm.h| 34 ++ > 17 files changed, 59 insertions(+), 45 deletions(-) Honestly, I don't think this is worth the churn. If you think people will easily get confused by this then a better solution might be to more explicitly document the pwm_get_state() function to say exactly what it returns. But there's no need to make life difficult for everyone by renaming this to something as cumbersome as this. Thierry signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/pmu: Do not report 100% RC6 if not supported
Hi Tvrtko,
> We use GT parked status to estimate RC6 while not in use, however if RC6
> is not supported to start with that does not work very well and produces a
> false 100% RC6 readout.
>
> Fix by not advancing the estimated RC6 counter when feature is not
> supported.
>
> Signed-off-by: Tvrtko Ursulin
> Fixes: 1fe699e30113 ("drm/i915/pmu: Fix sleep under atomic in RC6 readout")
> Reported-by: Eero T Tamminen
> ---
> drivers/gpu/drm/i915/i915_pmu.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
> index 41651ac255fa..02fe0d22c470 100644
> --- a/drivers/gpu/drm/i915/i915_pmu.c
> +++ b/drivers/gpu/drm/i915/i915_pmu.c
> @@ -191,7 +191,10 @@ static u64 get_rc6(struct intel_gt *gt)
>* on top of the last known real value, as the approximated RC6
>* counter value.
>*/
> - val = ktime_since_raw(pmu->sleep_last);
> + if (gt->rc6.supported)
> + val = ktime_since_raw(pmu->sleep_last);
> + else
> + val = 0;
if rc6 is not supported, why are we here?
Did you mean rc6.enabled ?
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915/hdcp: Fix uninitialized symbol 'msg_end'
== Series Details == Series: drm/i915/hdcp: Fix uninitialized symbol 'msg_end' URL : https://patchwork.freedesktop.org/series/88756/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:102: warning: Function parameter or member 'ww' not described in 'i915_gem_shrink' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function parameter 'trampoline' description in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'jump_whitelist' not described in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'shadow_map' not described in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'batch_map' not described in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function parameter 'trampoline' description in 'intel_engine_cmd_parser' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] pwm: Rename pwm_get_state() to better reflect its semantic
On Tue, Apr 06, 2021 at 09:30:36AM +0200, Uwe Kleine-König wrote: > Given that lowlevel drivers usually cannot implement exactly what a > consumer requests with pwm_apply_state() there is some rounding involved. Acked-by: Mark Brown signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/hdcp: Fix uninitialized symbol 'msg_end'
== Series Details ==
Series: drm/i915/hdcp: Fix uninitialized symbol 'msg_end'
URL : https://patchwork.freedesktop.org/series/88756/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9928 -> Patchwork_19894
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19894/index.html
Known issues
Here are the changes found in Patchwork_19894 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@semaphore:
- fi-bdw-5557u: NOTRUN -> [SKIP][1] ([fdo#109271]) +27 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19894/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html
* igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u: NOTRUN -> [WARN][2] ([i915#2283])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19894/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html
* igt@debugfs_test@read_all_entries:
- fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([i915#402]) +2 similar
issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9928/fi-tgl-y/igt@debugfs_test@read_all_entries.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19894/fi-tgl-y/igt@debugfs_test@read_all_entries.html
* igt@kms_chamelium@dp-crc-fast:
- fi-bdw-5557u: NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827]) +8
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19894/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html
Possible fixes
* igt@prime_self_import@basic-with_one_bo_two_files:
- fi-tgl-y: [DMESG-WARN][6] ([i915#402]) -> [PASS][7] +1 similar
issue
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9928/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19894/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#2283]: https://gitlab.freedesktop.org/drm/intel/issues/2283
[i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
Participating hosts (45 -> 40)
--
Additional (1): fi-bdw-5557u
Missing(6): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan
fi-ctg-p8600 fi-bdw-samus
Build changes
-
* Linux: CI_DRM_9928 -> Patchwork_19894
CI-20190529: 20190529
CI_DRM_9928: 39a8c358dcd5eaa8c6f8c81c69055d4f6574307c @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6056: 84e6a7e19ccc7fafc46f372e756cad9d4aa093f7 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_19894: e4f71c7c55045407ab9c4f203c397e22a6d4e9a4 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
e4f71c7c5504 drm/i915/hdcp: Fix uninitialized symbol 'msg_end'
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19894/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/11] treewide: address gcc-11 -Wstringop-overread warnings
On Mon, 22 Mar 2021 17:02:38 +0100, Arnd Bergmann wrote: > The coming gcc release introduces a new warning for string operations > reading beyond the end of a fixed-length object. After testing > randconfig kernels for a while, think I have patches for any such > warnings that came up on x86, arm and arm64. > > Most of these warnings are false-positive ones, either gcc warning > about something that is entirely correct, or about something that > looks suspicious but turns out to be correct after all. > > [...] Applied to 5.13/scsi-queue, thanks! [09/11] scsi: lpfc: fix gcc -Wstringop-overread warning https://git.kernel.org/mkp/scsi/c/ada48ba70f6b -- Martin K. Petersen Oracle Linux Engineering ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] pwm: Rename pwm_get_state() to better reflect its semantic
Given that lowlevel drivers usually cannot implement exactly what a
consumer requests with pwm_apply_state() there is some rounding involved.
pwm_get_state() traditionally returned the setting that was requested most
recently by the consumer (opposed to what was actually implemented in
hardware in reply to the last request). To make this semantic obvious
rename the function.
Signed-off-by: Uwe Kleine-König
---
Documentation/driver-api/pwm.rst | 6 +++-
drivers/clk/clk-pwm.c | 2 +-
drivers/gpu/drm/i915/display/intel_panel.c | 4 +--
drivers/input/misc/da7280.c| 2 +-
drivers/input/misc/pwm-beeper.c| 2 +-
drivers/input/misc/pwm-vibra.c | 4 +--
drivers/pwm/core.c | 4 +--
drivers/pwm/pwm-atmel-hlcdc.c | 2 +-
drivers/pwm/pwm-atmel.c| 2 +-
drivers/pwm/pwm-imx27.c| 2 +-
drivers/pwm/pwm-rockchip.c | 2 +-
drivers/pwm/pwm-stm32-lp.c | 4 +--
drivers/pwm/pwm-sun4i.c| 2 +-
drivers/pwm/sysfs.c| 18 ++--
drivers/regulator/pwm-regulator.c | 4 +--
drivers/video/backlight/pwm_bl.c | 10 +++
include/linux/pwm.h| 34 ++
17 files changed, 59 insertions(+), 45 deletions(-)
diff --git a/Documentation/driver-api/pwm.rst b/Documentation/driver-api/pwm.rst
index ab62f1bb0366..381f3c46cdac 100644
--- a/Documentation/driver-api/pwm.rst
+++ b/Documentation/driver-api/pwm.rst
@@ -55,7 +55,11 @@ several parameter at once. For example, if you see
pwm_config() and
pwm_{enable,disable}() calls in the same function, this probably means you
should switch to pwm_apply_state().
-The PWM user API also allows one to query the PWM state with pwm_get_state().
+The PWM user API also allows one to query the last applied PWM state with
+pwm_get_last_applied_state(). Note this is different to what the driver has
+actually implemented if the request cannot be implemented exactly with the
+hardware in use. There is currently no way for consumers to get the actually
+implemented settings.
In addition to the PWM state, the PWM API also exposes PWM arguments, which
are the reference PWM config one should use on this PWM.
diff --git a/drivers/clk/clk-pwm.c b/drivers/clk/clk-pwm.c
index da2c8eddfd9f..7cfaff32980b 100644
--- a/drivers/clk/clk-pwm.c
+++ b/drivers/clk/clk-pwm.c
@@ -49,7 +49,7 @@ static int clk_pwm_get_duty_cycle(struct clk_hw *hw, struct
clk_duty *duty)
struct clk_pwm *clk_pwm = to_clk_pwm(hw);
struct pwm_state state;
- pwm_get_state(clk_pwm->pwm, &state);
+ pwm_get_last_applied_state(clk_pwm->pwm, &state);
duty->num = state.duty_cycle;
duty->den = state.period;
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
b/drivers/gpu/drm/i915/display/intel_panel.c
index 5fdf52643150..3aebf9be6b6a 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -627,7 +627,7 @@ static u32 ext_pwm_get_backlight(struct intel_connector
*connector, enum pipe un
struct intel_panel *panel = &connector->panel;
struct pwm_state state;
- pwm_get_state(panel->backlight.pwm, &state);
+ pwm_get_last_applied_state(panel->backlight.pwm, &state);
return pwm_get_relative_duty_cycle(&state, 100);
}
@@ -1915,7 +1915,7 @@ static int ext_pwm_setup_backlight(struct intel_connector
*connector,
if (pwm_is_enabled(panel->backlight.pwm)) {
/* PWM is already enabled, use existing settings */
- pwm_get_state(panel->backlight.pwm,
&panel->backlight.pwm_state);
+ pwm_get_last_applied_state(panel->backlight.pwm,
&panel->backlight.pwm_state);
level = pwm_get_relative_duty_cycle(&panel->backlight.pwm_state,
100);
diff --git a/drivers/input/misc/da7280.c b/drivers/input/misc/da7280.c
index b08610d6e575..409670be1d2b 100644
--- a/drivers/input/misc/da7280.c
+++ b/drivers/input/misc/da7280.c
@@ -333,7 +333,7 @@ static int da7280_haptic_set_pwm(struct da7280_haptic
*haptics, bool enabled)
return -EINVAL;
}
- pwm_get_state(haptics->pwm_dev, &state);
+ pwm_get_last_applied_state(haptics->pwm_dev, &state);
state.enabled = enabled;
if (enabled) {
period_mag_multi = (u64)state.period * haptics->gain;
diff --git a/drivers/input/misc/pwm-beeper.c b/drivers/input/misc/pwm-beeper.c
index d6b12477748a..4c5f09201ecf 100644
--- a/drivers/input/misc/pwm-beeper.c
+++ b/drivers/input/misc/pwm-beeper.c
@@ -33,7 +33,7 @@ static int pwm_beeper_on(struct pwm_beeper *beeper, unsigned
long period)
struct pwm_state state;
int error;
- pwm_get_state(beeper->pwm, &state);
+ pwm_get_last_applied_state(beeper->pwm, &stat
Re: [Intel-gfx] [PATCH] drm/i915/sysfs: convert snprintf to sysfs_emit
On Sun, 04 Apr 2021, Carlis wrote:
> From: Xuezhi Zhang
>
> Fix the following coccicheck warning:
> drivers/gpu/drm/i915//i915_sysfs.c:266:8-16:
> WARNING: use scnprintf or sprintf
> drivers/gpu/drm/i915//i915_sysfs.c:285:8-16:
> WARNING: use scnprintf or sprintf
> drivers/gpu/drm/i915//i915_sysfs.c:276:8-16:
> WARNING: use scnprintf or sprintf
> drivers/gpu/drm/i915//i915_sysfs.c:335:8-16:
> WARNING: use scnprintf or sprintf
> drivers/gpu/drm/i915//i915_sysfs.c:390:8-16:
> WARNING: use scnprintf or sprintf
> drivers/gpu/drm/i915//i915_sysfs.c:465:8-16:
> WARNING: use scnprintf or sprintf
> drivers/gpu/drm/i915//i915_sysfs.c:107:8-16:
> WARNING: use scnprintf or sprintf
> drivers/gpu/drm/i915//i915_sysfs.c:75:8-16:
> WARNING: use scnprintf or sprintf
> drivers/gpu/drm/i915//i915_sysfs.c:83:8-16:
> WARNING: use scnprintf or sprintf
> drivers/gpu/drm/i915//i915_sysfs.c:91:8-16:
> WARNING: use scnprintf or sprintf
> drivers/gpu/drm/i915//i915_sysfs.c:99:8-16:
> WARNING: use scnprintf or sprintf
> drivers/gpu/drm/i915//i915_sysfs.c:326:8-16:
> WARNING: use scnprintf or sprintf
>
> Signed-off-by: Xuezhi Zhang
Thanks for the patch, pushed to drm-intel-next.
BR,
Jani.
> ---
> drivers/gpu/drm/i915/i915_sysfs.c | 30 --
> 1 file changed, 12 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
> b/drivers/gpu/drm/i915/i915_sysfs.c
> index 45d32ef42787..4c6b5d52b5ca 100644
> --- a/drivers/gpu/drm/i915/i915_sysfs.c
> +++ b/drivers/gpu/drm/i915/i915_sysfs.c
> @@ -72,7 +72,7 @@ show_rc6_mask(struct device *kdev, struct device_attribute
> *attr, char *buf)
> if (HAS_RC6pp(dev_priv))
> mask |= BIT(2);
>
> - return snprintf(buf, PAGE_SIZE, "%x\n", mask);
> + return sysfs_emit(buf, "%x\n", mask);
> }
>
> static ssize_t
> @@ -80,7 +80,7 @@ show_rc6_ms(struct device *kdev, struct device_attribute
> *attr, char *buf)
> {
> struct drm_i915_private *dev_priv = kdev_minor_to_i915(kdev);
> u32 rc6_residency = calc_residency(dev_priv, GEN6_GT_GFX_RC6);
> - return snprintf(buf, PAGE_SIZE, "%u\n", rc6_residency);
> + return sysfs_emit(buf, "%u\n", rc6_residency);
> }
>
> static ssize_t
> @@ -88,7 +88,7 @@ show_rc6p_ms(struct device *kdev, struct device_attribute
> *attr, char *buf)
> {
> struct drm_i915_private *dev_priv = kdev_minor_to_i915(kdev);
> u32 rc6p_residency = calc_residency(dev_priv, GEN6_GT_GFX_RC6p);
> - return snprintf(buf, PAGE_SIZE, "%u\n", rc6p_residency);
> + return sysfs_emit(buf, "%u\n", rc6p_residency);
> }
>
> static ssize_t
> @@ -96,7 +96,7 @@ show_rc6pp_ms(struct device *kdev, struct device_attribute
> *attr, char *buf)
> {
> struct drm_i915_private *dev_priv = kdev_minor_to_i915(kdev);
> u32 rc6pp_residency = calc_residency(dev_priv, GEN6_GT_GFX_RC6pp);
> - return snprintf(buf, PAGE_SIZE, "%u\n", rc6pp_residency);
> + return sysfs_emit(buf, "%u\n", rc6pp_residency);
> }
>
> static ssize_t
> @@ -104,7 +104,7 @@ show_media_rc6_ms(struct device *kdev, struct
> device_attribute *attr, char *buf)
> {
> struct drm_i915_private *dev_priv = kdev_minor_to_i915(kdev);
> u32 rc6_residency = calc_residency(dev_priv, VLV_GT_MEDIA_RC6);
> - return snprintf(buf, PAGE_SIZE, "%u\n", rc6_residency);
> + return sysfs_emit(buf, "%u\n", rc6_residency);
> }
>
> static DEVICE_ATTR(rc6_enable, S_IRUGO, show_rc6_mask, NULL);
> @@ -263,8 +263,7 @@ static ssize_t gt_act_freq_mhz_show(struct device *kdev,
> struct drm_i915_private *i915 = kdev_minor_to_i915(kdev);
> struct intel_rps *rps = &i915->gt.rps;
>
> - return snprintf(buf, PAGE_SIZE, "%d\n",
> - intel_rps_read_actual_frequency(rps));
> + return sysfs_emit(buf, "%d\n", intel_rps_read_actual_frequency(rps));
> }
>
> static ssize_t gt_cur_freq_mhz_show(struct device *kdev,
> @@ -273,8 +272,7 @@ static ssize_t gt_cur_freq_mhz_show(struct device *kdev,
> struct drm_i915_private *i915 = kdev_minor_to_i915(kdev);
> struct intel_rps *rps = &i915->gt.rps;
>
> - return snprintf(buf, PAGE_SIZE, "%d\n",
> - intel_gpu_freq(rps, rps->cur_freq));
> + return sysfs_emit(buf, "%d\n", intel_gpu_freq(rps, rps->cur_freq));
> }
>
> static ssize_t gt_boost_freq_mhz_show(struct device *kdev, struct
> device_attribute *attr, char *buf)
> @@ -282,8 +280,7 @@ static ssize_t gt_boost_freq_mhz_show(struct device
> *kdev, struct device_attribu
> struct drm_i915_private *i915 = kdev_minor_to_i915(kdev);
> struct intel_rps *rps = &i915->gt.rps;
>
> - return snprintf(buf, PAGE_SIZE, "%d\n",
> - intel_gpu_freq(rps, rps->boost_freq));
> + return sysfs_emit(buf, "%d\n", intel_gpu_freq(rps, rps->boost_freq));
> }
>
> static ssize_t gt_boost_freq_mhz_store(struct device *kdev,
> @@ -323,8 +320,7 @@ static ssize_t vlv_rpe_freq_mhz_show(struct device *kdev,
> st
[Intel-gfx] ✗ Fi.CI.DOCS: warning for pwm: Rename pwm_get_state() to better reflect its semantic
== Series Details == Series: pwm: Rename pwm_get_state() to better reflect its semantic URL : https://patchwork.freedesktop.org/series/88759/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:102: warning: Function parameter or member 'ww' not described in 'i915_gem_shrink' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function parameter 'trampoline' description in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'jump_whitelist' not described in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'shadow_map' not described in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'batch_map' not described in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function parameter 'trampoline' description in 'intel_engine_cmd_parser' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for pwm: Rename pwm_get_state() to better reflect its semantic
== Series Details ==
Series: pwm: Rename pwm_get_state() to better reflect its semantic
URL : https://patchwork.freedesktop.org/series/88759/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9928 -> Patchwork_19895
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19895/index.html
Known issues
Here are the changes found in Patchwork_19895 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@semaphore:
- fi-bdw-5557u: NOTRUN -> [SKIP][1] ([fdo#109271]) +27 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19895/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html
* igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u: NOTRUN -> [WARN][2] ([i915#2283])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19895/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html
* igt@kms_chamelium@dp-crc-fast:
- fi-bdw-5557u: NOTRUN -> [SKIP][3] ([fdo#109271] / [fdo#111827]) +8
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19895/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html
* igt@vgem_basic@setversion:
- fi-tgl-y: [PASS][4] -> [DMESG-WARN][5] ([i915#402]) +1 similar
issue
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9928/fi-tgl-y/igt@vgem_ba...@setversion.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19895/fi-tgl-y/igt@vgem_ba...@setversion.html
Possible fixes
* igt@prime_self_import@basic-with_one_bo_two_files:
- fi-tgl-y: [DMESG-WARN][6] ([i915#402]) -> [PASS][7] +1 similar
issue
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9928/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19895/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#2283]: https://gitlab.freedesktop.org/drm/intel/issues/2283
[i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
Participating hosts (45 -> 40)
--
Additional (1): fi-bdw-5557u
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-icl-y
fi-bdw-samus
Build changes
-
* Linux: CI_DRM_9928 -> Patchwork_19895
CI-20190529: 20190529
CI_DRM_9928: 39a8c358dcd5eaa8c6f8c81c69055d4f6574307c @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6056: 84e6a7e19ccc7fafc46f372e756cad9d4aa093f7 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_19895: 8e7dc086283dd54eedcc5df63004e88d33a44877 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
8e7dc086283d pwm: Rename pwm_get_state() to better reflect its semantic
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19895/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/hdcp: Fix uninitialized symbol 'msg_end'
== Series Details == Series: drm/i915/hdcp: Fix uninitialized symbol 'msg_end' URL : https://patchwork.freedesktop.org/series/88756/ State : success == Summary == CI Bug Log - changes from CI_DRM_9928_full -> Patchwork_19894_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_19894_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@clone: - shard-snb: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#1099]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19894/shard-snb6/igt@gem_ctx_persiste...@clone.html * igt@gem_eio@in-flight-contexts-10ms: - shard-tglb: [PASS][2] -> [TIMEOUT][3] ([i915#3063]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9928/shard-tglb6/igt@gem_...@in-flight-contexts-10ms.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19894/shard-tglb5/igt@gem_...@in-flight-contexts-10ms.html * igt@gem_eio@in-flight-contexts-immediate: - shard-skl: [PASS][4] -> [TIMEOUT][5] ([i915#3063]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9928/shard-skl3/igt@gem_...@in-flight-contexts-immediate.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19894/shard-skl10/igt@gem_...@in-flight-contexts-immediate.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-tglb: [PASS][6] -> [FAIL][7] ([i915#2842]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9928/shard-tglb2/igt@gem_exec_fair@basic-none-sh...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19894/shard-tglb3/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][8] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19894/shard-iclb4/igt@gem_exec_fair@basic-n...@vcs1.html - shard-kbl: [PASS][9] -> [FAIL][10] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9928/shard-kbl4/igt@gem_exec_fair@basic-n...@vcs1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19894/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-none@vecs0: - shard-glk: [PASS][11] -> [FAIL][12] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9928/shard-glk8/igt@gem_exec_fair@basic-n...@vecs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19894/shard-glk4/igt@gem_exec_fair@basic-n...@vecs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-kbl: [PASS][13] -> [SKIP][14] ([fdo#109271]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9928/shard-kbl2/igt@gem_exec_fair@basic-p...@rcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19894/shard-kbl1/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-iclb: [PASS][15] -> [FAIL][16] ([i915#2849]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9928/shard-iclb1/igt@gem_exec_fair@basic-throt...@rcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19894/shard-iclb8/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_reloc@basic-many-active@bcs0: - shard-apl: NOTRUN -> [FAIL][17] ([i915#2389]) +6 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19894/shard-apl6/igt@gem_exec_reloc@basic-many-act...@bcs0.html * igt@gem_exec_reloc@basic-wide-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][18] ([i915#2389]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19894/shard-iclb2/igt@gem_exec_reloc@basic-wide-act...@vcs1.html * igt@gem_exec_whisper@basic-contexts-all: - shard-glk: [PASS][19] -> [DMESG-WARN][20] ([i915#118] / [i915#95]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9928/shard-glk8/igt@gem_exec_whis...@basic-contexts-all.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19894/shard-glk4/igt@gem_exec_whis...@basic-contexts-all.html * igt@gem_huc_copy@huc-copy: - shard-skl: NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#2190]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19894/shard-skl5/igt@gem_huc_c...@huc-copy.html * igt@gem_mmap_gtt@big-copy-odd: - shard-skl: NOTRUN -> [FAIL][22] ([i915#307]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19894/shard-skl10/igt@gem_mmap_...@big-copy-odd.html * igt@gem_mmap_gtt@coherency: - shard-iclb: NOTRUN -> [SKIP][23] ([fdo#109292]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19894/shard-iclb2/igt@gem_mmap_...@coherency.html * igt@gem_mmap_gtt@cpuset-big-copy: - shard-glk: [PASS][24] -> [FAIL][25] ([i915#307]) [24]: https://intel-gfx-
[Intel-gfx] [PULL] drm-intel-gt-next
Hi Dave & Daniel,
Bit late PR due to Easter break.
Prep work for local memory support as requested. Hard hang
fix for Sandybridge. Sanitize dma-buf size on import and
avoid GPU reset if heartbeat callback runs before timeout.
The rest is mostly small fixes and code/checkpatch cleanups.
Regards, Joonas
***
drm-intel-gt-next-2021-04-06:
Driver Changes:
- Prepare for local/device memory support on DG1 by starting
to use it for kernel internal allocations: context, ring
and engine scratch (Matt A, CQ, Abdiel, Imre)
- Sandybridge fix to avoid hard hang on ring resume (Chris)
- Limit imported dma-buf size to int32 (Matt A)
- Double check heartbeat timeout before resetting (Chris)
- Use new tasklet API for execution list (Emil)
- Fix SPDX checkpats warnings (Chris)
- Fixes for various checkpatch warnings (Chris)
- Selftest improvements (Chris)
- Move the defer_request waiter active assertion to correct spot (Chris)
- Make local-memory probing a GT operation (Matt, Tvrtko)
- Protect against request freeing during cancellation on wedging (Chris)
- Retire unexpected starting state error dumping (Chris)
- Distinction of memory regions in debugging (Zbigniew)
- Always flush the submission queue on checking for idle (Chris)
- Consolidate 2big error check to helper (Matt)
- Decrease number of subplatform bits (Tvrtko)
- Remove unused internal request priority levels (Chris)
- Document the unused internal header bits in buddy allocator (Matt)
- Cleanup the region class/instance encoding (Matt)
The following changes since commit 06debd6e1b28029e6e77c41e59a162868f377897:
Merge tag 'drm-intel-next-2021-03-16' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2021-03-18 08:06:34
+1000)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-2021-04-06
for you to fetch changes up to 2da21daa7d93817fa82f703c29adfcb5eed7f77d:
drm/i915/gt: Always flush the submission queue on checking for idle
(2021-03-24 19:31:59 +0100)
Driver Changes:
- Prepare for local/device memory support on DG1 by starting
to use it for kernel internal allocations: context, ring
and engine scratch (Matt A, CQ, Abdiel, Imre)
- Sandybridge fix to avoid hard hang on ring resume (Chris)
- Limit imported dma-buf size to int32 (Matt A)
- Double check heartbeat timeout before resetting (Chris)
- Use new tasklet API for execution list (Emil)
- Fix SPDX checkpats warnings (Chris)
- Fixes for various checkpatch warnings (Chris)
- Selftest improvements (Chris)
- Move the defer_request waiter active assertion to correct spot (Chris)
- Make local-memory probing a GT operation (Matt, Tvrtko)
- Protect against request freeing during cancellation on wedging (Chris)
- Retire unexpected starting state error dumping (Chris)
- Distinction of memory regions in debugging (Zbigniew)
- Always flush the submission queue on checking for idle (Chris)
- Consolidate 2big error check to helper (Matt)
- Decrease number of subplatform bits (Tvrtko)
- Remove unused internal request priority levels (Chris)
- Document the unused internal header bits in buddy allocator (Matt)
- Cleanup the region class/instance encoding (Matt)
Abdiel Janulgue (1):
drm/i915: introduce mem->reserved
CQ Tang (1):
drm/i915: reserve stolen for LMEM region
Chris Wilson (22):
drm/i915: Strip out internal priorities
drm/i915: Remove I915_USER_PRIORITY_SHIFT
drm/i915/gt: Call stop_ring() from ring resume, again
drm/i915/gt: SPDX cleanup
drm/i915/gt: Add some missing blank lines after declaration
drm/i915/gt: Remove repeated words from comments
drm/i915/gt: Fixup misaligned function parameters
drm/i915/gt: Remove a bonus newline
drm/i915/gt: Wrap macro arg in ()
drm/i915/gt: Insert spaces into GEN3_L3LOG_SIZE/4
drm/i915/gt: Replace unnecessary ',' with '; '
drm/i915/gt: Add a space before '('
drm/i915/gt: Replace 'return' with a fall-through
drm/i915/selftests: Check for engine-reset errors in the middle of
workarounds
drm/i915/gt: Move the defer_request waiter active assertion
drm/i915: Protect against request freeing during cancellation on wedging
drm/i915/selftests: Use a single copy of the mocs table
drm/i915/gt: Retire unexpected starting state error dumping
drm/i915/selftests: Restore previous heartbeat interval
drm/i915/gt: Double check heartbeat timeout before resetting
drm/i915/selftest: Synchronise with the GPU timestamp
drm/i915/gt: Always flush the submission queue on checking for idle
Emil Renner Berthing (1):
drm/i915/gt: use new tasklet API for execution list
Imre Deak (1):
drm/i915/dg1: Reserve first 1MB of local memory
Matthew Auld (11):
drm/i915/gem: don't trust the dma_buf->size
drm/i915/gem: consolid
Re: [Intel-gfx] [PATCH 1/2] drm/i915/display/vlv_dsi: Do not skip panel_pwr_cycle_delay when disabling the panel
Hi,
On 3/25/21 12:48 PM, Hans de Goede wrote:
> After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down
> displays gracefully on reboot"), the DSI panel on a Cherry Trail based
> Predia Basic tablet would no longer properly light up after reboot.
>
> I've managed to reproduce this without rebooting by doing:
> chvt 3; echo 1 > /sys/class/graphics/fb0/blank;\
> echo 0 > /sys/class/graphics/fb0/blank
>
> Which rapidly turns the panel off and back on again.
>
> The vlv_dsi.c code uses an intel_dsi_msleep() helper for the various delays
> used for panel on/off, since starting with MIPI-sequences version >= 3 the
> delays are already included inside the MIPI-sequences.
>
> The problems exposed by the "Shut down displays gracefully on reboot"
> change, show that using this helper for the panel_pwr_cycle_delay is
> not the right thing to do. This has not been noticed until now because
> normally the panel never is cycled off and directly on again in quick
> succession.
>
> Change the msleep for the panel_pwr_cycle_delay to a normal msleep()
> call to avoid the panel staying black after a quick off + on cycle.
>
> Cc: Ville Syrjälä
> Fixes: fe0f1e3bfdfe ("drm/i915: Shut down displays gracefully on reboot")
> Signed-off-by: Hans de Goede
Ping? Ville AFAICT this is ready for merging, can you review this please so
that I can push it to drm-intel-next ?
Regards,
Hans
> ---
> drivers/gpu/drm/i915/display/vlv_dsi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c
> b/drivers/gpu/drm/i915/display/vlv_dsi.c
> index d5a3f69c5df3..38d5a1f3ded5 100644
> --- a/drivers/gpu/drm/i915/display/vlv_dsi.c
> +++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
> @@ -996,14 +996,14 @@ static void intel_dsi_post_disable(struct
> intel_atomic_state *state,
>* FIXME As we do with eDP, just make a note of the time here
>* and perform the wait before the next panel power on.
>*/
> - intel_dsi_msleep(intel_dsi, intel_dsi->panel_pwr_cycle_delay);
> + msleep(intel_dsi->panel_pwr_cycle_delay);
> }
>
> static void intel_dsi_shutdown(struct intel_encoder *encoder)
> {
> struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
>
> - intel_dsi_msleep(intel_dsi, intel_dsi->panel_pwr_cycle_delay);
> + msleep(intel_dsi->panel_pwr_cycle_delay);
> }
>
> static bool intel_dsi_get_hw_state(struct intel_encoder *encoder,
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for pwm: Rename pwm_get_state() to better reflect its semantic
== Series Details == Series: pwm: Rename pwm_get_state() to better reflect its semantic URL : https://patchwork.freedesktop.org/series/88759/ State : success == Summary == CI Bug Log - changes from CI_DRM_9928_full -> Patchwork_19895_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_19895_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@psr2: - shard-iclb: NOTRUN -> [SKIP][1] ([i915#658]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19895/shard-iclb5/igt@feature_discov...@psr2.html * igt@gem_ctx_isolation@preservation-s3@vcs0: - shard-apl: NOTRUN -> [DMESG-WARN][2] ([i915#180]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19895/shard-apl1/igt@gem_ctx_isolation@preservation...@vcs0.html * igt@gem_ctx_persistence@legacy-engines-hang@render: - shard-iclb: [PASS][3] -> [FAIL][4] ([i915#2410]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9928/shard-iclb3/igt@gem_ctx_persistence@legacy-engines-h...@render.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19895/shard-iclb8/igt@gem_ctx_persistence@legacy-engines-h...@render.html * igt@gem_ctx_persistence@smoketest: - shard-snb: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19895/shard-snb2/igt@gem_ctx_persiste...@smoketest.html * igt@gem_exec_capture@pi@rcs0: - shard-skl: [PASS][6] -> [INCOMPLETE][7] ([i915#2369]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9928/shard-skl1/igt@gem_exec_capture@p...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19895/shard-skl6/igt@gem_exec_capture@p...@rcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][8] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19895/shard-iclb2/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-kbl: [PASS][9] -> [FAIL][10] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9928/shard-kbl2/igt@gem_exec_fair@basic-pace-s...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19895/shard-kbl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9928/shard-tglb6/igt@gem_exec_fair@basic-p...@vcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19895/shard-tglb7/igt@gem_exec_fair@basic-p...@vcs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-iclb: [PASS][13] -> [FAIL][14] ([i915#2842]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9928/shard-iclb1/igt@gem_exec_fair@basic-throt...@rcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19895/shard-iclb8/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_reloc@basic-wide-active@bcs0: - shard-apl: NOTRUN -> [FAIL][15] ([i915#2389]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19895/shard-apl1/igt@gem_exec_reloc@basic-wide-act...@bcs0.html * igt@gem_exec_reloc@basic-wide-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][16] ([i915#2389]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19895/shard-iclb1/igt@gem_exec_reloc@basic-wide-act...@vcs1.html * igt@gem_huc_copy@huc-copy: - shard-skl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#2190]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19895/shard-skl9/igt@gem_huc_c...@huc-copy.html * igt@gem_mmap_gtt@coherency: - shard-iclb: NOTRUN -> [SKIP][18] ([fdo#109292]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19895/shard-iclb5/igt@gem_mmap_...@coherency.html * igt@gem_pwrite@basic-exhaustion: - shard-snb: NOTRUN -> [WARN][19] ([i915#2658]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19895/shard-snb2/igt@gem_pwr...@basic-exhaustion.html * igt@gem_userptr_blits@process-exit-mmap@wb: - shard-apl: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#1699]) +7 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19895/shard-apl1/igt@gem_userptr_blits@process-exit-m...@wb.html * igt@gem_userptr_blits@set-cache-level: - shard-apl: NOTRUN -> [FAIL][21] ([i915#3324]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19895/shard-apl2/igt@gem_userptr_bl...@set-cache-level.html * igt@gem_userptr_blits@unsync-unmap-after-close: - shard-iclb: NOTRUN -> [SKIP][22] ([i915#3297]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19895/shard-iclb5/igt@gem_userptr_bl...@
Re: [Intel-gfx] [PATCH] drm/i915/dpcd_bl: Don't try vesa interface unless specified by VBT
On Tue, 23 Mar 2021, Lyude Paul wrote:
> On Tue, 2021-03-23 at 16:06 +0200, Jani Nikula wrote:
>> On Thu, 18 Mar 2021, Lyude Paul wrote:
>> > Actually-NAK this. I just realized I've been misreading the bug and that
>> > this
>> > doesn't actually seem to be fixed. Will resend once I figure out what's
>> > going on
>>
>> Well, I think there are actually multiple issues on multiple
>> machines. This fixes the issue on ThinkPad X1 Titanium Gen1 [1].
>>
>> I suspect reverting 98e497e203a5 ("drm/i915/dpcd_bl: uncheck PWM_PIN_CAP
>> when detect eDP backlight capabilities") would too. But then that would
>> break *other* machines that claim support for *both* eDP PWM pin and
>> DPCD backlight control, I think.
>>
>> I think there are issues with how we try setup DPCD backlight if the GOP
>> has set up PWM backlight. For example, we don't set the backlight
>> control mode correctly until the next disable/enable sequence. However,
>> I tried to fix this, and I think I was doing all the right things, and
>> DPCD reads seemed to confirm this, yet I was not able to control
>> brightness using DPCD. I don't know what gives, but I do know eDP PWM
>> pin control works.
>
> Should we go ahead and push the VESA fix for this then? If you're willing to
> test future patches on that machine, we could give another shot at enabling
> this
> in the future if we find reason to.
Yes, let's go with this first.
Reviewed-by: Jani Nikula
>
>>
>>
>> BR,
>> Jani.
>>
>>
>> [1] https://gitlab.freedesktop.org/drm/intel/-/issues/3158
>>
>>
>> >
>> > On Thu, 2021-03-18 at 13:02 -0400, Lyude Paul wrote:
>> > > Looks like that there actually are another subset of laptops on the
>> > > market
>> > > that don't support the Intel HDR backlight interface, but do advertise
>> > > support for the VESA DPCD backlight interface despite the fact it doesn't
>> > > seem to work.
>> > >
>> > > Note though I'm not entirely clear on this - on one of the machines where
>> > > this issue was observed, I also noticed that we appeared to be rejecting
>> > > the VBT defined backlight frequency in
>> > > intel_dp_aux_vesa_calc_max_backlight(). It's noted in this function that:
>> > >
>> > > /* Use highest possible value of Pn for more granularity of brightness
>> > > * adjustment while satifying the conditions below.
>> > > * ...
>> > > * - FxP is within 25% of desired value.
>> > > * Note: 25% is arbitrary value and may need some tweak.
>> > > */
>> > >
>> > > So it's possible that this value might just need to be tweaked, but for
>> > > now
>> > > let's just disable the VESA backlight interface unless it's specified in
>> > > the VBT just to be safe. We might be able to try enabling this again by
>> > > default in the future.
>> > >
>> > > Fixes: 2227816e647a ("drm/i915/dp: Allow forcing specific interfaces
>> > > through
>> > > enable_dpcd_backlight")
>> > > Cc: Jani Nikula
>> > > Cc: Rodrigo Vivi
>> > > Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/3169
>> > > Signed-off-by: Lyude Paul
>> > > ---
>> > > drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 1 -
>> > > 1 file changed, 1 deletion(-)
>> > >
>> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> > > index 651884390137..4f8337c7fd2e 100644
>> > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> > > @@ -646,7 +646,6 @@ int intel_dp_aux_init_backlight_funcs(struct
>> > > intel_connector *connector)
>> > > break;
>> > > case INTEL_BACKLIGHT_DISPLAY_DDI:
>> > > try_intel_interface = true;
>> > > - try_vesa_interface = true;
>> > > break;
>> > > default:
>> > > return -ENODEV;
>>
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] vfio/pci: Add support for opregion v2.1+
On Fri, 26 Mar 2021 01:09:53 +0800 Fred Gao wrote: > Before opregion version 2.0 VBT data is stored in opregion mailbox #4, > but when VBT data exceeds 6KB size and cannot be within mailbox #4 > then from opregion v2.0+, Extended VBT region, next to opregion is > used to hold the VBT data, so the total size will be opregion size plus > extended VBT region size. > > Since opregion v2.0 with physical host VBT address would not be > practically available for end user and guest can not directly access > host physical address, so it is not supported. > > Cc: Zhenyu Wang > Signed-off-by: Swee Yee Fonn > Signed-off-by: Fred Gao > --- > drivers/vfio/pci/vfio_pci_igd.c | 53 + > 1 file changed, 53 insertions(+) Applied to vfio next branch for v5.13. Thanks, Alex ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] pwm: Rename pwm_get_state() to better reflect its semantic
Hello Thierry, On Tue, Apr 06, 2021 at 01:16:31PM +0200, Thierry Reding wrote: > On Tue, Apr 06, 2021 at 09:30:36AM +0200, Uwe Kleine-König wrote: > > Given that lowlevel drivers usually cannot implement exactly what a > > consumer requests with pwm_apply_state() there is some rounding involved. > > > > pwm_get_state() traditionally returned the setting that was requested most > > recently by the consumer (opposed to what was actually implemented in > > hardware in reply to the last request). To make this semantic obvious > > rename the function. > > > > Signed-off-by: Uwe Kleine-König > > --- > > Documentation/driver-api/pwm.rst | 6 +++- > > drivers/clk/clk-pwm.c | 2 +- > > drivers/gpu/drm/i915/display/intel_panel.c | 4 +-- > > drivers/input/misc/da7280.c| 2 +- > > drivers/input/misc/pwm-beeper.c| 2 +- > > drivers/input/misc/pwm-vibra.c | 4 +-- > > drivers/pwm/core.c | 4 +-- > > drivers/pwm/pwm-atmel-hlcdc.c | 2 +- > > drivers/pwm/pwm-atmel.c| 2 +- > > drivers/pwm/pwm-imx27.c| 2 +- > > drivers/pwm/pwm-rockchip.c | 2 +- > > drivers/pwm/pwm-stm32-lp.c | 4 +-- > > drivers/pwm/pwm-sun4i.c| 2 +- > > drivers/pwm/sysfs.c| 18 ++-- > > drivers/regulator/pwm-regulator.c | 4 +-- > > drivers/video/backlight/pwm_bl.c | 10 +++ > > include/linux/pwm.h| 34 ++ > > 17 files changed, 59 insertions(+), 45 deletions(-) > > Honestly, I don't think this is worth the churn. If you think people > will easily get confused by this then a better solution might be to more > explicitly document the pwm_get_state() function to say exactly what it > returns. I'm not so optimistic that people become aware of the semantic just because there is documentation describing it and I strongly believe that a good name for functions is more important than accurate documentation. If you don't agree, what do you think about the updated wording in Documentation/driver-api/pwm.rst? > But there's no need to make life difficult for everyone by > renaming this to something as cumbersome as this. I don't expect any merge conflicts (and if still a problem occurs resolving should be trivial enough). So I obviously don't agree to your weighing. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 18/18] vfio/mdev: Correct the function signatures for the mdev_type_attributes
On Tue, Mar 23, 2021 at 08:31:03PM +0100, Christoph Hellwig wrote: > > - type = intel_gvt_find_vgpu_type(gvt, mtype_get_type_group_id(kobj)); > > + type = intel_gvt_find_vgpu_type(gvt, mtype_get_type_group_id(mtype)); > > Somewhere in this series you should probably switch > intel_gvt_find_vgpu_type to only get the mtype, as it can trivially > deduct the gvt from it (which also seems to have lost its type > somewhere..) I look at just this minor change for a bit and it just is a mess. This only exists like this because the gvt_type_attrs[] are in the wrong file and I already tried to fix that and gave up. Deleting the intel_gvt_ops looks like precondition to do any big improvement in here :\ Jason ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 00/18] Make vfio_mdev type safe
vfio_mdev has a number of different objects: mdev_parent, mdev_type and mdev_device. Unfortunately the types of these have been erased in various places throughout the API, and this makes it very hard to understand this code or maintain it by the time it reaches all of the drivers. This series puts in all the types and aligns some of the design with the driver core standard for a driver core bus driver: - Replace 'struct device *' with 'struct mdev_device * - Replace 'struct device *' with 'struct mdev_type *' and mtype_get_parent_dev() - Replace 'struct kobject *' with 'struct mdev_type *' Now that types are clear it is easy to spot a few places that have duplicated information. More significantly we can now understand how to directly fix the obfuscated 'kobj->name' matching by realizing the the kobj is a mdev_type, which is linked to the supported_types_list provided by the driver, and thus the core code can directly return the array indexes all the drivers actually want. v2: - Use a mdev_type local in mdev_create_sysfs_files - Rename the goto unwind labels in mdev_device_free() - Reorder patches, annotate reviewed-by's thanks all v1: https://lore.kernel.org/r/0-v1-7dedf20b2b75+4f785-vfio2_...@nvidia.com Jason Gunthorpe (18): vfio/mdev: Fix missing static's on MDEV_TYPE_ATTR's vfio/mdev: Do not allow a mdev_type to have a NULL parent pointer vfio/mdev: Add missing typesafety around mdev_device vfio/mdev: Simplify driver registration vfio/mdev: Use struct mdev_type in struct mdev_device vfio/mdev: Expose mdev_get/put_parent to mdev_private.h vfio/mdev: Add missing reference counting to mdev_type vfio/mdev: Reorganize mdev_device_create() vfio/mdev: Add missing error handling to dev_set_name() vfio/mdev: Remove duplicate storage of parent in mdev_device vfio/mdev: Add mdev/mtype_get_type_group_id() vfio/mtty: Use mdev_get_type_group_id() vfio/mdpy: Use mdev_get_type_group_id() vfio/mbochs: Use mdev_get_type_group_id() vfio/gvt: Make DRM_I915_GVT depend on VFIO_MDEV vfio/gvt: Use mdev_get_type_group_id() vfio/mdev: Remove kobj from mdev_parent_ops->create() vfio/mdev: Correct the function signatures for the mdev_type_attributes .../driver-api/vfio-mediated-device.rst | 9 +- drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/i915/gvt/gvt.c| 41 ++--- drivers/gpu/drm/i915/gvt/gvt.h| 4 +- drivers/gpu/drm/i915/gvt/kvmgt.c | 7 +- drivers/s390/cio/vfio_ccw_ops.c | 17 +- drivers/s390/crypto/vfio_ap_ops.c | 14 +- drivers/vfio/mdev/mdev_core.c | 174 +++--- drivers/vfio/mdev/mdev_driver.c | 19 +- drivers/vfio/mdev/mdev_private.h | 40 ++-- drivers/vfio/mdev/mdev_sysfs.c| 59 +++--- drivers/vfio/mdev/vfio_mdev.c | 29 +-- drivers/vfio/vfio_iommu_type1.c | 25 +-- include/linux/mdev.h | 80 +--- samples/vfio-mdev/mbochs.c| 55 +++--- samples/vfio-mdev/mdpy.c | 56 +++--- samples/vfio-mdev/mtty.c | 66 ++- 17 files changed, 313 insertions(+), 383 deletions(-) -- 2.31.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 16/18] vfio/gvt: Use mdev_get_type_group_id()
intel_gvt_init_vgpu_type_groups() makes gvt->types 1:1 with the
supported_type_groups array, so the type_group_id is also the index into
gvt->types. Use it directly and remove the string matching.
Reviewed-by: Kevin Tian
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/gvt.c | 24 +++-
drivers/gpu/drm/i915/gvt/gvt.h | 4 ++--
drivers/gpu/drm/i915/gvt/kvmgt.c | 5 ++---
3 files changed, 11 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
index d1d8ee4a5f16a3..4b47a18e9dfa0f 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -46,22 +46,12 @@ static const char * const supported_hypervisors[] = {
[INTEL_GVT_HYPERVISOR_KVM] = "KVM",
};
-static struct intel_vgpu_type *intel_gvt_find_vgpu_type(struct intel_gvt *gvt,
- const char *name)
+static struct intel_vgpu_type *
+intel_gvt_find_vgpu_type(struct intel_gvt *gvt, unsigned int type_group_id)
{
- const char *driver_name =
- dev_driver_string(&gvt->gt->i915->drm.pdev->dev);
- int i;
-
- name += strlen(driver_name) + 1;
- for (i = 0; i < gvt->num_types; i++) {
- struct intel_vgpu_type *t = &gvt->types[i];
-
- if (!strncmp(t->name, name, sizeof(t->name)))
- return t;
- }
-
- return NULL;
+ if (WARN_ON(type_group_id >= gvt->num_types))
+ return NULL;
+ return &gvt->types[type_group_id];
}
static ssize_t available_instances_show(struct kobject *kobj,
@@ -71,7 +61,7 @@ static ssize_t available_instances_show(struct kobject *kobj,
unsigned int num = 0;
void *gvt = kdev_to_i915(dev)->gvt;
- type = intel_gvt_find_vgpu_type(gvt, kobject_name(kobj));
+ type = intel_gvt_find_vgpu_type(gvt, mtype_get_type_group_id(kobj));
if (!type)
num = 0;
else
@@ -92,7 +82,7 @@ static ssize_t description_show(struct kobject *kobj, struct
device *dev,
struct intel_vgpu_type *type;
void *gvt = kdev_to_i915(dev)->gvt;
- type = intel_gvt_find_vgpu_type(gvt, kobject_name(kobj));
+ type = intel_gvt_find_vgpu_type(gvt, mtype_get_type_group_id(kobj));
if (!type)
return 0;
diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
index 03c993d68f105a..0cf480f42850d2 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.h
+++ b/drivers/gpu/drm/i915/gvt/gvt.h
@@ -569,8 +569,8 @@ struct intel_gvt_ops {
void (*vgpu_reset)(struct intel_vgpu *);
void (*vgpu_activate)(struct intel_vgpu *);
void (*vgpu_deactivate)(struct intel_vgpu *);
- struct intel_vgpu_type *(*gvt_find_vgpu_type)(struct intel_gvt *gvt,
- const char *name);
+ struct intel_vgpu_type *(*gvt_find_vgpu_type)(
+ struct intel_gvt *gvt, unsigned int type_group_id);
bool (*get_gvt_attrs)(struct attribute_group ***intel_vgpu_type_groups);
int (*vgpu_query_plane)(struct intel_vgpu *vgpu, void *);
int (*vgpu_get_dmabuf)(struct intel_vgpu *vgpu, unsigned int);
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index b4348256ae9591..16e1e4a38aa1f6 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -700,10 +700,9 @@ static int intel_vgpu_create(struct kobject *kobj, struct
mdev_device *mdev)
pdev = mdev_parent_dev(mdev);
gvt = kdev_to_i915(pdev)->gvt;
- type = intel_gvt_ops->gvt_find_vgpu_type(gvt, kobject_name(kobj));
+ type = intel_gvt_ops->gvt_find_vgpu_type(gvt,
+mdev_get_type_group_id(mdev));
if (!type) {
- gvt_vgpu_err("failed to find type %s to create\n",
- kobject_name(kobj));
ret = -EINVAL;
goto out;
}
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 18/18] vfio/mdev: Correct the function signatures for the mdev_type_attributes
The driver core standard is to pass in the properly typed object, the
properly typed attribute and the buffer data. It stems from the root
kobject method:
ssize_t (*show)(struct kobject *kobj, struct kobj_attribute *attr,..)
Each subclass of kobject should provide their own function with the same
signature but more specific types, eg struct device uses:
ssize_t (*show)(struct device *dev, struct device_attribute *attr,..)
In this case the existing signature is:
ssize_t (*show)(struct kobject *kobj, struct device *dev,..)
Where kobj is a 'struct mdev_type *' and dev is 'mdev_type->parent->dev'.
Change the mdev_type related sysfs attribute functions to:
ssize_t (*show)(struct mdev_type *mtype, struct mdev_type_attribute *attr,..)
In order to restore type safety and match the driver core standard
There are no current users of 'attr', but if it is ever needed it would be
hard to add in retroactively, so do it now.
Reviewed-by: Kevin Tian
Reviewed-by: Cornelia Huck
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/gvt.c| 21 +++--
drivers/s390/cio/vfio_ccw_ops.c | 15 +--
drivers/s390/crypto/vfio_ap_ops.c | 12 +++-
drivers/vfio/mdev/mdev_core.c | 14 --
drivers/vfio/mdev/mdev_sysfs.c| 11 ++-
include/linux/mdev.h | 11 +++
samples/vfio-mdev/mbochs.c| 26 +++---
samples/vfio-mdev/mdpy.c | 24 ++--
samples/vfio-mdev/mtty.c | 18 +-
9 files changed, 90 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
index 4b47a18e9dfa0f..3703814a669b46 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -54,14 +54,15 @@ intel_gvt_find_vgpu_type(struct intel_gvt *gvt, unsigned
int type_group_id)
return &gvt->types[type_group_id];
}
-static ssize_t available_instances_show(struct kobject *kobj,
- struct device *dev, char *buf)
+static ssize_t available_instances_show(struct mdev_type *mtype,
+ struct mdev_type_attribute *attr,
+ char *buf)
{
struct intel_vgpu_type *type;
unsigned int num = 0;
- void *gvt = kdev_to_i915(dev)->gvt;
+ void *gvt = kdev_to_i915(mtype_get_parent_dev(mtype))->gvt;
- type = intel_gvt_find_vgpu_type(gvt, mtype_get_type_group_id(kobj));
+ type = intel_gvt_find_vgpu_type(gvt, mtype_get_type_group_id(mtype));
if (!type)
num = 0;
else
@@ -70,19 +71,19 @@ static ssize_t available_instances_show(struct kobject
*kobj,
return sprintf(buf, "%u\n", num);
}
-static ssize_t device_api_show(struct kobject *kobj, struct device *dev,
- char *buf)
+static ssize_t device_api_show(struct mdev_type *mtype,
+ struct mdev_type_attribute *attr, char *buf)
{
return sprintf(buf, "%s\n", VFIO_DEVICE_API_PCI_STRING);
}
-static ssize_t description_show(struct kobject *kobj, struct device *dev,
- char *buf)
+static ssize_t description_show(struct mdev_type *mtype,
+ struct mdev_type_attribute *attr, char *buf)
{
struct intel_vgpu_type *type;
- void *gvt = kdev_to_i915(dev)->gvt;
+ void *gvt = kdev_to_i915(mtype_get_parent_dev(mtype))->gvt;
- type = intel_gvt_find_vgpu_type(gvt, mtype_get_type_group_id(kobj));
+ type = intel_gvt_find_vgpu_type(gvt, mtype_get_type_group_id(mtype));
if (!type)
return 0;
diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
index 10407cf67583c6..491a64c61fff1a 100644
--- a/drivers/s390/cio/vfio_ccw_ops.c
+++ b/drivers/s390/cio/vfio_ccw_ops.c
@@ -71,23 +71,26 @@ static int vfio_ccw_mdev_notifier(struct notifier_block *nb,
return NOTIFY_DONE;
}
-static ssize_t name_show(struct kobject *kobj, struct device *dev, char *buf)
+static ssize_t name_show(struct mdev_type *mtype,
+struct mdev_type_attribute *attr, char *buf)
{
return sprintf(buf, "I/O subchannel (Non-QDIO)\n");
}
static MDEV_TYPE_ATTR_RO(name);
-static ssize_t device_api_show(struct kobject *kobj, struct device *dev,
- char *buf)
+static ssize_t device_api_show(struct mdev_type *mtype,
+ struct mdev_type_attribute *attr, char *buf)
{
return sprintf(buf, "%s\n", VFIO_DEVICE_API_CCW_STRING);
}
static MDEV_TYPE_ATTR_RO(device_api);
-static ssize_t available_instances_show(struct kobject *kobj,
- struct device *dev, char *buf)
+static ssize_t available_instances_show(struct mdev_type *mtype,
+ struct mdev_type_attribute *attr,
+
[Intel-gfx] [PATCH v2 15/18] vfio/gvt: Make DRM_I915_GVT depend on VFIO_MDEV
At some point there may have been some reason for this weird split in this driver, but today only the VFIO side is actually implemented. However, it got messed up at some point and mdev code was put in gvt.c and is pretending to be "generic" by masquerading as some generic attribute list: static MDEV_TYPE_ATTR_RO(description); But MDEV_TYPE attributes are only usable with mdev_device, nothing else. Ideally all of this would be moved to kvmgt.c, but it is entangled with the rest of the "generic" code in an odd way. Thus put in a kconfig dependency so we don't get randconfig failures when the next patch creates a link time dependency related to the use of MDEV_TYPE. Reviewed-by: Kevin Tian Reviewed-by: Christoph Hellwig Signed-off-by: Jason Gunthorpe --- drivers/gpu/drm/i915/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index 1e1cb245fca778..483e9ff8ca1d23 100644 --- a/drivers/gpu/drm/i915/Kconfig +++ b/drivers/gpu/drm/i915/Kconfig @@ -101,6 +101,7 @@ config DRM_I915_GVT bool "Enable Intel GVT-g graphics virtualization host support" depends on DRM_I915 depends on 64BIT + depends on VFIO_MDEV default n help Choose this option if you want to enable Intel GVT-g graphics -- 2.31.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] pwm: Rename pwm_get_state() to better reflect its semantic
On Tue, 06 Apr 2021, Uwe Kleine-König wrote: > Given that lowlevel drivers usually cannot implement exactly what a > consumer requests with pwm_apply_state() there is some > rounding involved. > > pwm_get_state() traditionally returned the setting that was requested > most recently by the consumer (opposed to what was > actually implemented in hardware in reply to the last request). > To make this semantic obvious rename the function. > > Signed-off-by: Uwe Kleine-König > --- > drivers/input/misc/da7280.c| 2 +- Acked-by: Roy Im ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] ACPI: utils: Add acpi_reduced_hardware() helper
Add a getter for the acpi_gbl_reduced_hardware variable so that modules
can check if they are running on an ACPI reduced-hw platform or not.
Signed-off-by: Hans de Goede
---
drivers/acpi/utils.c| 11 +++
include/acpi/acpi_bus.h | 1 +
include/linux/acpi.h| 5 +
3 files changed, 17 insertions(+)
diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c
index 682edd913b3b..4cb061d3169a 100644
--- a/drivers/acpi/utils.c
+++ b/drivers/acpi/utils.c
@@ -872,6 +872,17 @@ acpi_dev_get_first_match_dev(const char *hid, const char
*uid, s64 hrv)
}
EXPORT_SYMBOL(acpi_dev_get_first_match_dev);
+/**
+ * acpi_reduced_hardware - Return if this is an ACPI-reduced-hw machine
+ *
+ * Return true when running on an ACPI-reduced-hw machine, false otherwise.
+ */
+bool acpi_reduced_hardware(void)
+{
+ return acpi_gbl_reduced_hardware;
+}
+EXPORT_SYMBOL(acpi_reduced_hardware);
+
/*
* acpi_backlight= handling, this is done here rather then in video_detect.c
* because __setup cannot be used in modules.
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index f28b097c658f..d631cb52283e 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -78,6 +78,7 @@ acpi_evaluate_dsm_typed(acpi_handle handle, const guid_t
*guid, u64 rev,
bool acpi_dev_found(const char *hid);
bool acpi_dev_present(const char *hid, const char *uid, s64 hrv);
+bool acpi_reduced_hardware(void);
#ifdef CONFIG_ACPI
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 3bdcfc4401b7..e2e6db8313c8 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -748,6 +748,11 @@ acpi_dev_get_first_match_dev(const char *hid, const char
*uid, s64 hrv)
return NULL;
}
+static inline bool acpi_reduced_hardware(void)
+{
+ return false;
+}
+
static inline void acpi_dev_put(struct acpi_device *adev) {}
static inline bool is_acpi_node(const struct fwnode_handle *fwnode)
--
2.30.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] ACPI: video: Check LCD flag on ACPI-reduced-hardware devices
Starting with Windows 8, Windows no longer uses the ACPI-video interface
for backlight control by default. Instead backlight control is left up
to the GPU drivers and these are typically directly accessing the GPU
for this instead of going through ACPI.
This means that the ACPI video interface is no longer being tested by
many vendors, which leads to false-positive /sys/class/backlight entries
on devices which don't have a backlight at all such as desktops or
top-set boxes. These false-positives causes desktop environments to show
a non functional brightness slider in various places.
Checking the LCD flag greatly reduces the amount of false-positives,
so commit 5928c281524f ("ACPI / video: Default lcd_only to true on
Win8-ready and newer machines") enabled the checking of this flag
by default on all win8 BIOS-es. But this let to regressions on some
models, so the check was made stricter adding a DMI chassis-type check
to only enable the LCD flag checking on desktop/server chassis.
Unfortunately the chassis-type reported in the DMI strings is not always
reliable. One class of devices where this is a problem is Intel Bay Trail-T
based top-set boxes / mini PCs / HDMI sticks. These are based on reference
designs which were targetets and the reference design BIOS code
is often used without changing the chassis-type to something more
appropriate.
There are many, many Bay Trail-T based devices affected by this, so DMI
quirking our way out of this is a bad idea. This patch takes a different
approach, Bay Trail-T (unlike regular Bay Trail) is an ACPI-reduced-hw
platform and ACPI-reduced-hw platforms generally don't have
an embedded-controller and thus will use a native (GPU specific) backlight
interface. This patch enables Checking the LCD flag by default on
ACPI-reduced-hw platforms with a win8 BIOS independent of the reported
chassis-type, fixing the false positive /sys/class/backlight entries
on these devices.
Note in hindsight I should have never added the DMI chassis-type check
when the enabling of LCD flag checking on Windows 8 BIOS-es let to some
regressions. Instead I should have added DMI quirks for the (presumably
few) models where the LCD flag check let to issues. But I'm afraid that
it is too late to change this now, changing this now will likely lead to
a bunch of regressions.
This patch was tested on a Mele PCG03 mini PC.
Signed-off-by: Hans de Goede
---
drivers/acpi/acpi_video.c | 39 ++-
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
index 2ea1781290cc..ade02152bb06 100644
--- a/drivers/acpi/acpi_video.c
+++ b/drivers/acpi/acpi_video.c
@@ -2182,6 +2182,30 @@ static bool dmi_is_desktop(void)
return false;
}
+/*
+ * We're seeing a lot of bogus backlight interfaces on newer machines
+ * without a LCD such as desktops, servers and HDMI sticks. Checking the
+ * lcd flag fixes this, enable this by default on any machines which are:
+ * 1. Win8 ready (where we also prefer the native backlight driver, so
+ * normally the acpi_video code should not register there anyways); *and*
+ * 2.1 Report a desktop/server DMI chassis-type, or
+ * 2.2 Are an ACPI-reduced-hardware platform (and thus won't use the EC for
+ backlight control)
+ */
+static bool should_check_lcd_flag(void)
+{
+ if (!acpi_osi_is_win8())
+ return false;
+
+ if (dmi_is_desktop())
+ return true;
+
+ if (acpi_reduced_hardware())
+ return true;
+
+ return false;
+}
+
int acpi_video_register(void)
{
int ret = 0;
@@ -2195,19 +2219,8 @@ int acpi_video_register(void)
goto leave;
}
- /*
-* We're seeing a lot of bogus backlight interfaces on newer machines
-* without a LCD such as desktops, servers and HDMI sticks. Checking
-* the lcd flag fixes this, so enable this on any machines which are
-* win8 ready (where we also prefer the native backlight driver, so
-* normally the acpi_video code should not register there anyways).
-*/
- if (only_lcd == -1) {
- if (dmi_is_desktop() && acpi_osi_is_win8())
- only_lcd = true;
- else
- only_lcd = false;
- }
+ if (only_lcd == -1)
+ only_lcd = should_check_lcd_flag();
dmi_check_system(video_dmi_table);
--
2.30.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] ACPI: utils: Add acpi_reduced_hardware() helper
== Series Details == Series: series starting with [1/2] ACPI: utils: Add acpi_reduced_hardware() helper URL : https://patchwork.freedesktop.org/series/88779/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1
[Intel-gfx] ✗ Fi.CI.DOCS: warning for series starting with [1/2] ACPI: utils: Add acpi_reduced_hardware() helper
== Series Details == Series: series starting with [1/2] ACPI: utils: Add acpi_reduced_hardware() helper URL : https://patchwork.freedesktop.org/series/88779/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:102: warning: Function parameter or member 'ww' not described in 'i915_gem_shrink' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function parameter 'trampoline' description in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'jump_whitelist' not described in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'shadow_map' not described in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'batch_map' not described in 'intel_engine_cmd_parser' ./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function parameter 'trampoline' description in 'intel_engine_cmd_parser' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] ACPI: utils: Add acpi_reduced_hardware() helper
== Series Details ==
Series: series starting with [1/2] ACPI: utils: Add acpi_reduced_hardware()
helper
URL : https://patchwork.freedesktop.org/series/88779/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9930 -> Patchwork_19896
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19896/index.html
Known issues
Here are the changes found in Patchwork_19896 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@semaphore:
- fi-icl-y: NOTRUN -> [SKIP][1] ([fdo#109315]) +17 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19896/fi-icl-y/igt@amdgpu/amd_ba...@semaphore.html
* igt@gem_flink_basic@bad-open:
- fi-tgl-y: [PASS][2] -> [DMESG-WARN][3] ([i915#402])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9930/fi-tgl-y/igt@gem_flink_ba...@bad-open.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19896/fi-tgl-y/igt@gem_flink_ba...@bad-open.html
* igt@gem_huc_copy@huc-copy:
- fi-icl-y: NOTRUN -> [SKIP][4] ([i915#2190])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19896/fi-icl-y/igt@gem_huc_c...@huc-copy.html
* igt@kms_chamelium@dp-crc-fast:
- fi-icl-y: NOTRUN -> [SKIP][5] ([fdo#109284] / [fdo#111827]) +8
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19896/fi-icl-y/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-icl-y: NOTRUN -> [SKIP][6] ([fdo#109285])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19896/fi-icl-y/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-icl-y: NOTRUN -> [SKIP][7] ([fdo#109278])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19896/fi-icl-y/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
* igt@kms_psr@primary_mmap_gtt:
- fi-icl-y: NOTRUN -> [SKIP][8] ([fdo#110189]) +3 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19896/fi-icl-y/igt@kms_psr@primary_mmap_gtt.html
* igt@prime_vgem@basic-userptr:
- fi-icl-y: NOTRUN -> [SKIP][9] ([i915#3301])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19896/fi-icl-y/igt@prime_v...@basic-userptr.html
Possible fixes
* igt@i915_selftest@live@hangcheck:
- {fi-hsw-gt1}: [DMESG-WARN][10] ([i915#3303]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9930/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19896/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html
Warnings
* igt@debugfs_test@read_all_entries:
- fi-tgl-y: [DMESG-WARN][12] ([i915#1982] / [i915#402]) ->
[DMESG-WARN][13] ([i915#402])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9930/fi-tgl-y/igt@debugfs_test@read_all_entries.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19896/fi-tgl-y/igt@debugfs_test@read_all_entries.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
Participating hosts (45 -> 41)
--
Additional (1): fi-icl-y
Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600
fi-bdw-samus
Build changes
-
* Linux: CI_DRM_9930 -> Patchwork_19896
CI-20190529: 20190529
CI_DRM_9930: 64ca4816d6657b4f651f7c44bb0458d7fdd9a775 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6058: 5db5b0d311e79ecb45d3f5a7b98c430c3bb1ed6b @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_19896: 0f275b3da11b59e30d37e3ee709e3b9b45a52586 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
0f275b3da11b ACPI: video: Check LCD flag on ACPI-reduced-hardware devices
9dbdf376c396 ACPI: utils: Add acpi_reduced_hardware() helper
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwo
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] ACPI: utils: Add acpi_reduced_hardware() helper
== Series Details == Series: series starting with [1/2] ACPI: utils: Add acpi_reduced_hardware() helper URL : https://patchwork.freedesktop.org/series/88779/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9930_full -> Patchwork_19896_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19896_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19896_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19896_full: ### IGT changes ### Possible regressions * igt@gem_ctx_persistence@engines-hostile@bcs0: - shard-kbl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9930/shard-kbl7/igt@gem_ctx_persistence@engines-host...@bcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19896/shard-kbl4/igt@gem_ctx_persistence@engines-host...@bcs0.html * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence: - shard-tglb: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9930/shard-tglb2/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-b-frame-sequence.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19896/shard-tglb3/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-b-frame-sequence.html Known issues Here are the changes found in Patchwork_19896_full that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@read_all_entries_display_on: - shard-skl: NOTRUN -> [DMESG-WARN][5] ([i915#1982]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19896/shard-skl5/igt@debugfs_test@read_all_entries_display_on.html * igt@gem_ctx_persistence@clone: - shard-snb: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#1099]) +5 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19896/shard-snb6/igt@gem_ctx_persiste...@clone.html * igt@gem_ctx_shared@q-in-order: - shard-snb: NOTRUN -> [SKIP][7] ([fdo#109271]) +325 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19896/shard-snb7/igt@gem_ctx_sha...@q-in-order.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][8] -> [FAIL][9] ([i915#2846]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9930/shard-glk1/igt@gem_exec_f...@basic-deadline.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19896/shard-glk2/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-iclb: [PASS][10] -> [FAIL][11] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9930/shard-iclb4/igt@gem_exec_fair@basic-none-sh...@rcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19896/shard-iclb1/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][12] -> [FAIL][13] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9930/shard-glk9/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19896/shard-glk9/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-kbl: [PASS][14] -> [SKIP][15] ([fdo#109271]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9930/shard-kbl6/igt@gem_exec_fair@basic-p...@vcs0.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19896/shard-kbl6/igt@gem_exec_fair@basic-p...@vcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-kbl: [PASS][16] -> [FAIL][17] ([i915#2842]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9930/shard-kbl6/igt@gem_exec_fair@basic-p...@vcs1.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19896/shard-kbl6/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-iclb: [PASS][18] -> [FAIL][19] ([i915#2849]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9930/shard-iclb3/igt@gem_exec_fair@basic-throt...@rcs0.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19896/shard-iclb3/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_whisper@basic-queues: - shard-glk: [PASS][20] -> [DMESG-WARN][21] ([i915#118] / [i915#95]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9930/shard-glk9/igt@gem_exec_whis...@basic-queues.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19896/shard-glk9/igt@gem_exec_whis...@basic-queues.html * igt@gem_mmap_gtt@cpuset-big-copy-odd: - shard-iclb: [PASS][22] -> [FAIL][23]
Re: [Intel-gfx] [PATCH] drm/i915: Add Wa_14010733141
On 4/1/2021 9:28 AM, Aditya Swarup wrote:
The WA requires the following procedure for VDBox SFC reset:
If (MFX-SFC usage is 1) {
1.Issue a MFX-SFC forced lock
2.Wait for MFX-SFC forced lock ack
3.Check the MFX-SFC usage bit
If (MFX-SFC usage bit is 1)
Reset VDBOX and SFC
else
Reset VDBOX
Release the force lock MFX-SFC
}
else if(HCP+SFC usage is 1) {
1.Issue a VE-SFC forced lock
2.Wait for SFC forced lock ack
3.Check the VE-SFC usage bit
If (VE-SFC usage bit is 1)
Reset VDBOX
else
Reset VDBOX and SFC
Release the force lock VE-SFC.
}
else
Reset VDBOX
- Restructure: the changes to the original code flow should stay
relatively minimal; we only need to do an extra HCP check after the
usual VD-MFX check and, if true, switch the register/bit we're
performing the lock on.(MattR)
Bspec: 52890, 53509
Co-developed-by: Matt Roper
Cc: Tvrtko Ursulin
Cc: Matt Roper
Cc: Daniele Ceraolo Spurio
Cc: Lucas De Marchi
Signed-off-by: Aditya Swarup
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_reset.c | 194 +-
drivers/gpu/drm/i915/i915_reg.h | 6 +
2 files changed, 137 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index a377c4588aaa..bcb3d864db11 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -338,15 +338,69 @@ static int gen6_reset_engines(struct intel_gt *gt,
return gen6_hw_domain_reset(gt, hw_mask);
}
-static int gen11_lock_sfc(struct intel_engine_cs *engine, u32 *hw_mask)
+static struct intel_engine_cs *find_sfc_paired_vecs_engine(struct
intel_engine_cs *engine)
+{
+ int vecs_id;
+
+ GEM_BUG_ON(engine->class != VIDEO_DECODE_CLASS);
+
+ vecs_id = _VECS((engine->instance) / 2);
+
+ return engine->gt->engine[vecs_id];
+}
+
+struct sfc_lock_data {
+ i915_reg_t lock_reg;
+ i915_reg_t ack_reg;
+ i915_reg_t usage_reg;
+ u32 lock_bit;
+ u32 ack_bit;
+ u32 usage_bit;
+ u32 reset_bit;
+};
+
+static void get_sfc_forced_lock_data(struct intel_engine_cs *engine,
+struct sfc_lock_data *sfc_lock)
+{
+ switch (engine->class) {
+ default:
+ MISSING_CASE(engine->class);
+ fallthrough;
+ case VIDEO_DECODE_CLASS:
+ sfc_lock->lock_reg = GEN11_VCS_SFC_FORCED_LOCK(engine);
+ sfc_lock->lock_bit = GEN11_VCS_SFC_FORCED_LOCK_BIT;
+
+ sfc_lock->ack_reg = GEN11_VCS_SFC_LOCK_STATUS(engine);
+ sfc_lock->ack_bit = GEN11_VCS_SFC_LOCK_ACK_BIT;
+
+ sfc_lock->usage_reg = GEN11_VCS_SFC_LOCK_STATUS(engine);
+ sfc_lock->usage_bit = GEN11_VCS_SFC_USAGE_BIT;
+ sfc_lock->reset_bit = GEN11_VCS_SFC_RESET_BIT(engine->instance);
+
+ break;
+ case VIDEO_ENHANCEMENT_CLASS:
+ sfc_lock->lock_reg = GEN11_VECS_SFC_FORCED_LOCK(engine);
+ sfc_lock->lock_bit = GEN11_VECS_SFC_FORCED_LOCK_BIT;
+
+ sfc_lock->ack_reg = GEN11_VECS_SFC_LOCK_ACK(engine);
+ sfc_lock->ack_bit = GEN11_VECS_SFC_LOCK_ACK_BIT;
+
+ sfc_lock->usage_reg = GEN11_VECS_SFC_USAGE(engine);
+ sfc_lock->usage_bit = GEN11_VECS_SFC_USAGE_BIT;
+ sfc_lock->reset_bit =
GEN11_VECS_SFC_RESET_BIT(engine->instance);
+
+ break;
+ }
+}
+
+static int gen11_lock_sfc(struct intel_engine_cs *engine,
+ u32 *reset_mask,
+ u32 *unlock_mask)
{
struct intel_uncore *uncore = engine->uncore;
u8 vdbox_sfc_access = engine->gt->info.vdbox_sfc_access;
- i915_reg_t sfc_forced_lock, sfc_forced_lock_ack;
- u32 sfc_forced_lock_bit, sfc_forced_lock_ack_bit;
- i915_reg_t sfc_usage;
- u32 sfc_usage_bit;
- u32 sfc_reset_bit;
+ struct sfc_lock_data sfc_lock;
+ bool lock_obtained, lock_to_other = false;
int ret;
switch (engine->class) {
@@ -354,53 +408,72 @@ static int gen11_lock_sfc(struct intel_engine_cs *engine,
u32 *hw_mask)
if ((BIT(engine->instance) & vdbox_sfc_access) == 0)
return 0;
- sfc_forced_lock = GEN11_VCS_SFC_FORCED_LOCK(engine);
- sfc_forced_lock_bit = GEN11_VCS_SFC_FORCED_LOCK_BIT;
-
- sfc_forced_lock_ack = GEN11_VCS_SFC_LOCK_STATUS(engine);
- sfc_forced_lock_ack_bit = GEN11_VCS_SFC_LOCK_ACK_BIT;
+ fallthrough;
+ case VIDEO_ENHANCEMENT_CLASS:
+ get_sfc_forced_lock_data(engine, &sfc_lock);
- sfc_usage = GEN11_VCS_SFC_LOCK_STATUS(engine);
- sfc_usage_bit = GEN11_VCS_SFC_USAGE_BIT;
- sfc_reset_bit = GEN11_
