Re: [Intel-gfx] [PATCH] drm/i915:Move the code position to reduce the number of judgments
On Thu, 25 Aug 2022, Lv qian wrote:
> If the kmalloc allocation is successful, the if is judged twice,
> so I move the second judgment in to the first judgment.
The code is fine as it is.
BR,
Jani.
>
> Signed-off-by: Lv qian
> ---
> drivers/gpu/drm/i915/i915_gpu_error.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index 32e92651ef7c..c8230a8beadb 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -112,10 +112,10 @@ static bool __i915_error_grow(struct
> drm_i915_error_state_buf *e, size_t len)
> if (!e->buf) {
> e->size = PAGE_ALIGN(len + 1);
> e->buf = kmalloc(e->size, GFP_KERNEL);
> - }
> - if (!e->buf) {
> - e->err = -ENOMEM;
> - return false;
> + if (!e->buf) {
> + e->err = -ENOMEM;
> + return false;
> + }
> }
>
> return true;
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] i915/pmu: Wire GuC backend to per-client busyness
On Thu, 04 Aug 2022 16:21:25 -0700, Umesh Nerlige Ramappa wrote:
>
Hi Umesh,
Still reviewing but I have a question below.
> diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> b/drivers/gpu/drm/i915/gt/intel_context.c
> index 654a092ed3d6..e2d70a9fdac0 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context.c
> +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> @@ -576,16 +576,24 @@ void intel_context_bind_parent_child(struct
> intel_context *parent,
> child->parallel.parent = parent;
> }
>
> -u64 intel_context_get_total_runtime_ns(const struct intel_context *ce)
> +u64 intel_context_get_total_runtime_ns(struct intel_context *ce)
> {
> u64 total, active;
>
> + if (ce->ops->update_stats)
> + ce->ops->update_stats(ce);
> +
/snip/
> @@ -1396,6 +1399,10 @@ static void guc_timestamp_ping(struct work_struct *wrk)
> with_intel_runtime_pm(>->i915->runtime_pm, wakeref)
> __update_guc_busyness_stats(guc);
>
> + /* adjust context stats for overflow */
> + xa_for_each(&guc->context_lookup, index, ce)
> + __guc_context_update_clks(ce);
> +
The question is why do we have 2 functions: __guc_context_update_clks()
(which we call periodically from guc_timestamp_ping()) and
guc_context_update_stats() (which we call non-periodically from
intel_context_get_total_runtime_ns()? Why don't we have just one function
which is called from both places? Or rather why don't we call
guc_context_update_stats() from both places?
If we don't call guc_context_update_stats() periodically from
guc_timestamp_ping() how e.g. does ce->stats.runtime.start_gt_clk get reset
to 0? If it gets reset to 0 in __guc_context_update_clks() then why do we
need to reset it in guc_context_update_stats()?
Also IMO guc->timestamp.lock should be taken by this single function,
(otherwise guc_context_update_stats() is modifying
ce->stats.runtime.start_gt_clk without taking the lock).
Thanks.
--
Ashutosh
> +static void __guc_context_update_clks(struct intel_context *ce)
> +{
> + struct intel_guc *guc = ce_to_guc(ce);
> + struct intel_gt *gt = ce->engine->gt;
> + u32 *pphwsp, last_switch, engine_id;
> + u64 start_gt_clk, active;
> + unsigned long flags;
> + ktime_t unused;
> +
> + spin_lock_irqsave(&guc->timestamp.lock, flags);
> +
> + /*
> + * GPU updates ce->lrc_reg_state[CTX_TIMESTAMP] when context is switched
> + * out, however GuC updates PPHWSP offsets below. Hence KMD (CPU)
> + * relies on GuC and GPU for busyness calculations. Due to this, A
> + * potential race was highlighted in an earlier review that can lead to
> + * double accounting of busyness. While the solution to this is a wip,
> + * busyness is still usable for platforms running GuC submission.
> + */
> + pphwsp = ((void *)ce->lrc_reg_state) - LRC_STATE_OFFSET;
> + last_switch = READ_ONCE(pphwsp[PPHWSP_GUC_CONTEXT_USAGE_STAMP_LO]);
> + engine_id = READ_ONCE(pphwsp[PPHWSP_GUC_CONTEXT_USAGE_ENGINE_ID]);
> +
> + guc_update_pm_timestamp(guc, &unused);
> +
> + if (engine_id != 0x && last_switch) {
> + start_gt_clk = READ_ONCE(ce->stats.runtime.start_gt_clk);
> + __extend_last_switch(guc, &start_gt_clk, last_switch);
> + active = intel_gt_clock_interval_to_ns(gt,
> guc->timestamp.gt_stamp - start_gt_clk);
> + WRITE_ONCE(ce->stats.runtime.start_gt_clk, start_gt_clk);
> + WRITE_ONCE(ce->stats.active, active);
> + } else {
> + lrc_update_runtime(ce);
> + }
> +
> + spin_unlock_irqrestore(&guc->timestamp.lock, flags);
> +}
> +
> +static void guc_context_update_stats(struct intel_context *ce)
> +{
> + if (!intel_context_pin_if_active(ce)) {
> + WRITE_ONCE(ce->stats.runtime.start_gt_clk, 0);
> + WRITE_ONCE(ce->stats.active, 0);
> + return;
> + }
> +
> + __guc_context_update_clks(ce);
> + intel_context_unpin(ce);
> +}
Re: [Intel-gfx] [PATCH 6/7] drm/i915/guc: Make GuC log sizes runtime configurable
Quoting John Harrison (2022-08-24 21:45:09)
> On 8/24/2022 02:01, Joonas Lahtinen wrote:
> > NACK on this one. Let's get this reverted or fixed to eliminate
> > new module parameters.
> >
> > What prevents us just from using the maximum sizes? Or alternatively
> > we could check the already existing drm.debug variable or anything else
> > but addding 3 new module parameters.
> We don't want to waste 24MB of memory for all users when 99.999% of them
> don't care about GuC logs.
It is not exactly wasting memory if it is what is needed to capture
the error logs to properly debug a system. And it's definitely not much
on any modern system where you will have a GPU. You can always leave
the Kconfig options in place for the cases where it matters.
On the other hand, if 99.999% don't need this, then it could just stay
as a kernel config time option as well?
> We also don't want to tie the GuC logging buffer size to the DRM
> debugging output. Enabling kernel debug output can change timings and
> prevent the issue that one is trying to capture in the GuC log. And it
> seems unlikely we could add an entire new top level DRM debug flag just
> for an internal i915 only log buffer size. Plus drm.debug is explicitly
> stated as being dynamically changeable via sysfs at any time. The GuC
> log buffer size cannot be changed without reloading the i915 driver. Or
> at least, not without reloading the GuC, but we definitely don't want to
> create a UAPI for arbitrarily reloading the GuC.
>
> We can make these parameters 'unsafe' so that they taint the kernel if
> used. But this is exactly what module parameters are for - configuration
> that we don't want to hardcode as CONFIG options but which must be set
> at module load time.
It's better to have sane defaults. And if somebody wants something
strange, they can have a Kconfig behind EXPERT option. But even then
there should really be need for it.
So for now, let's get the module parameters reverted and go with
reasonable default buffer sizes when GuC is enabled. The compile time
options can be left in place.
Thank you in advance.
Regards, Joonas
>
> John.
>
> >
> > For future reference, please do Cc maintainers when adding new uAPI
> > like module parameters.
> >
> > Regards, Joonas
> >
> > Quoting john.c.harri...@intel.com (2022-07-28 05:20:27)
> >> From: John Harrison
> >>
> >> The GuC log buffer sizes had to be configured statically at compile
> >> time. This can be quite troublesome when needing to get larger logs
> >> out of a released driver. So re-organise the code to allow a boot time
> >> module parameter override.
> >>
> >> Signed-off-by: John Harrison
> >> ---
> >> drivers/gpu/drm/i915/gt/uc/intel_guc.c| 53 ++
> >> .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 14 +-
> >> drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 176 +-
> >> drivers/gpu/drm/i915/gt/uc/intel_guc_log.h| 42 +++--
> >> drivers/gpu/drm/i915/i915_params.c| 12 ++
> >> drivers/gpu/drm/i915/i915_params.h| 3 +
> >> 6 files changed, 226 insertions(+), 74 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> >> b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> >> index ab4aacc516aa4..01f2705cb94a3 100644
> >> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> >> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> >> @@ -224,53 +224,22 @@ static u32 guc_ctl_feature_flags(struct intel_guc
> >> *guc)
> >>
> >> static u32 guc_ctl_log_params_flags(struct intel_guc *guc)
> >> {
> >> - u32 offset = intel_guc_ggtt_offset(guc, guc->log.vma) >>
> >> PAGE_SHIFT;
> >> - u32 flags;
> >> -
> >> - #if (((CRASH_BUFFER_SIZE) % SZ_1M) == 0)
> >> - #define LOG_UNIT SZ_1M
> >> - #define LOG_FLAG GUC_LOG_LOG_ALLOC_UNITS
> >> - #else
> >> - #define LOG_UNIT SZ_4K
> >> - #define LOG_FLAG 0
> >> - #endif
> >> -
> >> - #if (((CAPTURE_BUFFER_SIZE) % SZ_1M) == 0)
> >> - #define CAPTURE_UNIT SZ_1M
> >> - #define CAPTURE_FLAG GUC_LOG_CAPTURE_ALLOC_UNITS
> >> - #else
> >> - #define CAPTURE_UNIT SZ_4K
> >> - #define CAPTURE_FLAG 0
> >> - #endif
> >> -
> >> - BUILD_BUG_ON(!CRASH_BUFFER_SIZE);
> >> - BUILD_BUG_ON(!IS_ALIGNED(CRASH_BUFFER_SIZE, LOG_UNIT));
> >> - BUILD_BUG_ON(!DEBUG_BUFFER_SIZE);
> >> - BUILD_BUG_ON(!IS_ALIGNED(DEBUG_BUFFER_SIZE, LOG_UNIT));
> >> - BUILD_BUG_ON(!CAPTURE_BUFFER_SIZE);
> >> - BUILD_BUG_ON(!IS_ALIGNED(CAPTURE_BUFFER_SIZE, CAPTURE_UNIT));
> >> -
> >> - BUILD_BUG_ON((CRASH_BUFFER_SIZE / LOG_UNIT - 1) >
> >> - (GUC_LOG_CRASH_MASK >> GUC_LOG_CRASH_SHIFT));
> >> - BUILD_BUG_ON((DEBUG_BUFFER_SIZE / LOG_UNIT - 1) >
> >> - (GUC_LOG_DEBUG_MASK >> GUC_LOG_DEBUG_SHIFT));
> >> - BUILD_BUG_ON((CAPTURE_BUFFER_SIZE / CAPTURE_UNIT - 1) >
> >> - (GUC_LOG_CAPTURE_MASK >> GUC_LOG_CAPTURE_SHIFT)
Re: [Intel-gfx] [PATCH] i915/pmu: Wire GuC backend to per-client busyness
On Wed, 15 Jun 2022 10:42:08 -0700, Umesh Nerlige Ramappa wrote:
>
> +static void __guc_context_update_clks(struct intel_context *ce)
> +{
> + struct intel_guc *guc = ce_to_guc(ce);
> + struct intel_gt *gt = ce->engine->gt;
> + u32 *pphwsp, last_switch, engine_id;
> + u64 start_gt_clk = 0, active = 0;
> >>>
> >>> No need to init these two.
> >>>
> + unsigned long flags;
> + ktime_t unused;
> +
> + spin_lock_irqsave(&guc->timestamp.lock, flags);
> +
> + pphwsp = ((void *)ce->lrc_reg_state) - LRC_STATE_OFFSET;
> + last_switch = READ_ONCE(pphwsp[PPHWSP_GUC_CONTEXT_USAGE_STAMP_LO]);
> + engine_id = READ_ONCE(pphwsp[PPHWSP_GUC_CONTEXT_USAGE_ENGINE_ID]);
> +
> + guc_update_pm_timestamp(guc, &unused);
> +
> + if (engine_id != 0x && last_switch) {
> + start_gt_clk = READ_ONCE(ce->stats.runtime.start_gt_clk);
> + __extend_last_switch(guc, &start_gt_clk, last_switch);
> + active = intel_gt_clock_interval_to_ns(gt,
> guc->timestamp.gt_stamp - start_gt_clk);
> + WRITE_ONCE(ce->stats.runtime.start_gt_clk, start_gt_clk);
> + WRITE_ONCE(ce->stats.active, active);
> + } else {
> + lrc_update_runtime(ce);
> >>>
> >>> Why is this called from here? Presumably it was called already from
> >>> guc_context_unpin if here code things context is not active. Or will be
> >>> called shortly, once context save is done.
> >>
> >> guc_context_unpin is only called in the path of ce->sched_disable. The
> >> sched_disable is implemented in GuC (H2G message). Once the
> >> corresponding G2H response is received, the context is actually
> >> unpinned, eventually calling guc_context_unpin. Also the context may not
> >> necessarily be disabled after each context exit.
> >
> > So if I understand correctly, lrc runtime is only updated if someone is
> > reading the busyness and not as part of normal context state transitions?
>
> If you mean context_in/out events (like csb interrupts), only GuC can see
> those events. KMD has no visibility into that. These 3 paths call
> lrc_update_runtime.
>
> user query: (engine_id != 0x && last_switch) translates to GuC
> being within context_in and context_out events, so updating it outside of
> this window is one way to report the correct busyness.
>
> worker: guc_timestamp_ping() also updates context stats (infrequently) for
> all contexts primarily to take care of overflows.
>
> context unpin: Existing code calls lrc_update_runtime only when unpinning
> the context which takes care of accumulating busyness when requests are
> retired.
Will adding lrc_update_runtime() to lrc_unpin() work?
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: compute config for audio
== Series Details == Series: drm/i915/display: compute config for audio URL : https://patchwork.freedesktop.org/series/107647/ State : success == Summary == CI Bug Log - changes from CI_DRM_12018_full -> Patchwork_107647v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (12 -> 12) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_107647v1_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_exec@basic-nohangcheck: - shard-tglb: [PASS][1] -> [FAIL][2] ([i915#6268]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12018/shard-tglb3/igt@gem_ctx_e...@basic-nohangcheck.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107647v1/shard-tglb3/igt@gem_ctx_e...@basic-nohangcheck.html * igt@gem_ctx_isolation@preservation-s3@rcs0: - shard-apl: NOTRUN -> [INCOMPLETE][3] ([i915#6598]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107647v1/shard-apl8/igt@gem_ctx_isolation@preservation...@rcs0.html * igt@gem_exec_balancer@parallel-keep-submit-fence: - shard-iclb: [PASS][4] -> [SKIP][5] ([i915#4525]) +2 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12018/shard-iclb1/igt@gem_exec_balan...@parallel-keep-submit-fence.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107647v1/shard-iclb5/igt@gem_exec_balan...@parallel-keep-submit-fence.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-kbl: [PASS][6] -> [SKIP][7] ([fdo#109271]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12018/shard-kbl7/igt@gem_exec_fair@basic-none-sh...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107647v1/shard-kbl1/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-apl: [PASS][8] -> [FAIL][9] ([i915#2842]) +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12018/shard-apl6/igt@gem_exec_fair@basic-none-s...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107647v1/shard-apl6/igt@gem_exec_fair@basic-none-s...@rcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-kbl: [PASS][10] -> [FAIL][11] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12018/shard-kbl4/igt@gem_exec_fair@basic-pace-s...@rcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107647v1/shard-kbl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-glk: [PASS][12] -> [FAIL][13] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12018/shard-glk8/igt@gem_exec_fair@basic-p...@vcs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107647v1/shard-glk9/igt@gem_exec_fair@basic-p...@vcs0.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-iclb: [PASS][14] -> [FAIL][15] ([i915#2842]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12018/shard-iclb2/igt@gem_exec_fair@basic-p...@vecs0.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107647v1/shard-iclb7/igt@gem_exec_fair@basic-p...@vecs0.html * igt@gem_workarounds@suspend-resume-context: - shard-kbl: [PASS][16] -> [DMESG-WARN][17] ([i915#180]) +4 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12018/shard-kbl4/igt@gem_workarou...@suspend-resume-context.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107647v1/shard-kbl4/igt@gem_workarou...@suspend-resume-context.html * igt@kms_ccs@pipe-c-random-ccs-data-y_tiled_gen12_mc_ccs: - shard-apl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#3886]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107647v1/shard-apl8/igt@kms_ccs@pipe-c-random-ccs-data-y_tiled_gen12_mc_ccs.html * igt@kms_chamelium@hdmi-edid-read: - shard-apl: NOTRUN -> [SKIP][19] ([fdo#109271] / [fdo#111827]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107647v1/shard-apl8/igt@kms_chamel...@hdmi-edid-read.html * igt@kms_chamelium@vga-hpd-enable-disable-mode: - shard-glk: NOTRUN -> [SKIP][20] ([fdo#109271] / [fdo#111827]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107647v1/shard-glk5/igt@kms_chamel...@vga-hpd-enable-disable-mode.html * igt@kms_dither@fb-8bpc-vs-panel-6bpc@pipe-a-hdmi-a-1: - shard-glk: NOTRUN -> [SKIP][21] ([fdo#109271]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107647v1/shard-glk9/igt@kms_dither@fb-8bpc-vs-panel-6...@pipe-a-hdmi-a-1.html * igt@kms_flip_scaled_crc@flip-64bpp-yftile-to-16bpp-yftile-upscaling@pipe-a-default-mode: - shard-iclb: NOTRUN -> [SKIP][22] ([i915#2672]) +4 similar issues [22]: https://
Re: [Intel-gfx] [PATCH 1/7] drm/i915/hwmon: Add HWMON infrastructure
On 23-08-2022 20:11, Jani Nikula wrote: On Tue, 23 Aug 2022, "Nilawar, Badal" wrote: On 23-08-2022 19:05, Jani Nikula wrote: On Tue, 23 Aug 2022, Guenter Roeck wrote: On Tue, Aug 23, 2022 at 12:46:14PM +0300, Jani Nikula wrote: [ ... ] So why not do this in i915 Kconfig: config DRM_I915 ... depends on HWMON || HWMON=n With this change I am getting recursive dependancy error when I run make oldconfig badal@bnilawar-desk1:~/workspace/wp3/drm-tip$ make oldconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/confdata.o HOSTCC scripts/kconfig/expr.o LEX scripts/kconfig/lexer.lex.c YACCscripts/kconfig/parser.tab.[ch] HOSTCC scripts/kconfig/lexer.lex.o HOSTCC scripts/kconfig/menu.o HOSTCC scripts/kconfig/parser.tab.o HOSTCC scripts/kconfig/preprocess.o HOSTCC scripts/kconfig/symbol.o HOSTCC scripts/kconfig/util.o HOSTLD scripts/kconfig/conf drivers/gpu/drm/i915/Kconfig:2:error: recursive dependency detected! drivers/gpu/drm/i915/Kconfig:2: symbol DRM_I915 depends on HWMON drivers/hwmon/Kconfig:6:symbol HWMON is selected by EEEPC_LAPTOP drivers/platform/x86/Kconfig:332: symbol EEEPC_LAPTOP depends on INPUT drivers/input/Kconfig:8:symbol INPUT is selected by DRM_I915 For a resolution refer to Documentation/kbuild/kconfig-language.rst subsection "Kconfig recursive dependency limitations" *sigh* Note: select should be used with care. select will force a symbol to a value without visiting the dependencies. By abusing select you are able to select a symbol FOO even if FOO depends on BAR that is not set. In general use select only for non-visible symbols (no prompts anywhere) and for symbols with no dependencies. That will limit the usefulness but on the other hand avoid the illegal configurations all over. Agreed. HWMON should not be selected anywhere. Unfortunately it is, and drm is no exception. It is selected by DRM_RADEON and DRM_AMDGPU. Maybe just select it in DRM_I915 as well after all; in practice it won't make a difference. And I guess everyone just does what I'm about to do now, throw my hands up in the air in disgust and resignation. :p How about sticking to existing approach only. In my previous response I mentioned that for combo which we want to reject CONFIG_HWMON=m && CONFIG_DRM_I915=y combo i915_hwmon.o is not getting build. It is only getting build for below combos CONFIG_HWMON=m && CONFIG_DRM_I915=y CONFIG_HWMON=m && CONFIG_DRM_I915=m CONFIG_HWMON=y && CONFIG_DRM_I915=m Then please hide the IS_REACHABLE() within i915_hwmon.h and add stubs as is customary. Let's not clutter high level driver code with some random #if directives. Thanks, I will resolve this and float the new series. Regards, Badal BR, Jani. Regards, Badal BR, Jani.
Re: [Intel-gfx] [PATCH] drm/i915: Skip wm/ddb readout for disabled pipes
On Fri, Jun 17, 2022 at 10:59:48PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > The stuff programmed into the wm/ddb registers of planes > on disabled pipes doesn't matter. So during readout just > leave our software state tracking for those zeroed. > > This should avoid us trying too hard to clean up after > whatever mess the VBIOS/GOP left in there. The actual > hardware state will get cleaned up if/when we enable > the pipe anyway. > > References: https://gitlab.freedesktop.org/drm/intel/-/issues/5711 > Signed-off-by: Ville Syrjälä Reviewed-by: Stanislav Lisovskiy > --- > drivers/gpu/drm/i915/intel_pm.c | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index 174fab564d10..d083964d5470 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -6560,7 +6560,10 @@ void skl_wm_get_hw_state(struct drm_i915_private > *dev_priv) > enum plane_id plane_id; > u8 slices; > > - skl_pipe_wm_get_hw_state(crtc, &crtc_state->wm.skl.optimal); > + memset(&crtc_state->wm.skl.optimal, 0, > +sizeof(crtc_state->wm.skl.optimal)); > + if (crtc_state->hw.active) > + skl_pipe_wm_get_hw_state(crtc, > &crtc_state->wm.skl.optimal); > crtc_state->wm.skl.raw = crtc_state->wm.skl.optimal; > > memset(&dbuf_state->ddb[pipe], 0, > sizeof(dbuf_state->ddb[pipe])); > @@ -6571,6 +6574,9 @@ void skl_wm_get_hw_state(struct drm_i915_private > *dev_priv) > struct skl_ddb_entry *ddb_y = > &crtc_state->wm.skl.plane_ddb_y[plane_id]; > > + if (!crtc_state->hw.active) > + continue; > + > skl_ddb_get_hw_plane_state(dev_priv, crtc->pipe, > plane_id, ddb, ddb_y); > > -- > 2.35.1 >
Re: [Intel-gfx] [PATCH v1] drm/i915: fix null pointer dereference
On Tue, 23 Aug 2022, Łukasz Bartosik wrote:
>>
>> Hi all,
>>
>> Apologies in advance if you see this twice. I did not see the original
>> make it to either lore.kernel.org or the freedesktop.org archives so I
>> figured it might have been sent into the void.
>>
>> On Tue, Feb 01, 2022 at 04:33:54PM +0100, Lukasz Bartosik wrote:
>> > From: Łukasz Bartosik
>> >
>> > Asus chromebook CX550 crashes during boot on v5.17-rc1 kernel.
>> > The root cause is null pointer defeference of bi_next
>> > in tgl_get_bw_info() in drivers/gpu/drm/i915/display/intel_bw.c.
>> >
>> > BUG: kernel NULL pointer dereference, address: 002e
>> > PGD 0 P4D 0
>> > Oops: 0002 [#1] PREEMPT SMP NOPTI
>> > CPU: 0 PID: 1 Comm: swapper/0 Tainted: G U5.17.0-rc1
>> > Hardware name: Google Delbin/Delbin, BIOS Google_Delbin.13672.156.3
>> > 05/14/2021
>> > RIP: 0010:tgl_get_bw_info+0x2de/0x510
>> > ...
>> > [2.554467] Call Trace:
>> > [2.554467]
>> > [2.554467] intel_bw_init_hw+0x14a/0x434
>> > [2.554467] ? _printk+0x59/0x73
>> > [2.554467] ? _dev_err+0x77/0x91
>> > [2.554467] i915_driver_hw_probe+0x329/0x33e
>> > [2.554467] i915_driver_probe+0x4c8/0x638
>> > [2.554467] i915_pci_probe+0xf8/0x14e
>> > [2.554467] ? _raw_spin_unlock_irqrestore+0x12/0x2c
>> > [2.554467] pci_device_probe+0xaa/0x142
>> > [2.554467] really_probe+0x13f/0x2f4
>> > [2.554467] __driver_probe_device+0x9e/0xd3
>> > [2.554467] driver_probe_device+0x24/0x7c
>> > [2.554467] __driver_attach+0xba/0xcf
>> > [2.554467] ? driver_attach+0x1f/0x1f
>> > [2.554467] bus_for_each_dev+0x8c/0xc0
>> > [2.554467] bus_add_driver+0x11b/0x1f7
>> > [2.554467] driver_register+0x60/0xea
>> > [2.554467] ? mipi_dsi_bus_init+0x16/0x16
>> > [2.554467] i915_init+0x2c/0xb9
>> > [2.554467] ? mipi_dsi_bus_init+0x16/0x16
>> > [2.554467] do_one_initcall+0x12e/0x2b3
>> > [2.554467] do_initcall_level+0xd6/0xf3
>> > [2.554467] do_initcalls+0x4e/0x79
>> > [2.554467] kernel_init_freeable+0xed/0x14d
>> > [2.554467] ? rest_init+0xc1/0xc1
>> > [2.554467] kernel_init+0x1a/0x120
>> > [2.554467] ret_from_fork+0x1f/0x30
>> > [2.554467]
>> > ...
>> > Kernel panic - not syncing: Fatal exception
>> >
>> > Fixes: c64a9a7c05be ("drm/i915: Update memory bandwidth formulae")
>> > Signed-off-by: Łukasz Bartosik
>> > ---
>> > drivers/gpu/drm/i915/display/intel_bw.c | 16 +---
>> > 1 file changed, 9 insertions(+), 7 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
>> > b/drivers/gpu/drm/i915/display/intel_bw.c
>> > index 2da4aacc956b..bd0ed68b7faa 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_bw.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_bw.c
>> > @@ -404,15 +404,17 @@ static int tgl_get_bw_info(struct drm_i915_private
>> > *dev_priv, const struct intel
>> > int clpchgroup;
>> > int j;
>> >
>> > - if (i < num_groups - 1)
>> > - bi_next = &dev_priv->max_bw[i + 1];
>> > -
>> > clpchgroup = (sa->deburst * qi.deinterleave / num_channels)
>> > << i;
>> >
>> > - if (i < num_groups - 1 && clpchgroup < clperchgroup)
>> > - bi_next->num_planes = (ipqdepth - clpchgroup) /
>> > clpchgroup + 1;
>> > - else
>> > - bi_next->num_planes = 0;
>> > + if (i < num_groups - 1) {
>> > + bi_next = &dev_priv->max_bw[i + 1];
>> > +
>> > + if (clpchgroup < clperchgroup)
>> > + bi_next->num_planes = (ipqdepth -
>> > clpchgroup) /
>> > +clpchgroup + 1;
>> > + else
>> > + bi_next->num_planes = 0;
>> > + }
>> >
>> > bi->num_qgv_points = qi.num_points;
>> > bi->num_psf_gv_points = qi.num_psf_points;
>> > --
>> > 2.35.0.rc2.247.g8bbb082509-goog
>> >
>> >
>>
>> Was this patch ever applied or was the issue fixed in a different way?
>> If CONFIG_INIT_STACK_ALL_ZERO is enabled (it is on by default when the
>> compiler supports it), bi_next will be deterministically initialized to
>> NULL, which means 'bi_next->num_planes = 0' will crash when the first if
>> statement is not taken (i.e. 'i > num_groups - 1'). This was reported to
>> us at [1] so it impacts real users (and I have been applying this change
>> locally for six months). I see some discussion in this thread, was it
>> ever resolved?
>>
>> [1]: https://github.com/ClangBuiltLinux/linux/issues/1626
>>
>> Cheers,
>> Nathan
>
> The patch was not accepted by upstream. I gave up after sending two reminders
> that the issue is still present which resulted in no upstream reaction.
> I have been also applying that patch locally for a few months.
> Thanks for bringing it up to upstream attention again.
Apologies for us dropping the b
Re: [Intel-gfx] [PATCH 1/2] drm/i915/uc: Support for version reduced and multiple firmware files
On 8/16/2022 1:28 PM, john.c.harri...@intel.com wrote:
From: John Harrison
There was a misunderstanding in how firmware file compatibility should
be managed within i915. This has been clarified as:
i915 must support all existing firmware releases forever
new minor firmware releases should replace prior versions
only backwards compatibility breaking releases should be a new file
Hence this patch cleans up the single fallback file support that was
added as a quick fix emergency effort. That is now removed in
preference to supporting arbitrary numbers of firmware files per
platform as normal.
The patch also adds support for having GuC firmwrae files that are
named by major version only (because the major version indicates
backwards breaking changes that affect the KMD) and for having HuC
firmware files with no version number at all (because the KMD has no
interface requirements with the HuC).
For GuC, the driver will report via dmesg if the found file is older than
expected. For HuC, the KMD will no longer require updating for any new
HuC release so will not be able to report what the latest expected
version is.
Signed-off-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 10 +-
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 4 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 396 +++---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 33 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 16 +-
5 files changed, 275 insertions(+), 184 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 0d17da77e7872..d1715971fdd79 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1868,7 +1868,7 @@ int intel_guc_submission_init(struct intel_guc *guc)
if (guc->submission_initialized)
return 0;
- if (guc->fw.major_ver_found < 70) {
+ if (guc->fw.file_found.major_ver < 70) {
ret = guc_lrc_desc_pool_create_v69(guc);
if (ret)
return ret;
@@ -2303,7 +2303,7 @@ static int register_context(struct intel_context *ce,
bool loop)
GEM_BUG_ON(intel_context_is_child(ce));
trace_intel_context_register(ce);
- if (guc->fw.major_ver_found >= 70)
+ if (guc->fw.file_found.major_ver >= 70)
ret = register_context_v70(guc, ce, loop);
else
ret = register_context_v69(guc, ce, loop);
@@ -2315,7 +2315,7 @@ static int register_context(struct intel_context *ce,
bool loop)
set_context_registered(ce);
spin_unlock_irqrestore(&ce->guc_state.lock, flags);
- if (guc->fw.major_ver_found >= 70)
+ if (guc->fw.file_found.major_ver >= 70)
guc_context_policy_init_v70(ce, loop);
}
@@ -2921,7 +2921,7 @@ static void __guc_context_set_preemption_timeout(struct intel_guc *guc,
u16 guc_id,
u32 preemption_timeout)
{
- if (guc->fw.major_ver_found >= 70) {
+ if (guc->fw.file_found.major_ver >= 70) {
struct context_policy policy;
__guc_context_policy_start_klv(&policy, guc_id);
@@ -3186,7 +3186,7 @@ static int guc_context_alloc(struct intel_context *ce)
static void __guc_context_set_prio(struct intel_guc *guc,
struct intel_context *ce)
{
- if (guc->fw.major_ver_found >= 70) {
+ if (guc->fw.file_found.major_ver >= 70) {
struct context_policy policy;
__guc_context_policy_start_klv(&policy, ce->guc_id.id);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index f2e7c82985efd..0697128cc3362 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -436,8 +436,8 @@ static void print_fw_ver(struct intel_uc *uc, struct
intel_uc_fw *fw)
struct drm_i915_private *i915 = uc_to_gt(uc)->i915;
drm_info(&i915->drm, "%s firmware %s version %u.%u\n",
-intel_uc_fw_type_repr(fw->type), fw->path,
-fw->major_ver_found, fw->minor_ver_found);
+intel_uc_fw_type_repr(fw->type), fw->file_found.path,
+fw->file_found.major_ver, fw->file_found.minor_ver);
}
static int __uc_init_hw(struct intel_uc *uc)
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 58547292efa0a..eb3a15f0fa479 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -41,7 +41,7 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
"%s firmware -> %s\n",
intel_uc_fw_type_repr(uc_fw->type),
status == INTEL_UC_FIRMWARE_SELECTED ?
- uc_fw->
Re: [Intel-gfx] [PATCH] drm/i915: Implement a bit of bw_state readout
On Fri, Jun 17, 2022 at 07:07:30PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We currently fail to reconstruct the bw related cdclk limits
> during readout, which triggers a cdclk reclaculation during
> fastboot, which is then likely forces a full modeset anyway.
> Reconstruct some of the missing state so that we can skip
> the cdclk recomputation and thus have a higher chance for
> flicker free boot.
Problem is that intel_bw_min_cdclk is using intel_bw_dbuf_min_cdclk,
which in turns relies that bw_state->dbuf_bw was already calculated,
however this is calculated in intel_bw_calc_min_cdclk, which is called
from intel_cdclk_atomic_check.
So wondering will that work?
Stan
>
> Cc: Stanislav Lisovskiy
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_bw.c | 9 ++---
> drivers/gpu/drm/i915/display/intel_display.c | 7 +--
> 2 files changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index 79269d2c476b..30ffec63f9a3 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -627,11 +627,14 @@ void intel_bw_crtc_update(struct intel_bw_state
> *bw_state,
> intel_bw_crtc_data_rate(crtc_state);
> bw_state->num_active_planes[crtc->pipe] =
> intel_bw_crtc_num_active_planes(crtc_state);
> + bw_state->min_cdclk[crtc->pipe] =
> + intel_bw_crtc_min_cdclk(crtc_state);
>
> - drm_dbg_kms(&i915->drm, "pipe %c data rate %u num active planes %u\n",
> - pipe_name(crtc->pipe),
> + drm_dbg_kms(&i915->drm, "[CRTC:%d:%s] data rate %u num active planes %u
> min cdclk %d kHz\n",
> + crtc->base.base.id, crtc->base.name,
> bw_state->data_rate[crtc->pipe],
> - bw_state->num_active_planes[crtc->pipe]);
> + bw_state->num_active_planes[crtc->pipe],
> + bw_state->min_cdclk[crtc->pipe]);
> }
>
> static unsigned int intel_bw_num_active_planes(struct drm_i915_private
> *dev_priv,
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 90bd26431e31..b17b9493c68f 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -2498,6 +2498,7 @@ static void intel_crtc_disable_noatomic(struct
> intel_crtc *crtc,
>
> bw_state->data_rate[pipe] = 0;
> bw_state->num_active_planes[pipe] = 0;
> + bw_state->min_cdclk[pipe] = 0;
> }
>
> /*
> @@ -9310,6 +9311,8 @@ static void intel_modeset_readout_hw_state(struct
> drm_device *dev)
> to_intel_cdclk_state(dev_priv->cdclk.obj.state);
> struct intel_dbuf_state *dbuf_state =
> to_intel_dbuf_state(dev_priv->dbuf.obj.state);
> + struct intel_bw_state *bw_state =
> + to_intel_bw_state(dev_priv->bw_obj.state);
> enum pipe pipe;
> struct intel_crtc *crtc;
> struct intel_encoder *encoder;
> @@ -9425,8 +9428,6 @@ static void intel_modeset_readout_hw_state(struct
> drm_device *dev)
> drm_connector_list_iter_end(&conn_iter);
>
> for_each_intel_crtc(dev, crtc) {
> - struct intel_bw_state *bw_state =
> - to_intel_bw_state(dev_priv->bw_obj.state);
> struct intel_crtc_state *crtc_state =
> to_intel_crtc_state(crtc->base.state);
> struct intel_plane *plane;
> @@ -9490,6 +9491,8 @@ static void intel_modeset_readout_hw_state(struct
> drm_device *dev)
>
> intel_bw_crtc_update(bw_state, crtc_state);
> }
> +
> + cdclk_state->bw_min_cdclk = intel_bw_min_cdclk(dev_priv, bw_state);
> }
>
> static void
> --
> 2.35.1
>
Re: [Intel-gfx] [PATCH v9 2/8] util_macros: Add exact_type macro to catch type mis-match while compiling
Hi Bartosz Golaszewski,
would you mind taking a look at this patch?
Thanks,
G.G.
On 8/24/22 5:45 PM, Gwan-gyeong Mun wrote:
It adds exact_type and exactly_pgoff_t macro to catch type mis-match while
compiling. The existing typecheck() macro outputs build warnings, but the
newly added exact_type() macro uses the BUILD_BUG_ON() macro to generate
a build break when the types are different and can be used to detect
explicit build errors.
v6: Move macro addition location so that it can be used by other than drm
subsystem (Jani, Mauro, Andi)
Signed-off-by: Gwan-gyeong Mun
Cc: Thomas Hellström
Cc: Matthew Auld
Cc: Nirmoy Das
Cc: Jani Nikula
Cc: Andi Shyti
Cc: Mauro Carvalho Chehab
---
include/linux/util_macros.h | 25 +
1 file changed, 25 insertions(+)
diff --git a/include/linux/util_macros.h b/include/linux/util_macros.h
index 72299f261b25..b6624b275257 100644
--- a/include/linux/util_macros.h
+++ b/include/linux/util_macros.h
@@ -2,6 +2,9 @@
#ifndef _LINUX_HELPER_MACROS_H_
#define _LINUX_HELPER_MACROS_H_
+#include
+#include
+
#define __find_closest(x, a, as, op) \
({\
typeof(as) __fc_i, __fc_as = (as) - 1; \
@@ -38,4 +41,26 @@
*/
#define find_closest_descending(x, a, as) __find_closest(x, a, as, >=)
+/**
+ * exact_type - break compile if source type and destination value's type are
+ * not the same
+ * @T: Source type
+ * @n: Destination value
+ *
+ * It is a helper macro for a poor man's -Wconversion: only allow variables of
+ * an exact type. It determines whether the source type and destination value's
+ * type are the same while compiling, and it breaks compile if two types are
+ * not the same
+ */
+#define exact_type(T, n) \
+ BUILD_BUG_ON(!__builtin_constant_p(n) &&
!__builtin_types_compatible_p(T, typeof(n)))
+
+/**
+ * exactly_pgoff_t - helper to check if the type of a value is pgoff_t
+ * @n: value to compare pgoff_t type
+ *
+ * It breaks compile if the argument value's type is not pgoff_t type.
+ */
+#define exactly_pgoff_t(n) exact_type(pgoff_t, n)
+
#endif
Re: [Intel-gfx] [PATCH] drm/i915: Implement a bit of bw_state readout
On Thu, Aug 25, 2022 at 10:54:48AM +0300, Lisovskiy, Stanislav wrote:
> On Fri, Jun 17, 2022 at 07:07:30PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > We currently fail to reconstruct the bw related cdclk limits
> > during readout, which triggers a cdclk reclaculation during
> > fastboot, which is then likely forces a full modeset anyway.
> > Reconstruct some of the missing state so that we can skip
> > the cdclk recomputation and thus have a higher chance for
> > flicker free boot.
>
> Problem is that intel_bw_min_cdclk is using intel_bw_dbuf_min_cdclk,
> which in turns relies that bw_state->dbuf_bw was already calculated,
> however this is calculated in intel_bw_calc_min_cdclk, which is called
> from intel_cdclk_atomic_check.
>
> So wondering will that work?
Hmm. I guess we're more or less just missing a call to
skl_crtc_calc_dbuf_bw(), but I don't have all that code paged
in atm so might be missing something.
So as is this is probably not a complete solution, but it did
avoid the cdclk modeset on some machine I tested. I guess that
one was a tgl and thus the maximum pipe read bandwidth stuff
kicked in and populated things suffiiciently to avoid the full
cdclk recalculation. I'll have to try this on some older machine
to check how it behaves...
>
> Stan
>
> >
> > Cc: Stanislav Lisovskiy
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_bw.c | 9 ++---
> > drivers/gpu/drm/i915/display/intel_display.c | 7 +--
> > 2 files changed, 11 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> > b/drivers/gpu/drm/i915/display/intel_bw.c
> > index 79269d2c476b..30ffec63f9a3 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bw.c
> > +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> > @@ -627,11 +627,14 @@ void intel_bw_crtc_update(struct intel_bw_state
> > *bw_state,
> > intel_bw_crtc_data_rate(crtc_state);
> > bw_state->num_active_planes[crtc->pipe] =
> > intel_bw_crtc_num_active_planes(crtc_state);
> > + bw_state->min_cdclk[crtc->pipe] =
> > + intel_bw_crtc_min_cdclk(crtc_state);
> >
> > - drm_dbg_kms(&i915->drm, "pipe %c data rate %u num active planes %u\n",
> > - pipe_name(crtc->pipe),
> > + drm_dbg_kms(&i915->drm, "[CRTC:%d:%s] data rate %u num active planes %u
> > min cdclk %d kHz\n",
> > + crtc->base.base.id, crtc->base.name,
> > bw_state->data_rate[crtc->pipe],
> > - bw_state->num_active_planes[crtc->pipe]);
> > + bw_state->num_active_planes[crtc->pipe],
> > + bw_state->min_cdclk[crtc->pipe]);
> > }
> >
> > static unsigned int intel_bw_num_active_planes(struct drm_i915_private
> > *dev_priv,
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 90bd26431e31..b17b9493c68f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -2498,6 +2498,7 @@ static void intel_crtc_disable_noatomic(struct
> > intel_crtc *crtc,
> >
> > bw_state->data_rate[pipe] = 0;
> > bw_state->num_active_planes[pipe] = 0;
> > + bw_state->min_cdclk[pipe] = 0;
> > }
> >
> > /*
> > @@ -9310,6 +9311,8 @@ static void intel_modeset_readout_hw_state(struct
> > drm_device *dev)
> > to_intel_cdclk_state(dev_priv->cdclk.obj.state);
> > struct intel_dbuf_state *dbuf_state =
> > to_intel_dbuf_state(dev_priv->dbuf.obj.state);
> > + struct intel_bw_state *bw_state =
> > + to_intel_bw_state(dev_priv->bw_obj.state);
> > enum pipe pipe;
> > struct intel_crtc *crtc;
> > struct intel_encoder *encoder;
> > @@ -9425,8 +9428,6 @@ static void intel_modeset_readout_hw_state(struct
> > drm_device *dev)
> > drm_connector_list_iter_end(&conn_iter);
> >
> > for_each_intel_crtc(dev, crtc) {
> > - struct intel_bw_state *bw_state =
> > - to_intel_bw_state(dev_priv->bw_obj.state);
> > struct intel_crtc_state *crtc_state =
> > to_intel_crtc_state(crtc->base.state);
> > struct intel_plane *plane;
> > @@ -9490,6 +9491,8 @@ static void intel_modeset_readout_hw_state(struct
> > drm_device *dev)
> >
> > intel_bw_crtc_update(bw_state, crtc_state);
> > }
> > +
> > + cdclk_state->bw_min_cdclk = intel_bw_min_cdclk(dev_priv, bw_state);
> > }
> >
> > static void
> > --
> > 2.35.1
> >
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH v4 05/31] drm/nouveau: Don't register backlight when another backlight should be used (v2)
Hi Lyude,
Thank you for the review.
On 8/24/22 19:41, Lyude Paul wrote:
> Just one tiny nitpick below:
>
> On Wed, 2022-08-24 at 14:14 +0200, Hans de Goede wrote:
>> Before this commit when we want userspace to use the acpi_video backlight
>> device we register both the GPU's native backlight device and acpi_video's
>> firmware acpi_video# backlight device. This relies on userspace preferring
>> firmware type backlight devices over native ones.
>>
>> Registering 2 backlight devices for a single display really is
>> undesirable, don't register the GPU's native backlight device when
>> another backlight device should be used.
>>
>> Changes in v2:
>> - Add nouveau_acpi_video_backlight_use_native() wrapper to avoid unresolved
>> symbol errors on non X86
>>
>> Signed-off-by: Hans de Goede
>> ---
>> drivers/gpu/drm/nouveau/nouveau_acpi.c | 5 +
>> drivers/gpu/drm/nouveau/nouveau_acpi.h | 2 ++
>> drivers/gpu/drm/nouveau/nouveau_backlight.c | 6 ++
>> 3 files changed, 13 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c
>> b/drivers/gpu/drm/nouveau/nouveau_acpi.c
>> index 6140db756d06..1592c9cd7750 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
>> @@ -386,3 +386,8 @@ nouveau_acpi_edid(struct drm_device *dev, struct
>> drm_connector *connector)
>>
>> return kmemdup(edid, EDID_LENGTH, GFP_KERNEL);
>> }
>> +
>> +bool nouveau_acpi_video_backlight_use_native(void)
>> +{
>> +return acpi_video_backlight_use_native();
>> +}
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.h
>> b/drivers/gpu/drm/nouveau/nouveau_acpi.h
>> index 330f9b837066..3c666c30dfca 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_acpi.h
>> +++ b/drivers/gpu/drm/nouveau/nouveau_acpi.h
>> @@ -11,6 +11,7 @@ void nouveau_register_dsm_handler(void);
>> void nouveau_unregister_dsm_handler(void);
>> void nouveau_switcheroo_optimus_dsm(void);
>> void *nouveau_acpi_edid(struct drm_device *, struct drm_connector *);
>> +bool nouveau_acpi_video_backlight_use_native(void);
>> #else
>> static inline bool nouveau_is_optimus(void) { return false; };
>> static inline bool nouveau_is_v1_dsm(void) { return false; };
>> @@ -18,6 +19,7 @@ static inline void nouveau_register_dsm_handler(void) {}
>> static inline void nouveau_unregister_dsm_handler(void) {}
>> static inline void nouveau_switcheroo_optimus_dsm(void) {}
>> static inline void *nouveau_acpi_edid(struct drm_device *dev, struct
>> drm_connector *connector) { return NULL; }
>> +static inline bool nouveau_acpi_video_backlight_use_native(void) { return
>> true; }
>> #endif
>>
>> #endif
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
>> b/drivers/gpu/drm/nouveau/nouveau_backlight.c
>> index a2141d3d9b1d..d2b8f8c13db4 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
>> @@ -38,6 +38,7 @@
>> #include "nouveau_reg.h"
>> #include "nouveau_encoder.h"
>> #include "nouveau_connector.h"
>> +#include "nouveau_acpi.h"
>>
>> static struct ida bl_ida;
>> #define BL_NAME_SIZE 15 // 12 for name + 2 for digits + 1 for '\0'
>> @@ -405,6 +406,11 @@ nouveau_backlight_init(struct drm_connector *connector)
>> goto fail_alloc;
>> }
>>
>> +if (!nouveau_acpi_video_backlight_use_native()) {
>> +NV_INFO(drm, "Skipping nv_backlight registration\n");
>> +goto fail_alloc;
>> +}
>
> We should probably make this say something like "No native backlight
> interface, using ACPI instead" instead. With that fixed
But that would not be correct. If we get to this point then before
the change we would continue with registering the native backlight
interface.
In other words, the native backlight interface is known to
be available at this point so saying "No native backlight interface"
would not be correct.
The reason the registration is being skipped is because the
drivers/acpi/video_detect.c heuristics (or DMI quirk or cmdline
override) say that another method to control the backlight is
preferred and we want to stop registering the native backlight
alltogether in that case so that there is only
1 /sys/class/backlight entry (on a 1 GPU 1 panel system).
Also "using ACPI instead" is not correct, on older systems
it might e.g. by a vendor specific control method such as
the one from dell-laptop. And on newer systems it might
e.g. be the new nvidia-wmi-ec-backlight driver instead.
So you could say the log message is a bit vague on purpose
because making it detailed would make it very long.
The idea behind the log message is to have something to
check for in dmesg if users start complaining about
/sys/class/backlight/nouveau_bl disappearing.
Normally users should not notice this, because indeed typically
they will then also have an /sys/class/backlight/acpi_video0
which is already preferred over the native one by userspace,
so nothing should change for them. But they could e.g.
have
Re: [Intel-gfx] [PATCH v4 02/31] drm/i915: Don't register backlight when another backlight should be used
Hi All,
On 8/24/22 14:50, Jani Nikula wrote:
> On Wed, 24 Aug 2022, Hans de Goede wrote:
>> Before this commit when we want userspace to use the acpi_video backlight
>> device we register both the GPU's native backlight device and acpi_video's
>> firmware acpi_video# backlight device. This relies on userspace preferring
>> firmware type backlight devices over native ones.
>>
>> Registering 2 backlight devices for a single display really is
>> undesirable, don't register the GPU's native backlight device when
>> another backlight device should be used.
>>
>> Signed-off-by: Hans de Goede
>> ---
>> drivers/gpu/drm/i915/display/intel_backlight.c | 7 +++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c
>> b/drivers/gpu/drm/i915/display/intel_backlight.c
>> index 681ebcda97ad..a4dd7924e0c1 100644
>> --- a/drivers/gpu/drm/i915/display/intel_backlight.c
>> +++ b/drivers/gpu/drm/i915/display/intel_backlight.c
>> @@ -8,6 +8,8 @@
>> #include
>> #include
>>
>> +#include
>> +
>> #include "intel_backlight.h"
>> #include "intel_backlight_regs.h"
>> #include "intel_connector.h"
>> @@ -952,6 +954,11 @@ int intel_backlight_device_register(struct
>> intel_connector *connector)
>>
>> WARN_ON(panel->backlight.max == 0);
>>
>> +if (!acpi_video_backlight_use_native()) {
>> +DRM_INFO("Skipping intel_backlight registration\n");
>
> Could use drm_info with drm_device.
Ack, fixed for v5.
> Either way,
>
> Reviewed-by: Jani Nikula
Thank you.
> and ack for merging via whichever tree suits you best.
My plan is to create a branch with the series on top
of 6.0-rc1 and then send a pull-req to all involved trees.
So far there are no conflicts between this branch and drm-tip...
Regards,
Hans
>> +return 0;
>> +}
>> +
>> memset(&props, 0, sizeof(props));
>> props.type = BACKLIGHT_RAW;
>
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Remove references to uncore from display. (rev2)
== Series Details == Series: drm/i915: Remove references to uncore from display. (rev2) URL : https://patchwork.freedesktop.org/series/107610/ State : success == Summary == CI Bug Log - changes from CI_DRM_12018_full -> Patchwork_107610v2_full Summary --- **SUCCESS** No regressions found. Participating hosts (12 -> 12) -- Additional (1): shard-dg1 Missing(1): shard-rkl Known issues Here are the changes found in Patchwork_107610v2_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@rcs0: - shard-apl: NOTRUN -> [INCOMPLETE][1] ([i915#6598]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107610v2/shard-apl2/igt@gem_ctx_isolation@preservation...@rcs0.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_12018/shard-tglb5/igt@gem_...@in-flight-contexts-10ms.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107610v2/shard-tglb5/igt@gem_...@in-flight-contexts-10ms.html * igt@gem_exec_balancer@parallel-keep-submit-fence: - shard-iclb: [PASS][4] -> [SKIP][5] ([i915#4525]) +2 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12018/shard-iclb1/igt@gem_exec_balan...@parallel-keep-submit-fence.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107610v2/shard-iclb3/igt@gem_exec_balan...@parallel-keep-submit-fence.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][6] -> [FAIL][7] ([i915#2842]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12018/shard-kbl7/igt@gem_exec_fair@basic-n...@vcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107610v2/shard-kbl4/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-glk: [PASS][8] -> [FAIL][9] ([i915#2876]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12018/shard-glk8/igt@gem_exec_fair@basic-p...@vcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107610v2/shard-glk1/igt@gem_exec_fair@basic-p...@vcs0.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-iclb: [PASS][10] -> [FAIL][11] ([i915#2842]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12018/shard-iclb2/igt@gem_exec_fair@basic-p...@vecs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107610v2/shard-iclb3/igt@gem_exec_fair@basic-p...@vecs0.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][12] -> [FAIL][13] ([i915#454]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12018/shard-iclb1/igt@i915_pm...@dc6-psr.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107610v2/shard-iclb3/igt@i915_pm...@dc6-psr.html * igt@kms_ccs@pipe-c-crc-primary-basic-4_tiled_dg2_mc_ccs: - shard-glk: NOTRUN -> [SKIP][14] ([fdo#109271]) +42 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107610v2/shard-glk7/igt@kms_ccs@pipe-c-crc-primary-basic-4_tiled_dg2_mc_ccs.html * igt@kms_ccs@pipe-c-random-ccs-data-y_tiled_gen12_mc_ccs: - shard-apl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#3886]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107610v2/shard-apl2/igt@kms_ccs@pipe-c-random-ccs-data-y_tiled_gen12_mc_ccs.html * igt@kms_chamelium@hdmi-edid-read: - shard-apl: NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827]) +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107610v2/shard-apl2/igt@kms_chamel...@hdmi-edid-read.html * igt@kms_chamelium@hdmi-hpd-for-each-pipe: - shard-glk: NOTRUN -> [SKIP][17] ([fdo#109271] / [fdo#111827]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107610v2/shard-glk7/igt@kms_chamel...@hdmi-hpd-for-each-pipe.html * igt@kms_flip@flip-vs-suspend-interruptible@c-dp1: - shard-kbl: [PASS][18] -> [DMESG-WARN][19] ([i915#180]) +5 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12018/shard-kbl7/igt@kms_flip@flip-vs-suspend-interrupti...@c-dp1.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107610v2/shard-kbl4/igt@kms_flip@flip-vs-suspend-interrupti...@c-dp1.html * igt@kms_flip_scaled_crc@flip-32bpp-4tile-to-32bpp-4tiledg2rcccs-downscaling@pipe-a-default-mode: - shard-iclb: NOTRUN -> [SKIP][20] ([i915#2672]) +3 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107610v2/shard-iclb2/igt@kms_flip_scaled_crc@flip-32bpp-4tile-to-32bpp-4tiledg2rcccs-downscal...@pipe-a-default-mode.html * igt@kms_flip_scaled_crc@flip-64bpp-linear-to-32bpp-linear-downscaling@pipe-a-default-mode: - shard-iclb: [PASS][21] -> [SKIP][22] ([i915#3555]) +1 simil
Re: [Intel-gfx] [PATCH v4 05/31] drm/nouveau: Don't register backlight when another backlight should be used (v2)
Just one tiny nitpick below:
On Wed, 2022-08-24 at 14:14 +0200, Hans de Goede wrote:
> Before this commit when we want userspace to use the acpi_video backlight
> device we register both the GPU's native backlight device and acpi_video's
> firmware acpi_video# backlight device. This relies on userspace preferring
> firmware type backlight devices over native ones.
>
> Registering 2 backlight devices for a single display really is
> undesirable, don't register the GPU's native backlight device when
> another backlight device should be used.
>
> Changes in v2:
> - Add nouveau_acpi_video_backlight_use_native() wrapper to avoid unresolved
> symbol errors on non X86
>
> Signed-off-by: Hans de Goede
> ---
> drivers/gpu/drm/nouveau/nouveau_acpi.c | 5 +
> drivers/gpu/drm/nouveau/nouveau_acpi.h | 2 ++
> drivers/gpu/drm/nouveau/nouveau_backlight.c | 6 ++
> 3 files changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c
> b/drivers/gpu/drm/nouveau/nouveau_acpi.c
> index 6140db756d06..1592c9cd7750 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
> @@ -386,3 +386,8 @@ nouveau_acpi_edid(struct drm_device *dev, struct
> drm_connector *connector)
>
> return kmemdup(edid, EDID_LENGTH, GFP_KERNEL);
> }
> +
> +bool nouveau_acpi_video_backlight_use_native(void)
> +{
> + return acpi_video_backlight_use_native();
> +}
> diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.h
> b/drivers/gpu/drm/nouveau/nouveau_acpi.h
> index 330f9b837066..3c666c30dfca 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_acpi.h
> +++ b/drivers/gpu/drm/nouveau/nouveau_acpi.h
> @@ -11,6 +11,7 @@ void nouveau_register_dsm_handler(void);
> void nouveau_unregister_dsm_handler(void);
> void nouveau_switcheroo_optimus_dsm(void);
> void *nouveau_acpi_edid(struct drm_device *, struct drm_connector *);
> +bool nouveau_acpi_video_backlight_use_native(void);
> #else
> static inline bool nouveau_is_optimus(void) { return false; };
> static inline bool nouveau_is_v1_dsm(void) { return false; };
> @@ -18,6 +19,7 @@ static inline void nouveau_register_dsm_handler(void) {}
> static inline void nouveau_unregister_dsm_handler(void) {}
> static inline void nouveau_switcheroo_optimus_dsm(void) {}
> static inline void *nouveau_acpi_edid(struct drm_device *dev, struct
> drm_connector *connector) { return NULL; }
> +static inline bool nouveau_acpi_video_backlight_use_native(void) { return
> true; }
> #endif
>
> #endif
> diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> index a2141d3d9b1d..d2b8f8c13db4 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> @@ -38,6 +38,7 @@
> #include "nouveau_reg.h"
> #include "nouveau_encoder.h"
> #include "nouveau_connector.h"
> +#include "nouveau_acpi.h"
>
> static struct ida bl_ida;
> #define BL_NAME_SIZE 15 // 12 for name + 2 for digits + 1 for '\0'
> @@ -405,6 +406,11 @@ nouveau_backlight_init(struct drm_connector *connector)
> goto fail_alloc;
> }
>
> + if (!nouveau_acpi_video_backlight_use_native()) {
> + NV_INFO(drm, "Skipping nv_backlight registration\n");
> + goto fail_alloc;
> + }
We should probably make this say something like "No native backlight
interface, using ACPI instead" instead. With that fixed
Reviewed-by: Lyude Paul
> +
> if (!nouveau_get_backlight_name(backlight_name, bl)) {
> NV_ERROR(drm, "Failed to retrieve a unique name for the
> backlight interface\n");
> goto fail_alloc;
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [Intel-gfx] [PATCH v4 12/31] drm/nouveau: Register ACPI video backlight when nv_backlight registration fails (v2)
Reviewed-by: Lyude Paul
On Wed, 2022-08-24 at 14:15 +0200, Hans de Goede wrote:
> Typically the acpi_video driver will initialize before nouveau, which
> used to cause /sys/class/backlight/acpi_video0 to get registered and then
> nouveau would register its own nv_backlight device later. After which
> the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
> to avoid there being 2 backlight devices.
>
> This means that userspace used to briefly see 2 devices and the
> disappearing of acpi_video0 after a brief time confuses the systemd
> backlight level save/restore code, see e.g.:
> https://bbs.archlinux.org/viewtopic.php?id=269920
>
> To fix this the ACPI video code has been modified to make backlight class
> device registration a separate step, relying on the drm/kms driver to
> ask for the acpi_video backlight registration after it is done setting up
> its native backlight device.
>
> Add a call to the new acpi_video_register_backlight() when native backlight
> device registration has failed / was skipped to ensure that there is a
> backlight device available before the drm_device gets registered with
> userspace.
>
> Changes in v2:
> - Add nouveau_acpi_video_register_backlight() wrapper to avoid unresolved
> symbol errors on non X86
>
> Signed-off-by: Hans de Goede
> ---
> drivers/gpu/drm/nouveau/nouveau_acpi.c | 5 +
> drivers/gpu/drm/nouveau/nouveau_acpi.h | 2 ++
> drivers/gpu/drm/nouveau/nouveau_backlight.c | 7 +++
> 3 files changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c
> b/drivers/gpu/drm/nouveau/nouveau_acpi.c
> index 1592c9cd7750..8cf096f841a9 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
> @@ -391,3 +391,8 @@ bool nouveau_acpi_video_backlight_use_native(void)
> {
> return acpi_video_backlight_use_native();
> }
> +
> +void nouveau_acpi_video_register_backlight(void)
> +{
> + acpi_video_register_backlight();
> +}
> diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.h
> b/drivers/gpu/drm/nouveau/nouveau_acpi.h
> index 3c666c30dfca..e39dd8b94b8b 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_acpi.h
> +++ b/drivers/gpu/drm/nouveau/nouveau_acpi.h
> @@ -12,6 +12,7 @@ void nouveau_unregister_dsm_handler(void);
> void nouveau_switcheroo_optimus_dsm(void);
> void *nouveau_acpi_edid(struct drm_device *, struct drm_connector *);
> bool nouveau_acpi_video_backlight_use_native(void);
> +void nouveau_acpi_video_register_backlight(void);
> #else
> static inline bool nouveau_is_optimus(void) { return false; };
> static inline bool nouveau_is_v1_dsm(void) { return false; };
> @@ -20,6 +21,7 @@ static inline void nouveau_unregister_dsm_handler(void) {}
> static inline void nouveau_switcheroo_optimus_dsm(void) {}
> static inline void *nouveau_acpi_edid(struct drm_device *dev, struct
> drm_connector *connector) { return NULL; }
> static inline bool nouveau_acpi_video_backlight_use_native(void) { return
> true; }
> +static inline void nouveau_acpi_video_register_backlight(void) {}
> #endif
>
> #endif
> diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> index d2b8f8c13db4..a614582779ca 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> @@ -436,6 +436,13 @@ nouveau_backlight_init(struct drm_connector *connector)
>
> fail_alloc:
> kfree(bl);
> + /*
> + * If we get here we have an internal panel, but no nv_backlight,
> + * try registering an ACPI video backlight device instead.
> + */
> + if (ret == 0)
> + nouveau_acpi_video_register_backlight();
> +
> return ret;
> }
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [Intel-gfx] [PATCH v4 31/31] drm/todo: Add entry about dealing with brightness control on devices with > 1 panel
Reviewed-by: Lyude Paul On Wed, 2022-08-24 at 14:15 +0200, Hans de Goede wrote: > Add an entry summarizing the discussion about dealing with brightness > control on devices with more then 1 internal panel. > > The original discussion can be found here: > https://lore.kernel.org/dri-devel/20220517152331.16217-1-hdego...@redhat.com/ > > Signed-off-by: Hans de Goede > --- > Documentation/gpu/todo.rst | 68 ++ > 1 file changed, 68 insertions(+) > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > index 7634c27ac562..393d218e4a0c 100644 > --- a/Documentation/gpu/todo.rst > +++ b/Documentation/gpu/todo.rst > @@ -679,6 +679,74 @@ Contact: Sam Ravnborg > > Level: Advanced > > +Brightness handling on devices with multiple internal panels > + > + > +On x86/ACPI devices there can be multiple backlight firmware interfaces: > +(ACPI) video, vendor specific and others. As well as direct/native (PWM) > +register programming by the KMS driver. > + > +To deal with this backlight drivers used on x86/ACPI call > +acpi_video_get_backlight_type() which has heuristics (+quirks) to select > +which backlight interface to use; and backlight drivers which do not match > +the returned type will not register themselves, so that only one backlight > +device gets registered (in a single GPU setup, see below). > + > +At the moment this more or less assumes that there will only > +be 1 (internal) panel on a system. > + > +On systems with 2 panels this may be a problem, depending on > +what interface acpi_video_get_backlight_type() selects: > + > +1. native: in this case the KMS driver is expected to know which backlight > + device belongs to which output so everything should just work. > +2. video: this does support controlling multiple backlights, but some work > + will need to be done to get the output <-> backlight device mapping > + > +The above assumes both panels will require the same backlight interface type. > +Things will break on systems with multiple panels where the 2 panels need > +a different type of control. E.g. one panel needs ACPI video backlight > control, > +where as the other is using native backlight control. Currently in this case > +only one of the 2 required backlight devices will get registered, based on > +the acpi_video_get_backlight_type() return value. > + > +If this (theoretical) case ever shows up, then supporting this will need some > +work. A possible solution here would be to pass a device and connector-name > +to acpi_video_get_backlight_type() so that it can deal with this. > + > +Note in a way we already have a case where userspace sees 2 panels, > +in dual GPU laptop setups with a mux. On those systems we may see > +either 2 native backlight devices; or 2 native backlight devices. > + > +Userspace already has code to deal with this by detecting if the related > +panel is active (iow which way the mux between the GPU and the panels > +points) and then uses that backlight device. Userspace here very much > +assumes a single panel though. It picks only 1 of the 2 backlight devices > +and then only uses that one. > + > +Note that all userspace code (that I know off) is currently hardcoded > +to assume a single panel. > + > +Before the recent changes to not register multiple (e.g. video + native) > +/sys/class/backlight devices for a single panel (on a single GPU laptop), > +userspace would see multiple backlight devices all controlling the same > +backlight. > + > +To deal with this userspace had to always picks one preferred device under > +/sys/class/backlight and will ignore the others. So to support brightness > +control on multiple panels userspace will need to be updated too. > + > +There are plans to allow brightness control through the KMS API by adding > +a "display brightness" property to drm_connector objects for panels. This > +solves a number of issues with the /sys/class/backlight API, including not > +being able to map a sysfs backlight device to a specific connector. Any > +userspace changes to add support for brightness control on devices with > +multiple panels really should build on top of this new KMS property. > + > +Contact: Hans de Goede > + > +Level: Advanced > + > Outside DRM > === > -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat
Re: [Intel-gfx] [PATCH v2 05/21] drm/i915/mtl: Define engine context layouts
On 18.08.2022 16:41, Radhakrishna Sripada wrote:
> From: Matt Roper
>
> The part of the media and blitter engine contexts that we care about for
> setting up an initial state are the same on MTL as they were on DG2
> (and PVC), so we need to update the driver conditions to re-use the DG2
> context table.
>
> For render/compute engines, the part of the context images are nearly
> the same, although the layout had a very slight change --- one POSH
> register was removed and the placement of some LRI/noops adjusted
> slightly to compensate.
>
> Bspec: 46261, 46260, 45585
> Signed-off-by: Matt Roper
> Signed-off-by: Radhakrishna Sripada
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 47 -
> 1 file changed, 46 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index eec73c66406c..d3833cbaabcb 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -606,6 +606,49 @@ static const u8 dg2_rcs_offsets[] = {
> END
> };
>
> +static const u8 mtl_rcs_offsets[] = {
> + NOP(1),
> + LRI(15, POSTED),
> + REG16(0x244),
> + REG(0x034),
> + REG(0x030),
> + REG(0x038),
> + REG(0x03c),
> + REG(0x168),
> + REG(0x140),
> + REG(0x110),
> + REG(0x1c0),
> + REG(0x1c4),
> + REG(0x1c8),
> + REG(0x180),
> + REG16(0x2b4),
Inspecting Bspecs 46261 and 46260 indicates the following 2 registers
are replaced by NOP for MTL. Can you check?
> + REG(0x120),
> + REG(0x124),
> +
> + NOP(1),
> + LRI(9, POSTED),
> + REG16(0x3a8),
> + REG16(0x28c),
> + REG16(0x288),
> + REG16(0x284),
> + REG16(0x280),
> + REG16(0x27c),
> + REG16(0x278),
> + REG16(0x274),
> + REG16(0x270),
> +
> + NOP(2),
> + LRI(2, POSTED),
> + REG16(0x5a8),
> + REG16(0x5ac),
> +
> + NOP(6),
> + LRI(1, 0),
> + REG(0x0c8),
> +
> + END
> +};
> +
> #undef END
> #undef REG16
> #undef REG
> @@ -624,7 +667,9 @@ static const u8 *reg_offsets(const struct intel_engine_cs
> *engine)
> !intel_engine_has_relative_mmio(engine));
>
> if (engine->flags & I915_ENGINE_HAS_RCS_REG_STATE) {
> - if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 55))
> + if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 70))
> + return mtl_rcs_offsets;
> + else if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 55))
> return dg2_rcs_offsets;
> else if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 50))
> return xehp_rcs_offsets;
Similarly from Bpsec 45582, the same 2 registers indicated above is
replaced by NOP even in Copy and Blitter engine contexts in MTL compared
to DG2. So we have to create a new structure for MTL for Copy and Media
engine contexts.
Regards,
Bala
> --
> 2.25.1
>
Re: [Intel-gfx] [PATCH] drm/i915: Switch TGL-H DP-IN to dGFX when it's supported
On Wed, Aug 24, 2022 at 7:50 PM Kai-Heng Feng
wrote:
>
> On Tue, Aug 16, 2022 at 4:06 PM Jani Nikula
> wrote:
> >
> > On Tue, 16 Aug 2022, Kai-Heng Feng wrote:
> > > On mobile workstations like HP ZBook Fury G8, iGFX's DP-IN can switch to
> > > dGFX so external monitors are routed to dGFX, and more monitors can be
> > > supported as result.
> > >
> > > To switch the DP-IN to dGFX, the driver needs to invoke _DSM function 20
> > > on intel_dsm_guid2. This method is described in Intel document 632107.
> >
> > Is this the policy decision that we want to unconditionally make,
> > though?
>
> I believes so, so more external monitors can be supported at the same time.
>
if there wouldn't be any drawbacks, yes, but sadly there are and I
don't see that hurting _all_ users affected with this by making their
system consume/generate around 10-15W more power/heat just that maybe
one user can use 4 instead of 3 displays at 4K is really worth it...
> Kai-Heng
>
> >
> > BR,
> > Jani.
> >
> > >
> > > Signed-off-by: Kai-Heng Feng
> > > ---
> > > drivers/gpu/drm/i915/display/intel_acpi.c | 18 +-
> > > 1 file changed, 17 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c
> > > b/drivers/gpu/drm/i915/display/intel_acpi.c
> > > index e78430001f077..3bd5930e2769b 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_acpi.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_acpi.c
> > > @@ -20,6 +20,7 @@ static const guid_t intel_dsm_guid =
> > > 0xa8, 0x54, 0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c);
> > >
> > > #define INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED 0 /* No args */
> > > +#define INTEL_DSM_FN_DP_IN_SWITCH_TO_DGFX 20 /* No args */
> > >
> > > static const guid_t intel_dsm_guid2 =
> > > GUID_INIT(0x3e5b41c6, 0xeb1d, 0x4260,
> > > @@ -187,6 +188,7 @@ void intel_dsm_get_bios_data_funcs_supported(struct
> > > drm_i915_private *i915)
> > > struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> > > acpi_handle dhandle;
> > > union acpi_object *obj;
> > > + int supported = 0;
> > >
> > > dhandle = ACPI_HANDLE(&pdev->dev);
> > > if (!dhandle)
> > > @@ -194,8 +196,22 @@ void intel_dsm_get_bios_data_funcs_supported(struct
> > > drm_i915_private *i915)
> > >
> > > obj = acpi_evaluate_dsm(dhandle, &intel_dsm_guid2,
> > > INTEL_DSM_REVISION_ID,
> > > INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED,
> > > NULL);
> > > - if (obj)
> > > + if (obj) {
> > > + if (obj->type == ACPI_TYPE_INTEGER)
> > > + supported = obj->integer.value;
> > > +
> > > ACPI_FREE(obj);
> > > + }
> > > +
> > > + /* Tiger Lake H DP-IN Boot Time Switching from iGfx to dGfx */
> > > + if (supported & BIT(20)) {
> > > + obj = acpi_evaluate_dsm(dhandle, &intel_dsm_guid2,
> > > + INTEL_DSM_REVISION_ID,
> > > + INTEL_DSM_FN_DP_IN_SWITCH_TO_DGFX,
> > > + NULL);
> > > + if (obj)
> > > + ACPI_FREE(obj);
> > > + }
> > > }
> > >
> > > /*
> >
> > --
> > Jani Nikula, Intel Open Source Graphics Center
>
[Intel-gfx] ✓ Fi.CI.IGT: success for Fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation
== Series Details == Series: Fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation URL : https://patchwork.freedesktop.org/series/107667/ State : success == Summary == CI Bug Log - changes from CI_DRM_12018_full -> Patchwork_107667v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (12 -> 13) -- Additional (1): shard-dg1 Known issues Here are the changes found in Patchwork_107667v1_full that come from known issues: ### IGT changes ### Issues hit * igt@api_intel_bb@object-noreloc-keep-cache-simple: - shard-snb: NOTRUN -> [SKIP][1] ([fdo#109271]) +40 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107667v1/shard-snb6/igt@api_intel...@object-noreloc-keep-cache-simple.html * igt@gem_ctx_isolation@preservation-s3@rcs0: - shard-apl: NOTRUN -> [INCOMPLETE][2] ([i915#6598]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107667v1/shard-apl2/igt@gem_ctx_isolation@preservation...@rcs0.html * igt@gem_exec_balancer@parallel: - shard-iclb: [PASS][3] -> [SKIP][4] ([i915#4525]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12018/shard-iclb2/igt@gem_exec_balan...@parallel.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107667v1/shard-iclb3/igt@gem_exec_balan...@parallel.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglb: [PASS][5] -> [FAIL][6] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12018/shard-tglb5/igt@gem_exec_fair@basic-f...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107667v1/shard-tglb7/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-glk: NOTRUN -> [FAIL][7] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107667v1/shard-glk8/igt@gem_exec_fair@basic-none-r...@rcs0.html - shard-iclb: NOTRUN -> [FAIL][8] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107667v1/shard-iclb5/igt@gem_exec_fair@basic-none-r...@rcs0.html - shard-tglb: NOTRUN -> [FAIL][9] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107667v1/shard-tglb5/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-glk: [PASS][10] -> [FAIL][11] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12018/shard-glk8/igt@gem_exec_fair@basic-p...@vcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107667v1/shard-glk5/igt@gem_exec_fair@basic-p...@vcs0.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-iclb: [PASS][12] -> [FAIL][13] ([i915#2842]) +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12018/shard-iclb2/igt@gem_exec_fair@basic-p...@vecs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107667v1/shard-iclb2/igt@gem_exec_fair@basic-p...@vecs0.html * igt@gem_pxp@reject-modify-context-protection-off-2: - shard-tglb: NOTRUN -> [SKIP][14] ([i915#4270]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107667v1/shard-tglb5/igt@gem_...@reject-modify-context-protection-off-2.html - shard-iclb: NOTRUN -> [SKIP][15] ([i915#4270]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107667v1/shard-iclb5/igt@gem_...@reject-modify-context-protection-off-2.html * igt@gem_render_copy@y-tiled-to-vebox-linear: - shard-iclb: NOTRUN -> [SKIP][16] ([i915#768]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107667v1/shard-iclb6/igt@gem_render_c...@y-tiled-to-vebox-linear.html * igt@gen9_exec_parse@allowed-single: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#5566] / [i915#716]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12018/shard-kbl7/igt@gen9_exec_pa...@allowed-single.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107667v1/shard-kbl4/igt@gen9_exec_pa...@allowed-single.html * igt@kms_big_fb@4-tiled-8bpp-rotate-270: - shard-tglb: NOTRUN -> [SKIP][19] ([i915#5286]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107667v1/shard-tglb7/igt@kms_big...@4-tiled-8bpp-rotate-270.html - shard-iclb: NOTRUN -> [SKIP][20] ([i915#5286]) +1 similar issue [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107667v1/shard-iclb6/igt@kms_big...@4-tiled-8bpp-rotate-270.html * igt@kms_big_fb@linear-64bpp-rotate-90: - shard-tglb: NOTRUN -> [SKIP][21] ([fdo#111614]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107667v1/shard-tglb5/igt@kms_big...@linear-64bpp-rotate-90.html - shard-iclb: NOTRUN -> [SKIP][22] ([fdo#110725] / [fdo#111614]) [22]: https://intel-gfx-
Re: [Intel-gfx] [PATCH] drm/i915/display: Fix warning callstack for imbalance wakeref
On Tue, Aug 23, 2022 at 03:56:56PM +0300, Golani, Mitulkumar Ajitkumar wrote: > > Hi Imre, > > > > > On Fri, Aug 12, 2022 at 10:17:24AM +0530, Mitul Golani wrote: > > > > While executing i915_selftest, wakeref imbalance warning is seen > > > > with i915_selftest failure. > > > > > > > > When device is already suspended, wakeref is acquired by > > > > disable_rpm_wakeref_asserts and rpm ownership is transferred back to > > > > core. During this case wakeref_count will not be zero. > > > > Once driver is unregistered, this wakeref is released with > > > > enable_rpm_wakeref_asserts and balancing wakeref_count acquired by > > > > driver. > > > > > > > > This patch will fix the warning callstack by adding check if device > > > > is already suspended and rpm ownership transfer is going on. > > > > > > > > Signed-off-by: Mitul Golani > > > > --- > > > > drivers/gpu/drm/i915/i915_driver.c | 8 +++- > > > > 1 file changed, 7 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/gpu/drm/i915/i915_driver.c > > > > b/drivers/gpu/drm/i915/i915_driver.c > > > > index deb8a8b76965..6530a8680cfd 100644 > > > > --- a/drivers/gpu/drm/i915/i915_driver.c > > > > +++ b/drivers/gpu/drm/i915/i915_driver.c > > > > @@ -1670,7 +1670,13 @@ static int intel_runtime_resume(struct device > > > > *kdev) > > > > > > > > drm_dbg(&dev_priv->drm, "Resuming device\n"); > > > > > > > > - drm_WARN_ON_ONCE(&dev_priv->drm, atomic_read(&rpm- > > > >wakeref_count)); > > > > + /* > > > > + * When device is already suspended, Wakeref is acquired by > > > disable_rpm_wakeref_asserts > > > > + * and rpm ownership is transferred back to core. During this case > > > wakeref_count will > > > > + * not be zero. Once driver is unregistered, this wakeref is > > > > +released > > > with > > > > + * enable_rpm_wakeref_asserts and balancing wakeref_count > > > acquired by driver. > > > > + */ > > > > + drm_WARN_ON_ONCE(&dev_priv->drm, atomic_read(&rpm- > > > >wakeref_count) && > > > > +!rpm->suspended); > > > > > > I can't see how disable/enable_rpm_wakeref_asserts() can lead to this > > > WARN. They are always called in pairs both in intel_runtime_suspend() > > > and intel_runtime_resume(), leaving rpm->wakeref_count unchanged. > > > > > > The root cause is probably somewhere else, incrementing > > > rpm->wakeref_count without runtime resuming the device. > > > > > > The WARN() condition is corret, we shouldn't get here with a non-zero > > > wakeref_count. rpm->suspended - set in intel_runtime_suspend() and > > > cleared in intel_runtime_resume() - should be always false here, so > > > the above change would just disable the WARN in all cases. > > > > > Yes, in case of DG2, after device is suspended, i915_driver_remove > > is being called. Here driver is taking wakeref with > > disable_rpm_wakeref_asserts when device was not resumed. > > > > As per logs, > > [ 395.872971] i915 :03:00.0: [drm:intel_runtime_suspend [i915]] > > Suspending device ... > > [ 403.553235] i915_driver_remove: START wakeref=0 [ 403.553288] > > i915_driver_remove: before unregister i915 wakeref=65537 (Wakeref Taken) > > [ 403.566086] i915 :03:00.0: [drm:intel_runtime_resume [i915]] > > Resuming device (Later Resuming Device) > > > > Pushed new change with : > > https://patchwork.freedesktop.org/series/107211/#rev5 > > > Also when compared DG2 logs with ADLP working logs, > Already 1 wakeref was taken by DMC firmware(i915/adlp_dmc_ver2_16.bin > (v2.16)), in-case of DG2 looks to be missing. > To support other targets and to prevent consecutive resuming device added > following check, > if (i915->runtime_pm.suspended && > !atomic_read(&i915->runtime_pm.wakeref_count)) > > ADLP Logs: > --- > [ 99.502434] i915_driver_probe: START wakeref=0 > [ 713.979074] i915 :00:02.0: [drm] Finished loading DMC firmware > i915/adlp_dmc_ver2_16.bin (v2.16) > [ 102.455766] i915_driver_probe: END wakeref=65538 > ... > [ 103.448570] i915_driver_remove: START wakeref=65537 > [ 103.448587] i915_driver_remove: before unregister i915 wakeref=131074 -> > (disable_rpm_wakeref_assert) > [ 103.585886] i915_driver_remove: END wakeref=0 > > DG2 Logs: > - > [ 1271.704314] i915_driver_probe: START wakeref=0 > [ 383.050984] i915 :03:00.0: [drm] Finished loading DMC firmware > i915/dg2_dmc_ver2_07.bin (v2.7) > [ 1272.021133] i915_driver_probe: END wakeref=1 > ... > [ 395.883531] i915 :03:00.0: [drm:intel_runtime_suspend [i915]] Device > suspended > ... > [ 1291.450841] i915_driver_remove: START wakeref=0 > [ 1291.450877] i915_driver_remove: before unregister i915 wakeref=65537 -> > (disable_rpm_wakeref_assert) > [ 1291.603281] i915_driver_remove: END wakeref=0 Still not sure what's going. Both i915_pci_probe() and i915_pci_remove()->i915_driver_remove() is called with a runtime PM reference - taken at local_pci_probe() and pci_device_remove() - and so the device should be runtime resumed at those points. > > > > disable_rpm_wa
[Intel-gfx] [PATCH 0/1] DGFX mmap with rpm
As per PCIe Spec Section 5.3.1.4.1 When pcie function is in d3hot state, Configuration and Message requests are the only TLPs accepted by a Function in the D3hot state. All other received Requests must be handled as Unsupported Requests, and all received Completions may optionally be handled as Unexpected Completions. Therefore when gfx endpoint function is in d3 state, all pcie iomem transaction requires to transition the pcie function in D0 state. This is formal patch extension of RFC proposal https://patchwork.freedesktop.org/series/107400/ Implementation of handling i915_gem_object_pin_map will be handled in different series. Anshuman Gupta (1): drm/i915/dgfx: Release mmap on rpm suspend .../gpu/drm/i915/gem/i915_gem_object_types.h | 3 +- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 48 --- drivers/gpu/drm/i915/gt/intel_gt.c| 2 + drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 ++ drivers/gpu/drm/i915/i915_gem.c | 8 5 files changed, 57 insertions(+), 7 deletions(-) -- 2.26.2
[Intel-gfx] [PATCH 1/1] drm/i915/dgfx: Release mmap on rpm suspend
Release all mmap mapping for all lmem objects which are associated
with userfault such that, while pcie function in D3hot, any access
to memory mappings will raise a userfault.
Runtime resume the dgpu(when gem object lies in lmem).
This will transition the dgpu graphics function to D0
state if it was in D3 in order to access the mmap memory
mappings.
v2:
- Squashes the patches. [Matt Auld]
- Add adequate locking for lmem_userfault_list addition. [Matt Auld]
- Reused obj->userfault_count to avoid double addition. [Matt Auld]
- Added i915_gem_object_lock to check
i915_gem_object_is_lmem. [Matt Auld]
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6331
Cc: Matthew Auld
Cc: Rodrigo Vivi
Signed-off-by: Anshuman Gupta
---
.../gpu/drm/i915/gem/i915_gem_object_types.h | 3 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 48 ---
drivers/gpu/drm/i915/gt/intel_gt.c| 2 +
drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 ++
drivers/gpu/drm/i915/i915_gem.c | 8
5 files changed, 57 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 9f6b14ec189a..40305e2bcd49 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -298,7 +298,8 @@ struct drm_i915_gem_object {
};
/**
-* Whether the object is currently in the GGTT mmap.
+* Whether the object is currently in the GGTT or any other supported
+* fake offset mmap backed by lmem.
*/
unsigned int userfault_count;
struct list_head userfault_link;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 5a5cf332d8a5..6532a634bd20 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1014,12 +1014,29 @@ static void i915_ttm_delayed_free(struct
drm_i915_gem_object *obj)
ttm_bo_put(i915_gem_to_ttm(obj));
}
+static intel_wakeref_t
+i915_gem_ttm_get_lmem_obj_wakeref(struct drm_i915_gem_object *obj)
+{
+ intel_wakeref_t wakeref = 0;
+
+ if (i915_gem_object_lock_interruptible(obj, NULL))
+ return 0;
+
+ if (i915_gem_object_is_lmem(obj))
+ wakeref =
intel_runtime_pm_get(&to_i915(obj->base.dev)->runtime_pm);
+
+ i915_gem_object_unlock(obj);
+
+ return wakeref;
+}
+
static vm_fault_t vm_fault_ttm(struct vm_fault *vmf)
{
struct vm_area_struct *area = vmf->vma;
struct ttm_buffer_object *bo = area->vm_private_data;
struct drm_device *dev = bo->base.dev;
struct drm_i915_gem_object *obj;
+ intel_wakeref_t wakeref = 0;
vm_fault_t ret;
int idx;
@@ -1027,18 +1044,23 @@ static vm_fault_t vm_fault_ttm(struct vm_fault *vmf)
if (!obj)
return VM_FAULT_SIGBUS;
+ wakeref = i915_gem_ttm_get_lmem_obj_wakeref(obj);
+
/* Sanity check that we allow writing into this object */
if (unlikely(i915_gem_object_is_readonly(obj) &&
-area->vm_flags & VM_WRITE))
- return VM_FAULT_SIGBUS;
+area->vm_flags & VM_WRITE)) {
+ ret = VM_FAULT_SIGBUS;
+ goto out_rpm;
+ }
ret = ttm_bo_vm_reserve(bo, vmf);
if (ret)
- return ret;
+ goto out_rpm;
if (obj->mm.madv != I915_MADV_WILLNEED) {
dma_resv_unlock(bo->base.resv);
- return VM_FAULT_SIGBUS;
+ ret = VM_FAULT_SIGBUS;
+ goto out_rpm;
}
if (!i915_ttm_resource_mappable(bo->resource)) {
@@ -1062,7 +1084,8 @@ static vm_fault_t vm_fault_ttm(struct vm_fault *vmf)
if (err) {
drm_dbg(dev, "Unable to make resource CPU
accessible\n");
dma_resv_unlock(bo->base.resv);
- return VM_FAULT_SIGBUS;
+ ret = VM_FAULT_SIGBUS;
+ goto out_rpm;
}
}
@@ -1073,12 +1096,25 @@ static vm_fault_t vm_fault_ttm(struct vm_fault *vmf)
} else {
ret = ttm_bo_vm_dummy_page(vmf, vmf->vma->vm_page_prot);
}
+
+ /* ttm_bo_vm_reserve() already has dma_resv_lock */
+ if (!ret && i915_gem_object_is_lmem(obj) && !obj->userfault_count++) {
+ mutex_lock(&to_gt(to_i915(obj->base.dev))->lmem_userfault_lock);
+ list_add(&obj->userfault_link,
&to_gt(to_i915(obj->base.dev))->lmem_userfault_list);
+
mutex_unlock(&to_gt(to_i915(obj->base.dev))->lmem_userfault_lock);
+ }
+
if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
- return ret;
+ goto out_rpm;
i915_ttm_adjust_lru(obj);
dma_resv_unlock(bo->base.resv);
+
+out_rpm:
+ if (wa
Re: [Intel-gfx] [PATCH v6 3/4] drm/i915/display: add hotplug.suspended flag
On 24.08.2022 13:22, Imre Deak wrote: On Tue, Aug 23, 2022 at 11:48:01PM +0200, Andrzej Hajda wrote: On 22.08.2022 19:27, Imre Deak wrote: On Fri, Jul 22, 2022 at 02:51:42PM +0200, Andrzej Hajda wrote: HPD events during driver removal can be generated by hardware and software frameworks - drm_dp_mst, the former we can avoid by disabling interrupts, the latter can be triggered by any drm_dp_mst transaction, and this is too late. Introducing suspended flag allows to solve this chicken-egg problem. intel_hpd_cancel_work() is always called after suspending MST and disabling IRQs (with the order I suggested in patch 1). If both of these have disabled the corresponding functionality (MST, IRQs) properly with all their MST/IRQ scheduled works guaranteed to not get rescheduled, then it's not clear how could either intel_hpd_trigger_irq() or an IRQ work run. So the problematic sequence would need a better explanation. I am not familiar with MST but as I understand from earlier discussion MST framework can be called during driver removal code even after intel_dp_mst_suspend. Not sure how that happens, but it looks wrong. One way I can imagine is that connector detection re-enables MST, which should be prevented then. I am not MST expert and atm I have no access to the machine on which I could look for real prove. As I understand intel_dp_mst_suspend prevents only downstream devices to initiate transactions, it does not prevent transactions initiated from i915 driver. My guesses for such transactions are: - any ioctl/sysfs/drm_property access initiated by user which can involve MST tranaction (set brightness, read EDID, reading capabilities, statuses, ), unless they are already blocked, how? - maybe some mode_config disabling code (for example intel_mst_disable_dp) - intel_mode_config_cleanup is called after intel_dp_mst_suspend. And since MST transfer can timeout it can trigger drm_dp_mst_wait_tx_reply --> mgr->cbs->poll_hpd_irq(mgr) --> intel_dp_mst_poll_hpd_irq --> intel_hpd_trigger_irq. If such situation happens after intel_dp_mst_suspend i915->hotplug.dig_port_work will be queued, and we have risk of use-after-free. If this analysis looks incorrect I can send patches 1, 2, 4 with your comments addressed. CI probably will verify this anyway. Regards Andrzej And since MST transfer can timeout it can trigger drm_dp_mst_wait_tx_reply --> mgr->cbs->poll_hpd_irq(mgr) --> intel_dp_mst_poll_hpd_irq --> intel_hpd_trigger_irq. So actually this patch supersedes the 1st patch. There's also already dev_priv->runtime_pm.irqs_enabled showing if hotplug interrupts are disabled (along with all other IRQs). So it is slightly different, this patch introduces flag indicating if HPD is enabled, we can have IRQs not related to HPD, and HPD events not related to IRQs. In its current form I can't see a difference. What would make sense is to add a flag that prevents connector detection (which would incorrectly enable MST for instace), but leave the handling of other interrupts enabled. That flag would be set already before suspending MST. Regards Andrzej Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5950 Signed-off-by: Andrzej Hajda Reviewed-by: Arun R Murthy --- drivers/gpu/drm/i915/display/intel_display.c | 2 +- drivers/gpu/drm/i915/display/intel_hotplug.c | 11 ++- drivers/gpu/drm/i915/display/intel_hotplug.h | 2 +- drivers/gpu/drm/i915/i915_driver.c | 4 ++-- drivers/gpu/drm/i915/i915_drv.h | 2 ++ 5 files changed, 16 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index f1c765ac7ab8aa..cd6139bb36151b 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -9022,7 +9022,7 @@ void intel_modeset_driver_remove_noirq(struct drm_i915_private *i915) intel_dp_mst_suspend(i915); /* MST is the last user of HPD work */ - intel_hpd_cancel_work(i915); + intel_hpd_suspend(i915); /* poll work can call into fbdev, hence clean that up afterwards */ intel_fbdev_fini(i915); diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c b/drivers/gpu/drm/i915/display/intel_hotplug.c index 5f8b4f481cff9a..e1d384cb99df6b 100644 --- a/drivers/gpu/drm/i915/display/intel_hotplug.c +++ b/drivers/gpu/drm/i915/display/intel_hotplug.c @@ -303,6 +303,8 @@ static void i915_digport_work_func(struct work_struct *work) u32 old_bits = 0; spin_lock_irq(&dev_priv->irq_lock); + if (dev_priv->hotplug.suspended) + return spin_unlock_irq(&dev_priv->irq_lock); long_port_mask = dev_priv->hotplug.long_port_mask; dev_priv->hotplug.long_port_mask = 0; short_port_mask = dev_priv->hotplug.short_port_mask; @@ -353,6 +355,8 @@ void intel_hpd_trigger_irq(struct intel_digital_port *dig_port) struct drm_i915_private
Re: [Intel-gfx] [PATCH] drm/i915/glk: ECS Liva Q2 needs GLK HDMI port timing quirk
On Thu, Jun 16, 2022 at 03:41:37PM +0300, Jani Nikula wrote:
> From: Diego Santa Cruz
>
> The quirk added in upstream commit 90c3e2198777 ("drm/i915/glk: Add
> Quirk for GLK NUC HDMI port issues.") is also required on the ECS Liva
> Q2.
>
> Note: Would be nicer to figure out the extra delay required for the
> retimer without quirks, however don't know how to check for that.
>
> Cc: sta...@vger.kernel.org
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1326
> Signed-off-by: Diego Santa Cruz
> Signed-off-by: Jani Nikula
Seems fine. Although I do wonder whether we could directly identify the
bogus retimer chip via the dual mode adapter registers. I've asked for
that in the bug.
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_quirks.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c
> b/drivers/gpu/drm/i915/display/intel_quirks.c
> index c8488f5ebd04..e415cd7c0b84 100644
> --- a/drivers/gpu/drm/i915/display/intel_quirks.c
> +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
> @@ -191,6 +191,9 @@ static struct intel_quirk intel_quirks[] = {
> /* ASRock ITX*/
> { 0x3185, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
> { 0x3184, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
> + /* ECS Liva Q2 */
> + { 0x3185, 0x1019, 0xa94d, quirk_increase_ddi_disabled_time },
> + { 0x3184, 0x1019, 0xa94d, quirk_increase_ddi_disabled_time },
> };
>
> void intel_init_quirks(struct drm_i915_private *i915)
> --
> 2.30.2
--
Ville Syrjälä
Intel
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for DGFX mmap with rpm (rev2)
== Series Details == Series: DGFX mmap with rpm (rev2) URL : https://patchwork.freedesktop.org/series/107400/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✓ Fi.CI.BAT: success for DGFX mmap with rpm (rev2)
== Series Details ==
Series: DGFX mmap with rpm (rev2)
URL : https://patchwork.freedesktop.org/series/107400/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12024 -> Patchwork_107400v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/index.html
Participating hosts (35 -> 35)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_107400v2:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@gt_heartbeat:
- {bat-dg2-10}: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/bat-dg2-10/igt@i915_selftest@live@gt_heartbeat.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/bat-dg2-10/igt@i915_selftest@live@gt_heartbeat.html
Known issues
Here are the changes found in Patchwork_107400v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][3] -> [INCOMPLETE][4] ([i915#4785])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka: [PASS][5] -> [FAIL][6] ([i915#6298])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12024/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
* igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][7] ([fdo#109271] / [i915#4312] /
[i915#5594] / [i915#6246])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/fi-hsw-4770/igt@run...@aborted.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
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
[i915#5594]: https://gitlab.freedesktop.org/drm/intel/issues/5594
[i915#6246]: https://gitlab.freedesktop.org/drm/intel/issues/6246
[i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#6380]: https://gitlab.freedesktop.org/drm/intel/issues/6380
Build changes
-
* Linux: CI_DRM_12024 -> Patchwork_107400v2
CI-20190529: 20190529
CI_DRM_12024: 656b7e74f416705f11953d30cda518a98f18ba2e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6636: 1298b5f0e1b3e010657ffba41d2e775fab028e08 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_107400v2: 656b7e74f416705f11953d30cda518a98f18ba2e @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
0da1a5ee767f drm/i915/dgfx: Release mmap on rpm suspend
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107400v2/index.html
[Intel-gfx] [PATCH 0/7] drm/i915: Add HWMON support
This series adds the HWMON support for DGFX v2: - Reorganized series. Created first patch as infrastructure patch followed by feature patches. (Ashutosh) - Fixed review comments (Jani) - Fixed review comments (Ashutosh) v3: - Fixed review comments from Guenter - Exposed energy inferface as standard hwmon interface (Ashutosh) - For power interface added entries for critical power and maintained standard interface for all the entries except power1_max_interval - Extended support for XEHPSDV (Ashutosh) v4: - Fixed review comment from Guenter - Cleaned up unused code v5: - Fixed review comments (Jani) Ashutosh Dixit (2): drm/i915/hwmon: Expose card reactive critical power drm/i915/hwmon: Expose power1_max_interval Dale B Stimson (4): drm/i915/hwmon: Add HWMON infrastructure drm/i915/hwmon: Power PL1 limit and TDP setting drm/i915/hwmon: Show device level energy usage drm/i915/hwmon: Extend power/energy for XEHPSDV Riana Tauro (1): drm/i915/hwmon: Add HWMON current voltage support .../ABI/testing/sysfs-driver-intel-i915-hwmon | 75 ++ drivers/gpu/drm/i915/Makefile | 3 + drivers/gpu/drm/i915/gt/intel_gt_regs.h | 8 + drivers/gpu/drm/i915/i915_driver.c| 5 + drivers/gpu/drm/i915/i915_drv.h | 2 + drivers/gpu/drm/i915/i915_hwmon.c | 788 ++ drivers/gpu/drm/i915/i915_hwmon.h | 21 + drivers/gpu/drm/i915/i915_reg.h | 22 + drivers/gpu/drm/i915/intel_mchbar_regs.h | 12 + 9 files changed, 936 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon create mode 100644 drivers/gpu/drm/i915/i915_hwmon.c create mode 100644 drivers/gpu/drm/i915/i915_hwmon.h -- 2.25.1
[Intel-gfx] [PATCH 5/7] drm/i915/hwmon: Expose card reactive critical power
From: Ashutosh Dixit
Expose the card reactive critical (I1) power. I1 is exposed as
power1_crit in microwatts (typically for client products) or as
curr1_crit in milliamperes (typically for server).
v2: Add curr1_crit functionality (Ashutosh)
v3:
- Use HWMON_CHANNEL_INFO to define power1_crit, curr1_crit (Badal)
- Update date and kernel version in Documentation.
v4: Use hwm_ prefix for static functions (Ashutosh)
Cc: Sujaritha Sundaresan
Signed-off-by: Ashutosh Dixit
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 26 +
drivers/gpu/drm/i915/i915_hwmon.c | 95 ++-
drivers/gpu/drm/i915/i915_reg.h | 6 ++
3 files changed, 126 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index 03d71c6869d3..bb1101757154 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -26,6 +26,32 @@ Description: RO. Card default power limit (default TDP
setting).
Only supported for particular Intel i915 graphics platforms.
+What: /sys/devices/.../hwmon/hwmon/power1_crit
+Date: June 2022
+KernelVersion: 5.19
+Contact: dri-de...@lists.freedesktop.org
+Description: RW. Card reactive critical (I1) power limit in microwatts.
+
+ Card reactive critical (I1) power limit in microwatts is exposed
+ for client products. The power controller will throttle the
+ operating frequency if the power averaged over a window exceeds
+ this limit.
+
+ Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/devices/.../hwmon/hwmon/curr1_crit
+Date: June 2022
+KernelVersion: 5.19
+Contact: dri-de...@lists.freedesktop.org
+Description: RW. Card reactive critical (I1) power limit in milliamperes.
+
+ Card reactive critical (I1) power limit in milliamperes is
+ exposed for server products. The power controller will throttle
+ the operating frequency if the power averaged over a window
+ exceeds this limit.
+
+ Only supported for particular Intel i915 graphics platforms.
+
What: /sys/devices/.../hwmon/hwmon/energy1_input
Date: June 2022
KernelVersion: 5.19
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index e35f125be242..e476c8a9351b 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -11,14 +11,17 @@
#include "i915_hwmon.h"
#include "i915_reg.h"
#include "intel_mchbar_regs.h"
+#include "intel_pcode.h"
#include "gt/intel_gt_regs.h"
/*
* SF_* - scale factors for particular quantities according to hwmon spec.
* - power - microwatts
+ * - curr - milliamperes
* - energy - microjoules
*/
#define SF_POWER 100
+#define SF_CURR1000
#define SF_ENERGY 100
#define FIELD_SHIFT(__mask)\
@@ -176,11 +179,25 @@ i915_hwmon_energy_status_get(struct drm_i915_private
*i915, long *energy)
static const struct hwmon_channel_info *hwm_info[] = {
HWMON_CHANNEL_INFO(in, HWMON_I_INPUT),
- HWMON_CHANNEL_INFO(power, HWMON_P_MAX | HWMON_P_RATED_MAX),
+ HWMON_CHANNEL_INFO(power, HWMON_P_MAX | HWMON_P_RATED_MAX |
HWMON_P_CRIT),
HWMON_CHANNEL_INFO(energy, HWMON_E_INPUT),
+ HWMON_CHANNEL_INFO(curr, HWMON_C_CRIT),
NULL
};
+/* I1 is exposed as power_crit or as curr_crit depending on bit 31 */
+static int hwm_pcode_read_i1(struct drm_i915_private *i915, u32 *uval)
+{
+ return snb_pcode_read_p(&i915->uncore, PCODE_POWER_SETUP,
+ POWER_SETUP_SUBCOMMAND_READ_I1, 0, uval);
+}
+
+static int hwm_pcode_write_i1(struct drm_i915_private *i915, u32 uval)
+{
+ return snb_pcode_write_p(&i915->uncore, PCODE_POWER_SETUP,
+ POWER_SETUP_SUBCOMMAND_WRITE_I1, 0, uval);
+}
+
static umode_t
hwm_in_is_visible(const struct hwm_drvdata *ddat, u32 attr)
{
@@ -214,13 +231,18 @@ hwm_in_read(struct hwm_drvdata *ddat, u32 attr, long *val)
static umode_t
hwm_power_is_visible(const struct hwm_drvdata *ddat, u32 attr, int chan)
{
+ struct drm_i915_private *i915 = ddat->uncore->i915;
struct i915_hwmon *hwmon = ddat->hwmon;
+ u32 uval;
switch (attr) {
case hwmon_power_max:
return i915_mmio_reg_valid(hwmon->rg.pkg_rapl_limit) ? 0664 : 0;
case hwmon_power_rated_max:
return i915_mmio_reg_valid(hwmon->rg.pkg_power_sku) ? 0444 : 0;
+ case hwmon_power_crit:
+ return (hwm_pcode_read_i1(i915, &uval) ||
+ !(uval & POWER_SETUP_I1_WATTS)) ? 0 : 0644;
default:
[Intel-gfx] [PATCH 4/7] drm/i915/hwmon: Show device level energy usage
From: Dale B Stimson
Use i915 HWMON to display device level energy input.
v2:
- Updated the date and kernel version in feature description
Signed-off-by: Dale B Stimson
Signed-off-by: Ashutosh Dixit
Signed-off-by: Riana Tauro
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 8 ++
drivers/gpu/drm/i915/i915_hwmon.c | 119 +-
drivers/gpu/drm/i915/i915_hwmon.h | 1 +
drivers/gpu/drm/i915/intel_mchbar_regs.h | 2 +
4 files changed, 128 insertions(+), 2 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index 9a2d10edfce8..03d71c6869d3 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -25,3 +25,11 @@ Contact: dri-de...@lists.freedesktop.org
Description: RO. Card default power limit (default TDP setting).
Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/devices/.../hwmon/hwmon/energy1_input
+Date: June 2022
+KernelVersion: 5.19
+Contact: dri-de...@lists.freedesktop.org
+Description: RO. Energy input of device in microjoules.
+
+ 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 922463da65bf..e35f125be242 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -16,8 +16,10 @@
/*
* SF_* - scale factors for particular quantities according to hwmon spec.
* - power - microwatts
+ * - energy - microjoules
*/
#define SF_POWER 100
+#define SF_ENERGY 100
#define FIELD_SHIFT(__mask)\
(BUILD_BUG_ON_ZERO(!__builtin_constant_p(__mask)) + \
@@ -29,12 +31,19 @@ struct hwm_reg {
i915_reg_t pkg_power_sku_unit;
i915_reg_t pkg_power_sku;
i915_reg_t pkg_rapl_limit;
+ i915_reg_t energy_status_all;
+};
+
+struct hwm_energy_info {
+ u32 reg_val_prev;
+ long accum_energy; /* Accumulated energy for
energy1_input */
};
struct hwm_drvdata {
struct i915_hwmon *hwmon;
struct intel_uncore *uncore;
struct device *hwmon_dev;
+ struct hwm_energy_info ei; /* Energy info for
energy1_input */
char name[12];
};
@@ -43,6 +52,7 @@ struct i915_hwmon {
struct mutex hwmon_lock;/* counter overflow logic and
rmw */
struct hwm_reg rg;
int scl_shift_power;
+ int scl_shift_energy;
};
static void
@@ -102,9 +112,72 @@ hwm_field_scale_and_write(struct hwm_drvdata *ddat,
i915_reg_t rgadr,
bits_to_clear, bits_to_set);
}
+/*
+ * hwm_energy - Obtain energy value
+ *
+ * The underlying energy hardware register is 32-bits and is subject to
+ * overflow. How long before overflow? For example, with an example
+ * scaling bit shift of 14 bits (see register *PACKAGE_POWER_SKU_UNIT) and
+ * a power draw of 1000 watts, the 32-bit counter will overflow in
+ * approximately 4.36 minutes.
+ *
+ * Examples:
+ *1 watt: (2^32 >> 14) /1 W / (60 * 60 * 24) secs/day -> 3 days
+ * 1000 watts: (2^32 >> 14) / 1000 W / 60 secs/min -> 4.36 minutes
+ *
+ * The function significantly increases overflow duration (from 4.36
+ * minutes) by accumulating the energy register into a 'long' as allowed by
+ * the hwmon API. Using x86_64 128 bit arithmetic (see mul_u64_u32_shr()),
+ * a 'long' of 63 bits, SF_ENERGY of 1e6 (~20 bits) and
+ * hwmon->scl_shift_energy of 14 bits we have 57 (63 - 20 + 14) bits before
+ * energy1_input overflows. This at 1000 W is an overflow duration of 278
years.
+ */
+static int
+hwm_energy(struct hwm_drvdata *ddat, long *energy)
+{
+ struct intel_uncore *uncore = ddat->uncore;
+ struct i915_hwmon *hwmon = ddat->hwmon;
+ struct hwm_energy_info *ei = &ddat->ei;
+ intel_wakeref_t wakeref;
+ i915_reg_t rgaddr;
+ u32 reg_val;
+
+ rgaddr = hwmon->rg.energy_status_all;
+
+ if (!i915_mmio_reg_valid(rgaddr))
+ return -EOPNOTSUPP;
+
+ mutex_lock(&hwmon->hwmon_lock);
+
+ with_intel_runtime_pm(uncore->rpm, wakeref)
+ reg_val = intel_uncore_read(uncore, rgaddr);
+
+ if (reg_val >= ei->reg_val_prev)
+ ei->accum_energy += reg_val - ei->reg_val_prev;
+ else
+ ei->accum_energy += UINT_MAX - ei->reg_val_prev + reg_val;
+ ei->reg_val_prev = reg_val;
+
+ *energy = mul_u64_u32_shr(ei->accum_energy, SF_ENERGY,
+ hwmon->scl_shift_energy);
+ mutex_unlock(&hwmon->hwmon_lock);
+
+ return 0;
+}
+
+int
+i915_hwmon_energy_status_get(struct drm_i915_private *i915, long *energy)
+{
+ struct
[Intel-gfx] [PATCH 2/7] drm/i915/hwmon: Add HWMON current voltage support
From: Riana Tauro
Use i915 HWMON subsystem to display current input voltage.
v2:
- Updated date and kernel version in feature description
- Fixed review comments (Ashutosh)
v3: Use macro HWMON_CHANNEL_INFO to define hwmon channel (Guenter)
v4:
- Fixed review comments (Ashutosh)
- Use hwm_ prefix for static functions (Ashutosh)
Cc: Guenter Roeck
Cc: Anshuman Gupta
Signed-off-by: Riana Tauro
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 7 +++
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 ++
drivers/gpu/drm/i915/i915_hwmon.c | 47 +++
3 files changed, 57 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
new file mode 100644
index ..24c4b7477d51
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -0,0 +1,7 @@
+What: /sys/devices/.../hwmon/hwmon/in0_input
+Date: June 2022
+KernelVersion: 5.19
+Contact: dri-de...@lists.freedesktop.org
+Description: RO. Current Voltage in millivolt.
+
+ Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 94f9ddcfb3a5..5d4fbda4d326 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1508,6 +1508,9 @@
#define VLV_RENDER_C0_COUNT_MMIO(0x138118)
#define VLV_MEDIA_C0_COUNT _MMIO(0x13811c)
+#define GEN12_RPSTAT1 _MMIO(0x1381b4)
+#define GEN12_VOLTAGE_MASK REG_GENMASK(10, 0)
+
#define GEN11_GT_INTR_DW(x)_MMIO(0x190018 + ((x) * 4))
#define GEN11_CSME (31)
#define GEN11_GUNIT (28)
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index 103dd543a214..2192d0fd4c66 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -11,8 +11,10 @@
#include "i915_hwmon.h"
#include "i915_reg.h"
#include "intel_mchbar_regs.h"
+#include "gt/intel_gt_regs.h"
struct hwm_reg {
+ i915_reg_t gt_perf_status;
};
struct hwm_drvdata {
@@ -29,14 +31,49 @@ struct i915_hwmon {
};
static const struct hwmon_channel_info *hwm_info[] = {
+ HWMON_CHANNEL_INFO(in, HWMON_I_INPUT),
NULL
};
+static umode_t
+hwm_in_is_visible(const struct hwm_drvdata *ddat, u32 attr)
+{
+ switch (attr) {
+ case hwmon_in_input:
+ return i915_mmio_reg_valid(ddat->hwmon->rg.gt_perf_status) ?
0444 : 0;
+ default:
+ return 0;
+ }
+}
+
+static int
+hwm_in_read(struct hwm_drvdata *ddat, u32 attr, long *val)
+{
+ struct i915_hwmon *hwmon = ddat->hwmon;
+ intel_wakeref_t wakeref;
+ u32 reg_value;
+
+ switch (attr) {
+ case hwmon_in_input:
+ with_intel_runtime_pm(ddat->uncore->rpm, wakeref)
+ reg_value = intel_uncore_read(ddat->uncore,
hwmon->rg.gt_perf_status);
+ /* In units of 2.5 millivolt */
+ *val = DIV_ROUND_CLOSEST(REG_FIELD_GET(GEN12_VOLTAGE_MASK,
reg_value) * 25, 10);
+ return 0;
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
static umode_t
hwm_is_visible(const void *drvdata, enum hwmon_sensor_types type,
u32 attr, int channel)
{
+ struct hwm_drvdata *ddat = (struct hwm_drvdata *)drvdata;
+
switch (type) {
+ case hwmon_in:
+ return hwm_in_is_visible(ddat, attr);
default:
return 0;
}
@@ -46,7 +83,11 @@ static int
hwm_read(struct device *dev, enum hwmon_sensor_types type, u32 attr,
int channel, long *val)
{
+ struct hwm_drvdata *ddat = dev_get_drvdata(dev);
+
switch (type) {
+ case hwmon_in:
+ return hwm_in_read(ddat, attr, val);
default:
return -EOPNOTSUPP;
}
@@ -76,6 +117,12 @@ static const struct hwmon_chip_info hwm_chip_info = {
static void
hwm_get_preregistration_info(struct drm_i915_private *i915)
{
+ struct i915_hwmon *hwmon = i915->hwmon;
+
+ if (IS_DG1(i915) || IS_DG2(i915))
+ hwmon->rg.gt_perf_status = GEN12_RPSTAT1;
+ else
+ hwmon->rg.gt_perf_status = INVALID_MMIO_REG;
}
void i915_hwmon_register(struct drm_i915_private *i915)
--
2.25.1
[Intel-gfx] [PATCH 6/7] drm/i915/hwmon: Expose power1_max_interval
From: Ashutosh Dixit
Expose power1_max_interval, that is the tau corresponding to PL1. Some bit
manipulation is needed because of the format of PKG_PWR_LIM_1_TIME in
GT0_PACKAGE_RAPL_LIMIT register (1.x * power(2,y)).
v2: Update date and kernel version in Documentation (Badal)
v3: Cleaned up hwm_power1_max_interval_store() (Badal)
Signed-off-by: Ashutosh Dixit
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 9 ++
drivers/gpu/drm/i915/i915_hwmon.c | 114 +-
drivers/gpu/drm/i915/i915_reg.h | 4 +-
drivers/gpu/drm/i915/intel_mchbar_regs.h | 4 +
4 files changed, 128 insertions(+), 3 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index bb1101757154..34668f6c2dc4 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -26,6 +26,15 @@ Description: RO. Card default power limit (default TDP
setting).
Only supported for particular Intel i915 graphics platforms.
+What: /sys/devices/.../hwmon/hwmon/power1_max_interval
+Date: June 2022
+KernelVersion: 5.19
+Contact: dri-de...@lists.freedesktop.org
+Description: RW. Sustained power limit interval (Tau in PL1/Tau) in
+ milliseconds over which sustained power is averaged.
+
+ Only supported for particular Intel i915 graphics platforms.
+
What: /sys/devices/.../hwmon/hwmon/power1_crit
Date: June 2022
KernelVersion: 5.19
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index e476c8a9351b..b8ac52f07681 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -16,10 +16,12 @@
/*
* SF_* - scale factors for particular quantities according to hwmon spec.
+ * - time - milliseconds
* - power - microwatts
* - curr - milliamperes
* - energy - microjoules
*/
+#define SF_TIME1000
#define SF_POWER 100
#define SF_CURR1000
#define SF_ENERGY 100
@@ -56,6 +58,7 @@ struct i915_hwmon {
struct hwm_reg rg;
int scl_shift_power;
int scl_shift_energy;
+ int scl_shift_time;
};
static void
@@ -177,6 +180,114 @@ i915_hwmon_energy_status_get(struct drm_i915_private
*i915, long *energy)
return hwm_energy(ddat, energy);
}
+static ssize_t
+hwm_power1_max_interval_show(struct device *dev, struct device_attribute *attr,
+char *buf)
+{
+ struct hwm_drvdata *ddat = dev_get_drvdata(dev);
+ struct i915_hwmon *hwmon = ddat->hwmon;
+ intel_wakeref_t wakeref;
+ u32 r, x, y, x_w = 2; /* 2 bits */
+ u64 tau4, out;
+
+ with_intel_runtime_pm(ddat->uncore->rpm, wakeref)
+ r = intel_uncore_read(ddat->uncore, hwmon->rg.pkg_rapl_limit);
+
+ x = REG_FIELD_GET(PKG_PWR_LIM_1_TIME_X, r);
+ y = REG_FIELD_GET(PKG_PWR_LIM_1_TIME_Y, r);
+ /*
+* tau = 1.x * power(2,y), x = bits(23:22), y = bits(21:17)
+* = (4 | x) << (y - 2)
+* where (y - 2) ensures a 1.x fixed point representation of 1.x
+* However because y can be < 2, we compute
+* tau4 = (4 | x) << y
+* but add 2 when doing the final right shift to account for units
+*/
+ tau4 = ((1 << x_w) | x) << y;
+ /* val in hwmon interface units (millisec) */
+ out = mul_u64_u32_shr(tau4, SF_TIME, hwmon->scl_shift_time + x_w);
+
+ return sysfs_emit(buf, "%llu\n", out);
+}
+
+static ssize_t
+hwm_power1_max_interval_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct hwm_drvdata *ddat = dev_get_drvdata(dev);
+ struct i915_hwmon *hwmon = ddat->hwmon;
+ long val, max_win, ret;
+ u32 x, y, rxy, x_w = 2; /* 2 bits */
+ u64 tau4, r;
+
+#define PKG_MAX_WIN_DEFAULT 0x12ull
+
+ ret = kstrtoul(buf, 0, &val);
+ if (ret)
+ return ret;
+
+ /*
+* val must be < max in hwmon interface units. The steps below are
+* explained in i915_power1_max_interval_show()
+*/
+ r = FIELD_PREP(PKG_MAX_WIN, PKG_MAX_WIN_DEFAULT);
+ x = REG_FIELD_GET(PKG_MAX_WIN_X, r);
+ y = REG_FIELD_GET(PKG_MAX_WIN_Y, r);
+ tau4 = ((1 << x_w) | x) << y;
+ max_win = mul_u64_u32_shr(tau4, SF_TIME, hwmon->scl_shift_time + x_w);
+
+ if (val > max_win)
+ return -EINVAL;
+
+ /* val in hw units */
+ val = DIV_ROUND_CLOSEST_ULL((u64)val << hwmon->scl_shift_time, SF_TIME);
+ /* Convert to 1.x * power(2,y) */
+ if (!val)
+ return -EINVAL;
+ y = ilog2(val);
+ /* x = (val - (1 << y)) >> (y - 2); */
+ x = (val - (
[Intel-gfx] [PATCH 1/7] drm/i915/hwmon: Add HWMON infrastructure
From: Dale B Stimson
The i915 HWMON module will be used to expose voltage, power and energy
values for dGfx. Here we set up i915 hwmon infrastructure including i915
hwmon registration, basic data structures and functions.
v2:
- Create HWMON infra patch (Ashutosh)
- Fixed review comments (Jani)
- Remove "select HWMON" from i915/Kconfig (Jani)
v3: Use hwm_ prefix for static functions (Ashutosh)
v4: s/#ifdef CONFIG_HWMON/#if IS_REACHABLE(CONFIG_HWMON)/ since the former
doesn't work if hwmon is compiled as a module (Guenter)
v5: Fixed review comments (Jani)
Cc: Guenter Roeck
Signed-off-by: Dale B Stimson
Signed-off-by: Ashutosh Dixit
Signed-off-by: Riana Tauro
Signed-off-by: Badal Nilawar
---
drivers/gpu/drm/i915/Makefile | 3 +
drivers/gpu/drm/i915/i915_driver.c | 5 ++
drivers/gpu/drm/i915/i915_drv.h| 2 +
drivers/gpu/drm/i915/i915_hwmon.c | 136 +
drivers/gpu/drm/i915/i915_hwmon.h | 20 +
5 files changed, 166 insertions(+)
create mode 100644 drivers/gpu/drm/i915/i915_hwmon.c
create mode 100644 drivers/gpu/drm/i915/i915_hwmon.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 522ef9b4aff3..2b235f747490 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -208,6 +208,9 @@ i915-y += gt/uc/intel_uc.o \
# graphics system controller (GSC) support
i915-y += gt/intel_gsc.o
+# graphics hardware monitoring (HWMON) support
+i915-$(CONFIG_HWMON) += i915_hwmon.o
+
# modesetting core code
i915-y += \
display/hsw_ips.o \
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index 1332c70370a6..248deecd26a5 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -80,6 +80,7 @@
#include "i915_drm_client.h"
#include "i915_drv.h"
#include "i915_getparam.h"
+#include "i915_hwmon.h"
#include "i915_ioc32.h"
#include "i915_ioctl.h"
#include "i915_irq.h"
@@ -736,6 +737,8 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
intel_gt_driver_register(to_gt(dev_priv));
+ i915_hwmon_register(dev_priv);
+
intel_display_driver_register(dev_priv);
intel_power_domains_enable(dev_priv);
@@ -762,6 +765,8 @@ static void i915_driver_unregister(struct drm_i915_private
*dev_priv)
intel_display_driver_unregister(dev_priv);
+ i915_hwmon_unregister(dev_priv);
+
intel_gt_driver_unregister(to_gt(dev_priv));
i915_perf_unregister(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 69ce6db6a7c1..7b5b10df3404 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -705,6 +705,8 @@ struct drm_i915_private {
struct i915_perf perf;
+ struct i915_hwmon *hwmon;
+
/* Abstract the submission mechanism (legacy ringbuffer or execlists)
away */
struct intel_gt gt0;
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
new file mode 100644
index ..103dd543a214
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -0,0 +1,136 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include
+#include
+#include
+
+#include "i915_drv.h"
+#include "i915_hwmon.h"
+#include "i915_reg.h"
+#include "intel_mchbar_regs.h"
+
+struct hwm_reg {
+};
+
+struct hwm_drvdata {
+ struct i915_hwmon *hwmon;
+ struct intel_uncore *uncore;
+ struct device *hwmon_dev;
+ char name[12];
+};
+
+struct i915_hwmon {
+ struct hwm_drvdata ddat;
+ struct mutex hwmon_lock;/* counter overflow logic and
rmw */
+ struct hwm_reg rg;
+};
+
+static const struct hwmon_channel_info *hwm_info[] = {
+ NULL
+};
+
+static umode_t
+hwm_is_visible(const void *drvdata, enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+ switch (type) {
+ default:
+ return 0;
+ }
+}
+
+static int
+hwm_read(struct device *dev, enum hwmon_sensor_types type, u32 attr,
+int channel, long *val)
+{
+ switch (type) {
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static int
+hwm_write(struct device *dev, enum hwmon_sensor_types type, u32 attr,
+ int channel, long val)
+{
+ switch (type) {
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static const struct hwmon_ops hwm_ops = {
+ .is_visible = hwm_is_visible,
+ .read = hwm_read,
+ .write = hwm_write,
+};
+
+static const struct hwmon_chip_info hwm_chip_info = {
+ .ops = &hwm_ops,
+ .info = hwm_info,
+};
+
+static void
+hwm_get_preregistration_info(struct drm_i915_private *i915)
+{
+}
+
+void i915_hwmon_register(struct drm_i915_private *i915)
+{
+ struct device *dev = i915->drm.dev;
+ struct i915_hwmon *hwmon;
+ struct device *hwmon_dev;
+ struct hwm_drvdata
[Intel-gfx] [PATCH 7/7] drm/i915/hwmon: Extend power/energy for XEHPSDV
From: Dale B Stimson
Extend hwmon power/energy for XEHPSDV especially per gt level energy
usage.
v2: Update to latest HWMON spec (Ashutosh)
Signed-off-by: Ashutosh Dixit
Signed-off-by: Dale B Stimson
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 7 +-
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 5 +
drivers/gpu/drm/i915/i915_hwmon.c | 120 +-
3 files changed, 128 insertions(+), 4 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index 34668f6c2dc4..e69bc43d4c9e 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -65,6 +65,11 @@ What:
/sys/devices/.../hwmon/hwmon/energy1_input
Date: June 2022
KernelVersion: 5.19
Contact: dri-de...@lists.freedesktop.org
-Description: RO. Energy input of device in microjoules.
+Description: RO. Energy input of device or gt in microjoules.
+
+ For i915 device level hwmon devices (name "i915") this
+ reflects energy input for the entire device. For gt level
+ hwmon devices (name "i915_gtN") this reflects energy input
+ for the gt.
Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 5d4fbda4d326..b7b343cec2da 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1579,4 +1579,9 @@
#define GEN12_SFC_DONE(n) _MMIO(0x1cc000 + (n) * 0x1000)
+#define GT0_PACKAGE_ENERGY_STATUS _MMIO(0x250004)
+#define GT0_PACKAGE_RAPL_LIMIT _MMIO(0x250008)
+#define GT0_PACKAGE_POWER_SKU_UNIT _MMIO(0x250068)
+#define GT0_PLATFORM_ENERGY_STATUS _MMIO(0x25006c)
+
#endif /* __INTEL_GT_REGS__ */
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index b8ac52f07681..76d73216c54e 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -12,6 +12,7 @@
#include "i915_reg.h"
#include "intel_mchbar_regs.h"
#include "intel_pcode.h"
+#include "gt/intel_gt.h"
#include "gt/intel_gt_regs.h"
/*
@@ -21,7 +22,7 @@
* - curr - milliamperes
* - energy - microjoules
*/
-#define SF_TIME1000
+#define SF_TIME1000
#define SF_POWER 100
#define SF_CURR1000
#define SF_ENERGY 100
@@ -37,6 +38,7 @@ struct hwm_reg {
i915_reg_t pkg_power_sku;
i915_reg_t pkg_rapl_limit;
i915_reg_t energy_status_all;
+ i915_reg_t energy_status_tile;
};
struct hwm_energy_info {
@@ -50,10 +52,12 @@ struct hwm_drvdata {
struct device *hwmon_dev;
struct hwm_energy_info ei; /* Energy info for
energy1_input */
char name[12];
+ int gt_n;
};
struct i915_hwmon {
struct hwm_drvdata ddat;
+ struct hwm_drvdata ddat_gt[I915_MAX_GT];
struct mutex hwmon_lock;/* counter overflow logic and
rmw */
struct hwm_reg rg;
int scl_shift_power;
@@ -148,7 +152,10 @@ hwm_energy(struct hwm_drvdata *ddat, long *energy)
i915_reg_t rgaddr;
u32 reg_val;
- rgaddr = hwmon->rg.energy_status_all;
+ if (ddat->gt_n >= 0)
+ rgaddr = hwmon->rg.energy_status_tile;
+ else
+ rgaddr = hwmon->rg.energy_status_all;
if (!i915_mmio_reg_valid(rgaddr))
return -EOPNOTSUPP;
@@ -296,6 +303,11 @@ static const struct hwmon_channel_info *hwm_info[] = {
NULL
};
+static const struct hwmon_channel_info *hwm_gt_info[] = {
+ HWMON_CHANNEL_INFO(energy, HWMON_E_INPUT),
+ NULL
+};
+
/* I1 is exposed as power_crit or as curr_crit depending on bit 31 */
static int hwm_pcode_read_i1(struct drm_i915_private *i915, u32 *uval)
{
@@ -428,7 +440,10 @@ hwm_energy_is_visible(const struct hwm_drvdata *ddat, u32
attr)
switch (attr) {
case hwmon_energy_input:
- rgaddr = hwmon->rg.energy_status_all;
+ if (ddat->gt_n >= 0)
+ rgaddr = hwmon->rg.energy_status_tile;
+ else
+ rgaddr = hwmon->rg.energy_status_all;
return i915_mmio_reg_valid(rgaddr) ? 0444 : 0;
default:
return 0;
@@ -563,6 +578,44 @@ static const struct hwmon_chip_info hwm_chip_info = {
.info = hwm_info,
};
+static umode_t
+hwm_gt_is_visible(const void *drvdata, enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+ struct hwm_drvdata *ddat = (struct hwm_drvdata *)drvdata;
+
+ switch (type) {
+ case hwmon_energy:
+ return hwm_energy_is_visible(ddat, attr);
[Intel-gfx] [PATCH 3/7] drm/i915/hwmon: Power PL1 limit and TDP setting
From: Dale B Stimson
Use i915 HWMON to display/modify dGfx power PL1 limit and TDP setting.
v2:
- Fix review comments (Ashutosh)
- Do not restore power1_max upon module unload/load sequence
because on production systems modules are always loaded
and not unloaded/reloaded (Ashutosh)
- Fix review comments (Jani)
- Remove endianness conversion (Ashutosh)
v3: Add power1_rated_max (Ashutosh)
v4:
- Use macro HWMON_CHANNEL_INFO to define power channel (Guenter)
- Update the date and kernel version in Documentation (Badal)
v5: Use hwm_ prefix for static functions (Ashutosh)
Cc: Guenter Roeck
Signed-off-by: Dale B Stimson
Signed-off-by: Ashutosh Dixit
Signed-off-by: Riana Tauro
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 20 ++
drivers/gpu/drm/i915/i915_hwmon.c | 175 +-
drivers/gpu/drm/i915/i915_reg.h | 16 ++
drivers/gpu/drm/i915/intel_mchbar_regs.h | 6 +
4 files changed, 215 insertions(+), 2 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index 24c4b7477d51..9a2d10edfce8 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -5,3 +5,23 @@ Contact: dri-de...@lists.freedesktop.org
Description: RO. Current Voltage in millivolt.
Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/devices/.../hwmon/hwmon/power1_max
+Date: June 2022
+KernelVersion: 5.19
+Contact: dri-de...@lists.freedesktop.org
+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.
+
+ Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/devices/.../hwmon/hwmon/power1_rated_max
+Date: June 2022
+KernelVersion: 5.19
+Contact: dri-de...@lists.freedesktop.org
+Description: RO. Card default power limit (default TDP setting).
+
+ 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 2192d0fd4c66..922463da65bf 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -13,8 +13,22 @@
#include "intel_mchbar_regs.h"
#include "gt/intel_gt_regs.h"
+/*
+ * SF_* - scale factors for particular quantities according to hwmon spec.
+ * - power - microwatts
+ */
+#define SF_POWER 100
+
+#define FIELD_SHIFT(__mask)\
+ (BUILD_BUG_ON_ZERO(!__builtin_constant_p(__mask)) + \
+ BUILD_BUG_ON_ZERO((__mask) == 0) + \
+ __bf_shf(__mask))
+
struct hwm_reg {
i915_reg_t gt_perf_status;
+ i915_reg_t pkg_power_sku_unit;
+ i915_reg_t pkg_power_sku;
+ i915_reg_t pkg_rapl_limit;
};
struct hwm_drvdata {
@@ -28,10 +42,69 @@ struct i915_hwmon {
struct hwm_drvdata ddat;
struct mutex hwmon_lock;/* counter overflow logic and
rmw */
struct hwm_reg rg;
+ int scl_shift_power;
};
+static void
+hwm_locked_with_pm_intel_uncore_rmw(struct hwm_drvdata *ddat,
+ i915_reg_t reg, u32 clear, u32 set)
+{
+ struct i915_hwmon *hwmon = ddat->hwmon;
+ struct intel_uncore *uncore = ddat->uncore;
+ intel_wakeref_t wakeref;
+
+ mutex_lock(&hwmon->hwmon_lock);
+
+ with_intel_runtime_pm(uncore->rpm, wakeref)
+ intel_uncore_rmw(uncore, reg, clear, set);
+
+ mutex_unlock(&hwmon->hwmon_lock);
+}
+
+/*
+ * This function's return type of u64 allows for the case where the scaling
+ * of the field taken from the 32-bit register value might cause a result to
+ * exceed 32 bits.
+ */
+static u64
+hwm_field_read_and_scale(struct hwm_drvdata *ddat, i915_reg_t rgadr,
+u32 field_msk, int field_shift,
+int nshift, u32 scale_factor)
+{
+ struct intel_uncore *uncore = ddat->uncore;
+ intel_wakeref_t wakeref;
+ u32 reg_value;
+
+ with_intel_runtime_pm(uncore->rpm, wakeref)
+ reg_value = intel_uncore_read(uncore, rgadr);
+
+ reg_value = (reg_value & field_msk) >> field_shift;
+
+ return mul_u64_u32_shr(reg_value, scale_factor, nshift);
+}
+
+static void
+hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
+ u32 field_msk, int field_shift,
+ int nshift, unsigned int scale_factor, long lval)
+{
+ u32 nval;
+ u32 bits_to_clear;
+ u32 bits_to_set;
+
+ /* Computation in 64-bits to avoid overflow. Round to near
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Add HWMON support (rev5)
== Series Details == Series: drm/i915: Add HWMON support (rev5) URL : https://patchwork.freedesktop.org/series/104278/ State : warning == Summary == Error: dim checkpatch failed 4d2dbe77d024 drm/i915/hwmon: Add HWMON infrastructure Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' -:83: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #83: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 196 lines checked c2288792c911 drm/i915/hwmon: Add HWMON current voltage support -:23: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #23: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 98 lines checked 896c4806810e drm/i915/hwmon: Power PL1 limit and TDP setting -:70: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__mask' - possible side-effects? #70: FILE: drivers/gpu/drm/i915/i915_hwmon.c:22: +#define FIELD_SHIFT(__mask)\ + (BUILD_BUG_ON_ZERO(!__builtin_constant_p(__mask)) + \ + BUILD_BUG_ON_ZERO((__mask) == 0) + \ + __bf_shf(__mask)) total: 0 errors, 0 warnings, 1 checks, 290 lines checked 0d7f6bd1a25b drm/i915/hwmon: Show device level energy usage cc18f86da554 drm/i915/hwmon: Expose card reactive critical power 90028741f465 drm/i915/hwmon: Expose power1_max_interval 0f7b7b59ec09 drm/i915/hwmon: Extend power/energy for XEHPSDV
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Add HWMON support (rev5)
== Series Details == Series: drm/i915: Add HWMON support (rev5) URL : https://patchwork.freedesktop.org/series/104278/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add HWMON support (rev5)
== Series Details ==
Series: drm/i915: Add HWMON support (rev5)
URL : https://patchwork.freedesktop.org/series/104278/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12024 -> Patchwork_104278v5
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v5/index.html
Participating hosts (35 -> 35)
--
Additional (1): bat-dg1-6
Missing(1): bat-dg2-8
Known issues
Here are the changes found in Patchwork_104278v5 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_mmap@basic:
- bat-dg1-6: NOTRUN -> [SKIP][1] ([i915#4083])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v5/bat-dg1-6/igt@gem_m...@basic.html
* igt@gem_render_tiled_blits@basic:
- bat-dg1-6: NOTRUN -> [SKIP][2] ([i915#4079]) +1 similar issue
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v5/bat-dg1-6/igt@gem_render_tiled_bl...@basic.html
* igt@gem_tiled_fence_blits@basic:
- bat-dg1-6: NOTRUN -> [SKIP][3] ([i915#4077]) +2 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v5/bat-dg1-6/igt@gem_tiled_fence_bl...@basic.html
* igt@i915_pm_backlight@basic-brightness:
- bat-dg1-6: NOTRUN -> [SKIP][4] ([i915#1155])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v5/bat-dg1-6/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_pm_rps@basic-api:
- bat-dg1-6: NOTRUN -> [SKIP][5] ([i915#6621])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v5/bat-dg1-6/igt@i915_pm_...@basic-api.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: NOTRUN -> [DMESG-FAIL][6] ([i915#4494] / [i915#4957])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v5/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
* igt@i915_suspend@basic-s2idle-without-i915:
- bat-dg1-6: NOTRUN -> [INCOMPLETE][7] ([i915#6011])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v5/bat-dg1-6/igt@i915_susp...@basic-s2idle-without-i915.html
* igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-dg1-6: NOTRUN -> [SKIP][8] ([i915#4215])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v5/bat-dg1-6/igt@kms_addfb_ba...@basic-y-tiled-legacy.html
* igt@kms_addfb_basic@tile-pitch-mismatch:
- bat-dg1-6: NOTRUN -> [SKIP][9] ([i915#4212]) +7 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v5/bat-dg1-6/igt@kms_addfb_ba...@tile-pitch-mismatch.html
* igt@kms_chamelium@hdmi-crc-fast:
- bat-dg1-6: NOTRUN -> [SKIP][10] ([fdo#111827]) +7 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v5/bat-dg1-6/igt@kms_chamel...@hdmi-crc-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- bat-dg1-6: NOTRUN -> [SKIP][11] ([i915#4103] / [i915#4213])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v5/bat-dg1-6/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html
* igt@kms_force_connector_basic@force-load-detect:
- bat-dg1-6: NOTRUN -> [SKIP][12] ([fdo#109285])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v5/bat-dg1-6/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_psr@sprite_plane_onoff:
- bat-dg1-6: NOTRUN -> [SKIP][13] ([i915#1072] / [i915#4078]) +3
similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v5/bat-dg1-6/igt@kms_psr@sprite_plane_onoff.html
* igt@kms_setmode@basic-clone-single-crtc:
- bat-dg1-6: NOTRUN -> [SKIP][14] ([i915#3555])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v5/bat-dg1-6/igt@kms_setm...@basic-clone-single-crtc.html
* igt@prime_vgem@basic-gtt:
- bat-dg1-6: NOTRUN -> [SKIP][15] ([i915#3708] / [i915#4077]) +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v5/bat-dg1-6/igt@prime_v...@basic-gtt.html
* igt@prime_vgem@basic-read:
- bat-dg1-6: NOTRUN -> [SKIP][16] ([i915#3708]) +3 similar issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v5/bat-dg1-6/igt@prime_v...@basic-read.html
* igt@prime_vgem@basic-userptr:
- bat-dg1-6: NOTRUN -> [SKIP][17] ([i915#3708] / [i915#4873])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v5/bat-dg1-6/igt@prime_v...@basic-userptr.html
* igt@runner@aborted:
- bat-dg1-6: NOTRUN -> [FAIL][18] ([i915#4312] / [i915#5257])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v5/bat-dg1-6/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@hugepages:
- {bat-rpls-1}: [DMESG-WARN][19] ([i915#5278]) -> [PASS][20]
[19]:
https
[Intel-gfx] [PATCH v5 00/31] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display
Hi All, As mentioned in my RFC titled "drm/kms: control display brightness through drm_connector properties": https://lore.kernel.org/dri-devel/0d188965-d809-81b5-74ce-7d30c49fe...@redhat.com/ The first step towards this is to deal with some existing technical debt in backlight handling on x86/ACPI boards, specifically we need to stop registering multiple /sys/class/backlight devs for a single display. This series implements my RFC describing my plan for these cleanups: https://lore.kernel.org/dri-devel/98519ba0-7f18-201a-ea34-652f50343...@redhat.com/ Changes in version 5: - Use drm_info(drm_dev, ...) in patch 2/31 - Modify "drm/i915: Call acpi_video_register_backlight()", dropping the global has_panel flag, replacing it with a new intel_acpi_video_register() helper Changes in version 4: - Minor tweaks to nvidia-wmi-ec-backlight changes - Add nouveau_acpi_* wrappers around used include/acpi/video.h functions to fix unresolved symbol errors on non X86 Changes in version 3: - ACPI_VIDEO can now be enabled on non X86 too, adjust various Kconfig changes - Make the delay before doing fallback acpi_video backlight registration a module option (patch 9) - Move the nvidia-wmi-ec-backlight fw API definitions to a shared header - Add a "acpi_video_get_backlight_type() == acpi_backlight_nvidia_wmi_ec" check to the nvidia-wmi-ec-backlight driver (patch 19) Changes in version 2: - Introduce acpi_video_backlight_use_native() helper - Finishes the refactoring, addressing all the bits from the "Other issues" section of the refactor RFC This series as submitted is based on drm-tip for CI purposes. Assuming the last i915 patch also pass review now, I hope to push out an immutable branch with this series on top of v6.0-rc1 and send out a pull-request to all involved subsystems based on this branch soon. Regards, Hans Hans de Goede (31): ACPI: video: Add acpi_video_backlight_use_native() helper drm/i915: Don't register backlight when another backlight should be used (v2) drm/amdgpu: Don't register backlight when another backlight should be used (v3) drm/radeon: Don't register backlight when another backlight should be used (v3) drm/nouveau: Don't register backlight when another backlight should be used (v2) ACPI: video: Drop backlight_device_get_by_type() call from acpi_video_get_backlight_type() ACPI: video: Remove acpi_video_bus from list before tearing it down ACPI: video: Simplify acpi_video_unregister_backlight() ACPI: video: Make backlight class device registration a separate step (v2) ACPI: video: Remove code to unregister acpi_video backlight when a native backlight registers drm/i915: Call acpi_video_register_backlight() (v3) drm/nouveau: Register ACPI video backlight when nv_backlight registration fails (v2) drm/amdgpu: Register ACPI video backlight when skipping amdgpu backlight registration drm/radeon: Register ACPI video backlight when skipping radeon backlight registration platform/x86: nvidia-wmi-ec-backlight: Move fw interface definitions to a header (v2) ACPI: video: Refactor acpi_video_get_backlight_type() a bit ACPI: video: Add Nvidia WMI EC brightness control detection (v3) ACPI: video: Add Apple GMUX brightness control detection platform/x86: nvidia-wmi-ec-backlight: Use acpi_video_get_backlight_type() platform/x86: apple-gmux: Stop calling acpi/video.h functions platform/x86: toshiba_acpi: Stop using acpi_video_set_dmi_backlight_type() platform/x86: acer-wmi: Move backlight DMI quirks to acpi/video_detect.c platform/x86: asus-wmi: Drop DMI chassis-type check from backlight handling platform/x86: asus-wmi: Move acpi_backlight=vendor quirks to ACPI video_detect.c platform/x86: asus-wmi: Move acpi_backlight=native quirks to ACPI video_detect.c platform/x86: samsung-laptop: Move acpi_backlight=[vendor|native] quirks to ACPI video_detect.c ACPI: video: Remove acpi_video_set_dmi_backlight_type() ACPI: video: Drop "Samsung X360" acpi_backlight=native quirk ACPI: video: Drop NL5x?U, PF4NU1F and PF5?U?? acpi_backlight=native quirks ACPI: video: Fix indentation of video_detect_dmi_table[] entries drm/todo: Add entry about dealing with brightness control on devices with > 1 panel Documentation/gpu/todo.rst| 68 +++ MAINTAINERS | 1 + drivers/acpi/Kconfig | 1 + drivers/acpi/acpi_video.c | 64 ++- drivers/acpi/video_detect.c | 428 +++--- drivers/gpu/drm/Kconfig | 14 + .../gpu/drm/amd/amdgpu/atombios_encoders.c| 14 +- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 9 + drivers/gpu/drm/gma500/Kconfig| 2 + drivers/gpu/drm/i915/Kconfig | 2 + drivers/gpu/drm/i915/display/intel_acpi.c | 27 ++ drivers/gpu/drm/i915/display/intel_acpi.h | 3 +
[Intel-gfx] [PATCH v5 03/31] drm/amdgpu: Don't register backlight when another backlight should be used (v3)
Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.
Registering 2 backlight devices for a single display really is
undesirable, don't register the GPU's native backlight device when
another backlight device should be used.
Changes in v2:
- To avoid linker errors when amdgpu is builtin and video_detect.c is in
a module, select ACPI_VIDEO and its deps if ACPI is enabled.
When ACPI is disabled, ACPI_VIDEO is also always disabled, ensuring
the stubs from acpi/video.h will be used.
Changes in v3:
- Use drm_info(drm_dev, "...") to log messages
- ACPI_VIDEO can now be enabled on non X86 too,
adjust the Kconfig changes to match this.
Acked-by: Alex Deucher
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/Kconfig | 7 +++
drivers/gpu/drm/amd/amdgpu/atombios_encoders.c| 7 +++
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +++
3 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 0b2ad7212ee6..95ca33938b4a 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -259,6 +259,13 @@ config DRM_AMDGPU
select BACKLIGHT_CLASS_DEVICE
select INTERVAL_TREE
select DRM_BUDDY
+ # amdgpu depends on ACPI_VIDEO when ACPI is enabled, for select to work
+ # ACPI_VIDEO's dependencies must also be selected.
+ select INPUT if ACPI
+ select ACPI_VIDEO if ACPI
+ # On x86 ACPI_VIDEO also needs ACPI_WMI
+ select X86_PLATFORM_DEVICES if ACPI && X86
+ select ACPI_WMI if ACPI && X86
help
Choose this option if you have a recent AMD Radeon graphics card.
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
index fa7421afb9a6..b4e3cedceaf8 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
@@ -26,6 +26,8 @@
#include
+#include
+
#include
#include
#include "amdgpu.h"
@@ -184,6 +186,11 @@ void amdgpu_atombios_encoder_init_backlight(struct
amdgpu_encoder *amdgpu_encode
if (!(adev->mode_info.firmware_flags &
ATOM_BIOS_INFO_BL_CONTROLLED_BY_GPU))
return;
+ if (!acpi_video_backlight_use_native()) {
+ drm_info(dev, "Skipping amdgpu atom DIG backlight
registration\n");
+ return;
+ }
+
pdata = kmalloc(sizeof(struct amdgpu_backlight_privdata), GFP_KERNEL);
if (!pdata) {
DRM_ERROR("Memory allocation failed\n");
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index e702f0d72d53..706c67f4bda8 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -90,6 +90,8 @@
#include
#include
+#include
+
#include "ivsrcid/dcn/irqsrcs_dcn_1_0.h"
#include "dcn/dcn_1_0_offset.h"
@@ -4033,6 +4035,11 @@ amdgpu_dm_register_backlight_device(struct
amdgpu_display_manager *dm)
amdgpu_dm_update_backlight_caps(dm, dm->num_of_edps);
dm->brightness[dm->num_of_edps] = AMDGPU_MAX_BL_LEVEL;
+ if (!acpi_video_backlight_use_native()) {
+ drm_info(adev_to_drm(dm->adev), "Skipping amdgpu DM backlight
registration\n");
+ return;
+ }
+
props.max_brightness = AMDGPU_MAX_BL_LEVEL;
props.brightness = AMDGPU_MAX_BL_LEVEL;
props.type = BACKLIGHT_RAW;
--
2.37.2
[Intel-gfx] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)
Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.
Registering 2 backlight devices for a single display really is
undesirable, don't register the GPU's native backlight device when
another backlight device should be used.
Changes in v2:
- Use drm_info(drm_dev, ...) for log messages
Reviewed-by: Jani Nikula
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_backlight.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c
b/drivers/gpu/drm/i915/display/intel_backlight.c
index 681ebcda97ad..03c7966f68d6 100644
--- a/drivers/gpu/drm/i915/display/intel_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_backlight.c
@@ -8,6 +8,8 @@
#include
#include
+#include
+
#include "intel_backlight.h"
#include "intel_backlight_regs.h"
#include "intel_connector.h"
@@ -952,6 +954,11 @@ int intel_backlight_device_register(struct intel_connector
*connector)
WARN_ON(panel->backlight.max == 0);
+ if (!acpi_video_backlight_use_native()) {
+ drm_info(&i915->drm, "Skipping intel_backlight registration\n");
+ return 0;
+ }
+
memset(&props, 0, sizeof(props));
props.type = BACKLIGHT_RAW;
--
2.37.2
[Intel-gfx] [PATCH v5 01/31] ACPI: video: Add acpi_video_backlight_use_native() helper
ATM on x86 laptops where we want userspace to use the acpi_video backlight
device we often register both the GPU's native backlight device and
acpi_video's firmware acpi_video# backlight device. This relies on
userspace preferring firmware type backlight devices over native ones, but
registering 2 backlight devices for a single display really is undesirable.
On x86 laptops where the native GPU backlight device should be used,
the registering of other backlight devices is avoided by their drivers
using acpi_video_get_backlight_type() and only registering their backlight
if the return value matches their type.
acpi_video_get_backlight_type() uses
backlight_device_get_by_type(BACKLIGHT_RAW) to determine if a native
driver is available and will never return native if this returns
false. This means that the GPU's native backlight registering code
cannot just call acpi_video_get_backlight_type() to determine if it
should register its backlight, since acpi_video_get_backlight_type() will
never return native until the native backlight has already registered.
To fix this add a new internal native function parameter to
acpi_video_get_backlight_type(), which when set to true will make
acpi_video_get_backlight_type() behave as if a native backlight has
already been registered.
And add a new acpi_video_backlight_use_native() helper, which sets this
to true, for use in native GPU backlight code.
Changes in v2:
- Replace adding a native parameter to acpi_video_get_backlight_type() with
adding a new acpi_video_backlight_use_native() helper.
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/video_detect.c | 24
include/acpi/video.h| 5 +
2 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 5d7f38016a24..5f105eaa7d30 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -17,8 +17,9 @@
* Otherwise vendor specific drivers like thinkpad_acpi, asus-laptop,
* sony_acpi,... can take care about backlight brightness.
*
- * Backlight drivers can use acpi_video_get_backlight_type() to determine
- * which driver should handle the backlight.
+ * Backlight drivers can use acpi_video_get_backlight_type() to determine which
+ * driver should handle the backlight. RAW/GPU-driver backlight drivers must
+ * use the acpi_video_backlight_use_native() helper for this.
*
* If CONFIG_ACPI_VIDEO is neither set as "compiled in" (y) nor as a module (m)
* this file will not be compiled and acpi_video_get_backlight_type() will
@@ -571,9 +572,10 @@ static int acpi_video_backlight_notify(struct
notifier_block *nb,
* Arguably the native on win8 check should be done first, but that would
* be a behavior change, which may causes issues.
*/
-enum acpi_backlight_type acpi_video_get_backlight_type(void)
+static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
{
static DEFINE_MUTEX(init_mutex);
+ static bool native_available;
static bool init_done;
static long video_caps;
@@ -593,6 +595,8 @@ enum acpi_backlight_type acpi_video_get_backlight_type(void)
backlight_notifier_registered = true;
init_done = true;
}
+ if (native)
+ native_available = true;
mutex_unlock(&init_mutex);
if (acpi_backlight_cmdline != acpi_backlight_undef)
@@ -604,13 +608,25 @@ enum acpi_backlight_type
acpi_video_get_backlight_type(void)
if (!(video_caps & ACPI_VIDEO_BACKLIGHT))
return acpi_backlight_vendor;
- if (acpi_osi_is_win8() && backlight_device_get_by_type(BACKLIGHT_RAW))
+ if (acpi_osi_is_win8() &&
+ (native_available || backlight_device_get_by_type(BACKLIGHT_RAW)))
return acpi_backlight_native;
return acpi_backlight_video;
}
+
+enum acpi_backlight_type acpi_video_get_backlight_type(void)
+{
+ return __acpi_video_get_backlight_type(false);
+}
EXPORT_SYMBOL(acpi_video_get_backlight_type);
+bool acpi_video_backlight_use_native(void)
+{
+ return __acpi_video_get_backlight_type(true) == acpi_backlight_native;
+}
+EXPORT_SYMBOL(acpi_video_backlight_use_native);
+
/*
* Set the preferred backlight interface type based on DMI info.
* This function allows DMI blacklists to be implemented by external
diff --git a/include/acpi/video.h b/include/acpi/video.h
index db8548ff03ce..4705e339c252 100644
--- a/include/acpi/video.h
+++ b/include/acpi/video.h
@@ -56,6 +56,7 @@ extern void acpi_video_unregister(void);
extern int acpi_video_get_edid(struct acpi_device *device, int type,
int device_id, void **edid);
extern enum acpi_backlight_type acpi_video_get_backlight_type(void);
+extern bool acpi_video_backlight_use_native(void);
extern void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type type);
/*
* Note: The value returned by acpi_v
[Intel-gfx] [PATCH v5 04/31] drm/radeon: Don't register backlight when another backlight should be used (v3)
Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.
Registering 2 backlight devices for a single display really is
undesirable, don't register the GPU's native backlight device when
another backlight device should be used.
Changes in v2:
- To avoid linker errors when amdgpu is builtin and video_detect.c is in
a module, select ACPI_VIDEO and its deps if ACPI is enabled.
When ACPI is disabled, ACPI_VIDEO is also always disabled, ensuring
the stubs from acpi/video.h will be used.
Changes in v3:
- Use drm_info(drm_dev, "...") to log messages
- ACPI_VIDEO can now be enabled on non X86 too,
adjust the Kconfig changes to match this.
Acked-by: Alex Deucher
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/Kconfig | 7 +++
drivers/gpu/drm/radeon/atombios_encoders.c | 7 +++
drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 7 +++
3 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 95ca33938b4a..0471505e951d 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -234,6 +234,13 @@ config DRM_RADEON
select HWMON
select BACKLIGHT_CLASS_DEVICE
select INTERVAL_TREE
+ # radeon depends on ACPI_VIDEO when ACPI is enabled, for select to work
+ # ACPI_VIDEO's dependencies must also be selected.
+ select INPUT if ACPI
+ select ACPI_VIDEO if ACPI
+ # On x86 ACPI_VIDEO also needs ACPI_WMI
+ select X86_PLATFORM_DEVICES if ACPI && X86
+ select ACPI_WMI if ACPI && X86
help
Choose this option if you have an ATI Radeon graphics card. There
are both PCI and AGP versions. You don't need to choose this to
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
b/drivers/gpu/drm/radeon/atombios_encoders.c
index 0eae05dfb385..c841c273222e 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -32,6 +32,8 @@
#include
#include
+#include
+
#include "atom.h"
#include "radeon_atombios.h"
#include "radeon.h"
@@ -209,6 +211,11 @@ void radeon_atom_backlight_init(struct radeon_encoder
*radeon_encoder,
if (!(rdev->mode_info.firmware_flags &
ATOM_BIOS_INFO_BL_CONTROLLED_BY_GPU))
return;
+ if (!acpi_video_backlight_use_native()) {
+ drm_info(dev, "Skipping radeon atom DIG backlight
registration\n");
+ return;
+ }
+
pdata = kmalloc(sizeof(struct radeon_backlight_privdata), GFP_KERNEL);
if (!pdata) {
DRM_ERROR("Memory allocation failed\n");
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
index 1a66fb969ee7..0cd32c65456c 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
@@ -33,6 +33,8 @@
#include
#include
+#include
+
#include "radeon.h"
#include "radeon_asic.h"
#include "radeon_legacy_encoders.h"
@@ -387,6 +389,11 @@ void radeon_legacy_backlight_init(struct radeon_encoder
*radeon_encoder,
return;
#endif
+ if (!acpi_video_backlight_use_native()) {
+ drm_info(dev, "Skipping radeon legacy LVDS backlight
registration\n");
+ return;
+ }
+
pdata = kmalloc(sizeof(struct radeon_backlight_privdata), GFP_KERNEL);
if (!pdata) {
DRM_ERROR("Memory allocation failed\n");
--
2.37.2
[Intel-gfx] [PATCH v5 09/31] ACPI: video: Make backlight class device registration a separate step (v2)
On x86/ACPI boards the acpi_video driver will usually initialize before
the kms driver (except i915). This causes /sys/class/backlight/acpi_video0
to show up and then the kms driver registers its own native backlight
device after which the drivers/acpi/video_detect.c code unregisters
the acpi_video0 device (when acpi_video_get_backlight_type()==native).
This means that userspace briefly sees 2 devices and the disappearing of
acpi_video0 after a brief time confuses the systemd backlight level
save/restore code, see e.g.:
https://bbs.archlinux.org/viewtopic.php?id=269920
To fix this make backlight class device registration a separate step
done by a new acpi_video_register_backlight() function. The intend is for
this to be called by the drm/kms driver *after* it is done setting up its
own native backlight device. So that acpi_video_get_backlight_type() knows
if a native backlight will be available or not at acpi_video backlight
registration time, avoiding the add + remove dance.
Note the new acpi_video_register_backlight() function is also called from
a delayed work to ensure that the acpi_video backlight devices does get
registered if necessary even if there is no drm/kms driver or when it is
disabled.
Changes in v2:
- Make register_backlight_delay a module parameter, mainly so that it can
be disabled by Nvidia binary driver users
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/acpi_video.c | 50 ---
include/acpi/video.h | 2 ++
2 files changed, 49 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
index 8545bf94866f..09dd86f86cf3 100644
--- a/drivers/acpi/acpi_video.c
+++ b/drivers/acpi/acpi_video.c
@@ -73,6 +73,16 @@ module_param(device_id_scheme, bool, 0444);
static int only_lcd = -1;
module_param(only_lcd, int, 0444);
+/*
+ * Display probing is known to take up to 5 seconds, so delay the fallback
+ * backlight registration by 5 seconds + 3 seconds for some extra margin.
+ */
+static int register_backlight_delay = 8;
+module_param(register_backlight_delay, int, 0444);
+MODULE_PARM_DESC(register_backlight_delay,
+ "Delay in seconds before doing fallback (non GPU driver triggered) "
+ "backlight registration, set to 0 to disable.");
+
static bool may_report_brightness_keys;
static int register_count;
static DEFINE_MUTEX(register_count_mutex);
@@ -81,6 +91,9 @@ static LIST_HEAD(video_bus_head);
static int acpi_video_bus_add(struct acpi_device *device);
static int acpi_video_bus_remove(struct acpi_device *device);
static void acpi_video_bus_notify(struct acpi_device *device, u32 event);
+static void acpi_video_bus_register_backlight_work(struct work_struct
*ignored);
+static DECLARE_DELAYED_WORK(video_bus_register_backlight_work,
+ acpi_video_bus_register_backlight_work);
void acpi_video_detect_exit(void);
/*
@@ -1859,8 +1872,6 @@ static int acpi_video_bus_register_backlight(struct
acpi_video_bus *video)
if (video->backlight_registered)
return 0;
- acpi_video_run_bcl_for_osi(video);
-
if (acpi_video_get_backlight_type() != acpi_backlight_video)
return 0;
@@ -2086,7 +2097,11 @@ static int acpi_video_bus_add(struct acpi_device *device)
list_add_tail(&video->entry, &video_bus_head);
mutex_unlock(&video_list_lock);
- acpi_video_bus_register_backlight(video);
+ /*
+* The userspace visible backlight_device gets registered separately
+* from acpi_video_register_backlight().
+*/
+ acpi_video_run_bcl_for_osi(video);
acpi_video_bus_add_notify_handler(video);
return 0;
@@ -2125,6 +2140,11 @@ static int acpi_video_bus_remove(struct acpi_device
*device)
return 0;
}
+static void acpi_video_bus_register_backlight_work(struct work_struct *ignored)
+{
+ acpi_video_register_backlight();
+}
+
static int __init is_i740(struct pci_dev *dev)
{
if (dev->device == 0x00D1)
@@ -2235,6 +2255,18 @@ int acpi_video_register(void)
*/
register_count = 1;
+ /*
+* acpi_video_bus_add() skips registering the userspace visible
+* backlight_device. The intend is for this to be registered by the
+* drm/kms driver calling acpi_video_register_backlight() *after* it is
+* done setting up its own native backlight device. The delayed work
+* ensures that acpi_video_register_backlight() always gets called
+* eventually, in case there is no drm/kms driver or it is disabled.
+*/
+ if (register_backlight_delay)
+ schedule_delayed_work(&video_bus_register_backlight_work,
+ register_backlight_delay * HZ);
+
leave:
mutex_unlock(®ister_count_mutex);
return ret;
@@ -2245,6 +2277,7 @@ void acpi_video_unregister(void)
{
mutex_lock(®ister_count_mutex);
if (reg
[Intel-gfx] [PATCH v5 05/31] drm/nouveau: Don't register backlight when another backlight should be used (v2)
Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.
Registering 2 backlight devices for a single display really is
undesirable, don't register the GPU's native backlight device when
another backlight device should be used.
Changes in v2:
- Add nouveau_acpi_video_backlight_use_native() wrapper to avoid unresolved
symbol errors on non X86
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 5 +
drivers/gpu/drm/nouveau/nouveau_acpi.h | 2 ++
drivers/gpu/drm/nouveau/nouveau_backlight.c | 6 ++
3 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c
b/drivers/gpu/drm/nouveau/nouveau_acpi.c
index 6140db756d06..1592c9cd7750 100644
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
@@ -386,3 +386,8 @@ nouveau_acpi_edid(struct drm_device *dev, struct
drm_connector *connector)
return kmemdup(edid, EDID_LENGTH, GFP_KERNEL);
}
+
+bool nouveau_acpi_video_backlight_use_native(void)
+{
+ return acpi_video_backlight_use_native();
+}
diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.h
b/drivers/gpu/drm/nouveau/nouveau_acpi.h
index 330f9b837066..3c666c30dfca 100644
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.h
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.h
@@ -11,6 +11,7 @@ void nouveau_register_dsm_handler(void);
void nouveau_unregister_dsm_handler(void);
void nouveau_switcheroo_optimus_dsm(void);
void *nouveau_acpi_edid(struct drm_device *, struct drm_connector *);
+bool nouveau_acpi_video_backlight_use_native(void);
#else
static inline bool nouveau_is_optimus(void) { return false; };
static inline bool nouveau_is_v1_dsm(void) { return false; };
@@ -18,6 +19,7 @@ static inline void nouveau_register_dsm_handler(void) {}
static inline void nouveau_unregister_dsm_handler(void) {}
static inline void nouveau_switcheroo_optimus_dsm(void) {}
static inline void *nouveau_acpi_edid(struct drm_device *dev, struct
drm_connector *connector) { return NULL; }
+static inline bool nouveau_acpi_video_backlight_use_native(void) { return
true; }
#endif
#endif
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index a2141d3d9b1d..d2b8f8c13db4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -38,6 +38,7 @@
#include "nouveau_reg.h"
#include "nouveau_encoder.h"
#include "nouveau_connector.h"
+#include "nouveau_acpi.h"
static struct ida bl_ida;
#define BL_NAME_SIZE 15 // 12 for name + 2 for digits + 1 for '\0'
@@ -405,6 +406,11 @@ nouveau_backlight_init(struct drm_connector *connector)
goto fail_alloc;
}
+ if (!nouveau_acpi_video_backlight_use_native()) {
+ NV_INFO(drm, "Skipping nv_backlight registration\n");
+ goto fail_alloc;
+ }
+
if (!nouveau_get_backlight_name(backlight_name, bl)) {
NV_ERROR(drm, "Failed to retrieve a unique name for the
backlight interface\n");
goto fail_alloc;
--
2.37.2
[Intel-gfx] [PATCH v5 06/31] ACPI: video: Drop backlight_device_get_by_type() call from acpi_video_get_backlight_type()
All x86/ACPI kms drivers which register native/BACKLIGHT_RAW type backlight devices call acpi_video_backlight_use_native() now. This sets __acpi_video_get_backlight_type()'s internal static native_available flag. This makes the backlight_device_get_by_type(BACKLIGHT_RAW) check unnecessary. Relying on the cached native_available value not only is simpler, it will also work correctly in cases where then native backlight registration was skipped because of acpi_video_backlight_use_native() returning false. Acked-by: Rafael J. Wysocki Signed-off-by: Hans de Goede --- drivers/acpi/video_detect.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c index 5f105eaa7d30..385eb49c763f 100644 --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -608,8 +608,7 @@ static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native) if (!(video_caps & ACPI_VIDEO_BACKLIGHT)) return acpi_backlight_vendor; - if (acpi_osi_is_win8() && - (native_available || backlight_device_get_by_type(BACKLIGHT_RAW))) + if (acpi_osi_is_win8() && native_available) return acpi_backlight_native; return acpi_backlight_video; -- 2.37.2
[Intel-gfx] [PATCH v5 08/31] ACPI: video: Simplify acpi_video_unregister_backlight()
When acpi_video_register() has not run yet the video_bus_head will be
empty, so there is no need to check the register_count flag first.
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/acpi_video.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
index cde8ffa9f0b8..8545bf94866f 100644
--- a/drivers/acpi/acpi_video.c
+++ b/drivers/acpi/acpi_video.c
@@ -2257,14 +2257,10 @@ void acpi_video_unregister_backlight(void)
{
struct acpi_video_bus *video;
- mutex_lock(®ister_count_mutex);
- if (register_count) {
- mutex_lock(&video_list_lock);
- list_for_each_entry(video, &video_bus_head, entry)
- acpi_video_bus_unregister_backlight(video);
- mutex_unlock(&video_list_lock);
- }
- mutex_unlock(®ister_count_mutex);
+ mutex_lock(&video_list_lock);
+ list_for_each_entry(video, &video_bus_head, entry)
+ acpi_video_bus_unregister_backlight(video);
+ mutex_unlock(&video_list_lock);
}
bool acpi_video_handles_brightness_key_presses(void)
--
2.37.2
[Intel-gfx] [PATCH v5 11/31] drm/i915: Call acpi_video_register_backlight() (v3)
On machins without an i915 opregion the acpi_video driver immediately
probes the ACPI video bus and used to also immediately register
acpi_video# backlight devices when supported.
Once the drm/kms driver then loaded later and possibly registered
a native backlight device then the drivers/acpi/video_detect.c code
unregistered the acpi_video0 device to avoid there being 2 backlight
devices (when acpi_video_get_backlight_type()==native).
This means that userspace used to briefly see 2 devices and the
disappearing of acpi_video0 after a brief time confuses the systemd
backlight level save/restore code, see e.g.:
https://bbs.archlinux.org/viewtopic.php?id=269920
To fix this the ACPI video code has been modified to make backlight class
device registration a separate step, relying on the drm/kms driver to
ask for the acpi_video backlight registration after it is done setting up
its native backlight device.
Add a call to the new acpi_video_register_backlight() after the i915 calls
acpi_video_register() (after setting up the i915 opregion) so that the
acpi_video backlight devices get registered on systems where the i915
native backlight device is not registered.
Changes in v2:
-Only call acpi_video_register_backlight() when a panel is detected
Changes in v3:
-Add a new intel_acpi_video_register() helper which checks if a panel
is present and then calls acpi_video_register_backlight()
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_acpi.c| 27
drivers/gpu/drm/i915/display/intel_acpi.h| 3 +++
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
3 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c
b/drivers/gpu/drm/i915/display/intel_acpi.c
index e78430001f07..9df78e7caa2b 100644
--- a/drivers/gpu/drm/i915/display/intel_acpi.c
+++ b/drivers/gpu/drm/i915/display/intel_acpi.c
@@ -7,6 +7,7 @@
#include
#include
+#include
#include "i915_drv.h"
#include "intel_acpi.h"
@@ -331,3 +332,29 @@ void intel_acpi_assign_connector_fwnodes(struct
drm_i915_private *i915)
*/
fwnode_handle_put(fwnode);
}
+
+void intel_acpi_video_register(struct drm_i915_private *i915)
+{
+ struct drm_connector_list_iter conn_iter;
+ struct drm_connector *connector;
+
+ acpi_video_register();
+
+ /*
+* If i915 is driving an internal panel without registering its native
+* backlight handler try to register the acpi_video backlight.
+* For panels not driven by i915 another GPU driver may still register
+* a native backlight later and acpi_video_register_backlight() should
+* only be called after any native backlights have been registered.
+*/
+ drm_connector_list_iter_begin(&i915->drm, &conn_iter);
+ drm_for_each_connector_iter(connector, &conn_iter) {
+ struct intel_panel *panel =
&to_intel_connector(connector)->panel;
+
+ if (panel->backlight.funcs && !panel->backlight.device) {
+ acpi_video_register_backlight();
+ break;
+ }
+ }
+ drm_connector_list_iter_end(&conn_iter);
+}
diff --git a/drivers/gpu/drm/i915/display/intel_acpi.h
b/drivers/gpu/drm/i915/display/intel_acpi.h
index 4a760a2baed9..6a0007452f95 100644
--- a/drivers/gpu/drm/i915/display/intel_acpi.h
+++ b/drivers/gpu/drm/i915/display/intel_acpi.h
@@ -14,6 +14,7 @@ void intel_unregister_dsm_handler(void);
void intel_dsm_get_bios_data_funcs_supported(struct drm_i915_private *i915);
void intel_acpi_device_id_update(struct drm_i915_private *i915);
void intel_acpi_assign_connector_fwnodes(struct drm_i915_private *i915);
+void intel_acpi_video_register(struct drm_i915_private *i915);
#else
static inline void intel_register_dsm_handler(void) { return; }
static inline void intel_unregister_dsm_handler(void) { return; }
@@ -23,6 +24,8 @@ static inline
void intel_acpi_device_id_update(struct drm_i915_private *i915) { return; }
static inline
void intel_acpi_assign_connector_fwnodes(struct drm_i915_private *i915) {
return; }
+static inline
+void intel_acpi_video_register(struct drm_i915_private *i915) { return; }
#endif /* CONFIG_ACPI */
#endif /* __INTEL_ACPI_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 6103b02c081f..129a13375101 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -9087,7 +9087,7 @@ void intel_display_driver_register(struct
drm_i915_private *i915)
/* Must be done after probing outputs */
intel_opregion_register(i915);
- acpi_video_register();
+ intel_acpi_video_register(i915);
intel_audio_init(i915);
--
2.37.2
[Intel-gfx] [PATCH v5 13/31] drm/amdgpu: Register ACPI video backlight when skipping amdgpu backlight registration
Typically the acpi_video driver will initialize before amdgpu, which
used to cause /sys/class/backlight/acpi_video0 to get registered and then
amdgpu would register its own amdgpu_bl# device later. After which
the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
to avoid there being 2 backlight devices.
This means that userspace used to briefly see 2 devices and the
disappearing of acpi_video0 after a brief time confuses the systemd
backlight level save/restore code, see e.g.:
https://bbs.archlinux.org/viewtopic.php?id=269920
To fix this the ACPI video code has been modified to make backlight class
device registration a separate step, relying on the drm/kms driver to
ask for the acpi_video backlight registration after it is done setting up
its native backlight device.
Add a call to the new acpi_video_register_backlight() when amdgpu skips
registering its own backlight device because of either the firmware_flags
or the acpi_video_get_backlight_type() return value. This ensures that
if the acpi_video backlight device should be used, it will be available
before the amdgpu drm_device gets registered with userspace.
Acked-by: Alex Deucher
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/amd/amdgpu/atombios_encoders.c| 9 +++--
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
index b4e3cedceaf8..6be9ac2b9c5b 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
@@ -184,11 +184,11 @@ void amdgpu_atombios_encoder_init_backlight(struct
amdgpu_encoder *amdgpu_encode
return;
if (!(adev->mode_info.firmware_flags &
ATOM_BIOS_INFO_BL_CONTROLLED_BY_GPU))
- return;
+ goto register_acpi_backlight;
if (!acpi_video_backlight_use_native()) {
drm_info(dev, "Skipping amdgpu atom DIG backlight
registration\n");
- return;
+ goto register_acpi_backlight;
}
pdata = kmalloc(sizeof(struct amdgpu_backlight_privdata), GFP_KERNEL);
@@ -225,6 +225,11 @@ void amdgpu_atombios_encoder_init_backlight(struct
amdgpu_encoder *amdgpu_encode
error:
kfree(pdata);
return;
+
+register_acpi_backlight:
+ /* Try registering an ACPI video backlight device instead. */
+ acpi_video_register_backlight();
+ return;
}
void
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 706c67f4bda8..c450964f84d4 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4037,6 +4037,8 @@ amdgpu_dm_register_backlight_device(struct
amdgpu_display_manager *dm)
if (!acpi_video_backlight_use_native()) {
drm_info(adev_to_drm(dm->adev), "Skipping amdgpu DM backlight
registration\n");
+ /* Try registering an ACPI video backlight device instead. */
+ acpi_video_register_backlight();
return;
}
--
2.37.2
[Intel-gfx] [PATCH v5 14/31] drm/radeon: Register ACPI video backlight when skipping radeon backlight registration
Typically the acpi_video driver will initialize before radeon, which
used to cause /sys/class/backlight/acpi_video0 to get registered and then
radeon would register its own radeon_bl# device later. After which
the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
to avoid there being 2 backlight devices.
This means that userspace used to briefly see 2 devices and the
disappearing of acpi_video0 after a brief time confuses the systemd
backlight level save/restore code, see e.g.:
https://bbs.archlinux.org/viewtopic.php?id=269920
To fix this the ACPI video code has been modified to make backlight class
device registration a separate step, relying on the drm/kms driver to
ask for the acpi_video backlight registration after it is done setting up
its native backlight device.
Add a call to the new acpi_video_register_backlight() when radeon skips
registering its own backlight device because of e.g. the firmware_flags
or the acpi_video_get_backlight_type() return value. This ensures that
if the acpi_video backlight device should be used, it will be available
before the radeon drm_device gets registered with userspace.
Acked-by: Alex Deucher
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/radeon/radeon_encoders.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c
b/drivers/gpu/drm/radeon/radeon_encoders.c
index 35c535e48b8d..fbc0a2182318 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -30,6 +30,8 @@
#include
#include
+#include
+
#include "radeon.h"
#include "radeon_atombios.h"
#include "radeon_legacy_encoders.h"
@@ -167,7 +169,7 @@ static void radeon_encoder_add_backlight(struct
radeon_encoder *radeon_encoder,
return;
if (radeon_backlight == 0) {
- return;
+ use_bl = false;
} else if (radeon_backlight == 1) {
use_bl = true;
} else if (radeon_backlight == -1) {
@@ -193,6 +195,13 @@ static void radeon_encoder_add_backlight(struct
radeon_encoder *radeon_encoder,
else
radeon_legacy_backlight_init(radeon_encoder, connector);
}
+
+ /*
+* If there is no native backlight device (which may happen even when
+* use_bl==true) try registering an ACPI video backlight device instead.
+*/
+ if (!rdev->mode_info.bl_encoder)
+ acpi_video_register_backlight();
}
void
--
2.37.2
[Intel-gfx] [PATCH v5 10/31] ACPI: video: Remove code to unregister acpi_video backlight when a native backlight registers
Remove the code to unregister acpi_video backlight devices when
a native backlight device gets registered later.
Now that the acpi_video backlight device registration is a separate step
which runs later, after the drm/kms driver is done setting up its own
native backlight device, it is no longer necessary to monitor for a
native (BACKLIGHT_RAW) device showing up later and to then unregister
the acpi_video backlight device(s).
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/acpi_video.c | 2 --
drivers/acpi/video_detect.c | 36
2 files changed, 38 deletions(-)
diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
index 09dd86f86cf3..d1e41f30c004 100644
--- a/drivers/acpi/acpi_video.c
+++ b/drivers/acpi/acpi_video.c
@@ -94,7 +94,6 @@ static void acpi_video_bus_notify(struct acpi_device *device,
u32 event);
static void acpi_video_bus_register_backlight_work(struct work_struct
*ignored);
static DECLARE_DELAYED_WORK(video_bus_register_backlight_work,
acpi_video_bus_register_backlight_work);
-void acpi_video_detect_exit(void);
/*
* Indices in the _BCL method response: the first two items are special,
@@ -2342,7 +2341,6 @@ static int __init acpi_video_init(void)
static void __exit acpi_video_exit(void)
{
- acpi_video_detect_exit();
acpi_video_unregister();
}
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 385eb49c763f..fb49b8f4523a 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -38,10 +38,6 @@
void acpi_video_unregister_backlight(void);
-static bool backlight_notifier_registered;
-static struct notifier_block backlight_nb;
-static struct work_struct backlight_notify_work;
-
static enum acpi_backlight_type acpi_backlight_cmdline = acpi_backlight_undef;
static enum acpi_backlight_type acpi_backlight_dmi = acpi_backlight_undef;
@@ -538,26 +534,6 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
{ },
};
-/* This uses a workqueue to avoid various locking ordering issues */
-static void acpi_video_backlight_notify_work(struct work_struct *work)
-{
- if (acpi_video_get_backlight_type() != acpi_backlight_video)
- acpi_video_unregister_backlight();
-}
-
-static int acpi_video_backlight_notify(struct notifier_block *nb,
- unsigned long val, void *bd)
-{
- struct backlight_device *backlight = bd;
-
- /* A raw bl registering may change video -> native */
- if (backlight->props.type == BACKLIGHT_RAW &&
- val == BACKLIGHT_REGISTERED)
- schedule_work(&backlight_notify_work);
-
- return NOTIFY_OK;
-}
-
/*
* Determine which type of backlight interface to use on this system,
* First check cmdline, then dmi quirks, then do autodetect.
@@ -587,12 +563,6 @@ static enum acpi_backlight_type
__acpi_video_get_backlight_type(bool native)
acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
ACPI_UINT32_MAX, find_video, NULL,
&video_caps, NULL);
- INIT_WORK(&backlight_notify_work,
- acpi_video_backlight_notify_work);
- backlight_nb.notifier_call = acpi_video_backlight_notify;
- backlight_nb.priority = 0;
- if (backlight_register_notifier(&backlight_nb) == 0)
- backlight_notifier_registered = true;
init_done = true;
}
if (native)
@@ -639,9 +609,3 @@ void acpi_video_set_dmi_backlight_type(enum
acpi_backlight_type type)
acpi_video_unregister_backlight();
}
EXPORT_SYMBOL(acpi_video_set_dmi_backlight_type);
-
-void __exit acpi_video_detect_exit(void)
-{
- if (backlight_notifier_registered)
- backlight_unregister_notifier(&backlight_nb);
-}
--
2.37.2
[Intel-gfx] [PATCH v5 07/31] ACPI: video: Remove acpi_video_bus from list before tearing it down
Move the list_del removing an acpi_video_bus from video_bus_head on teardown to before the teardown is done, to avoid code iterating over the video_bus_head list seeing acpi_video_bus objects on there which are (partly) torn down already. Acked-by: Rafael J. Wysocki Signed-off-by: Hans de Goede --- drivers/acpi/acpi_video.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c index 5cbe2196176d..cde8ffa9f0b8 100644 --- a/drivers/acpi/acpi_video.c +++ b/drivers/acpi/acpi_video.c @@ -2111,14 +2111,14 @@ static int acpi_video_bus_remove(struct acpi_device *device) video = acpi_driver_data(device); - acpi_video_bus_remove_notify_handler(video); - acpi_video_bus_unregister_backlight(video); - acpi_video_bus_put_devices(video); - mutex_lock(&video_list_lock); list_del(&video->entry); mutex_unlock(&video_list_lock); + acpi_video_bus_remove_notify_handler(video); + acpi_video_bus_unregister_backlight(video); + acpi_video_bus_put_devices(video); + kfree(video->attached_array); kfree(video); -- 2.37.2
[Intel-gfx] [PATCH v5 18/31] ACPI: video: Add Apple GMUX brightness control detection
On Apple laptops with an Apple GMUX using this for brightness control,
should take precedence of any other brightness control methods.
Add apple-gmux detection to acpi_video_get_backlight_type() using
the already existing apple_gmux_present() helper function.
This will allow removig the (ab)use of:
acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
Inside the apple-gmux driver.
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/video_detect.c | 4
include/acpi/video.h| 1 +
2 files changed, 5 insertions(+)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 4dc7fb865083..be2fc43418af 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -28,6 +28,7 @@
#include
#include
+#include
#include
#include
#include
@@ -607,6 +608,9 @@ static enum acpi_backlight_type
__acpi_video_get_backlight_type(bool native)
if (nvidia_wmi_ec_present)
return acpi_backlight_nvidia_wmi_ec;
+ if (apple_gmux_present())
+ return acpi_backlight_apple_gmux;
+
/* On systems with ACPI video use either native or ACPI video. */
if (video_caps & ACPI_VIDEO_BACKLIGHT) {
/*
diff --git a/include/acpi/video.h b/include/acpi/video.h
index 91578e77ac4e..dbd48cb8bd23 100644
--- a/include/acpi/video.h
+++ b/include/acpi/video.h
@@ -49,6 +49,7 @@ enum acpi_backlight_type {
acpi_backlight_vendor,
acpi_backlight_native,
acpi_backlight_nvidia_wmi_ec,
+ acpi_backlight_apple_gmux,
};
#if IS_ENABLED(CONFIG_ACPI_VIDEO)
--
2.37.2
[Intel-gfx] [PATCH v5 12/31] drm/nouveau: Register ACPI video backlight when nv_backlight registration fails (v2)
Typically the acpi_video driver will initialize before nouveau, which
used to cause /sys/class/backlight/acpi_video0 to get registered and then
nouveau would register its own nv_backlight device later. After which
the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
to avoid there being 2 backlight devices.
This means that userspace used to briefly see 2 devices and the
disappearing of acpi_video0 after a brief time confuses the systemd
backlight level save/restore code, see e.g.:
https://bbs.archlinux.org/viewtopic.php?id=269920
To fix this the ACPI video code has been modified to make backlight class
device registration a separate step, relying on the drm/kms driver to
ask for the acpi_video backlight registration after it is done setting up
its native backlight device.
Add a call to the new acpi_video_register_backlight() when native backlight
device registration has failed / was skipped to ensure that there is a
backlight device available before the drm_device gets registered with
userspace.
Changes in v2:
- Add nouveau_acpi_video_register_backlight() wrapper to avoid unresolved
symbol errors on non X86
Reviewed-by: Lyude Paul
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 5 +
drivers/gpu/drm/nouveau/nouveau_acpi.h | 2 ++
drivers/gpu/drm/nouveau/nouveau_backlight.c | 7 +++
3 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c
b/drivers/gpu/drm/nouveau/nouveau_acpi.c
index 1592c9cd7750..8cf096f841a9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
@@ -391,3 +391,8 @@ bool nouveau_acpi_video_backlight_use_native(void)
{
return acpi_video_backlight_use_native();
}
+
+void nouveau_acpi_video_register_backlight(void)
+{
+ acpi_video_register_backlight();
+}
diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.h
b/drivers/gpu/drm/nouveau/nouveau_acpi.h
index 3c666c30dfca..e39dd8b94b8b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.h
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.h
@@ -12,6 +12,7 @@ void nouveau_unregister_dsm_handler(void);
void nouveau_switcheroo_optimus_dsm(void);
void *nouveau_acpi_edid(struct drm_device *, struct drm_connector *);
bool nouveau_acpi_video_backlight_use_native(void);
+void nouveau_acpi_video_register_backlight(void);
#else
static inline bool nouveau_is_optimus(void) { return false; };
static inline bool nouveau_is_v1_dsm(void) { return false; };
@@ -20,6 +21,7 @@ static inline void nouveau_unregister_dsm_handler(void) {}
static inline void nouveau_switcheroo_optimus_dsm(void) {}
static inline void *nouveau_acpi_edid(struct drm_device *dev, struct
drm_connector *connector) { return NULL; }
static inline bool nouveau_acpi_video_backlight_use_native(void) { return
true; }
+static inline void nouveau_acpi_video_register_backlight(void) {}
#endif
#endif
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index d2b8f8c13db4..a614582779ca 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -436,6 +436,13 @@ nouveau_backlight_init(struct drm_connector *connector)
fail_alloc:
kfree(bl);
+ /*
+* If we get here we have an internal panel, but no nv_backlight,
+* try registering an ACPI video backlight device instead.
+*/
+ if (ret == 0)
+ nouveau_acpi_video_register_backlight();
+
return ret;
}
--
2.37.2
[Intel-gfx] [PATCH v5 20/31] platform/x86: apple-gmux: Stop calling acpi/video.h functions
Now that acpi_video_get_backlight_type() has apple-gmux detection (using apple_gmux_present()), it is no longer necessary for the apple-gmux code to manually remove possibly conflicting drivers. So remove the handling for this from the apple-gmux driver. Signed-off-by: Hans de Goede --- drivers/platform/x86/apple-gmux.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/platform/x86/apple-gmux.c b/drivers/platform/x86/apple-gmux.c index ffe98a18440b..ca33df7ea550 100644 --- a/drivers/platform/x86/apple-gmux.c +++ b/drivers/platform/x86/apple-gmux.c @@ -21,7 +21,6 @@ #include #include #include -#include #include /** @@ -694,7 +693,6 @@ static int gmux_probe(struct pnp_dev *pnp, const struct pnp_device_id *id) * backlight control and supports more levels than other options. * Disable the other backlight choices. */ - acpi_video_set_dmi_backlight_type(acpi_backlight_vendor); apple_bl_unregister(); gmux_data->power_state = VGA_SWITCHEROO_ON; @@ -804,7 +802,6 @@ static void gmux_remove(struct pnp_dev *pnp) apple_gmux_data = NULL; kfree(gmux_data); - acpi_video_register(); apple_bl_register(); } -- 2.37.2
[Intel-gfx] [PATCH v5 16/31] ACPI: video: Refactor acpi_video_get_backlight_type() a bit
Refactor acpi_video_get_backlight_type() so that the heuristics /
detection steps are stricly in order of descending precedence.
Also move the comments describing the steps to when the various steps are
actually done, to avoid the comments getting out of sync with the code.
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/video_detect.c | 39 ++---
1 file changed, 23 insertions(+), 16 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index fb49b8f4523a..cc9d0d91e268 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -537,16 +537,6 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
/*
* Determine which type of backlight interface to use on this system,
* First check cmdline, then dmi quirks, then do autodetect.
- *
- * The autodetect order is:
- * 1) Is the acpi-video backlight interface supported ->
- * no, use a vendor interface
- * 2) Is this a win8 "ready" BIOS and do we have a native interface ->
- * yes, use a native interface
- * 3) Else use the acpi-video interface
- *
- * Arguably the native on win8 check should be done first, but that would
- * be a behavior change, which may causes issues.
*/
static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
{
@@ -569,19 +559,36 @@ static enum acpi_backlight_type
__acpi_video_get_backlight_type(bool native)
native_available = true;
mutex_unlock(&init_mutex);
+ /*
+* The below heuristics / detection steps are in order of descending
+* presedence. The commandline takes presedence over anything else.
+*/
if (acpi_backlight_cmdline != acpi_backlight_undef)
return acpi_backlight_cmdline;
+ /* DMI quirks override any autodetection. */
if (acpi_backlight_dmi != acpi_backlight_undef)
return acpi_backlight_dmi;
- if (!(video_caps & ACPI_VIDEO_BACKLIGHT))
- return acpi_backlight_vendor;
-
- if (acpi_osi_is_win8() && native_available)
- return acpi_backlight_native;
+ /* On systems with ACPI video use either native or ACPI video. */
+ if (video_caps & ACPI_VIDEO_BACKLIGHT) {
+ /*
+* Windows 8 and newer no longer use the ACPI video interface,
+* so it often does not work. If the ACPI tables are written
+* for win8 and native brightness ctl is available, use that.
+*
+* The native check deliberately is inside the if acpi-video
+* block on older devices without acpi-video support native
+* is usually not the best choice.
+*/
+ if (acpi_osi_is_win8() && native_available)
+ return acpi_backlight_native;
+ else
+ return acpi_backlight_video;
+ }
- return acpi_backlight_video;
+ /* No ACPI video (old hw), use vendor specific fw methods. */
+ return acpi_backlight_vendor;
}
enum acpi_backlight_type acpi_video_get_backlight_type(void)
--
2.37.2
[Intel-gfx] [PATCH v5 15/31] platform/x86: nvidia-wmi-ec-backlight: Move fw interface definitions to a header (v2)
Move the WMI interface definitions to a header, so that the definitions
can be shared with drivers/acpi/video_detect.c .
Changes in v2:
- Add missing Nvidia copyright header
- Move WMI_BRIGHTNESS_GUID to nvidia-wmi-ec-backlight.h as well
Suggested-by: Daniel Dadap
Signed-off-by: Hans de Goede
---
MAINTAINERS | 1 +
.../platform/x86/nvidia-wmi-ec-backlight.c| 68 +
.../x86/nvidia-wmi-ec-backlight.h | 76 +++
3 files changed, 78 insertions(+), 67 deletions(-)
create mode 100644 include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 9d7f64dc0efe..d6f6b96f51f7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14527,6 +14527,7 @@ M: Daniel Dadap
L: platform-driver-...@vger.kernel.org
S: Supported
F: drivers/platform/x86/nvidia-wmi-ec-backlight.c
+F: include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
NVM EXPRESS DRIVER
M: Keith Busch
diff --git a/drivers/platform/x86/nvidia-wmi-ec-backlight.c
b/drivers/platform/x86/nvidia-wmi-ec-backlight.c
index 61e37194df70..be803e47eac0 100644
--- a/drivers/platform/x86/nvidia-wmi-ec-backlight.c
+++ b/drivers/platform/x86/nvidia-wmi-ec-backlight.c
@@ -7,74 +7,10 @@
#include
#include
#include
+#include
#include
#include
-/**
- * enum wmi_brightness_method - WMI method IDs
- * @WMI_BRIGHTNESS_METHOD_LEVEL: Get/Set EC brightness level status
- * @WMI_BRIGHTNESS_METHOD_SOURCE: Get/Set EC Brightness Source
- */
-enum wmi_brightness_method {
- WMI_BRIGHTNESS_METHOD_LEVEL = 1,
- WMI_BRIGHTNESS_METHOD_SOURCE = 2,
- WMI_BRIGHTNESS_METHOD_MAX
-};
-
-/**
- * enum wmi_brightness_mode - Operation mode for WMI-wrapped method
- * @WMI_BRIGHTNESS_MODE_GET:Get the current brightness
level/source.
- * @WMI_BRIGHTNESS_MODE_SET:Set the brightness level.
- * @WMI_BRIGHTNESS_MODE_GET_MAX_LEVEL: Get the maximum brightness level. This
- * is only valid when the WMI method is
- * %WMI_BRIGHTNESS_METHOD_LEVEL.
- */
-enum wmi_brightness_mode {
- WMI_BRIGHTNESS_MODE_GET = 0,
- WMI_BRIGHTNESS_MODE_SET = 1,
- WMI_BRIGHTNESS_MODE_GET_MAX_LEVEL = 2,
- WMI_BRIGHTNESS_MODE_MAX
-};
-
-/**
- * enum wmi_brightness_source - Backlight brightness control source selection
- * @WMI_BRIGHTNESS_SOURCE_GPU: Backlight brightness is controlled by the GPU.
- * @WMI_BRIGHTNESS_SOURCE_EC: Backlight brightness is controlled by the
- * system's Embedded Controller (EC).
- * @WMI_BRIGHTNESS_SOURCE_AUX: Backlight brightness is controlled over the
- * DisplayPort AUX channel.
- */
-enum wmi_brightness_source {
- WMI_BRIGHTNESS_SOURCE_GPU = 1,
- WMI_BRIGHTNESS_SOURCE_EC = 2,
- WMI_BRIGHTNESS_SOURCE_AUX = 3,
- WMI_BRIGHTNESS_SOURCE_MAX
-};
-
-/**
- * struct wmi_brightness_args - arguments for the WMI-wrapped ACPI method
- * @mode:Pass in an &enum wmi_brightness_mode value to select between
- * getting or setting a value.
- * @val: In parameter for value to set when using %WMI_BRIGHTNESS_MODE_SET
- * mode. Not used in conjunction with %WMI_BRIGHTNESS_MODE_GET or
- * %WMI_BRIGHTNESS_MODE_GET_MAX_LEVEL mode.
- * @ret: Out parameter returning retrieved value when operating in
- * %WMI_BRIGHTNESS_MODE_GET or %WMI_BRIGHTNESS_MODE_GET_MAX_LEVEL
- * mode. Not used in %WMI_BRIGHTNESS_MODE_SET mode.
- * @ignored: Padding; not used. The ACPI method expects a 24 byte params
struct.
- *
- * This is the parameters structure for the WmiBrightnessNotify ACPI method as
- * wrapped by WMI. The value passed in to @val or returned by @ret will be a
- * brightness value when the WMI method ID is %WMI_BRIGHTNESS_METHOD_LEVEL, or
- * an &enum wmi_brightness_source value with %WMI_BRIGHTNESS_METHOD_SOURCE.
- */
-struct wmi_brightness_args {
- u32 mode;
- u32 val;
- u32 ret;
- u32 ignored[3];
-};
-
/**
* wmi_brightness_notify() - helper function for calling WMI-wrapped ACPI
method
* @w:Pointer to the struct wmi_device identified by %WMI_BRIGHTNESS_GUID
@@ -191,8 +127,6 @@ static int nvidia_wmi_ec_backlight_probe(struct wmi_device
*wdev, const void *ct
return PTR_ERR_OR_ZERO(bdev);
}
-#define WMI_BRIGHTNESS_GUID "603E9613-EF25-4338-A3D0-C46177516DB7"
-
static const struct wmi_device_id nvidia_wmi_ec_backlight_id_table[] = {
{ .guid_string = WMI_BRIGHTNESS_GUID },
{ }
diff --git a/include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
b/include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
new file mode 100644
index ..23d60130272c
--- /dev/null
+++ b/include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
@@ -0,0 +1,76 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2020, NVIDIA CORPOR
[Intel-gfx] [PATCH v5 19/31] platform/x86: nvidia-wmi-ec-backlight: Use acpi_video_get_backlight_type()
Add an acpi_video_get_backlight_type() == acpi_backlight_nvidia_wmi_ec
check. This will make nvidia-wmi-ec-backlight properly honor the user
selecting a different backlight driver through the acpi_backlight=...
kernel commandline option.
Since the auto-detect code check for nvidia-wmi-ec-backlight in
drivers/acpi/video_detect.c already checks that the WMI advertised
brightness-source is the embedded controller, this new check makes it
unnecessary for nvidia_wmi_ec_backlight_probe() to check this itself.
Suggested-by: Daniel Dadap
Reviewed-by: Daniel Dadap
Signed-off-by: Hans de Goede
---
drivers/platform/x86/Kconfig | 1 +
drivers/platform/x86/nvidia-wmi-ec-backlight.c | 14 +++---
2 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index f2f98e942cf2..0cc5ac35fc57 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -93,6 +93,7 @@ config PEAQ_WMI
config NVIDIA_WMI_EC_BACKLIGHT
tristate "EC Backlight Driver for Hybrid Graphics Notebook Systems"
+ depends on ACPI_VIDEO
depends on ACPI_WMI
depends on BACKLIGHT_CLASS_DEVICE
help
diff --git a/drivers/platform/x86/nvidia-wmi-ec-backlight.c
b/drivers/platform/x86/nvidia-wmi-ec-backlight.c
index be803e47eac0..baccdf658538 100644
--- a/drivers/platform/x86/nvidia-wmi-ec-backlight.c
+++ b/drivers/platform/x86/nvidia-wmi-ec-backlight.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
/**
* wmi_brightness_notify() - helper function for calling WMI-wrapped ACPI
method
@@ -87,19 +88,10 @@ static int nvidia_wmi_ec_backlight_probe(struct wmi_device
*wdev, const void *ct
{
struct backlight_properties props = {};
struct backlight_device *bdev;
- u32 source;
int ret;
- ret = wmi_brightness_notify(wdev, WMI_BRIGHTNESS_METHOD_SOURCE,
- WMI_BRIGHTNESS_MODE_GET, &source);
- if (ret)
- return ret;
-
- /*
-* This driver is only to be used when brightness control is handled
-* by the EC; otherwise, the GPU driver(s) should control brightness.
-*/
- if (source != WMI_BRIGHTNESS_SOURCE_EC)
+ /* drivers/acpi/video_detect.c also checks that SOURCE == EC */
+ if (acpi_video_get_backlight_type() != acpi_backlight_nvidia_wmi_ec)
return -ENODEV;
/*
--
2.37.2
[Intel-gfx] [PATCH v5 17/31] ACPI: video: Add Nvidia WMI EC brightness control detection (v3)
On some new laptop designs a new Nvidia specific WMI interface is present
which gives info about panel brightness control and may allow controlling
the brightness through this interface when the embedded controller is used
for brightness control.
When this WMI interface is present and indicates that the EC is used,
then this interface should be used for brightness control.
Changes in v2:
- Use the new shared nvidia-wmi-ec-backlight.h header for the
WMI firmware API definitions
- ACPI_VIDEO can now be enabled on non X86 too,
adjust the Kconfig changes to match this.
Changes in v3:
- Use WMI_BRIGHTNESS_GUID define
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/Kconfig | 1 +
drivers/acpi/video_detect.c| 37 ++
drivers/gpu/drm/gma500/Kconfig | 2 ++
drivers/gpu/drm/i915/Kconfig | 2 ++
include/acpi/video.h | 1 +
5 files changed, 43 insertions(+)
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 7802d8846a8d..44ad4b6bd234 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -212,6 +212,7 @@ config ACPI_VIDEO
tristate "Video"
depends on BACKLIGHT_CLASS_DEVICE
depends on INPUT
+ depends on ACPI_WMI || !X86
select THERMAL
help
This driver implements the ACPI Extensions For Display Adapters
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index cc9d0d91e268..4dc7fb865083 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -75,6 +76,36 @@ find_video(acpi_handle handle, u32 lvl, void *context, void
**rv)
return AE_OK;
}
+/* This depends on ACPI_WMI which is X86 only */
+#ifdef CONFIG_X86
+static bool nvidia_wmi_ec_supported(void)
+{
+ struct wmi_brightness_args args = {
+ .mode = WMI_BRIGHTNESS_MODE_GET,
+ .val = 0,
+ .ret = 0,
+ };
+ struct acpi_buffer buf = { (acpi_size)sizeof(args), &args };
+ acpi_status status;
+
+ status = wmi_evaluate_method(WMI_BRIGHTNESS_GUID, 0,
+WMI_BRIGHTNESS_METHOD_SOURCE, &buf, &buf);
+ if (ACPI_FAILURE(status))
+ return false;
+
+ /*
+* If brightness is handled by the EC then nvidia-wmi-ec-backlight
+* should be used, else the GPU driver(s) should be used.
+*/
+ return args.ret == WMI_BRIGHTNESS_SOURCE_EC;
+}
+#else
+static bool nvidia_wmi_ec_supported(void)
+{
+ return false;
+}
+#endif
+
/* Force to use vendor driver when the ACPI device is known to be
* buggy */
static int video_detect_force_vendor(const struct dmi_system_id *d)
@@ -541,6 +572,7 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
{
static DEFINE_MUTEX(init_mutex);
+ static bool nvidia_wmi_ec_present;
static bool native_available;
static bool init_done;
static long video_caps;
@@ -553,6 +585,7 @@ static enum acpi_backlight_type
__acpi_video_get_backlight_type(bool native)
acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
ACPI_UINT32_MAX, find_video, NULL,
&video_caps, NULL);
+ nvidia_wmi_ec_present = nvidia_wmi_ec_supported();
init_done = true;
}
if (native)
@@ -570,6 +603,10 @@ static enum acpi_backlight_type
__acpi_video_get_backlight_type(bool native)
if (acpi_backlight_dmi != acpi_backlight_undef)
return acpi_backlight_dmi;
+ /* Special cases such as nvidia_wmi_ec and apple gmux. */
+ if (nvidia_wmi_ec_present)
+ return acpi_backlight_nvidia_wmi_ec;
+
/* On systems with ACPI video use either native or ACPI video. */
if (video_caps & ACPI_VIDEO_BACKLIGHT) {
/*
diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig
index 0cff20265f97..807b989e3c77 100644
--- a/drivers/gpu/drm/gma500/Kconfig
+++ b/drivers/gpu/drm/gma500/Kconfig
@@ -7,6 +7,8 @@ config DRM_GMA500
select ACPI_VIDEO if ACPI
select BACKLIGHT_CLASS_DEVICE if ACPI
select INPUT if ACPI
+ select X86_PLATFORM_DEVICES if ACPI
+ select ACPI_WMI if ACPI
help
Say yes for an experimental 2D KMS framebuffer driver for the
Intel GMA500 (Poulsbo), Intel GMA600 (Moorestown/Oak Trail) and
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 7ae3b7d67fcf..3efce05d7b57 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -23,6 +23,8 @@ config DRM_I915
# but for select to work, need to select ACPI_VIDEO's dependencies, ick
select BACKLIGHT_CLASS_DEVICE if ACPI
[Intel-gfx] [PATCH v5 22/31] platform/x86: acer-wmi: Move backlight DMI quirks to acpi/video_detect.c
Move the backlight DMI quirks to acpi/video_detect.c, so that
the driver no longer needs to call acpi_video_set_dmi_backlight_type().
acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.
Note that even though the DMI quirk table name was video_vendor_dmi_table,
5/6 quirks were actually quirks to use the GPU native backlight.
These 5 quirks also had a callback in their dmi_system_id entry which
disabled the acer-wmi vendor driver; and any DMI match resulted in:
acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
which disabled the acpi_video driver, so only the native driver was left.
The new entries for these 5/6 devices correctly marks these as needing
the native backlight driver.
Also note that other changes in this series change the native backlight
drivers to no longer unconditionally register their backlight. Instead
these drivers now do this check:
if (acpi_video_get_backlight_type(false) != acpi_backlight_native)
return 0; /* bail */
which without this patch would have broken these 5/6 "special" quirks.
Since I had to look at all the commits adding the quirks anyways, to make
sure that I understood the code correctly, I've also added links to
the various original bugzillas for these quirks to the new entries.
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/video_detect.c | 53 ++
drivers/platform/x86/acer-wmi.c | 66 -
2 files changed, 53 insertions(+), 66 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 74e2087c8ff0..6a2523bc02ba 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -149,6 +149,15 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
DMI_MATCH(DMI_BOARD_NAME, "X360"),
},
},
+ {
+/* https://bugzilla.redhat.com/show_bug.cgi?id=1128309 */
+.callback = video_detect_force_vendor,
+/* Acer KAV80 */
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "KAV80"),
+ },
+ },
{
.callback = video_detect_force_vendor,
/* Asus UL30VT */
@@ -437,6 +446,41 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
DMI_MATCH(DMI_BOARD_NAME, "JV50"),
},
},
+ {
+/* https://bugzilla.redhat.com/show_bug.cgi?id=1012674 */
+.callback = video_detect_force_native,
+/* Acer Aspire 5741 */
+.matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5741"),
+ },
+ },
+ {
+/* https://bugzilla.kernel.org/show_bug.cgi?id=42993 */
+.callback = video_detect_force_native,
+/* Acer Aspire 5750 */
+.matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5750"),
+ },
+ },
+ {
+/* https://bugzilla.kernel.org/show_bug.cgi?id=42833 */
+.callback = video_detect_force_native,
+/* Acer Extensa 5235 */
+.matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Extensa 5235"),
+ },
+ },
+ {
+.callback = video_detect_force_native,
+/* Acer TravelMate 4750 */
+.matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 4750"),
+ },
+ },
{
/* https://bugzilla.kernel.org/show_bug.cgi?id=207835 */
.callback = video_detect_force_native,
@@ -447,6 +491,15 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
DMI_MATCH(DMI_BOARD_NAME, "BA51_MV"),
},
},
+ {
+/* https://bugzilla.kernel.org/show_bug.cgi?id=36322 */
+.callback = video_detect_force_native,
+/* Acer TravelMate 5760 */
+.matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 5760"),
+ },
+ },
{
.callback = video_detect_force_native,
/* ASUSTeK COMPUTER INC. GA401 */
diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
index e0230ea0cb7e..b933a5165edb 100644
--- a/drivers/platform/x86/acer-wmi.c
+++ b/drivers/platform/x86/acer-wmi.c
@@ -643,69 +643,6 @@ static const struct dmi_system_id non_acer_quirks[]
__initconst = {
{}
};
-static int __init
-video_set_backlight_video_vendor(const struct dmi_system_id *d)
-{
- interface->cap
[Intel-gfx] [PATCH v5 23/31] platform/x86: asus-wmi: Drop DMI chassis-type check from backlight handling
Remove this check from the asus-wmi backlight handling: /* Some Asus desktop boards export an acpi-video backlight interface, stop this from showing up */ chassis_type = dmi_get_system_info(DMI_CHASSIS_TYPE); if (chassis_type && !strcmp(chassis_type, "3")) acpi_video_set_dmi_backlight_type(acpi_backlight_vendor); This acpi_video_set_dmi_backlight_type(acpi_backlight_vendor) call must be removed because other changes in this series change the native backlight drivers to no longer unconditionally register their backlight. Instead these drivers now do this check: if (acpi_video_get_backlight_type(false) != acpi_backlight_native) return 0; /* bail */ So leaving this in place can break things on laptops with a broken DMI chassis-type, which would have GPU native brightness control before the addition of the acpi_video_get_backlight_type() != native check. Removing this should be ok now, since the ACPI video code has improved heuristics for this itself now (which includes a chassis-type check). Signed-off-by: Hans de Goede --- drivers/platform/x86/asus-wmi.c | 7 --- 1 file changed, 7 deletions(-) diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c index 89b604e04d7f..301166a5697d 100644 --- a/drivers/platform/x86/asus-wmi.c +++ b/drivers/platform/x86/asus-wmi.c @@ -3553,7 +3553,6 @@ static int asus_wmi_add(struct platform_device *pdev) struct platform_driver *pdrv = to_platform_driver(pdev->dev.driver); struct asus_wmi_driver *wdrv = to_asus_wmi_driver(pdrv); struct asus_wmi *asus; - const char *chassis_type; acpi_status status; int err; u32 result; @@ -3635,12 +3634,6 @@ static int asus_wmi_add(struct platform_device *pdev) if (asus->driver->quirks->wmi_force_als_set) asus_wmi_set_als(); - /* Some Asus desktop boards export an acpi-video backlight interface, - stop this from showing up */ - chassis_type = dmi_get_system_info(DMI_CHASSIS_TYPE); - if (chassis_type && !strcmp(chassis_type, "3")) - acpi_video_set_dmi_backlight_type(acpi_backlight_vendor); - if (asus->driver->quirks->wmi_backlight_power) acpi_video_set_dmi_backlight_type(acpi_backlight_vendor); -- 2.37.2
[Intel-gfx] [PATCH v5 24/31] platform/x86: asus-wmi: Move acpi_backlight=vendor quirks to ACPI video_detect.c
Remove the asus-wmi quirk_entry.wmi_backlight_power quirk-flag, which
called acpi_video_set_dmi_backlight_type(acpi_backlight_vendor) and replace
it with acpi/video_detect.c video_detect_dmi_table[] entries using the
video_detect_force_vendor callback.
acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.
Note no entries are dropped from the dmi_system_id table in asus-nb-wmi.c.
This is because the entries using the removed wmi_backlight_power flag
also use other model specific quirks from the asus-wmi quirk_entry struct.
So the quirk_asus_x55u struct and the entries pointing to it cannot be
dropped.
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/video_detect.c| 40 ++
drivers/platform/x86/asus-nb-wmi.c | 7 --
drivers/platform/x86/asus-wmi.c| 3 ---
drivers/platform/x86/asus-wmi.h| 1 -
drivers/platform/x86/eeepc-wmi.c | 25 +--
5 files changed, 41 insertions(+), 35 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 6a2523bc02ba..d893313fe1a0 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -174,6 +174,46 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
DMI_MATCH(DMI_PRODUCT_NAME, "UL30A"),
},
},
+ {
+.callback = video_detect_force_vendor,
+/* Asus X55U */
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "X55U"),
+ },
+ },
+ {
+.callback = video_detect_force_vendor,
+/* Asus X101CH */
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "X101CH"),
+ },
+ },
+ {
+.callback = video_detect_force_vendor,
+/* Asus X401U */
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "X401U"),
+ },
+ },
+ {
+.callback = video_detect_force_vendor,
+/* Asus X501U */
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "X501U"),
+ },
+ },
+ {
+.callback = video_detect_force_vendor,
+/* Asus 1015CX */
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "1015CX"),
+ },
+ },
{
.callback = video_detect_force_vendor,
/* GIGABYTE GB-BXBT-2807 */
diff --git a/drivers/platform/x86/asus-nb-wmi.c
b/drivers/platform/x86/asus-nb-wmi.c
index 478dd300b9c9..810a94557a85 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -79,12 +79,10 @@ static struct quirk_entry quirk_asus_q500a = {
/*
* For those machines that need software to control bt/wifi status
- * and can't adjust brightness through ACPI interface
* and have duplicate events(ACPI and WMI) for display toggle
*/
static struct quirk_entry quirk_asus_x55u = {
.wapf = 4,
- .wmi_backlight_power = true,
.wmi_backlight_set_devstate = true,
.no_display_toggle = true,
};
@@ -147,11 +145,6 @@ static const struct dmi_system_id asus_quirks[] = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK Computer Inc."),
DMI_MATCH(DMI_PRODUCT_NAME, "U32U"),
},
- /*
-* Note this machine has a Brazos APU, and most Brazos Asus
-* machines need quirk_asus_x55u / wmi_backlight_power but
-* here acpi-video seems to work fine for backlight control.
-*/
.driver_data = &quirk_asus_wapf4,
},
{
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 301166a5697d..5cf9d9aff164 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -3634,9 +3634,6 @@ static int asus_wmi_add(struct platform_device *pdev)
if (asus->driver->quirks->wmi_force_als_set)
asus_wmi_set_als();
- if (asus->driver->quirks->wmi_backlight_power)
- acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
-
if (asus->driver->quirks->wmi_backlight_native)
acpi_video_set_dmi_backlight_type(acpi_backlight_native);
diff --git a/drivers/platform/x86/asus-wmi.h b/drivers/platform/x86/asus-wmi.h
index b302415bf1d9..30770e411301 100644
--- a/drivers/platform/x86/asus-wmi.h
+++ b/drivers/platform/x86/asus-wmi.h
@@ -29,7 +29,6 @@ struct
[Intel-gfx] [PATCH v5 21/31] platform/x86: toshiba_acpi: Stop using acpi_video_set_dmi_backlight_type()
acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.
In case of the acpi_video backlight, acpi_video_set_dmi_backlight_type()
actually calls acpi_video_unregister_backlight() since that is often
probed earlier, leading to userspace seeing the acpi_video0 class
device being briefly available, leading to races in userspace where
udev probe-rules try to access the device and it is already gone.
In case of toshiba_acpi there are no DMI quirks to move to
acpi/video_detect.c, but it also (ab)uses it for transflective
displays. Adding transflective display support to video_detect.c would
be quite involved. But luckily there are only 2 known models with
a transflective display, so we can just add DMI quirks for those.
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/video_detect.c | 19 +++
drivers/platform/x86/toshiba_acpi.c | 16
2 files changed, 19 insertions(+), 16 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index be2fc43418af..74e2087c8ff0 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -190,6 +190,25 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
},
},
+ /*
+* Toshiba models with Transflective display, these need to use
+* the toshiba_acpi vendor driver for proper Transflective handling.
+*/
+ {
+.callback = video_detect_force_vendor,
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "PORTEGE R500"),
+ },
+ },
+ {
+.callback = video_detect_force_vendor,
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "PORTEGE R600"),
+ },
+ },
+
/*
* These models have a working acpi_video backlight control, and using
* native backlight causes a regression where backlight does not work
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index 0fc9e8b8827b..030dc37d50b8 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -271,14 +271,6 @@ static const struct key_entry toshiba_acpi_alt_keymap[] = {
{ KE_END, 0 },
};
-/*
- * List of models which have a broken acpi-video backlight interface and thus
- * need to use the toshiba (vendor) interface instead.
- */
-static const struct dmi_system_id toshiba_vendor_backlight_dmi[] = {
- {}
-};
-
/*
* Utility
*/
@@ -2881,14 +2873,6 @@ static int toshiba_acpi_setup_backlight(struct
toshiba_acpi_dev *dev)
return 0;
}
- /*
-* Tell acpi-video-detect code to prefer vendor backlight on all
-* systems with transflective backlight and on dmi matched systems.
-*/
- if (dev->tr_backlight_supported ||
- dmi_check_system(toshiba_vendor_backlight_dmi))
- acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
-
if (acpi_video_get_backlight_type() != acpi_backlight_vendor)
return 0;
--
2.37.2
[Intel-gfx] [PATCH v5 27/31] ACPI: video: Remove acpi_video_set_dmi_backlight_type()
acpi_video_set_dmi_backlight_type() is troublesome because it may end
up getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.
In case of the acpi_video backlight, acpi_video_set_dmi_backlight_type()
actually calls acpi_video_unregister_backlight() since that is often
probed earlier, leading to userspace seeing the acpi_video0 class
device being briefly available, leading to races in userspace where
udev probe-rules try to access the device and it is already gone.
All callers have been fixed to no longer call it, so remove
acpi_video_set_dmi_backlight_type() now.
This means we now also no longer need acpi_video_unregister_backlight()
for the remove acpi_video backlight after it was wrongly registered hack,
so remove that too.
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/acpi_video.c | 10 --
drivers/acpi/video_detect.c | 16
include/acpi/video.h| 4
3 files changed, 30 deletions(-)
diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
index d1e41f30c004..a7c3d11e0dac 100644
--- a/drivers/acpi/acpi_video.c
+++ b/drivers/acpi/acpi_video.c
@@ -2296,16 +2296,6 @@ void acpi_video_register_backlight(void)
}
EXPORT_SYMBOL(acpi_video_register_backlight);
-void acpi_video_unregister_backlight(void)
-{
- struct acpi_video_bus *video;
-
- mutex_lock(&video_list_lock);
- list_for_each_entry(video, &video_bus_head, entry)
- acpi_video_bus_unregister_backlight(video);
- mutex_unlock(&video_list_lock);
-}
-
bool acpi_video_handles_brightness_key_presses(void)
{
return may_report_brightness_keys &&
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 3861d4121172..67a0211c07b4 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -38,8 +38,6 @@
#include
#include
-void acpi_video_unregister_backlight(void);
-
static enum acpi_backlight_type acpi_backlight_cmdline = acpi_backlight_undef;
static enum acpi_backlight_type acpi_backlight_dmi = acpi_backlight_undef;
@@ -817,17 +815,3 @@ bool acpi_video_backlight_use_native(void)
return __acpi_video_get_backlight_type(true) == acpi_backlight_native;
}
EXPORT_SYMBOL(acpi_video_backlight_use_native);
-
-/*
- * Set the preferred backlight interface type based on DMI info.
- * This function allows DMI blacklists to be implemented by external
- * platform drivers instead of putting a big blacklist in video_detect.c
- */
-void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type type)
-{
- acpi_backlight_dmi = type;
- /* Remove acpi-video backlight interface if it is no longer desired */
- if (acpi_video_get_backlight_type() != acpi_backlight_video)
- acpi_video_unregister_backlight();
-}
-EXPORT_SYMBOL(acpi_video_set_dmi_backlight_type);
diff --git a/include/acpi/video.h b/include/acpi/video.h
index dbd48cb8bd23..a275c35e5249 100644
--- a/include/acpi/video.h
+++ b/include/acpi/video.h
@@ -60,7 +60,6 @@ extern int acpi_video_get_edid(struct acpi_device *device,
int type,
int device_id, void **edid);
extern enum acpi_backlight_type acpi_video_get_backlight_type(void);
extern bool acpi_video_backlight_use_native(void);
-extern void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type type);
/*
* Note: The value returned by acpi_video_handles_brightness_key_presses()
* may change over time and should not be cached.
@@ -86,9 +85,6 @@ static inline bool acpi_video_backlight_use_native(void)
{
return true;
}
-static inline void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type
type)
-{
-}
static inline bool acpi_video_handles_brightness_key_presses(void)
{
return false;
--
2.37.2
[Intel-gfx] [PATCH v5 31/31] drm/todo: Add entry about dealing with brightness control on devices with > 1 panel
Add an entry summarizing the discussion about dealing with brightness control on devices with more then 1 internal panel. The original discussion can be found here: https://lore.kernel.org/dri-devel/20220517152331.16217-1-hdego...@redhat.com/ Reviewed-by: Lyude Paul Signed-off-by: Hans de Goede --- Documentation/gpu/todo.rst | 68 ++ 1 file changed, 68 insertions(+) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 7634c27ac562..393d218e4a0c 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -679,6 +679,74 @@ Contact: Sam Ravnborg Level: Advanced +Brightness handling on devices with multiple internal panels + + +On x86/ACPI devices there can be multiple backlight firmware interfaces: +(ACPI) video, vendor specific and others. As well as direct/native (PWM) +register programming by the KMS driver. + +To deal with this backlight drivers used on x86/ACPI call +acpi_video_get_backlight_type() which has heuristics (+quirks) to select +which backlight interface to use; and backlight drivers which do not match +the returned type will not register themselves, so that only one backlight +device gets registered (in a single GPU setup, see below). + +At the moment this more or less assumes that there will only +be 1 (internal) panel on a system. + +On systems with 2 panels this may be a problem, depending on +what interface acpi_video_get_backlight_type() selects: + +1. native: in this case the KMS driver is expected to know which backlight + device belongs to which output so everything should just work. +2. video: this does support controlling multiple backlights, but some work + will need to be done to get the output <-> backlight device mapping + +The above assumes both panels will require the same backlight interface type. +Things will break on systems with multiple panels where the 2 panels need +a different type of control. E.g. one panel needs ACPI video backlight control, +where as the other is using native backlight control. Currently in this case +only one of the 2 required backlight devices will get registered, based on +the acpi_video_get_backlight_type() return value. + +If this (theoretical) case ever shows up, then supporting this will need some +work. A possible solution here would be to pass a device and connector-name +to acpi_video_get_backlight_type() so that it can deal with this. + +Note in a way we already have a case where userspace sees 2 panels, +in dual GPU laptop setups with a mux. On those systems we may see +either 2 native backlight devices; or 2 native backlight devices. + +Userspace already has code to deal with this by detecting if the related +panel is active (iow which way the mux between the GPU and the panels +points) and then uses that backlight device. Userspace here very much +assumes a single panel though. It picks only 1 of the 2 backlight devices +and then only uses that one. + +Note that all userspace code (that I know off) is currently hardcoded +to assume a single panel. + +Before the recent changes to not register multiple (e.g. video + native) +/sys/class/backlight devices for a single panel (on a single GPU laptop), +userspace would see multiple backlight devices all controlling the same +backlight. + +To deal with this userspace had to always picks one preferred device under +/sys/class/backlight and will ignore the others. So to support brightness +control on multiple panels userspace will need to be updated too. + +There are plans to allow brightness control through the KMS API by adding +a "display brightness" property to drm_connector objects for panels. This +solves a number of issues with the /sys/class/backlight API, including not +being able to map a sysfs backlight device to a specific connector. Any +userspace changes to add support for brightness control on devices with +multiple panels really should build on top of this new KMS property. + +Contact: Hans de Goede + +Level: Advanced + Outside DRM === -- 2.37.2
[Intel-gfx] [PATCH v5 28/31] ACPI: video: Drop "Samsung X360" acpi_backlight=native quirk
acpi_backlight=native is the default for the "Samsung X360", but as
the comment explains the quirk was still necessary because even
briefly registering the acpi_video0 backlight; and then unregistering
it once the native driver showed up, was leading to issues.
After the "ACPI: video: Make backlight class device registration
a separate step" patch from earlier in this patch-series, we no
longer briefly register the acpi_video0 backlight on systems where
the native driver should be used.
So this is no longer an issue an the quirk is no longer needed.
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/video_detect.c | 15 ---
1 file changed, 15 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 67a0211c07b4..af2833b57b8b 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -132,21 +132,6 @@ static int video_detect_force_none(const struct
dmi_system_id *d)
}
static const struct dmi_system_id video_detect_dmi_table[] = {
- /* On Samsung X360, the BIOS will set a flag (VDRV) if generic
-* ACPI backlight device is used. This flag will definitively break
-* the backlight interface (even the vendor interface) until next
-* reboot. It's why we should prevent video.ko from being used here
-* and we can't rely on a later call to acpi_video_unregister().
-*/
- {
-.callback = video_detect_force_vendor,
-/* X360 */
-.matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
- DMI_MATCH(DMI_PRODUCT_NAME, "X360"),
- DMI_MATCH(DMI_BOARD_NAME, "X360"),
- },
- },
{
/* https://bugzilla.redhat.com/show_bug.cgi?id=1128309 */
.callback = video_detect_force_vendor,
--
2.37.2
[Intel-gfx] [PATCH v5 26/31] platform/x86: samsung-laptop: Move acpi_backlight=[vendor|native] quirks to ACPI video_detect.c
acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.
Move all the acpi_backlight=[vendor|native] quirks from samsung-laptop to
drivers/acpi/video_detect.c .
Note the X360 -> acpi_backlight=native quirk is not moved because that
already was present in drivers/acpi/video_detect.c .
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/video_detect.c | 54 +
drivers/platform/x86/samsung-laptop.c | 87 ---
2 files changed, 54 insertions(+), 87 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index a09089e7fada..3861d4121172 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -222,6 +222,33 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
DMI_MATCH(DMI_PRODUCT_NAME, "GB-BXBT-2807"),
},
},
+ {
+.callback = video_detect_force_vendor,
+/* Samsung N150/N210/N220 */
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "N150/N210/N220"),
+ DMI_MATCH(DMI_BOARD_NAME, "N150/N210/N220"),
+ },
+ },
+ {
+.callback = video_detect_force_vendor,
+/* Samsung NF110/NF210/NF310 */
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "NF110/NF210/NF310"),
+ DMI_MATCH(DMI_BOARD_NAME, "NF110/NF210/NF310"),
+ },
+ },
+ {
+.callback = video_detect_force_vendor,
+/* Samsung NC210 */
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "NC210/NC110"),
+ DMI_MATCH(DMI_BOARD_NAME, "NC210/NC110"),
+ },
+ },
{
.callback = video_detect_force_vendor,
/* Sony VPCEH3U1E */
@@ -572,6 +599,33 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
DMI_MATCH(DMI_PRODUCT_NAME, "UX303UB"),
},
},
+ {
+.callback = video_detect_force_native,
+/* Samsung N150P */
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "N150P"),
+ DMI_MATCH(DMI_BOARD_NAME, "N150P"),
+ },
+ },
+ {
+.callback = video_detect_force_native,
+/* Samsung N145P/N250P/N260P */
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "N145P/N250P/N260P"),
+ DMI_MATCH(DMI_BOARD_NAME, "N145P/N250P/N260P"),
+ },
+ },
+ {
+.callback = video_detect_force_native,
+/* Samsung N250P */
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "N250P"),
+ DMI_MATCH(DMI_BOARD_NAME, "N250P"),
+ },
+ },
/*
* Clevo NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2 have both a
* working native and video interface. However the default detection
diff --git a/drivers/platform/x86/samsung-laptop.c
b/drivers/platform/x86/samsung-laptop.c
index c187dcdf82f0..cc30cf08f32d 100644
--- a/drivers/platform/x86/samsung-laptop.c
+++ b/drivers/platform/x86/samsung-laptop.c
@@ -356,23 +356,13 @@ struct samsung_laptop {
};
struct samsung_quirks {
- bool broken_acpi_video;
bool four_kbd_backlight_levels;
bool enable_kbd_backlight;
- bool use_native_backlight;
bool lid_handling;
};
static struct samsung_quirks samsung_unknown = {};
-static struct samsung_quirks samsung_broken_acpi_video = {
- .broken_acpi_video = true,
-};
-
-static struct samsung_quirks samsung_use_native_backlight = {
- .use_native_backlight = true,
-};
-
static struct samsung_quirks samsung_np740u3e = {
.four_kbd_backlight_levels = true,
.enable_kbd_backlight = true,
@@ -1540,76 +1530,6 @@ static const struct dmi_system_id samsung_dmi_table[]
__initconst = {
},
},
/* Specific DMI ids for laptop with quirks */
- {
-.callback = samsung_dmi_matched,
-.ident = "N150P",
-.matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
- DMI_MATCH(DMI_PRODUCT_NAME, "N150P"),
- DMI_MATCH(DMI_BOARD_NAME, "N150P"),
- },
-.driver_data = &samsung_use_native_backlight,
- },
- {
-.callback = samsung
[Intel-gfx] [PATCH v5 29/31] ACPI: video: Drop NL5x?U, PF4NU1F and PF5?U?? acpi_backlight=native quirks
acpi_backlight=native is the default for these, but as the comment
explains the quirk was still necessary because even briefly registering
the acpi_video0 backlight; and then unregistering it once the native
driver showed up, was leading to issues.
After the "ACPI: video: Make backlight class device registration
a separate step" patch from earlier in this patch-series, we no
longer briefly register the acpi_video0 backlight on systems where
the native driver should be used.
So this is no longer an issue an the quirks are no longer needed.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215683
Tested-by: Werner Sembach
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/video_detect.c | 92 +
1 file changed, 1 insertion(+), 91 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index af2833b57b8b..789d5913c178 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -609,97 +609,7 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
DMI_MATCH(DMI_BOARD_NAME, "N250P"),
},
},
- /*
-* Clevo NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2 have both a
-* working native and video interface. However the default detection
-* mechanism first registers the video interface before unregistering
-* it again and switching to the native interface during boot. This
-* results in a dangling SBIOS request for backlight change for some
-* reason, causing the backlight to switch to ~2% once per boot on the
-* first power cord connect or disconnect event. Setting the native
-* interface explicitly circumvents this buggy behaviour, by avoiding
-* the unregistering process.
-*/
- {
- .callback = video_detect_force_native,
- .ident = "Clevo NL5xRU",
- .matches = {
- DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
- },
- },
- {
- .callback = video_detect_force_native,
- .ident = "Clevo NL5xRU",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
- DMI_MATCH(DMI_BOARD_NAME, "AURA1501"),
- },
- },
- {
- .callback = video_detect_force_native,
- .ident = "Clevo NL5xRU",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
- DMI_MATCH(DMI_BOARD_NAME, "EDUBOOK1502"),
- },
- },
- {
- .callback = video_detect_force_native,
- .ident = "Clevo NL5xNU",
- .matches = {
- DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"),
- },
- },
- /*
-* The TongFang PF5PU1G, PF4NU1F, PF5NU1G, and PF5LUXG/TUXEDO BA15
Gen10,
-* Pulse 14/15 Gen1, and Pulse 15 Gen2 have the same problem as the
Clevo
-* NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2. See the description
-* above.
-*/
- {
- .callback = video_detect_force_native,
- .ident = "TongFang PF5PU1G",
- .matches = {
- DMI_MATCH(DMI_BOARD_NAME, "PF5PU1G"),
- },
- },
- {
- .callback = video_detect_force_native,
- .ident = "TongFang PF4NU1F",
- .matches = {
- DMI_MATCH(DMI_BOARD_NAME, "PF4NU1F"),
- },
- },
- {
- .callback = video_detect_force_native,
- .ident = "TongFang PF4NU1F",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
- DMI_MATCH(DMI_BOARD_NAME, "PULSE1401"),
- },
- },
- {
- .callback = video_detect_force_native,
- .ident = "TongFang PF5NU1G",
- .matches = {
- DMI_MATCH(DMI_BOARD_NAME, "PF5NU1G"),
- },
- },
- {
- .callback = video_detect_force_native,
- .ident = "TongFang PF5NU1G",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
- DMI_MATCH(DMI_BOARD_NAME, "PULSE1501"),
- },
- },
- {
- .callback = video_detect_force_native,
- .ident = "TongFang PF5LUXG",
- .matches = {
- DMI_MATCH(DMI_BOARD_NAME, "PF5LUXG"),
- },
- },
+
/*
* Desktops which falsely report a backlight and which our heuristics
* for this do not catch.
--
2.37.2
[Intel-gfx] [PATCH v5 30/31] ACPI: video: Fix indentation of video_detect_dmi_table[] entries
The video_detect_dmi_table[] uses an unusual indentation for
before the ".name = ..." named struct initializers.
Instead of being indented with an extra tab compared to
the previous line's '{' these are indented to with only
a single space to allow for long DMI_MATCH() lines without
wrapping.
But over time some entries did not event have the single space
indent in front of the ".name = ..." lines.
Make things consistent by using a single space indent for these
lines everywhere.
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/video_detect.c | 48 ++---
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 789d5913c178..db2474fe58ac 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -142,17 +142,17 @@ static const struct dmi_system_id
video_detect_dmi_table[] = {
},
},
{
- .callback = video_detect_force_vendor,
- /* Asus UL30VT */
- .matches = {
+.callback = video_detect_force_vendor,
+/* Asus UL30VT */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK Computer Inc."),
DMI_MATCH(DMI_PRODUCT_NAME, "UL30VT"),
},
},
{
- .callback = video_detect_force_vendor,
- /* Asus UL30A */
- .matches = {
+.callback = video_detect_force_vendor,
+/* Asus UL30A */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK Computer Inc."),
DMI_MATCH(DMI_PRODUCT_NAME, "UL30A"),
},
@@ -198,9 +198,9 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
},
},
{
- .callback = video_detect_force_vendor,
- /* GIGABYTE GB-BXBT-2807 */
- .matches = {
+.callback = video_detect_force_vendor,
+/* GIGABYTE GB-BXBT-2807 */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "GIGABYTE"),
DMI_MATCH(DMI_PRODUCT_NAME, "GB-BXBT-2807"),
},
@@ -233,17 +233,17 @@ static const struct dmi_system_id
video_detect_dmi_table[] = {
},
},
{
- .callback = video_detect_force_vendor,
- /* Sony VPCEH3U1E */
- .matches = {
+.callback = video_detect_force_vendor,
+/* Sony VPCEH3U1E */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
DMI_MATCH(DMI_PRODUCT_NAME, "VPCEH3U1E"),
},
},
{
- .callback = video_detect_force_vendor,
- /* Xiaomi Mi Pad 2 */
- .matches = {
+.callback = video_detect_force_vendor,
+/* Xiaomi Mi Pad 2 */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Xiaomi Inc"),
DMI_MATCH(DMI_PRODUCT_NAME, "Mipad2"),
},
@@ -551,25 +551,25 @@ static const struct dmi_system_id
video_detect_dmi_table[] = {
},
},
{
- .callback = video_detect_force_native,
- /* ASUSTeK COMPUTER INC. GA401 */
- .matches = {
+.callback = video_detect_force_native,
+/* ASUSTeK COMPUTER INC. GA401 */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
DMI_MATCH(DMI_PRODUCT_NAME, "GA401"),
},
},
{
- .callback = video_detect_force_native,
- /* ASUSTeK COMPUTER INC. GA502 */
- .matches = {
+.callback = video_detect_force_native,
+/* ASUSTeK COMPUTER INC. GA502 */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
DMI_MATCH(DMI_PRODUCT_NAME, "GA502"),
},
},
{
- .callback = video_detect_force_native,
- /* ASUSTeK COMPUTER INC. GA503 */
- .matches = {
+.callback = video_detect_force_native,
+/* ASUSTeK COMPUTER INC. GA503 */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
DMI_MATCH(DMI_PRODUCT_NAME, "GA503"),
},
--
2.37.2
[Intel-gfx] [PATCH v5 25/31] platform/x86: asus-wmi: Move acpi_backlight=native quirks to ACPI video_detect.c
Remove the asus-wmi quirk_entry.wmi_backlight_native quirk-flag, which
called acpi_video_set_dmi_backlight_type(acpi_backlight_native) and replace
it with acpi/video_detect.c video_detect_dmi_table[] entries using the
video_detect_force_native callback.
acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/video_detect.c| 8
drivers/platform/x86/asus-nb-wmi.c | 14 --
drivers/platform/x86/asus-wmi.c| 3 ---
drivers/platform/x86/asus-wmi.h| 1 -
4 files changed, 8 insertions(+), 18 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index d893313fe1a0..a09089e7fada 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -564,6 +564,14 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
DMI_MATCH(DMI_PRODUCT_NAME, "GA503"),
},
},
+ {
+.callback = video_detect_force_native,
+/* Asus UX303UB */
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "UX303UB"),
+ },
+ },
/*
* Clevo NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2 have both a
* working native and video interface. However the default detection
diff --git a/drivers/platform/x86/asus-nb-wmi.c
b/drivers/platform/x86/asus-nb-wmi.c
index 810a94557a85..bbfed85051ee 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -97,11 +97,6 @@ static struct quirk_entry quirk_asus_x200ca = {
.wmi_backlight_set_devstate = true,
};
-static struct quirk_entry quirk_asus_ux303ub = {
- .wmi_backlight_native = true,
- .wmi_backlight_set_devstate = true,
-};
-
static struct quirk_entry quirk_asus_x550lb = {
.wmi_backlight_set_devstate = true,
.xusb2pr = 0x01D9,
@@ -372,15 +367,6 @@ static const struct dmi_system_id asus_quirks[] = {
},
.driver_data = &quirk_asus_x200ca,
},
- {
- .callback = dmi_matched,
- .ident = "ASUSTeK COMPUTER INC. UX303UB",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
- DMI_MATCH(DMI_PRODUCT_NAME, "UX303UB"),
- },
- .driver_data = &quirk_asus_ux303ub,
- },
{
.callback = dmi_matched,
.ident = "ASUSTeK COMPUTER INC. UX330UAK",
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 5cf9d9aff164..434249ac47a5 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -3634,9 +3634,6 @@ static int asus_wmi_add(struct platform_device *pdev)
if (asus->driver->quirks->wmi_force_als_set)
asus_wmi_set_als();
- if (asus->driver->quirks->wmi_backlight_native)
- acpi_video_set_dmi_backlight_type(acpi_backlight_native);
-
if (asus->driver->quirks->xusb2pr)
asus_wmi_set_xusb2pr(asus);
diff --git a/drivers/platform/x86/asus-wmi.h b/drivers/platform/x86/asus-wmi.h
index 30770e411301..f30252efe1db 100644
--- a/drivers/platform/x86/asus-wmi.h
+++ b/drivers/platform/x86/asus-wmi.h
@@ -29,7 +29,6 @@ struct quirk_entry {
bool hotplug_wireless;
bool scalar_panel_brightness;
bool store_backlight_power;
- bool wmi_backlight_native;
bool wmi_backlight_set_devstate;
bool wmi_force_als_set;
bool use_kbd_dock_devid;
--
2.37.2
Re: [Intel-gfx] [PATCH] drm/i915/glk: ECS Liva Q2 needs GLK HDMI port timing quirk
On Thu, 25 Aug 2022, Ville Syrjälä wrote:
> On Thu, Jun 16, 2022 at 03:41:37PM +0300, Jani Nikula wrote:
>> From: Diego Santa Cruz
>>
>> The quirk added in upstream commit 90c3e2198777 ("drm/i915/glk: Add
>> Quirk for GLK NUC HDMI port issues.") is also required on the ECS Liva
>> Q2.
>>
>> Note: Would be nicer to figure out the extra delay required for the
>> retimer without quirks, however don't know how to check for that.
>>
>> Cc: sta...@vger.kernel.org
>> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1326
>> Signed-off-by: Diego Santa Cruz
>> Signed-off-by: Jani Nikula
>
> Seems fine. Although I do wonder whether we could directly identify the
> bogus retimer chip via the dual mode adapter registers. I've asked for
> that in the bug.
>
> Reviewed-by: Ville Syrjälä
Thanks, pushed to drm-intel-next. Let's follow up with cleanups if the
folks in the bug ever reply.
BR,
Jani.
>
>> ---
>> drivers/gpu/drm/i915/display/intel_quirks.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c
>> b/drivers/gpu/drm/i915/display/intel_quirks.c
>> index c8488f5ebd04..e415cd7c0b84 100644
>> --- a/drivers/gpu/drm/i915/display/intel_quirks.c
>> +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
>> @@ -191,6 +191,9 @@ static struct intel_quirk intel_quirks[] = {
>> /* ASRock ITX*/
>> { 0x3185, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
>> { 0x3184, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
>> +/* ECS Liva Q2 */
>> +{ 0x3185, 0x1019, 0xa94d, quirk_increase_ddi_disabled_time },
>> +{ 0x3184, 0x1019, 0xa94d, quirk_increase_ddi_disabled_time },
>> };
>>
>> void intel_init_quirks(struct drm_i915_private *i915)
>> --
>> 2.30.2
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] [PATCH] drm/i915/selftests: do not try misaligned_pin test on unmappable memory
In case of Small BAR configurations stolen local memory can be unmappable.
Trying to test it causes -ENOSPC error from _i915_gem_object_stolen_init.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6565
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index fb5e6196347925..667c4c004bdbcf 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -1164,6 +1164,10 @@ static int misaligned_pin(struct i915_address_space *vm,
if (hole_size < 3 * min_alignment)
continue;
+ /* avoid -ENOSPC on unmappable memory */
+ if (!mr->io_size)
+ continue;
+
/* we can't test < 4k alignment due to flags being encoded in
lower bits */
if (min_alignment != I915_GTT_PAGE_SIZE_4K) {
err = misaligned_case(vm, mr, addr + (min_alignment /
2), size, flags);
--
2.25.1
Re: [Intel-gfx] [PATCH v6 3/4] drm/i915/display: add hotplug.suspended flag
On Thu, Aug 25, 2022 at 01:24:04PM +0200, Andrzej Hajda wrote: > On 24.08.2022 13:22, Imre Deak wrote: > > On Tue, Aug 23, 2022 at 11:48:01PM +0200, Andrzej Hajda wrote: > > > > > > > > > On 22.08.2022 19:27, Imre Deak wrote: > > > > On Fri, Jul 22, 2022 at 02:51:42PM +0200, Andrzej Hajda wrote: > > > > > HPD events during driver removal can be generated by hardware and > > > > > software frameworks - drm_dp_mst, the former we can avoid by disabling > > > > > interrupts, the latter can be triggered by any drm_dp_mst transaction, > > > > > and this is too late. Introducing suspended flag allows to solve this > > > > > chicken-egg problem. > > > > intel_hpd_cancel_work() is always called after suspending MST and > > > > disabling IRQs (with the order I suggested in patch 1). If both of these > > > > have disabled the corresponding functionality (MST, IRQs) properly with > > > > all their MST/IRQ scheduled works guaranteed to not get rescheduled, > > > > then it's not clear how could either intel_hpd_trigger_irq() or an IRQ > > > > work run. So the problematic sequence would need a better explanation. > > > > > > I am not familiar with MST but as I understand from earlier discussion MST > > > framework can be called during driver removal code even after > > > intel_dp_mst_suspend. > > > > Not sure how that happens, but it looks wrong. One way I can imagine is > > that connector detection re-enables MST, which should be prevented then. > > I am not MST expert and atm I have no access to the machine on which I could > look for real prove. > As I understand intel_dp_mst_suspend prevents only downstream devices to > initiate transactions, it does not prevent transactions initiated from i915 > driver. > My guesses for such transactions are: > - any ioctl/sysfs/drm_property access initiated by user which can involve > MST tranaction (set brightness, read EDID, reading capabilities, statuses, > ), unless they are already blocked, how? In theory all these should be blocked already, after i915_driver_unregister() has returned; for the above cases in particular via drm_connector_unregister_all(). > - maybe some mode_config disabling code (for example intel_mst_disable_dp) - This should be called already via i915_driver_unregister() -> intel_display_driver_unregister() -> drm_atomic_helper_shutdown(). > intel_mode_config_cleanup is called after intel_dp_mst_suspend. This should only free the allocated objects etc, but not do any transactions. > And since MST transfer can timeout it can trigger > drm_dp_mst_wait_tx_reply --> mgr->cbs->poll_hpd_irq(mgr) --> > intel_dp_mst_poll_hpd_irq --> intel_hpd_trigger_irq. > > If such situation happens after intel_dp_mst_suspend > i915->hotplug.dig_port_work will be queued, and we have risk of > use-after-free. > > If this analysis looks incorrect I can send patches 1, 2, 4 with your > comments addressed. CI probably will verify this anyway. Ok. I suppose blocking detection based on a new flag would mean avoiding scheduling and flushing hotplug.hotplug_work already as the first step in intel_display_driver_unregister() and somewhere early during system suspend. > Regards > Andrzej > > > > > > > And since MST transfer can timeout it can trigger > > > drm_dp_mst_wait_tx_reply --> mgr->cbs->poll_hpd_irq(mgr) --> > > > intel_dp_mst_poll_hpd_irq --> intel_hpd_trigger_irq. > > > > > > So actually this patch supersedes the 1st patch. > > > > > > > > > > > There's also already > > > > dev_priv->runtime_pm.irqs_enabled > > > > showing if hotplug interrupts are disabled (along with all other IRQs). > > > > > > So it is slightly different, this patch introduces flag indicating if HPD > > > is > > > enabled, we can have IRQs not related to HPD, and HPD events not related > > > to > > > IRQs. > > > > In its current form I can't see a difference. What would make sense is > > to add a flag that prevents connector detection (which would > > incorrectly enable MST for instace), but leave the handling of other > > interrupts enabled. That flag would be set already before suspending > > MST. > > > > > Regards > > > Andrzej > > > > > > > > > > > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5950 > > > > > Signed-off-by: Andrzej Hajda > > > > > Reviewed-by: Arun R Murthy > > > > > --- > > > > >drivers/gpu/drm/i915/display/intel_display.c | 2 +- > > > > >drivers/gpu/drm/i915/display/intel_hotplug.c | 11 ++- > > > > >drivers/gpu/drm/i915/display/intel_hotplug.h | 2 +- > > > > >drivers/gpu/drm/i915/i915_driver.c | 4 ++-- > > > > >drivers/gpu/drm/i915/i915_drv.h | 2 ++ > > > > >5 files changed, 16 insertions(+), 5 deletions(-) > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > > > > > b/drivers/gpu/drm/i915/display/intel_display.c > > > > > index f1c765ac7ab8aa..cd6139bb36151b 100644 > > > > > --- a/drivers/gpu/drm/i915/display/intel_display.c > > > > > +++ b/drivers/gpu/d
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Add DSC support to MST path
Hi Stan,
Some comments inline..
On Mon, 2022-08-22 at 12:40 +0300, Stanislav Lisovskiy wrote:
> Whenever we are not able to get enough timeslots
> for required PBN, let's try to allocate those
> using DSC, just same way as we do for SST.
>
> v2: Removed intel_dp_mst_dsc_compute_config and refactored
> intel_dp_dsc_compute_config to support timeslots as a
> parameter(Ville Syrjälä)
>
> v3: - Rebased
> - Added a debug to see that we at least try reserving
> VCPI slots using DSC, because currently its not visible
> from the logs, thus making debugging more tricky.
> - Moved timeslots to numerator, where it should be.
>
> v4: - Call drm_dp_mst_atomic_check already during link
> config computation, because we need to know already
> by this moment if uncompressed amount of VCPI slots
> needed can fit, otherwise we need to use DSC.
> (thanks to Vinod Govindapillai for pointing this out)
>
> v5: - Put pipe_config->bigjoiner_pipes back to original
> condition in intel_dp_dsc_compute_config
> (don't remember when I lost it)
>
> Signed-off-by: Stanislav Lisovskiy
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 73 -
> drivers/gpu/drm/i915/display/intel_dp.h | 17 +++
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 157
> 3 files changed, 205 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 32292c0be2bd..519b436fc530 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -116,7 +116,6 @@ bool intel_dp_is_edp(struct intel_dp *intel_dp)
> }
>
> static void intel_dp_unset_edid(struct intel_dp *intel_dp);
> -static int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp, u8
> dsc_max_bpc);
>
> /* Is link rate UHBR and thus 128b/132b? */
> bool intel_dp_is_uhbr(const struct intel_crtc_state *crtc_state)
> @@ -687,11 +686,12 @@ small_joiner_ram_size_bits(struct drm_i915_private
> *i915)
> return 6144 * 8;
> }
>
> -static u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *i915,
> - u32 link_clock, u32 lane_count,
> - u32 mode_clock, u32 mode_hdisplay,
> - bool bigjoiner,
> - u32 pipe_bpp)
> +u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *i915,
> + u32 link_clock, u32 lane_count,
> + u32 mode_clock, u32 mode_hdisplay,
> + bool bigjoiner,
> + u32 pipe_bpp,
> + u32 timeslots)
> {
> u32 bits_per_pixel, max_bpp_small_joiner_ram;
> int i;
> @@ -702,8 +702,9 @@ static u16 intel_dp_dsc_get_output_bpp(struct
> drm_i915_private *i915,
> * for SST -> TimeSlotsPerMTP is 1,
> * for MST -> TimeSlotsPerMTP has to be calculated
> */
> - bits_per_pixel = (link_clock * lane_count * 8) /
> + bits_per_pixel = (link_clock * lane_count * 8) * timeslots /
> intel_dp_mode_to_fec_clock(mode_clock);
> + drm_dbg_kms(&i915->drm, "Max link bpp: %u\n", bits_per_pixel);
>
> /* Small Joiner Check: output bpp <= joiner RAM (bits) / Horiz. width
> */
> max_bpp_small_joiner_ram = small_joiner_ram_size_bits(i915) /
> @@ -752,9 +753,9 @@ static u16 intel_dp_dsc_get_output_bpp(struct
> drm_i915_private *i915,
> return bits_per_pixel << 4;
> }
>
> -static u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp,
> - int mode_clock, int mode_hdisplay,
> - bool bigjoiner)
> +u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp,
> + int mode_clock, int mode_hdisplay,
> + bool bigjoiner)
> {
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> u8 min_slice_count, i;
> @@ -961,8 +962,8 @@ intel_dp_mode_valid_downstream(struct intel_connector
> *connector,
> return MODE_OK;
> }
>
> -static bool intel_dp_need_bigjoiner(struct intel_dp *intel_dp,
> - int hdisplay, int clock)
> +bool intel_dp_need_bigjoiner(struct intel_dp *intel_dp,
> + int hdisplay, int clock)
> {
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>
> @@ -1049,7 +1050,7 @@ intel_dp_mode_valid(struct drm_connector *_connector,
> target_clock,
> mode->hdisplay,
> bigjoiner,
> - pipe_bpp) >> 4;
> +
Re: [Intel-gfx] [PATCH] drm/i915/selftests: do not try misaligned_pin test on unmappable memory
On 25/08/2022 15:52, Andrzej Hajda wrote:
In case of Small BAR configurations stolen local memory can be unmappable.
Trying to test it causes -ENOSPC error from _i915_gem_object_stolen_init.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6565
Signed-off-by: Andrzej Hajda
Ah right. That failure makes perfect sense now :)
---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index fb5e6196347925..667c4c004bdbcf 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -1164,6 +1164,10 @@ static int misaligned_pin(struct i915_address_space *vm,
if (hole_size < 3 * min_alignment)
continue;
+ /* avoid -ENOSPC on unmappable memory */
+ if (!mr->io_size)
+ continue;
We could also pass I915_BO_ALLOC_GPU_ONLY when calling
i915_gem_object_create_region(), since nothing actually needs to CPU
access that memory, and then we still get coverage here for stolen? What
do you think?
+
/* we can't test < 4k alignment due to flags being encoded in
lower bits */
if (min_alignment != I915_GTT_PAGE_SIZE_4K) {
err = misaligned_case(vm, mr, addr + (min_alignment /
2), size, flags);
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Add DSC support to MST path
On Thu, Aug 25, 2022 at 05:58:19PM +0300, Govindapillai, Vinod wrote:
> Hi Stan,
>
> Some comments inline..
>
> On Mon, 2022-08-22 at 12:40 +0300, Stanislav Lisovskiy wrote:
> > Whenever we are not able to get enough timeslots
> > for required PBN, let's try to allocate those
> > using DSC, just same way as we do for SST.
> >
> > v2: Removed intel_dp_mst_dsc_compute_config and refactored
> > intel_dp_dsc_compute_config to support timeslots as a
> > parameter(Ville Syrjälä)
> >
> > v3: - Rebased
> > - Added a debug to see that we at least try reserving
> > VCPI slots using DSC, because currently its not visible
> > from the logs, thus making debugging more tricky.
> > - Moved timeslots to numerator, where it should be.
> >
> > v4: - Call drm_dp_mst_atomic_check already during link
> > config computation, because we need to know already
> > by this moment if uncompressed amount of VCPI slots
> > needed can fit, otherwise we need to use DSC.
> > (thanks to Vinod Govindapillai for pointing this out)
> >
> > v5: - Put pipe_config->bigjoiner_pipes back to original
> > condition in intel_dp_dsc_compute_config
> > (don't remember when I lost it)
> >
> > Signed-off-by: Stanislav Lisovskiy
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 73 -
> > drivers/gpu/drm/i915/display/intel_dp.h | 17 +++
> > drivers/gpu/drm/i915/display/intel_dp_mst.c | 157
> > 3 files changed, 205 insertions(+), 42 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 32292c0be2bd..519b436fc530 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -116,7 +116,6 @@ bool intel_dp_is_edp(struct intel_dp *intel_dp)
> > }
> >
> > static void intel_dp_unset_edid(struct intel_dp *intel_dp);
> > -static int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp, u8
> > dsc_max_bpc);
> >
> > /* Is link rate UHBR and thus 128b/132b? */
> > bool intel_dp_is_uhbr(const struct intel_crtc_state *crtc_state)
> > @@ -687,11 +686,12 @@ small_joiner_ram_size_bits(struct drm_i915_private
> > *i915)
> > return 6144 * 8;
> > }
> >
> > -static u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *i915,
> > - u32 link_clock, u32 lane_count,
> > - u32 mode_clock, u32 mode_hdisplay,
> > - bool bigjoiner,
> > - u32 pipe_bpp)
> > +u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *i915,
> > + u32 link_clock, u32 lane_count,
> > + u32 mode_clock, u32 mode_hdisplay,
> > + bool bigjoiner,
> > + u32 pipe_bpp,
> > + u32 timeslots)
> > {
> > u32 bits_per_pixel, max_bpp_small_joiner_ram;
> > int i;
> > @@ -702,8 +702,9 @@ static u16 intel_dp_dsc_get_output_bpp(struct
> > drm_i915_private *i915,
> > * for SST -> TimeSlotsPerMTP is 1,
> > * for MST -> TimeSlotsPerMTP has to be calculated
> > */
> > - bits_per_pixel = (link_clock * lane_count * 8) /
> > + bits_per_pixel = (link_clock * lane_count * 8) * timeslots /
> > intel_dp_mode_to_fec_clock(mode_clock);
> > + drm_dbg_kms(&i915->drm, "Max link bpp: %u\n", bits_per_pixel);
> >
> > /* Small Joiner Check: output bpp <= joiner RAM (bits) / Horiz.
> > width */
> > max_bpp_small_joiner_ram = small_joiner_ram_size_bits(i915) /
> > @@ -752,9 +753,9 @@ static u16 intel_dp_dsc_get_output_bpp(struct
> > drm_i915_private *i915,
> > return bits_per_pixel << 4;
> > }
> >
> > -static u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp,
> > - int mode_clock, int mode_hdisplay,
> > - bool bigjoiner)
> > +u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp,
> > + int mode_clock, int mode_hdisplay,
> > + bool bigjoiner)
> > {
> > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > u8 min_slice_count, i;
> > @@ -961,8 +962,8 @@ intel_dp_mode_valid_downstream(struct intel_connector
> > *connector,
> > return MODE_OK;
> > }
> >
> > -static bool intel_dp_need_bigjoiner(struct intel_dp *intel_dp,
> > - int hdisplay, int clock)
> > +bool intel_dp_need_bigjoiner(struct intel_dp *intel_dp,
> > + int hdisplay, int clock)
> > {
> > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> >
> > @@ -1049,7 +1050,7 @@ intel_dp_mode_valid(struct drm_connector *_connector,
> >
Re: [Intel-gfx] [PATCH] drm/i915/selftests: do not try misaligned_pin test on unmappable memory
On 25.08.2022 17:13, Matthew Auld wrote:
On 25/08/2022 15:52, Andrzej Hajda wrote:
In case of Small BAR configurations stolen local memory can be
unmappable.
Trying to test it causes -ENOSPC error from
_i915_gem_object_stolen_init.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6565
Signed-off-by: Andrzej Hajda
Ah right. That failure makes perfect sense now :)
---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index fb5e6196347925..667c4c004bdbcf 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -1164,6 +1164,10 @@ static int misaligned_pin(struct
i915_address_space *vm,
if (hole_size < 3 * min_alignment)
continue;
+ /* avoid -ENOSPC on unmappable memory */
+ if (!mr->io_size)
+ continue;
We could also pass I915_BO_ALLOC_GPU_ONLY when calling
i915_gem_object_create_region(), since nothing actually needs to CPU
access that memory, and then we still get coverage here for stolen?
What do you think?
I agree, I've just tested it successfully.
Regards
Andrzej
+
/* we can't test < 4k alignment due to flags being encoded
in lower bits */
if (min_alignment != I915_GTT_PAGE_SIZE_4K) {
err = misaligned_case(vm, mr, addr + (min_alignment /
2), size, flags);
[Intel-gfx] [PATCH] drm/i915/selftests: allow misaligned_pin test work with unmappable memory
In case of Small BAR configurations stolen local memory can be unmappable.
Since the test does not touch the memory, passing I915_BO_ALLOC_GPU_ONLY
flag to i915_gem_object_create_region, will prevent -ENOSPC error from
_i915_gem_object_stolen_init.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6565
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index fb5e6196347925..e050a2de5fd1df 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -1080,7 +1080,7 @@ static int misaligned_case(struct i915_address_space *vm,
struct intel_memory_re
bool is_stolen = mr->type == INTEL_MEMORY_STOLEN_SYSTEM ||
mr->type == INTEL_MEMORY_STOLEN_LOCAL;
- obj = i915_gem_object_create_region(mr, size, 0, 0);
+ obj = i915_gem_object_create_region(mr, size, 0,
I915_BO_ALLOC_GPU_ONLY);
if (IS_ERR(obj)) {
/* if iGVT-g or DMAR is active, stolen mem will be
uninitialized */
if (PTR_ERR(obj) == -ENODEV && is_stolen)
--
2.25.1
Re: [Intel-gfx] [PATCH] drm/i915/selftests: allow misaligned_pin test work with unmappable memory
On 25/08/2022 16:42, Andrzej Hajda wrote:
In case of Small BAR configurations stolen local memory can be unmappable.
Since the test does not touch the memory, passing I915_BO_ALLOC_GPU_ONLY
flag to i915_gem_object_create_region, will prevent -ENOSPC error from
_i915_gem_object_stolen_init.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6565
Signed-off-by: Andrzej Hajda
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index fb5e6196347925..e050a2de5fd1df 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -1080,7 +1080,7 @@ static int misaligned_case(struct i915_address_space *vm,
struct intel_memory_re
bool is_stolen = mr->type == INTEL_MEMORY_STOLEN_SYSTEM ||
mr->type == INTEL_MEMORY_STOLEN_LOCAL;
- obj = i915_gem_object_create_region(mr, size, 0, 0);
+ obj = i915_gem_object_create_region(mr, size, 0,
I915_BO_ALLOC_GPU_ONLY);
if (IS_ERR(obj)) {
/* if iGVT-g or DMAR is active, stolen mem will be
uninitialized */
if (PTR_ERR(obj) == -ENODEV && is_stolen)
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Add DSC support to MST path
On Thu, 2022-08-25 at 18:17 +0300, Lisovskiy, Stanislav wrote:
> On Thu, Aug 25, 2022 at 05:58:19PM +0300, Govindapillai, Vinod wrote:
> > Hi Stan,
> >
> > Some comments inline..
> >
> > On Mon, 2022-08-22 at 12:40 +0300, Stanislav Lisovskiy wrote:
> > > Whenever we are not able to get enough timeslots
> > > for required PBN, let's try to allocate those
> > > using DSC, just same way as we do for SST.
> > >
> > > v2: Removed intel_dp_mst_dsc_compute_config and refactored
> > > intel_dp_dsc_compute_config to support timeslots as a
> > > parameter(Ville Syrjälä)
> > >
> > > v3: - Rebased
> > > - Added a debug to see that we at least try reserving
> > > VCPI slots using DSC, because currently its not visible
> > > from the logs, thus making debugging more tricky.
> > > - Moved timeslots to numerator, where it should be.
> > >
> > > v4: - Call drm_dp_mst_atomic_check already during link
> > > config computation, because we need to know already
> > > by this moment if uncompressed amount of VCPI slots
> > > needed can fit, otherwise we need to use DSC.
> > > (thanks to Vinod Govindapillai for pointing this out)
> > >
> > > v5: - Put pipe_config->bigjoiner_pipes back to original
> > > condition in intel_dp_dsc_compute_config
> > > (don't remember when I lost it)
> > >
> > > Signed-off-by: Stanislav Lisovskiy
> > > ---
> > > drivers/gpu/drm/i915/display/intel_dp.c | 73 -
> > > drivers/gpu/drm/i915/display/intel_dp.h | 17 +++
> > > drivers/gpu/drm/i915/display/intel_dp_mst.c | 157
> > > 3 files changed, 205 insertions(+), 42 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > index 32292c0be2bd..519b436fc530 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > @@ -116,7 +116,6 @@ bool intel_dp_is_edp(struct intel_dp *intel_dp)
> > > }
> > >
> > > static void intel_dp_unset_edid(struct intel_dp *intel_dp);
> > > -static int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp, u8
> > > dsc_max_bpc);
> > >
> > > /* Is link rate UHBR and thus 128b/132b? */
> > > bool intel_dp_is_uhbr(const struct intel_crtc_state *crtc_state)
> > > @@ -687,11 +686,12 @@ small_joiner_ram_size_bits(struct drm_i915_private
> > > *i915)
> > > return 6144 * 8;
> > > }
> > >
> > > -static u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *i915,
> > > - u32 link_clock, u32 lane_count,
> > > - u32 mode_clock, u32 mode_hdisplay,
> > > - bool bigjoiner,
> > > - u32 pipe_bpp)
> > > +u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *i915,
> > > + u32 link_clock, u32 lane_count,
> > > + u32 mode_clock, u32 mode_hdisplay,
> > > + bool bigjoiner,
> > > + u32 pipe_bpp,
> > > + u32 timeslots)
> > > {
> > > u32 bits_per_pixel, max_bpp_small_joiner_ram;
> > > int i;
> > > @@ -702,8 +702,9 @@ static u16 intel_dp_dsc_get_output_bpp(struct
> > > drm_i915_private *i915,
> > > * for SST -> TimeSlotsPerMTP is 1,
> > > * for MST -> TimeSlotsPerMTP has to be calculated
> > > */
> > > - bits_per_pixel = (link_clock * lane_count * 8) /
> > > + bits_per_pixel = (link_clock * lane_count * 8) * timeslots /
> > > intel_dp_mode_to_fec_clock(mode_clock);
> > > + drm_dbg_kms(&i915->drm, "Max link bpp: %u\n", bits_per_pixel);
> > >
> > > /* Small Joiner Check: output bpp <= joiner RAM (bits) / Horiz.
> > > width */
> > > max_bpp_small_joiner_ram = small_joiner_ram_size_bits(i915) /
> > > @@ -752,9 +753,9 @@ static u16 intel_dp_dsc_get_output_bpp(struct
> > > drm_i915_private *i915,
> > > return bits_per_pixel << 4;
> > > }
> > >
> > > -static u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp,
> > > - int mode_clock, int mode_hdisplay,
> > > - bool bigjoiner)
> > > +u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp,
> > > + int mode_clock, int mode_hdisplay,
> > > + bool bigjoiner)
> > > {
> > > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > u8 min_slice_count, i;
> > > @@ -961,8 +962,8 @@ intel_dp_mode_valid_downstream(struct intel_connector
> > > *connector,
> > > return MODE_OK;
> > > }
> > >
> > > -static bool intel_dp_need_bigjoiner(struct intel_dp *intel_dp,
> > > - int hdisplay, int clock)
> > > +bool intel_dp_need_bigjoiner(struct intel_
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/kms: Stop registering multiple /sys/class/backlight devs for a single display
== Series Details == Series: drm/kms: Stop registering multiple /sys/class/backlight devs for a single display URL : https://patchwork.freedesktop.org/series/107755/ State : warning == Summary == Error: dim checkpatch failed 9770bde2adbd ACPI: video: Add acpi_video_backlight_use_native() helper -:112: CHECK:AVOID_EXTERNS: extern prototypes should be avoided in .h files #112: FILE: include/acpi/video.h:59: +extern bool acpi_video_backlight_use_native(void); -:120: CHECK:LINE_SPACING: Please use a blank line after function/struct/union/enum declarations #120: FILE: include/acpi/video.h:81: } +static inline bool acpi_video_backlight_use_native(void) total: 0 errors, 0 warnings, 2 checks, 73 lines checked 7bbb7b4364f8 drm/i915: Don't register backlight when another backlight should be used (v2) 21ff8de3d743 drm/amdgpu: Don't register backlight when another backlight should be used (v3) 4660f062ab74 drm/radeon: Don't register backlight when another backlight should be used (v3) 8f0a985ccd2d drm/nouveau: Don't register backlight when another backlight should be used (v2) a9d8a2239032 ACPI: video: Drop backlight_device_get_by_type() call from acpi_video_get_backlight_type() 827cedc90abe ACPI: video: Remove acpi_video_bus from list before tearing it down c46374a7c084 ACPI: video: Simplify acpi_video_unregister_backlight() 2c0dca45608a ACPI: video: Make backlight class device registration a separate step (v2) -:52: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #52: FILE: drivers/acpi/acpi_video.c:83: +MODULE_PARM_DESC(register_backlight_delay, + "Delay in seconds before doing fallback (non GPU driver triggered) " -:155: CHECK:AVOID_EXTERNS: extern prototypes should be avoided in .h files #155: FILE: include/acpi/video.h:56: +extern void acpi_video_register_backlight(void); total: 0 errors, 0 warnings, 2 checks, 112 lines checked ba74631acf23 ACPI: video: Remove code to unregister acpi_video backlight when a native backlight registers 0442c6a6fbfa drm/i915: Call acpi_video_register_backlight() (v3) 89fc23bf53df drm/nouveau: Register ACPI video backlight when nv_backlight registration fails (v2) 2098c614c444 drm/amdgpu: Register ACPI video backlight when skipping amdgpu backlight registration 012baaa975af drm/radeon: Register ACPI video backlight when skipping radeon backlight registration 9a316e427d90 platform/x86: nvidia-wmi-ec-backlight: Move fw interface definitions to a header (v2) Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' -:119: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #119: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 166 lines checked db397e31e959 ACPI: video: Refactor acpi_video_get_backlight_type() a bit 0746f167fbf6 ACPI: video: Add Nvidia WMI EC brightness control detection (v3) 8ded49115792 ACPI: video: Add Apple GMUX brightness control detection e7b522538f54 platform/x86: nvidia-wmi-ec-backlight: Use acpi_video_get_backlight_type() da5dc93cfd1d platform/x86: apple-gmux: Stop calling acpi/video.h functions 359a75cc8d2f platform/x86: toshiba_acpi: Stop using acpi_video_set_dmi_backlight_type() ab7d1912a362 platform/x86: acer-wmi: Move backlight DMI quirks to acpi/video_detect.c 99c3efe84b91 platform/x86: asus-wmi: Drop DMI chassis-type check from backlight handling f95c29c199a2 platform/x86: asus-wmi: Move acpi_backlight=vendor quirks to ACPI video_detect.c 5acb614534dc platform/x86: asus-wmi: Move acpi_backlight=native quirks to ACPI video_detect.c 17d1c19d714c platform/x86: samsung-laptop: Move acpi_backlight=[vendor|native] quirks to ACPI video_detect.c 7803178f9be6 ACPI: video: Remove acpi_video_set_dmi_backlight_type() debf21872658 ACPI: video: Drop "Samsung X360" acpi_backlight=native quirk db35244fef1b ACPI: video: Drop NL5x?U, PF4NU1F and PF5?U?? acpi_backlight=native quirks 1ab23762426c ACPI: video: Fix indentation of video_detect_dmi_table[] entries 3d4776063cd8 drm/todo: Add entry about dealing with brightness control on devices with > 1 panel -:11: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #11: https://lore.kernel.org/dri-devel/20220517152331.16217-1-hdego...@redhat.com/ total: 0 errors, 1 warnings, 0 checks, 74 lines checked
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/kms: Stop registering multiple /sys/class/backlight devs for a single display
== Series Details == Series: drm/kms: Stop registering multiple /sys/class/backlight devs for a single display URL : https://patchwork.freedesktop.org/series/107755/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning:
Re: [Intel-gfx] [PATCH 1/2] drm: Add missing DP DSC extended capability definitions.
Reviewed-by: Vinod Govindapillai On Mon, 2022-08-22 at 12:40 +0300, Stanislav Lisovskiy wrote: > Adding DP DSC register definitions, we might need for further > DSC implementation, supporting MST and DP branch pass-through mode. > > v2: - Fixed checkpatch comment warning > v3: - Removed function which is not yet used(Jani Nikula) > > Signed-off-by: Stanislav Lisovskiy > --- > include/drm/display/drm_dp.h | 10 +- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h > index 9e3aff7e68bb..0d05e3172f96 100644 > --- a/include/drm/display/drm_dp.h > +++ b/include/drm/display/drm_dp.h > @@ -239,6 +239,9 @@ > > #define DP_DSC_SUPPORT 0x060 /* DP 1.4 */ > # define DP_DSC_DECOMPRESSION_IS_SUPPORTED (1 << 0) > +# define DP_DSC_PASS_THROUGH_IS_SUPPORTED (1 << 1) > +# define DP_DSC_DYNAMIC_PPS_UPDATE_SUPPORT_COMP_TO_COMP (1 << 2) > +# define DP_DSC_DYNAMIC_PPS_UPDATE_SUPPORT_UNCOMP_TO_COMP (1 << 3) > > #define DP_DSC_REV 0x061 > # define DP_DSC_MAJOR_MASK (0xf << 0) > @@ -277,12 +280,15 @@ > > #define DP_DSC_BLK_PREDICTION_SUPPORT 0x066 > # define DP_DSC_BLK_PREDICTION_IS_SUPPORTED (1 << 0) > +# define DP_DSC_RGB_COLOR_CONV_BYPASS_SUPPORT (1 << 1) > > #define DP_DSC_MAX_BITS_PER_PIXEL_LOW 0x067 /* eDP 1.4 */ > > #define DP_DSC_MAX_BITS_PER_PIXEL_HI 0x068 /* eDP 1.4 */ > # define DP_DSC_MAX_BITS_PER_PIXEL_HI_MASK (0x3 << 0) > # define DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT 8 > +# define DP_DSC_MAX_BPP_DELTA_VERSION_MASK 0x06 > +# define DP_DSC_MAX_BPP_DELTA_AVAILABILITY 0x08 > > #define DP_DSC_DEC_COLOR_FORMAT_CAP 0x069 > # define DP_DSC_RGB (1 << 0) > @@ -344,11 +350,13 @@ > # define DP_DSC_24_PER_DP_DSC_SINK (1 << 2) > > #define DP_DSC_BITS_PER_PIXEL_INC 0x06F > +# define DP_DSC_RGB_YCbCr444_MAX_BPP_DELTA_MASK 0x1f > +# define DP_DSC_RGB_YCbCr420_MAX_BPP_DELTA_MASK 0xe0 > # define DP_DSC_BITS_PER_PIXEL_1_16 0x0 > # define DP_DSC_BITS_PER_PIXEL_1_8 0x1 > # define DP_DSC_BITS_PER_PIXEL_1_4 0x2 > # define DP_DSC_BITS_PER_PIXEL_1_2 0x3 > -# define DP_DSC_BITS_PER_PIXEL_1 0x4 > +# define DP_DSC_BITS_PER_PIXEL_1_1 0x4 > > #define DP_PSR_SUPPORT 0x070 /* XXX 1.2? */ > # define DP_PSR_IS_SUPPORTED 1
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/kms: Stop registering multiple /sys/class/backlight devs for a single display
== Series Details ==
Series: drm/kms: Stop registering multiple /sys/class/backlight devs for a
single display
URL : https://patchwork.freedesktop.org/series/107755/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12025 -> Patchwork_107755v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/index.html
Participating hosts (38 -> 35)
--
Missing(3): bat-dg2-8 bat-rpls-2 fi-hsw-4770
Known issues
Here are the changes found in Patchwork_107755v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_backlight@basic-brightness:
- fi-bsw-kefka: [PASS][1] -> [SKIP][2] ([fdo#109271])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/fi-bsw-kefka/igt@i915_pm_backli...@basic-brightness.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/fi-bsw-kefka/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@gt_engines:
- bat-dg1-6: [PASS][3] -> [INCOMPLETE][4] ([i915#4418])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-g3258: [PASS][5] -> [INCOMPLETE][6] ([i915#3303] /
[i915#4785])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
* igt@runner@aborted:
- fi-hsw-g3258: NOTRUN -> [FAIL][7] ([fdo#109271] / [i915#4312] /
[i915#6246])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/fi-hsw-g3258/igt@run...@aborted.html
Possible fixes
* igt@core_hotunplug@unbind-rebind:
- fi-ivb-3770:[FAIL][8] -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/fi-ivb-3770/igt@core_hotunp...@unbind-rebind.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/fi-ivb-3770/igt@core_hotunp...@unbind-rebind.html
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-rplp-1}: [DMESG-WARN][10] ([i915#2867]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka: [FAIL][12] ([i915#6298]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
Warnings
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: [FAIL][14] ([fdo#103375]) -> [INCOMPLETE][15]
([i915#5982])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
- fi-elk-e7500: [INCOMPLETE][16] ([i915#6598] / [i915#6601] /
[i915#6648]) -> [INCOMPLETE][17] ([i915#6598] / [i915#6648])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/fi-elk-e7500/igt@i915_susp...@basic-s3-without-i915.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107755v1/fi-elk-e7500/igt@i915_susp...@basic-s3-without-i915.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4418]: https://gitlab.freedesktop.org/drm/intel/issues/4418
[i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5982]: https://gitlab.freedesktop.org/drm/intel/issues/5982
[i915#6246]: https://gitlab.freedesktop.org/drm/intel/issues/6246
[i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#6380]: https://gitlab.freedesktop.org/drm/intel/issues/6380
[i915#6530]: https://g
Re: [Intel-gfx] [PATCH 6/7] drm/i915/guc: Make GuC log sizes runtime configurable
On 8/25/2022 00:15, Joonas Lahtinen wrote:
Quoting John Harrison (2022-08-24 21:45:09)
On 8/24/2022 02:01, Joonas Lahtinen wrote:
NACK on this one. Let's get this reverted or fixed to eliminate
new module parameters.
What prevents us just from using the maximum sizes? Or alternatively
we could check the already existing drm.debug variable or anything else
but addding 3 new module parameters.
We don't want to waste 24MB of memory for all users when 99.999% of them
don't care about GuC logs.
It is not exactly wasting memory if it is what is needed to capture
the error logs to properly debug a system. And it's definitely not much
on any modern system where you will have a GPU. You can always leave
the Kconfig options in place for the cases where it matters.
On the other hand, if 99.999% don't need this, then it could just stay
as a kernel config time option as well?
No. The point is that we need to able to ask customers to increase the
log size, repro an issue and send us the results. All on a pre-installed
system where they do not have the option to build a custom kernel.
Either we always allocate the maximum and waste the memory for all end
users or we have a runtime configuration option. Compile time is not
acceptable for some important customers/situations.
We also don't want to tie the GuC logging buffer size to the DRM
debugging output. Enabling kernel debug output can change timings and
prevent the issue that one is trying to capture in the GuC log. And it
seems unlikely we could add an entire new top level DRM debug flag just
for an internal i915 only log buffer size. Plus drm.debug is explicitly
stated as being dynamically changeable via sysfs at any time. The GuC
log buffer size cannot be changed without reloading the i915 driver. Or
at least, not without reloading the GuC, but we definitely don't want to
create a UAPI for arbitrarily reloading the GuC.
We can make these parameters 'unsafe' so that they taint the kernel if
used. But this is exactly what module parameters are for - configuration
that we don't want to hardcode as CONFIG options but which must be set
at module load time.
It's better to have sane defaults. And if somebody wants something
strange, they can have a Kconfig behind EXPERT option. But even then
there should really be need for it.
Define sane.
Sane for most users is to not allocate 24MB of memory for an internal
debug only buffer they will never use. And which completely swamps any
error capture log with the ASCII encoding of said buffer.
But as above, we need a way to (very occasionally) get larger GuC logs
from customers without rebuilding the kernel.
John.
So for now, let's get the module parameters reverted and go with
reasonable default buffer sizes when GuC is enabled. The compile time
options can be left in place.
Thank you in advance.
Regards, Joonas
John.
For future reference, please do Cc maintainers when adding new uAPI
like module parameters.
Regards, Joonas
Quoting john.c.harri...@intel.com (2022-07-28 05:20:27)
From: John Harrison
The GuC log buffer sizes had to be configured statically at compile
time. This can be quite troublesome when needing to get larger logs
out of a released driver. So re-organise the code to allow a boot time
module parameter override.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 53 ++
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 14 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 176 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_log.h| 42 +++--
drivers/gpu/drm/i915/i915_params.c| 12 ++
drivers/gpu/drm/i915/i915_params.h| 3 +
6 files changed, 226 insertions(+), 74 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index ab4aacc516aa4..01f2705cb94a3 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -224,53 +224,22 @@ static u32 guc_ctl_feature_flags(struct intel_guc *guc)
static u32 guc_ctl_log_params_flags(struct intel_guc *guc)
{
- u32 offset = intel_guc_ggtt_offset(guc, guc->log.vma) >> PAGE_SHIFT;
- u32 flags;
-
- #if (((CRASH_BUFFER_SIZE) % SZ_1M) == 0)
- #define LOG_UNIT SZ_1M
- #define LOG_FLAG GUC_LOG_LOG_ALLOC_UNITS
- #else
- #define LOG_UNIT SZ_4K
- #define LOG_FLAG 0
- #endif
-
- #if (((CAPTURE_BUFFER_SIZE) % SZ_1M) == 0)
- #define CAPTURE_UNIT SZ_1M
- #define CAPTURE_FLAG GUC_LOG_CAPTURE_ALLOC_UNITS
- #else
- #define CAPTURE_UNIT SZ_4K
- #define CAPTURE_FLAG 0
- #endif
-
- BUILD_BUG_ON(!CRASH_BUFFER_SIZE);
- BUILD_BUG_ON(!IS_ALIGNED(CRASH_BUFFER_SIZE, LOG_UNIT));
- BUILD_BUG_ON(!DEBUG_BUFFER_SIZE);
- BUILD_BUG_ON(!IS_ALIGNED(DEBUG_BUFFER_SIZE, LOG_UNIT));
- BUILD_BUG_ON(!CAPTURE_BUFFER_SIZE);
- BUILD_BUG_ON(!IS_ALIGNED(CAPTURE_BUF
Re: [Intel-gfx] [PATCH v9 1/8] overflow: Move and add few utility macros into overflow
On Wed, Aug 24, 2022 at 05:45:07PM +0900, Gwan-gyeong Mun wrote:
> It moves overflows_type utility macro into overflow header from i915_utils
> header. The overflows_type can be used to catch the truncaion (overflow)
> between different data types. And it adds check_assign() macro which
> performs an assigning source value into destination ptr along with an
> overflow check. overflow_type macro has been improved to handle the signbit
> by gcc's built-in overflow check function. And it adds overflows_ptr()
> helper macro for checking the overflows between a value and a pointer
> type/value.
>
> v3: Add is_type_unsigned() macro (Mauro)
> Modify overflows_type() macro to consider signed data types (Mauro)
> Fix the problem that safe_conversion() macro always returns true
> v4: Fix kernel-doc markups
> v6: Move macro addition location so that it can be used by other than drm
> subsystem (Jani, Mauro, Andi)
> Change is_type_unsigned to is_unsigned_type to have the same name form
> as is_signed_type macro
> v8: Add check_assign() and remove safe_conversion() (Kees)
> Fix overflows_type() to use gcc's built-in overflow function (Andrzej)
> Add overflows_ptr() to allow overflow checking when assigning a value
> into a pointer variable (G.G.)
> v9: Fix overflows_type() to use __builtin_add_overflow() instead of
> __builtin_add_overflow_p() (Andrzej)
> Fix overflows_ptr() to use overflows_type() with the unsigned long type
> (Andrzej)
>
> Signed-off-by: Gwan-gyeong Mun
> Cc: Thomas Hellström
> Cc: Matthew Auld
> Cc: Nirmoy Das
> Cc: Jani Nikula
> Cc: Andi Shyti
> Cc: Andrzej Hajda
> Cc: Mauro Carvalho Chehab
> Cc: Kees Cook
> Reviewed-by: Mauro Carvalho Chehab (v5)
> ---
> drivers/gpu/drm/i915/i915_user_extensions.c | 3 +-
> drivers/gpu/drm/i915/i915_utils.h | 5 +-
> include/linux/overflow.h| 62 +
> 3 files changed, 64 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_user_extensions.c
> b/drivers/gpu/drm/i915/i915_user_extensions.c
> index c822d0aafd2d..6f6b5b910968 100644
> --- a/drivers/gpu/drm/i915/i915_user_extensions.c
> +++ b/drivers/gpu/drm/i915/i915_user_extensions.c
> @@ -50,8 +50,7 @@ int i915_user_extensions(struct i915_user_extension __user
> *ext,
> if (err)
> return err;
>
> - if (get_user(next, &ext->next_extension) ||
> - overflows_type(next, ext))
> + if (get_user(next, &ext->next_extension) || overflows_ptr(next))
> return -EFAULT;
>
> ext = u64_to_user_ptr(next);
I continue to dislike the layers of macros and specialization here.
This is just a fancy version of check_assign():
if (get_user(next, &ext->next_extension) || check_assign(next, &ext))
return -EFAULT;
However, the __builtin_*_overflow() family only wants to work on
integral types, so this needs to be slightly expanded:
uintptr_t kptr;
...
if (get_user(next, &ext->next_extension) || check_assign(next, &kptr))
return -EFAULT;
ext = (void * __user)kptr;
But, it does seem like the actual problem here is that u64_to_user_ptr()
is not performing the checking? It's used heavily in the drm code.
Is a check_assign_user_ptr() needed?
> diff --git a/drivers/gpu/drm/i915/i915_utils.h
> b/drivers/gpu/drm/i915/i915_utils.h
> index c10d68cdc3ca..eb0ded23fa9c 100644
> --- a/drivers/gpu/drm/i915/i915_utils.h
> +++ b/drivers/gpu/drm/i915/i915_utils.h
> @@ -32,6 +32,7 @@
> #include
> #include
> #include
> +#include
>
> #ifdef CONFIG_X86
> #include
> @@ -111,10 +112,6 @@ bool i915_error_injected(void);
> #define range_overflows_end_t(type, start, size, max) \
> range_overflows_end((type)(start), (type)(size), (type)(max))
>
> -/* Note we don't consider signbits :| */
> -#define overflows_type(x, T) \
> - (sizeof(x) > sizeof(T) && (x) >> BITS_PER_TYPE(T))
> -
> #define ptr_mask_bits(ptr, n) ({ \
> unsigned long __v = (unsigned long)(ptr); \
> (typeof(ptr))(__v & -BIT(n)); \
> diff --git a/include/linux/overflow.h b/include/linux/overflow.h
> index f1221d11f8e5..6af9df1d67a1 100644
> --- a/include/linux/overflow.h
> +++ b/include/linux/overflow.h
> @@ -52,6 +52,68 @@ static inline bool __must_check __must_check_overflow(bool
> overflow)
> return unlikely(overflow);
> }
>
> +/**
> + * overflows_type - helper for checking the overflows between data types or
> + * values
> + *
> + * @x: Source value or data type for overflow check
> + * @T: Destination value or data type for overflow check
> + *
> + * It compares the values or data type between the first and second argument
> to
> + * check whether overflow can occur when assigning the first argument to the
> + * variable of th
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: do not try misaligned_pin test on unmappable memory
== Series Details ==
Series: drm/i915/selftests: do not try misaligned_pin test on unmappable memory
URL : https://patchwork.freedesktop.org/series/107758/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12025 -> Patchwork_107758v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107758v1/index.html
Participating hosts (38 -> 37)
--
Missing(1): bat-rpls-2
Known issues
Here are the changes found in Patchwork_107758v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-rkl-11600: NOTRUN -> [SKIP][1] ([fdo#111827])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107758v1/fi-rkl-11600/igt@kms_chamel...@common-hpd-after-suspend.html
Possible fixes
* igt@core_hotunplug@unbind-rebind:
- fi-ivb-3770:[FAIL][2] -> [PASS][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/fi-ivb-3770/igt@core_hotunp...@unbind-rebind.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107758v1/fi-ivb-3770/igt@core_hotunp...@unbind-rebind.html
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-rplp-1}: [DMESG-WARN][4] ([i915#2867]) -> [PASS][5] +1 similar
issue
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107758v1/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_exec_suspend@basic-s3@smem:
- fi-rkl-11600: [INCOMPLETE][6] ([i915#6179]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107758v1/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@requests:
- {bat-rpls-1}: [INCOMPLETE][8] ([i915#6257] / [i915#6380]) ->
[PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/bat-rpls-1/igt@i915_selftest@l...@requests.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107758v1/bat-rpls-1/igt@i915_selftest@l...@requests.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: [FAIL][10] ([fdo#103375]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107758v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka: [FAIL][12] ([i915#6298]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107758v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
Warnings
* igt@i915_suspend@basic-s3-without-i915:
- fi-hsw-g3258: [INCOMPLETE][14] ([i915#6598]) -> [INCOMPLETE][15]
([i915#4817] / [i915#6598])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/fi-hsw-g3258/igt@i915_susp...@basic-s3-without-i915.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107758v1/fi-hsw-g3258/igt@i915_susp...@basic-s3-without-i915.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#4817]: https://gitlab.freedesktop.org/drm/intel/issues/4817
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6179]: https://gitlab.freedesktop.org/drm/intel/issues/6179
[i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#6380]: https://gitlab.freedesktop.org/drm/intel/issues/6380
[i915#6530]: https://gitlab.freedesktop.org/drm/intel/issues/6530
[i915#6598]: https://gitlab.freedesktop.org/drm/intel/issues/6598
Build changes
-
* Linux: CI_DRM_12025 -> Patchwork_107758v1
CI-20190529: 20190529
CI_DRM_12025: a510fb9e9cb6f9ee56eae0ea0d4f3f9c0757a042 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6636: 1298b5f0e1b3e010657ffba41d2e775fab028e08 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_107758v1: a510fb9e9cb6f9ee56eae0ea0d4f3f9c0757a042 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
280091ef2df9 drm/i915/selftests: do not try misaligned_pin test on unmapp
Re: [Intel-gfx] [PATCH v9 2/8] util_macros: Add exact_type macro to catch type mis-match while compiling
On Wed, Aug 24, 2022 at 05:45:08PM +0900, Gwan-gyeong Mun wrote:
> It adds exact_type and exactly_pgoff_t macro to catch type mis-match while
> compiling. The existing typecheck() macro outputs build warnings, but the
> newly added exact_type() macro uses the BUILD_BUG_ON() macro to generate
> a build break when the types are different and can be used to detect
> explicit build errors.
>
> v6: Move macro addition location so that it can be used by other than drm
> subsystem (Jani, Mauro, Andi)
>
> Signed-off-by: Gwan-gyeong Mun
> Cc: Thomas Hellström
> Cc: Matthew Auld
> Cc: Nirmoy Das
> Cc: Jani Nikula
> Cc: Andi Shyti
> Cc: Mauro Carvalho Chehab
> ---
> include/linux/util_macros.h | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/include/linux/util_macros.h b/include/linux/util_macros.h
> index 72299f261b25..b6624b275257 100644
> --- a/include/linux/util_macros.h
> +++ b/include/linux/util_macros.h
> @@ -2,6 +2,9 @@
> #ifndef _LINUX_HELPER_MACROS_H_
> #define _LINUX_HELPER_MACROS_H_
>
> +#include
> +#include
> +
> #define __find_closest(x, a, as, op) \
> ({ \
> typeof(as) __fc_i, __fc_as = (as) - 1; \
> @@ -38,4 +41,26 @@
> */
> #define find_closest_descending(x, a, as) __find_closest(x, a, as, >=)
>
> +/**
> + * exact_type - break compile if source type and destination value's type are
> + * not the same
> + * @T: Source type
> + * @n: Destination value
> + *
> + * It is a helper macro for a poor man's -Wconversion: only allow variables
> of
> + * an exact type. It determines whether the source type and destination
> value's
> + * type are the same while compiling, and it breaks compile if two types are
> + * not the same
> + */
> +#define exact_type(T, n) \
> + BUILD_BUG_ON(!__builtin_constant_p(n) &&
> !__builtin_types_compatible_p(T, typeof(n)))
Maybe use __same_type() here instead of open-coded
__builtin_types_compatible_p()? Also, IIUC, currently coding style
advise is to use _Static_assert when possible over BUILD_BUG_ON for
error message readability.
This macro has a trap-door for literals, yes?
i.e. exact_type(pgoff_t, 5) will pass?
I also note that this is very close to the really common (and open-coded)
test scattered around the kernel already (BUILD_BUG_ON(__same_type(a,
b))), so I think it's good to get a macro defined for it, though I'm not
sure about the trap door test. Regardless, I'd like to bikeshed the name
a bit; I think this should be named something a bit more clear about
what happens on failure. Perhaps: assert_type()? Or to capture the
trapdoor idea, assert_typable()?
#define assert_type(t1, t2) _Static_assert(__same_type(t1, t2))
#define assert_typable(t, n)_Static_assert(__builtin_constant_p(n) ||
__same_type(t, typeof(n))
> +
> +/**
> + * exactly_pgoff_t - helper to check if the type of a value is pgoff_t
> + * @n: value to compare pgoff_t type
> + *
> + * It breaks compile if the argument value's type is not pgoff_t type.
> + */
> +#define exactly_pgoff_t(n) exact_type(pgoff_t, n)
Why specialize this? Just use assert_typable(pgoff_t, n) in the other
patches? It's almost the same amount to write. :)
--
Kees Cook
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: allow misaligned_pin test work with unmappable memory
== Series Details ==
Series: drm/i915/selftests: allow misaligned_pin test work with unmappable
memory
URL : https://patchwork.freedesktop.org/series/107760/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12025 -> Patchwork_107760v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107760v1/index.html
Participating hosts (38 -> 35)
--
Missing(3): fi-hsw-4770 bat-rpls-2 fi-rkl-11600
Known issues
Here are the changes found in Patchwork_107760v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@execlists:
- fi-bsw-nick:[PASS][1] -> [INCOMPLETE][2] ([i915#5847])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107760v1/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-pnv-d510:NOTRUN -> [INCOMPLETE][3] ([i915#6598] / [i915#6601])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107760v1/fi-pnv-d510/igt@i915_susp...@basic-s3-without-i915.html
* igt@runner@aborted:
- fi-bsw-nick:NOTRUN -> [FAIL][4] ([fdo#109271] / [i915#4312])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107760v1/fi-bsw-nick/igt@run...@aborted.html
Possible fixes
* igt@core_hotunplug@unbind-rebind:
- fi-ivb-3770:[FAIL][5] -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/fi-ivb-3770/igt@core_hotunp...@unbind-rebind.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107760v1/fi-ivb-3770/igt@core_hotunp...@unbind-rebind.html
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-rplp-1}: [DMESG-WARN][7] ([i915#2867]) -> [PASS][8] +1 similar
issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107760v1/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@requests:
- {bat-rpls-1}: [INCOMPLETE][9] ([i915#6257] / [i915#6380]) ->
[PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/bat-rpls-1/igt@i915_selftest@l...@requests.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107760v1/bat-rpls-1/igt@i915_selftest@l...@requests.html
- fi-pnv-d510:[DMESG-FAIL][11] ([i915#4528]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/fi-pnv-d510/igt@i915_selftest@l...@requests.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107760v1/fi-pnv-d510/igt@i915_selftest@l...@requests.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka: [FAIL][13] ([i915#6298]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107760v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
Warnings
* igt@i915_suspend@basic-s3-without-i915:
- fi-hsw-g3258: [INCOMPLETE][15] ([i915#6598]) -> [INCOMPLETE][16]
([i915#4817] / [i915#6598])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12025/fi-hsw-g3258/igt@i915_susp...@basic-s3-without-i915.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107760v1/fi-hsw-g3258/igt@i915_susp...@basic-s3-without-i915.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
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4528]: https://gitlab.freedesktop.org/drm/intel/issues/4528
[i915#4817]: https://gitlab.freedesktop.org/drm/intel/issues/4817
[i915#5847]: https://gitlab.freedesktop.org/drm/intel/issues/5847
[i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#6380]: https://gitlab.freedesktop.org/drm/intel/issues/6380
[i915#6530]: https://gitlab.freedesktop.org/drm/intel/issues/6530
[i915#6598]: https://gitlab.freedesktop.org/drm/intel/issues/6598
[i915#6601]: https://gitlab.freedesktop.org/drm/intel/issues/6601
[i915#6637]: https://gitlab.freedesktop.org/drm/intel/issues/6637
Build changes
-
* Linux: CI_DRM_12025 -> Patchwork_107760v1
CI-20190529: 20190529
CI_DRM_12025: a510fb9e9cb6f9ee56eae0ea0d4f3f9c0757a042 @
git://anongit.freedesktop.org/gfx-ci/l
Re: [Intel-gfx] [PATCH] drm/i915: Skip Bit12 fw domain reset for gen12+
Hi G.G, > -Original Message- > From: Mun, Gwan-gyeong > Sent: Tuesday, August 23, 2022 11:14 PM > To: Roper, Matthew D ; Sripada, Radhakrishna > > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Skip Bit12 fw domain reset for > gen12+ > > > > On 8/18/22 3:00 PM, Matt Roper wrote: > > On Wed, Aug 17, 2022 at 03:43:04PM -0700, Radhakrishna Sripada wrote: > >> Bit12 of the Forcewake request register should not be cleared post > >> gen12. Do not touch this bit while clearing during fw domain reset. > >> > >> Bspec: 52542 > >> > >> Signed-off-by: Sushma Venkatesh Reddy > > >> Signed-off-by: Radhakrishna Sripada > >> --- > >> drivers/gpu/drm/i915/intel_uncore.c | 5 - > >> 1 file changed, 4 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/gpu/drm/i915/intel_uncore.c > b/drivers/gpu/drm/i915/intel_uncore.c > >> index a852c471d1b3..c85e2b686c95 100644 > >> --- a/drivers/gpu/drm/i915/intel_uncore.c > >> +++ b/drivers/gpu/drm/i915/intel_uncore.c > >> @@ -113,7 +113,10 @@ fw_domain_reset(const struct > intel_uncore_forcewake_domain *d) > >> * off in ICL+), so no waiting for acks > >> */ > >>/* WaRsClearFWBitsAtReset:bdw,skl */ > > > > While we're at it, let's remove the "bdw,skl" from this comment since > > it's misleading and doesn't match the code. We do still apply this > > workaround on other pre-gen12 platforms than just those two. > > > > Aside from the comment tweak, > > > > Reviewed-by: Matt Roper > > > >> - fw_clear(d, 0x); > >> + if (GRAPHICS_VER(d->uncore->i915) >= 12) > Hi Radhakrishna Sripada, > > In bspec 52542, there is an explanation that BIT12 should not be set for > address 0xA188 corresponding to FORCEWAKE_MT/FORCEWAKE_GT_GEN9, but > in > bspec 52466, there is no explanation that BIT12 should not be set for > address 0xA278, address of FORCEWAKE_RENDER_GEN9. > > I ask if fw_domain_reset() should perform fw_clear() by comparing not > only GRAPHICS_VER() >= 12 but also checking of FW_DOMAIN_ID_RENDER and > FW_DOMAIN_ID_GT values. Based on the note in 52542, all other WA notes are overridden by the comment. So unless stated otherwise, it should apply to this register as well. Created a bspec issue to request for additional clarification just to be safe. Will send an additional patch if the comment contradicts our understanding. Thanks, RK > > Br, > G.G. > >> + fw_clear(d, 0xefff); > >> + else > >> + fw_clear(d, 0x); > >> } > >> > >> static inline void > >> -- > >> 2.25.1 > >> > >
Re: [Intel-gfx] [PATCH v2] drm/i915/dg2: Add Wa_1509727124
On Wed, Aug 24, 2022 at 02:26:38PM +0300, Joonas Lahtinen wrote: > Quoting Matt Roper (2022-08-02 18:09:16) > > On Mon, Aug 01, 2022 at 02:38:39PM -0700, Harish Chegondi wrote: > > > Bspec: 46052 > > > Reviewed-by: Matt Roper > > > Signed-off-by: Harish Chegondi > > > > Applied to drm-intel-gt-next. Thanks for the patch. > > This patch is completely lacking the commit message. > > That is unacceptable, please make sure there is a proper commit message > for any merged patches going forward. > > Please do explain the patch rationale in this mail thread so it at least > becomes available from the Link: that gets added by DIM when this was > committed. > > Regards, Joonas There isn't really too much to say on this one. For the record, the justification is that we're implementing Wa_1509727124 from the workaround database which simply tells us that we need to program 0xE18C[9] to 1; this patch is just following that guidance from the spec. There's no further information available beyond that. Going forward we'll make sure we put some kind of statement in the commit message body to make it clear that the workaround number and register/bit setting are the only information we have and that this isn't an oversight. Thanks. Matt -- Matt Roper Graphics Software Engineer VTT-OSGC Platform Enablement Intel Corporation
Re: [Intel-gfx] [PATCH] i915/pmu: Wire GuC backend to per-client busyness
On Wed, 24 Aug 2022 22:03:19 -0700, Dixit, Ashutosh wrote:
>
> On Thu, 04 Aug 2022 16:21:25 -0700, Umesh Nerlige Ramappa wrote:
> >
>
> Hi Umesh,
>
> Still reviewing but I have a question below.
Please ignore this mail for now, mostly a result of my misunderstanding the
code. I will ask again if I have any questions. Thanks.
>
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> > b/drivers/gpu/drm/i915/gt/intel_context.c
> > index 654a092ed3d6..e2d70a9fdac0 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> > @@ -576,16 +576,24 @@ void intel_context_bind_parent_child(struct
> > intel_context *parent,
> > child->parallel.parent = parent;
> > }
> >
> > -u64 intel_context_get_total_runtime_ns(const struct intel_context *ce)
> > +u64 intel_context_get_total_runtime_ns(struct intel_context *ce)
> > {
> > u64 total, active;
> >
> > + if (ce->ops->update_stats)
> > + ce->ops->update_stats(ce);
> > +
>
> /snip/
>
> > @@ -1396,6 +1399,10 @@ static void guc_timestamp_ping(struct work_struct
> > *wrk)
> > with_intel_runtime_pm(>->i915->runtime_pm, wakeref)
> > __update_guc_busyness_stats(guc);
> >
> > + /* adjust context stats for overflow */
> > + xa_for_each(&guc->context_lookup, index, ce)
> > + __guc_context_update_clks(ce);
> > +
>
> The question is why do we have 2 functions: __guc_context_update_clks()
> (which we call periodically from guc_timestamp_ping()) and
> guc_context_update_stats() (which we call non-periodically from
> intel_context_get_total_runtime_ns()? Why don't we have just one function
> which is called from both places? Or rather why don't we call
> guc_context_update_stats() from both places?
>
> If we don't call guc_context_update_stats() periodically from
> guc_timestamp_ping() how e.g. does ce->stats.runtime.start_gt_clk get reset
> to 0? If it gets reset to 0 in __guc_context_update_clks() then why do we
> need to reset it in guc_context_update_stats()?
>
> Also IMO guc->timestamp.lock should be taken by this single function,
> (otherwise guc_context_update_stats() is modifying
> ce->stats.runtime.start_gt_clk without taking the lock).
>
> Thanks.
> --
> Ashutosh
>
> > +static void __guc_context_update_clks(struct intel_context *ce)
> > +{
> > + struct intel_guc *guc = ce_to_guc(ce);
> > + struct intel_gt *gt = ce->engine->gt;
> > + u32 *pphwsp, last_switch, engine_id;
> > + u64 start_gt_clk, active;
> > + unsigned long flags;
> > + ktime_t unused;
> > +
> > + spin_lock_irqsave(&guc->timestamp.lock, flags);
> > +
> > + /*
> > +* GPU updates ce->lrc_reg_state[CTX_TIMESTAMP] when context is switched
> > +* out, however GuC updates PPHWSP offsets below. Hence KMD (CPU)
> > +* relies on GuC and GPU for busyness calculations. Due to this, A
> > +* potential race was highlighted in an earlier review that can lead to
> > +* double accounting of busyness. While the solution to this is a wip,
> > +* busyness is still usable for platforms running GuC submission.
> > +*/
> > + pphwsp = ((void *)ce->lrc_reg_state) - LRC_STATE_OFFSET;
> > + last_switch = READ_ONCE(pphwsp[PPHWSP_GUC_CONTEXT_USAGE_STAMP_LO]);
> > + engine_id = READ_ONCE(pphwsp[PPHWSP_GUC_CONTEXT_USAGE_ENGINE_ID]);
> > +
> > + guc_update_pm_timestamp(guc, &unused);
> > +
> > + if (engine_id != 0x && last_switch) {
> > + start_gt_clk = READ_ONCE(ce->stats.runtime.start_gt_clk);
> > + __extend_last_switch(guc, &start_gt_clk, last_switch);
> > + active = intel_gt_clock_interval_to_ns(gt,
> > guc->timestamp.gt_stamp - start_gt_clk);
> > + WRITE_ONCE(ce->stats.runtime.start_gt_clk, start_gt_clk);
> > + WRITE_ONCE(ce->stats.active, active);
> > + } else {
> > + lrc_update_runtime(ce);
> > + }
> > +
> > + spin_unlock_irqrestore(&guc->timestamp.lock, flags);
> > +}
> > +
> > +static void guc_context_update_stats(struct intel_context *ce)
> > +{
> > + if (!intel_context_pin_if_active(ce)) {
> > + WRITE_ONCE(ce->stats.runtime.start_gt_clk, 0);
> > + WRITE_ONCE(ce->stats.active, 0);
> > + return;
> > + }
> > +
> > + __guc_context_update_clks(ce);
> > + intel_context_unpin(ce);
> > +}
[Intel-gfx] [PATCH] drm/i915/slpc: Set rps' min and max frequencies even with SLPC.
We need to inform PCODE of a desired ring frequencies so PCODE update
the memory frequencies to us. rps->min_freq and rps->max_freq are the
frequencies used in that request. However they were unset when SLPC was
enabled and PCODE never updated the memory freq.
Let's at least for now get these freq set up so we can inform PCODE.
Cc: Ashutosh Dixit
Tested-by: Sushma Venkatesh Reddy
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/gt/intel_rps.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 8c289a032103..58a82978d5df 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -1128,6 +1128,20 @@ void gen6_rps_get_freq_caps(struct intel_rps *rps,
struct intel_rps_freq_caps *c
}
}
+static void rps_basic_init_for_slpc(struct intel_rps *rps)
+{
+ struct intel_rps_freq_caps caps;
+
+ /*
+* Even with SLPC we need to initialize at least a basic min and max
+* frequency so we can inform pcode a desired IA ring frequency in
+* gen6_update_ring_freq
+*/
+ gen6_rps_get_freq_caps(rps, &caps);
+ rps->min_freq = caps.min_freq;
+ rps->max_freq = caps.rp0_freq;
+}
+
static void gen6_rps_init(struct intel_rps *rps)
{
struct drm_i915_private *i915 = rps_to_i915(rps);
@@ -1970,8 +1984,10 @@ void intel_rps_init(struct intel_rps *rps)
{
struct drm_i915_private *i915 = rps_to_i915(rps);
- if (rps_uses_slpc(rps))
+ if (rps_uses_slpc(rps)) {
+ rps_basic_init_for_slpc(rps);
return;
+ }
if (IS_CHERRYVIEW(i915))
chv_rps_init(rps);
--
2.37.1
Re: [Intel-gfx] [PATCH] drm/i915/slpc: Set rps' min and max frequencies even with SLPC.
On Thu, Aug 25, 2022 at 06:23:15PM -0400, Rodrigo Vivi wrote:
> We need to inform PCODE of a desired ring frequencies so PCODE update
> the memory frequencies to us. rps->min_freq and rps->max_freq are the
> frequencies used in that request. However they were unset when SLPC was
> enabled and PCODE never updated the memory freq.
>
> Let's at least for now get these freq set up so we can inform PCODE.
>
> Cc: Ashutosh Dixit
> Tested-by: Sushma Venkatesh Reddy
> Signed-off-by: Rodrigo Vivi
As suggested by Sushma:
Fixes: 7ba79a671568 ("drm/i915/guc/slpc: Gate Host RPS when SLPC is enabled")
Cc: # v5.15+
> ---
> drivers/gpu/drm/i915/gt/intel_rps.c | 18 +-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
> b/drivers/gpu/drm/i915/gt/intel_rps.c
> index 8c289a032103..58a82978d5df 100644
> --- a/drivers/gpu/drm/i915/gt/intel_rps.c
> +++ b/drivers/gpu/drm/i915/gt/intel_rps.c
> @@ -1128,6 +1128,20 @@ void gen6_rps_get_freq_caps(struct intel_rps *rps,
> struct intel_rps_freq_caps *c
> }
> }
>
> +static void rps_basic_init_for_slpc(struct intel_rps *rps)
> +{
> + struct intel_rps_freq_caps caps;
> +
> + /*
> + * Even with SLPC we need to initialize at least a basic min and max
> + * frequency so we can inform pcode a desired IA ring frequency in
> + * gen6_update_ring_freq
> + */
> + gen6_rps_get_freq_caps(rps, &caps);
> + rps->min_freq = caps.min_freq;
> + rps->max_freq = caps.rp0_freq;
> +}
> +
> static void gen6_rps_init(struct intel_rps *rps)
> {
> struct drm_i915_private *i915 = rps_to_i915(rps);
> @@ -1970,8 +1984,10 @@ void intel_rps_init(struct intel_rps *rps)
> {
> struct drm_i915_private *i915 = rps_to_i915(rps);
>
> - if (rps_uses_slpc(rps))
> + if (rps_uses_slpc(rps)) {
> + rps_basic_init_for_slpc(rps);
> return;
> + }
>
> if (IS_CHERRYVIEW(i915))
> chv_rps_init(rps);
> --
> 2.37.1
>
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/slpc: Set rps' min and max frequencies even with SLPC.
== Series Details ==
Series: drm/i915/slpc: Set rps' min and max frequencies even with SLPC.
URL : https://patchwork.freedesktop.org/series/107766/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12026 -> Patchwork_107766v1
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_107766v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_107766v1, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v1/index.html
Participating hosts (32 -> 33)
--
Additional (1): fi-hsw-4770
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_107766v1:
### IGT changes ###
Possible regressions
* igt@kms_force_connector_basic@force-connector-state:
- fi-cfl-8109u: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12026/fi-cfl-8109u/igt@kms_force_connector_ba...@force-connector-state.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v1/fi-cfl-8109u/igt@kms_force_connector_ba...@force-connector-state.html
Known issues
Here are the changes found in Patchwork_107766v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_backlight@basic-brightness:
- fi-hsw-4770:NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#3012])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v1/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@requests:
- fi-pnv-d510:[PASS][4] -> [DMESG-FAIL][5] ([i915#4528])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12026/fi-pnv-d510/igt@i915_selftest@l...@requests.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v1/fi-pnv-d510/igt@i915_selftest@l...@requests.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-hsw-4770:NOTRUN -> [INCOMPLETE][6] ([i915#4817] / [i915#6598])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v1/fi-hsw-4770/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- fi-hsw-4770:NOTRUN -> [SKIP][7] ([fdo#109271]) +9 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v1/fi-hsw-4770/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html
* igt@kms_chamelium@dp-crc-fast:
- fi-hsw-4770:NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +7
similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v1/fi-hsw-4770/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_psr@sprite_plane_onoff:
- fi-hsw-4770:NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#1072]) +3
similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v1/fi-hsw-4770/igt@kms_psr@sprite_plane_onoff.html
Possible fixes
* igt@i915_pm_rpm@module-reload:
- fi-bsw-kefka: [DMESG-WARN][10] ([i915#1982]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12026/fi-bsw-kefka/igt@i915_pm_...@module-reload.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v1/fi-bsw-kefka/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka: [FAIL][12] ([i915#6298]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12026/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
Warnings
* igt@i915_suspend@basic-s3-without-i915:
- fi-elk-e7500: [INCOMPLETE][14] ([i915#6598] / [i915#6601] /
[i915#6648]) -> [INCOMPLETE][15] ([i915#6598] / [i915#6648])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12026/fi-elk-e7500/igt@i915_susp...@basic-s3-without-i915.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107766v1/fi-elk-e7500/igt@i915_susp...@basic-s3-without-i915.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#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012
[i915
Re: [Intel-gfx] [PATCH v3] drm/i915/pxp: don't start pxp without mei_pxp bind
On 8/23/2022 2:15 PM, Juston Li wrote:
On Fri, Aug 19, 2022 at 4:53 AM Andrzej Hajda wrote:
On 18.08.2022 19:42, Juston Li wrote:
pxp will not start correctly until after mei_pxp bind completes and
intel_pxp_init_hw() is called.
Wait for the bind to complete before proceeding with startup.
This fixes a race condition during bootup where we observed a small
window for pxp commands to be sent, starting pxp before mei_pxp bind
completed.
Changes since v2:
- wait for pxp_component to bind instead of returning -EAGAIN (Daniele)
Changes since v1:
- check pxp_component instead of pxp_component_added (Daniele)
- pxp_component needs tee_mutex (Daniele)
- return -EAGAIN so caller knows to retry (Daniele)
Signed-off-by: Juston Li
In typical usage of component framework driver postpones initialization
till component is bound. In such case checking/waiting for component as
in this patch is not necessary and the code is more straightforward.
I wonder how it behaves on component unbind.
This component is only used for a specific use-case (content
protection), so we don't want to hold back the whole graphics driver
initialization for that. Unbind can only happen on suspend or driver
removal and in both cases we're not accepting userspace submission at
that point.
Anyway:
Reviewed-by: Andrzej Hajda
Thanks Andrzej!
Any other comments Daniele?
Otherwise, need some help from someone to merge this :)
No other comments from me. I've pushed the patch to gt-next.
Thanks,
Daniele
Thanks
Juston
Regards
Andrzej
---
drivers/gpu/drm/i915/pxp/intel_pxp.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 15311eaed848..17109c513259 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -176,6 +176,18 @@ static void pxp_queue_termination(struct intel_pxp *pxp)
spin_unlock_irq(>->irq_lock);
}
+static bool pxp_component_bound(struct intel_pxp *pxp)
+{
+ bool bound = false;
+
+ mutex_lock(&pxp->tee_mutex);
+ if (pxp->pxp_component)
+ bound = true;
+ mutex_unlock(&pxp->tee_mutex);
+
+ return bound;
+}
+
/*
* the arb session is restarted from the irq work when we receive the
* termination completion interrupt
@@ -187,6 +199,9 @@ int intel_pxp_start(struct intel_pxp *pxp)
if (!intel_pxp_is_enabled(pxp))
return -ENODEV;
+ if (wait_for(pxp_component_bound(pxp), 250))
+ return -ENXIO;
+
mutex_lock(&pxp->arb_mutex);
if (pxp->arb_is_valid)
Re: [Intel-gfx] [PATCH] drm/i915/slpc: Set rps' min and max frequencies even with SLPC.
On Thu, 25 Aug 2022 15:23:15 -0700, Rodrigo Vivi wrote:
>
> We need to inform PCODE of a desired ring frequencies so PCODE update
> the memory frequencies to us. rps->min_freq and rps->max_freq are the
> frequencies used in that request. However they were unset when SLPC was
> enabled and PCODE never updated the memory freq.
>
> Let's at least for now get these freq set up so we can inform PCODE.
Hi Rodrigo,
Great find. Though may I propose a more direct patch below for fixing this:
+
diff --git a/drivers/gpu/drm/i915/gt/intel_llc.c
b/drivers/gpu/drm/i915/gt/intel_llc.c
index 14fe65812e42..a1791b6c7e04 100644
--- a/drivers/gpu/drm/i915/gt/intel_llc.c
+++ b/drivers/gpu/drm/i915/gt/intel_llc.c
@@ -49,6 +49,7 @@ static unsigned int cpu_max_MHz(void)
static bool get_ia_constants(struct intel_llc *llc,
struct ia_constants *consts)
{
+ struct intel_guc_slpc *slpc = &llc_to_gt(llc)->uc.guc.slpc;
struct drm_i915_private *i915 = llc_to_gt(llc)->i915;
struct intel_rps *rps = &llc_to_gt(llc)->rps;
@@ -65,8 +66,14 @@ static bool get_ia_constants(struct intel_llc *llc,
/* convert DDR frequency from units of 266.6MHz to bandwidth */
consts->min_ring_freq = mult_frac(consts->min_ring_freq, 8, 3);
- consts->min_gpu_freq = rps->min_freq;
- consts->max_gpu_freq = rps->max_freq;
+ if (intel_uc_uses_guc_slpc(&llc_to_gt(llc)->uc)) {
+ consts->min_gpu_freq = slpc->min_freq;
+ consts->max_gpu_freq = slpc->rp0_freq;
+ } else {
+ consts->min_gpu_freq = rps->min_freq;
+ consts->max_gpu_freq = rps->max_freq;
+ }
+
if (GRAPHICS_VER(i915) >= 9) {
/* Convert GT frequency to 50 HZ units */
consts->min_gpu_freq /= GEN9_FREQ_SCALER;
+
I have only compile tested the patch but it looks like everything is set up
so the patch above should work. The call stack for slpc initialization is
the following (I am writing here due to the rather opaque uc macros):
intel_gt_resume
-> intel_gt_init_hw
-> intel_uc_init_hw/__uc_init_hw
-> intel_guc_slpc_enable
-> slpc_get_rp_values
As we can see intel_llc_enable() is called after intel_gt_init_hw() in
intel_gt_resume() so SLPC params should be set up.
What you have is fine too, I can R-b that if you prefer that.
Thanks.
--
Ashutosh
> Cc: Ashutosh Dixit
> Tested-by: Sushma Venkatesh Reddy
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/gt/intel_rps.c | 18 +-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
> b/drivers/gpu/drm/i915/gt/intel_rps.c
> index 8c289a032103..58a82978d5df 100644
> --- a/drivers/gpu/drm/i915/gt/intel_rps.c
> +++ b/drivers/gpu/drm/i915/gt/intel_rps.c
> @@ -1128,6 +1128,20 @@ void gen6_rps_get_freq_caps(struct intel_rps *rps,
> struct intel_rps_freq_caps *c
> }
> }
>
> +static void rps_basic_init_for_slpc(struct intel_rps *rps)
> +{
> + struct intel_rps_freq_caps caps;
> +
> + /*
> + * Even with SLPC we need to initialize at least a basic min and max
> + * frequency so we can inform pcode a desired IA ring frequency in
> + * gen6_update_ring_freq
> + */
> + gen6_rps_get_freq_caps(rps, &caps);
> + rps->min_freq = caps.min_freq;
> + rps->max_freq = caps.rp0_freq;
> +}
> +
> static void gen6_rps_init(struct intel_rps *rps)
> {
> struct drm_i915_private *i915 = rps_to_i915(rps);
> @@ -1970,8 +1984,10 @@ void intel_rps_init(struct intel_rps *rps)
> {
> struct drm_i915_private *i915 = rps_to_i915(rps);
>
> - if (rps_uses_slpc(rps))
> + if (rps_uses_slpc(rps)) {
> + rps_basic_init_for_slpc(rps);
> return;
> + }
>
> if (IS_CHERRYVIEW(i915))
> chv_rps_init(rps);
> --
> 2.37.1
>
Re: [Intel-gfx] [PATCH 1/2] drm/i915/uc: Support for version reduced and multiple firmware files
On 8/24/2022 21:49, Ceraolo Spurio, Daniele wrote:
On 8/16/2022 1:28 PM, john.c.harri...@intel.com wrote:
From: John Harrison
There was a misunderstanding in how firmware file compatibility should
be managed within i915. This has been clarified as:
i915 must support all existing firmware releases forever
new minor firmware releases should replace prior versions
only backwards compatibility breaking releases should be a new file
Hence this patch cleans up the single fallback file support that was
added as a quick fix emergency effort. That is now removed in
preference to supporting arbitrary numbers of firmware files per
platform as normal.
The patch also adds support for having GuC firmwrae files that are
named by major version only (because the major version indicates
backwards breaking changes that affect the KMD) and for having HuC
firmware files with no version number at all (because the KMD has no
interface requirements with the HuC).
For GuC, the driver will report via dmesg if the found file is older
than
expected. For HuC, the KMD will no longer require updating for any new
HuC release so will not be able to report what the latest expected
version is.
Signed-off-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 10 +-
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 4 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 396 +++---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 33 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 16 +-
5 files changed, 275 insertions(+), 184 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 0d17da77e7872..d1715971fdd79 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1868,7 +1868,7 @@ int intel_guc_submission_init(struct intel_guc
*guc)
if (guc->submission_initialized)
return 0;
- if (guc->fw.major_ver_found < 70) {
+ if (guc->fw.file_found.major_ver < 70) {
ret = guc_lrc_desc_pool_create_v69(guc);
if (ret)
return ret;
@@ -2303,7 +2303,7 @@ static int register_context(struct
intel_context *ce, bool loop)
GEM_BUG_ON(intel_context_is_child(ce));
trace_intel_context_register(ce);
- if (guc->fw.major_ver_found >= 70)
+ if (guc->fw.file_found.major_ver >= 70)
ret = register_context_v70(guc, ce, loop);
else
ret = register_context_v69(guc, ce, loop);
@@ -2315,7 +2315,7 @@ static int register_context(struct
intel_context *ce, bool loop)
set_context_registered(ce);
spin_unlock_irqrestore(&ce->guc_state.lock, flags);
- if (guc->fw.major_ver_found >= 70)
+ if (guc->fw.file_found.major_ver >= 70)
guc_context_policy_init_v70(ce, loop);
}
@@ -2921,7 +2921,7 @@ static void
__guc_context_set_preemption_timeout(struct intel_guc *guc,
u16 guc_id,
u32 preemption_timeout)
{
- if (guc->fw.major_ver_found >= 70) {
+ if (guc->fw.file_found.major_ver >= 70) {
struct context_policy policy;
__guc_context_policy_start_klv(&policy, guc_id);
@@ -3186,7 +3186,7 @@ static int guc_context_alloc(struct
intel_context *ce)
static void __guc_context_set_prio(struct intel_guc *guc,
struct intel_context *ce)
{
- if (guc->fw.major_ver_found >= 70) {
+ if (guc->fw.file_found.major_ver >= 70) {
struct context_policy policy;
__guc_context_policy_start_klv(&policy, ce->guc_id.id);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index f2e7c82985efd..0697128cc3362 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -436,8 +436,8 @@ static void print_fw_ver(struct intel_uc *uc,
struct intel_uc_fw *fw)
struct drm_i915_private *i915 = uc_to_gt(uc)->i915;
drm_info(&i915->drm, "%s firmware %s version %u.%u\n",
- intel_uc_fw_type_repr(fw->type), fw->path,
- fw->major_ver_found, fw->minor_ver_found);
+ intel_uc_fw_type_repr(fw->type), fw->file_found.path,
+ fw->file_found.major_ver, fw->file_found.minor_ver);
}
static int __uc_init_hw(struct intel_uc *uc)
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 58547292efa0a..eb3a15f0fa479 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -41,7 +41,7 @@ void intel_uc_fw_change_status(struct intel_uc_fw
*uc_fw,
"%s firmware -> %s\n",
intel_uc_fw_type_repr(uc_fw->type),
status == INTEL_UC_FIRMWARE_SELECTED ?
- uc_fw->path : intel_uc_fw_status_repr(status));
+ uc_fw->file_found.path : intel_uc_fw_status_repr(status));
}
#endif
@@ -52,83 +52,113 @@ v
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/slpc: Set rps' min and max frequencies even with SLPC. (rev2)
== Series Details == Series: drm/i915/slpc: Set rps' min and max frequencies even with SLPC. (rev2) URL : https://patchwork.freedesktop.org/series/107766/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/107766/revisions/2/mbox/ not applied Applying: drm/i915/slpc: Set rps' min and max frequencies even with SLPC. error: corrupt patch at line 58 error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 drm/i915/slpc: Set rps' min and max frequencies even with SLPC. When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
