Re: [Intel-gfx] [PATCH v7 09/11] drm: uevent for connector status change
On Tue, May 21, 2019 at 8:55 AM Pekka Paalanen wrote: > > On Mon, 20 May 2019 18:11:07 +0200 > Daniel Vetter wrote: > > > On Fri, May 17, 2019 at 01:08:24PM +0300, Pekka Paalanen wrote: > > > On Thu, 16 May 2019 14:24:55 +0200 > > > Daniel Vetter wrote: > > > > > > > On Thu, May 16, 2019 at 11:22:11AM +0300, Pekka Paalanen wrote: > > > > > On Wed, 15 May 2019 10:24:49 +0200 > > > > > Daniel Vetter wrote: > > > > > > > > > > > On Wed, May 15, 2019 at 10:37:31AM +0300, Pekka Paalanen wrote: > > > > > > > On Tue, 14 May 2019 16:34:01 +0200 > > > > > > > Daniel Vetter wrote: > > > > > > > > > > > > > > > On Tue, May 14, 2019 at 3:36 PM Pekka Paalanen > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Tue, 14 May 2019 13:02:09 +0200 > > > > > > > > > Daniel Vetter wrote: > > > > > > > > > > > > > > > > > > > On Tue, May 14, 2019 at 10:18 AM Ser, Simon > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > On Tue, 2019-05-14 at 11:02 +0300, Pekka Paalanen wrote: > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > > Hi Daniel, > > > > > > > > > > > > > > > > > > > > > > > > just to clarify the first case, specific to one very > > > > > > > > > > > > particular > > > > > > > > > > > > property: > > > > > > > > > > > > > > > > > > > > > > > > With HDCP, there is a property that may change > > > > > > > > > > > > dynamically at runtime > > > > > > > > > > > > (the undesired/desired/enabled tristate). Userspace > > > > > > > > > > > > must be notified > > > > > > > > > > > > when it changes, I do not want userspace have to poll > > > > > > > > > > > > that property > > > > > > > > > > > > with a timer. > > > > > > > > > > > > > > > > > > > > > > > > When that property alone changes, and userspace is > > > > > > > > > > > > prepared to handle > > > > > > > > > > > > that property changing alone, it must not trigger a > > > > > > > > > > > > reprobe of the > > > > > > > > > > > > connector. There is no reason to reprobe at that point > > > > > > > > > > > > AFAIU. > > > > > > > > > > > > > > > > > > > > > > > > How do you ensure that userspace can avoid triggering a > > > > > > > > > > > > reprobe with the > > > > > > > > > > > > epoch approach or with any alternate uevent design? > > > > > > > > > > > > > > > > > > > > > > > > We need an event to userspace that indicates that > > > > > > > > > > > > re-reading the > > > > > > > > > > > > properties is enough and reprobe of the connector is > > > > > > > > > > > > not necessary. > > > > > > > > > > > > This is complementary to indicating to userspace that > > > > > > > > > > > > only some > > > > > > > > > > > > connectors need to be reprobed instead of everything. > > > > > > > > > > > > > > > > > > > > > > Can't you use the PROPERTY hint? If PROPERTY is the HDCP > > > > > > > > > > > one, skip the > > > > > > > > > > > reprobing. Would that work? > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > yes, that would work, if it was acceptable to DRM upstream. > > > > > > > > > The replies > > > > > > > > > to Paul seemed to be going south so fast that I thought we > > > > > > > > > wouldn't get > > > > > > > > > any new uevent fields in favour of "epoch counters". > > > > > > > > > > > > > > > > > > > Yes that's the idea, depending upon which property you get > > > > > > > > > > you know > > > > > > > > > > it's a sink change (needs full reprobe) or something else > > > > > > > > > > like hdcp > > > > > > > > > > state machinery update. > > > > > > > > > > > > > > > > > > Right. > > > > > > > > > > > > > > > > > > > Wrt avoiding the full reprobe for sink changes: I think we > > > > > > > > > > should > > > > > > > > > > indeed decouple that from the per-connector event for sink > > > > > > > > > > changes. > > > > > > > > > > That along is a good win already, since you know for which > > > > > > > > > > connector > > > > > > > > > > you need to call drmGetConnector (which forces the > > > > > > > > > > reprobe). It would > > > > > > > > > > be nice to only call drmGetConnectorCurrent (avoids the > > > > > > > > > > reprobe), but > > > > > > > > > > historically speaking every time we tried to rely on this > > > > > > > > > > we ended up > > > > > > > > > > regretting things. > > > > > > > > > > > > > > > > > > What changed? This sounds very much what Paul suggested. > > > > > > > > > Looking at it > > > > > > > > > from userspace side: > > > > > > > > > > > > > > > > This sounds solid, some refinements below: > > > > > > > > > > > > > > > > > HOTPLUG=1 CONNECTOR=xx PROPERTY=yy > > > > > > > > > > > > > > > > > > - If yy is "Content Protection", no need to > > > > > > > > > drmModeGetConnector(), just > > > > > > > > > re-get the connector properties. > > > > > > > > > > > > > > > > > > - Kernel probably shouldn't bother sending this for > > > > > > > > > properties where > > > > > > > > > re-probe could be necessary, and send the below instead. > > > > > > > > > > >
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 02/27] trace.pl: Ignore signaling on non i915 fences
Quoting Tvrtko Ursulin (2019-05-20 15:47:14)
> From: Tvrtko Ursulin
>
> gem_wsim uses the sw_fence timeline and confuses the script.
>
> v2:
> * Check the correct timeline as well. (Chris)
>
> Signed-off-by: Tvrtko Ursulin
> ---
> scripts/trace.pl | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/scripts/trace.pl b/scripts/trace.pl
> index 8c896cfde6b0..ac141a514055 100755
> --- a/scripts/trace.pl
> +++ b/scripts/trace.pl
> @@ -443,6 +443,9 @@ while (<>) {
> } elsif ($tp_name eq 'dma_fence:dma_fence_signaled:') {
> my $nkey;
>
> + next unless $tp{'driver'} eq 'i915' and
> + $tp{'timeline'} eq 'signaled';
Hopefully that remains unique...
Reviewed-by: Chris Wilson
I do recall wanting to remove the strings from all the tracepoints :-p
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 12/27] gem_wsim: Engine map support
Quoting Tvrtko Ursulin (2019-05-20 15:47:24)
> @@ -999,30 +1092,53 @@ prepare_workload(unsigned int id, struct workload
> *wrk, unsigned int flags)
> /*
> * Identify if contexts target specific engine instances and if they
> * want to be balanced.
> +*
> +* Transfer over engine map configuration from the workload step.
> */
> for (j = 0; j < wrk->nr_ctxs; j += 2) {
> bool targets = false;
> bool balance = false;
>
> for (i = 0, w = wrk->steps; i < wrk->nr_steps; i++, w++) {
> - if (w->type != BATCH)
> - continue;
> -
> if (w->context != (j / 2))
> continue;
>
> - if (w->engine == VCS)
> - balance = true;
> - else
> - targets = true;
> + if (w->type == BATCH) {
> + if (w->engine == VCS)
> + balance = true;
> + else
> + targets = true;
> + } else if (w->type == ENGINE_MAP) {
> + wrk->ctx_list[j].engine_map = w->engine_map;
> + wrk->ctx_list[j].engine_map_count =
> + w->engine_map_count;
> + }
> }
>
> - if (flags & I915) {
> - wrk->ctx_list[j].targets_instance = targets;
> + wrk->ctx_list[j].targets_instance = targets;
> + if (flags & I915)
> wrk->ctx_list[j].wants_balance = balance;
> + }
> +
> + /*
> +* Ensure VCS is not allowed with engine map contexts.
> +*/
> + for (j = 0; j < wrk->nr_ctxs; j += 2) {
> + for (i = 0, w = wrk->steps; i < wrk->nr_steps; i++, w++) {
> + if (w->context != (j / 2))
> + continue;
> +
> + if (w->type != BATCH)
> + continue;
> +
> + if (wrk->ctx_list[j].engine_map && w->engine == VCS) {
> + wsim_err("Batches targetting engine maps must
> use explicit engines!\n");
> + return -1;
> + }
> }
> }
>
> +
^^^
> /*
> * Create and configure contexts.
> */
I'm helping!
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 4/7] drm/i915: move and rename i915_runtime_pm
On Fri, 17 May 2019, Chris Wilson wrote: > Quoting Daniele Ceraolo Spurio (2019-05-17 16:27:26) >> >> >> On 5/16/19 3:42 PM, Chris Wilson wrote: >> > Quoting Chris Wilson (2019-05-16 23:10:10) >> >> Quoting Chris Wilson (2019-05-16 23:07:43) >> >>> Quoting Daniele Ceraolo Spurio (2019-05-16 22:56:31) >> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.h >> b/drivers/gpu/drm/i915/intel_runtime_pm.h >> index b964ca7af9c8..0e3817f9785e 100644 >> --- a/drivers/gpu/drm/i915/intel_runtime_pm.h >> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.h >> @@ -6,6 +6,7 @@ >> #ifndef __INTEL_RUNTIME_PM_H__ >> #define __INTEL_RUNTIME_PM_H__ >> >> +#include >> >>> >> >>> There doesn't seem to be any peeking into struct device, so do we not >> >>> just need the struct device forward decl here? >> >> True, will fix. At some point we had the idea of adding separate _types.h headers for types. The more we add structs in the headers, the more they'll need to include to be self-contained, while the interface users in many cases don't need to look at the internals at all. They just need the forward decls for the pointers. >> >> >> >> >> And add it to Makefile.headers_test >> > >> > Hint: we may need to split out intel_display_power.[ch] >> > >> >> Should I add intel_display_power.h to Makefile.headers_test as well? It >> does compile on its own, but it'll have to include intel_display.h, >> which isn't on the list. > > Yes. If we have to include intel_display.h, that means whenever we get > around to splitting intel_display.h, we will remember to update > intel_display_power.h. Rainy day tasks will be to delete #include at > random and see which are still required in headers. Storm day task will be to bang iwyu [1] to work nicely with the kernel build. BR, Jani. [1] https://include-what-you-use.org/ -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 4/8] drm/i915: vgpu context submission pv optimization
On 04/29/2019 06:03 PM, Chris Wilson wrote:
> Quoting Xiaolin Zhang (2019-04-29 04:10:54)
>> +static void pv_submit(struct intel_engine_cs *engine)
>> +{
>> + struct intel_engine_execlists * const execlists = &engine->execlists;
>> + struct execlist_port *port = execlists->port;
>> + unsigned int n;
>> + struct gvt_shared_page *shared_page = engine->i915->vgpu.shared_page;
>> + u64 descs[2];
>> +
>> + for (n = 0; n < execlists_num_ports(execlists); n++) {
>> + struct i915_request *rq;
>> + unsigned int count = 0;
>> +
>> + descs[n] = 0;
>> + rq = port_unpack(&port[n], &count);
>> + if (rq && count == 0) {
>> + port_set(&port[n], port_pack(rq, ++count));
>> + descs[n] = execlists_update_context(rq);
>> + }
>> + }
>> +
>> + spin_lock(&engine->i915->vgpu.shared_page_lock[engine->id]);
> Only one engine at a time now accesses that portion of pv_elsp, so the
> spin lock is not required per-se, aiui.
>
> The problem is that there is no coordination between pv_submit and the
> other side of the pipe, as far as I can see. So it seems very possible
> for us to overwrite entries before they have been read. I expect to see
> some ack mechanism for VGT_G2V_PV_SUBMISSION.
>
>> + for (n = 0; n < execlists_num_ports(execlists); n++)
>> + shared_page->pv_elsp[engine->id].descs[n] = descs[n];
> I'd recommend not using engine->id, that's just our internal id and may
> vary between host/guest. Use engine->hw_id? Or negotiate using pv setup
> and store pv_id?
>
> But starting to look more solid over all. We just need to finish
> splitting out the various similar-but-quite-different-really submission
> backends. :)
> -Chris
>
Chris, Thanks your great comments and will be addressed next version
(will remove spin lock, use hw_id, add ack mechanism and refine patches).
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert "ICL HACK: Disable ACPI idle driver"
On Tue, 21 May 2019, "Saarinen, Jani" wrote:
> HI,
>
>> -Original Message-
>> From: Vivi, Rodrigo
>> Sent: tiistai 21. toukokuuta 2019 3.12
>> To: Saarinen, Jani
>> Cc: Swarup, Aditya ; Gupta, Anshuman
>> ; Vetter, Daniel ; intel-
>> g...@lists.freedesktop.org; Syrjala, Ville ; Peres,
>> Martin
>> ; Wilson, Chris P
>> Subject: Re: [Intel-gfx] [PATCH] Revert "ICL HACK: Disable ACPI idle driver"
>>
>> On Mon, May 20, 2019 at 01:42:35PM +, Saarinen, Jani wrote:
>> > HI,
>> >
>> > > -Original Message-
>> > > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On
>> > > Behalf Of Aditya Swarup
>> > > Sent: lauantai 18. toukokuuta 2019 1.00
>> > > To: Gupta, Anshuman
>> > > Cc: Vetter, Daniel ;
>> > > intel-gfx@lists.freedesktop.org; Syrjala, Ville
>> > > ; Peres, Martin
>> > > Subject: Re: [Intel-gfx] [PATCH] Revert "ICL HACK: Disable ACPI idle
>> > > driver"
>> > >
>> > > The patch looks fine to me.
>> > > On Thu, May 16, 2019 at 10:41:56PM +0530, Anshuman Gupta wrote:
>> > > > This reverts commit 99b69db57544ec7ed427607f1a2a1858a7d43b61
>> > > > Core-for-CI:ICL_only Disable ACPI idle driver.
>> > > >
>> > > > This hack has been provided considering the Bug assessment that
>> > > > ACPI idle driver page fault causes below bug.
>> > > > FDO https://bugs.freedesktop.org/show_bug.cgi?id=108840
>> > > > But this bug is still reproducible after disabling ACPI idle driver.
>> > > >
>> > > > It looks "rcu_preempt self-detected stall on CPU" causes to hung
>> > > > kworker and followed by panic resulted this bug.
>> > > >
>> > > > Hence it make sense to revert this patch.
>> > > >
>> > > > Cc: martin.pe...@intel.com
>> > > > Cc: daniel.vet...@intel.com
>> > > > Cc: ville.syrj...@intel.com
>> > >
>> > > Reviewed-by: Aditya Swarup
>> > Are we now ok to merge this or? Chris, Ville?
>>
>> We shouldn't merge this. Instead we just need to go there and remove from
>> topic/core-for-CI and force push with dim to rebuild drm-tip.
> Yes, this was my ask here, isnt't this change for reverting that from
> topic/core-for-CI (so basically remove) or no?
>>
>> If this is the wish from CI perspective, let's do it.
> If other players agree first. Ville, Chris?
I threw the commit out of topic/core-for-CI.
BR,
Jani.
>
>>
>> >
>> > >
>> > > > Signed-off-by: Anshuman Gupta
>> > > > ---
>> > > > drivers/acpi/processor_driver.c | 18 +-
>> > > > 1 file changed, 1 insertion(+), 17 deletions(-)
>> > > >
>> > > > diff --git a/drivers/acpi/processor_driver.c
>> > > > b/drivers/acpi/processor_driver.c index ee842a2f..9d6aff2 100644
>> > > > --- a/drivers/acpi/processor_driver.c
>> > > > +++ b/drivers/acpi/processor_driver.c
>> > > > @@ -35,12 +35,6 @@
>> > > >
>> > > > #include
>> > > >
>> > > > -/* Only for Core-for-CI so don't want ia64 to fail compilation.*/
>> > > > -#ifdef CONFIG_X86 -#include -#include
>> > > > -#endif
>> > > > -
>> > > > #include "internal.h"
>> > > >
>> > > > #define ACPI_PROCESSOR_NOTIFY_PERFORMANCE 0x80 @@ -64,13 +58,6
>> @@
>> > > > static const struct acpi_device_id processor_device_ids[] = { };
>> > > > MODULE_DEVICE_TABLE(acpi, processor_device_ids);
>> > > >
>> > > > -#define ICPU(model) { X86_VENDOR_INTEL, 6, model,
>> X86_FEATURE_ANY, }
>> > > > -static const struct x86_cpu_id intel_cpu_ids[] = {
>> > > > - ICPU(INTEL_FAM6_ICELAKE_MOBILE),/* ICL */
>> > > > - {}
>> > > > -};
>> > > > -MODULE_DEVICE_TABLE(x86cpu, intel_cpu_ids);
>> > > > -
>> > > > static struct device_driver acpi_processor_driver = {
>> > > >.name = "processor",
>> > > >.bus = &cpu_subsys,
>> > > > @@ -239,7 +226,6 @@ static inline void acpi_pss_perf_exit(struct
>> > > > acpi_processor *pr, static int __acpi_processor_start(struct
>> > > > acpi_device *device) {
>> > > >struct acpi_processor *pr = acpi_driver_data(device);
>> > > > - const struct x86_cpu_id *id;
>> > > >acpi_status status;
>> > > >int result = 0;
>> > > >
>> > > > @@ -253,9 +239,7 @@ static int __acpi_processor_start(struct
>> > > > acpi_device
>> > > *device)
>> > > >if (result && !IS_ENABLED(CONFIG_ACPI_CPU_FREQ_PSS))
>> > > >dev_dbg(&device->dev, "CPPC data invalid or not
>> > > > present\n");
>> > > >
>> > > > - id = x86_match_cpu(intel_cpu_ids);
>> > > > - if (!id && (!cpuidle_get_driver() || cpuidle_get_driver() ==
>> > > > - &acpi_idle_driver))
>> > > > + if (!cpuidle_get_driver() || cpuidle_get_driver() ==
>> > > > +&acpi_idle_driver)
>> > > >acpi_processor_power_init(pr);
>> > > >
>> > > >result = acpi_pss_perf_init(pr, device);
>> > > > --
>> > > > 2.7.4
>> > > >
>> > > > ___
>> > > > Intel-gfx mailing list
>> > > > Intel-gfx@lists.freedesktop.org
>> > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>> > > ___
>> > > Intel-gfx mailing list
>> > > I
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 12/27] gem_wsim: Engine map support
On 21/05/2019 09:14, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-20 15:47:24)
@@ -999,30 +1092,53 @@ prepare_workload(unsigned int id, struct workload *wrk,
unsigned int flags)
/*
* Identify if contexts target specific engine instances and if they
* want to be balanced.
+*
+* Transfer over engine map configuration from the workload step.
*/
for (j = 0; j < wrk->nr_ctxs; j += 2) {
bool targets = false;
bool balance = false;
for (i = 0, w = wrk->steps; i < wrk->nr_steps; i++, w++) {
- if (w->type != BATCH)
- continue;
-
if (w->context != (j / 2))
continue;
- if (w->engine == VCS)
- balance = true;
- else
- targets = true;
+ if (w->type == BATCH) {
+ if (w->engine == VCS)
+ balance = true;
+ else
+ targets = true;
+ } else if (w->type == ENGINE_MAP) {
+ wrk->ctx_list[j].engine_map = w->engine_map;
+ wrk->ctx_list[j].engine_map_count =
+ w->engine_map_count;
+ }
}
- if (flags & I915) {
- wrk->ctx_list[j].targets_instance = targets;
+ wrk->ctx_list[j].targets_instance = targets;
+ if (flags & I915)
wrk->ctx_list[j].wants_balance = balance;
+ }
+
+ /*
+* Ensure VCS is not allowed with engine map contexts.
+*/
+ for (j = 0; j < wrk->nr_ctxs; j += 2) {
+ for (i = 0, w = wrk->steps; i < wrk->nr_steps; i++, w++) {
+ if (w->context != (j / 2))
+ continue;
+
+ if (w->type != BATCH)
+ continue;
+
+ if (wrk->ctx_list[j].engine_map && w->engine == VCS) {
+ wsim_err("Batches targetting engine maps must use
explicit engines!\n");
+ return -1;
+ }
}
}
+
^^^
/*
* Create and configure contexts.
*/
I'm helping!
Is this the only complaint? I want to avoid respinning just for this if
there is further feedback.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 1/7] drm/i915: prefer i915_runtime_pm in intel_runtime function
On Thu, 16 May 2019, Daniele Ceraolo Spurio
wrote:
> As a first step towards updating the code to work on the runtime_pm
> structure instead of i915, rework all the internals to use and pass
> around that.
>
> Signed-off-by: Daniele Ceraolo Spurio
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +
> drivers/gpu/drm/i915/intel_drv.h| 10 +-
> drivers/gpu/drm/i915/intel_runtime_pm.c | 152
> 3 files changed, 82 insertions(+), 82 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 5801f5407589..474074c7f395 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1177,6 +1177,8 @@ struct skl_wm_params {
> */
> struct i915_runtime_pm {
> atomic_t wakeref_count;
> + struct device *kdev;
This could use a small comment to say what device this is.
BR,
Jani.
> + bool available;
> bool suspended;
> bool irqs_enabled;
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 30b2d6ed2d53..bd04f394fbd3 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1662,13 +1662,17 @@ assert_rpm_wakelock_held(struct i915_runtime_pm
> *rpm, int wakeref_count)
> }
>
> static inline void
> -assert_rpm_raw_wakeref_held(struct drm_i915_private *i915)
> +__assert_rpm_raw_wakeref_held(struct i915_runtime_pm *rpm)
> {
> - struct i915_runtime_pm *rpm = &i915->runtime_pm;
> -
> assert_rpm_raw_wakeref_held(rpm, atomic_read(&rpm->wakeref_count));
> }
>
> +static inline void
> +assert_rpm_raw_wakeref_held(struct drm_i915_private *i915)
> +{
> + __assert_rpm_raw_wakeref_held(&i915->runtime_pm);
> +}
> +
> static inline void
> __assert_rpm_wakelock_held(struct i915_runtime_pm *rpm)
> {
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index b4abababdf6c..2e21f562df44 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -60,19 +60,19 @@
> * present for a given platform.
> */
>
> -static intel_wakeref_t intel_runtime_pm_get_raw(struct drm_i915_private
> *i915);
> +static intel_wakeref_t intel_runtime_pm_get_raw(struct i915_runtime_pm *rpm);
> static void
> -__intel_runtime_pm_put(struct drm_i915_private *i915, intel_wakeref_t wref,
> +__intel_runtime_pm_put(struct i915_runtime_pm *rpm, intel_wakeref_t wref,
> bool wakelock);
>
> #if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
> static void
> -intel_runtime_pm_put_raw(struct drm_i915_private *i915, intel_wakeref_t
> wref);
> +intel_runtime_pm_put_raw(struct i915_runtime_pm *rpm, intel_wakeref_t wref);
> #else
> -static inline void intel_runtime_pm_put_raw(struct drm_i915_private *i915,
> +static inline void intel_runtime_pm_put_raw(struct i915_runtime_pm *rpm,
> intel_wakeref_t wref)
> {
> - __intel_runtime_pm_put(i915, -1, false);
> + __intel_runtime_pm_put(rpm, -1, false);
> }
> #endif
>
> @@ -112,21 +112,18 @@ static void __print_depot_stack(depot_stack_handle_t
> stack,
> snprint_stack_trace(buf, sz, &trace, indent);
> }
>
> -static void init_intel_runtime_pm_wakeref(struct drm_i915_private *i915)
> +static void init_intel_runtime_pm_wakeref(struct i915_runtime_pm *rpm)
> {
> - struct i915_runtime_pm *rpm = &i915->runtime_pm;
> -
> spin_lock_init(&rpm->debug.lock);
> }
>
> static noinline depot_stack_handle_t
> -track_intel_runtime_pm_wakeref(struct drm_i915_private *i915)
> +track_intel_runtime_pm_wakeref(struct i915_runtime_pm *rpm)
> {
> - struct i915_runtime_pm *rpm = &i915->runtime_pm;
> depot_stack_handle_t stack, *stacks;
> unsigned long flags;
>
> - if (!HAS_RUNTIME_PM(i915))
> + if (!rpm->available)
> return -1;
>
> stack = __save_depot_stack();
> @@ -153,10 +150,9 @@ track_intel_runtime_pm_wakeref(struct drm_i915_private
> *i915)
> return stack;
> }
>
> -static void untrack_intel_runtime_pm_wakeref(struct drm_i915_private *i915,
> +static void untrack_intel_runtime_pm_wakeref(struct i915_runtime_pm *rpm,
>depot_stack_handle_t stack)
> {
> - struct i915_runtime_pm *rpm = &i915->runtime_pm;
> unsigned long flags, n;
> bool found = false;
>
> @@ -274,9 +270,8 @@ dump_and_free_wakeref_tracking(struct
> intel_runtime_pm_debug *debug)
> }
>
> static noinline void
> -__intel_wakeref_dec_and_check_tracking(struct drm_i915_private *i915)
> +__intel_wakeref_dec_and_check_tracking(struct i915_runtime_pm *rpm)
> {
> - struct i915_runtime_pm *rpm = &i915->runtime_pm;
> struct intel_runtime_pm_debug dbg = {};
> unsigned long flags;
>
> @@ -292,9 +287,8 @@ __intel_wakeref_dec_and_check_tracking(struct
> drm_i915_private *i915)
> }
>
> static noinline void
Re: [Intel-gfx] [PATCH v7 09/11] drm: uevent for connector status change
On Tue, 21 May 2019 09:52:50 +0200 Daniel Vetter wrote: > On Tue, May 21, 2019 at 8:55 AM Pekka Paalanen wrote: > > > > On Mon, 20 May 2019 18:11:07 +0200 > > Daniel Vetter wrote: > > > > > On Fri, May 17, 2019 at 01:08:24PM +0300, Pekka Paalanen wrote: > > > > On Thu, 16 May 2019 14:24:55 +0200 > > > > Daniel Vetter wrote: > > > > > > > > > On Thu, May 16, 2019 at 11:22:11AM +0300, Pekka Paalanen wrote: ... > > > > > > No, my concern is not an issue with netlink reliability. It is a > > > > > > potential issue when userspace chooses to not use netlink, and uses > > > > > > something else instead. I'm not sure what that else is but Paul says > > > > > > there is code in libudev and that is completely outside the control > > > > > > of > > > > > > KMS apps like display servers. > > > > > > > > > > afaik this other path only exists because it's the older one, for uapi > > > > > backwards compatibility with older userspace. Shouldn't be used for > > > > > anything. > > > > > > > > "Shouldn't be used" and someone screaming "kernel regression"... are you > > > > sure that path won't matter? > > > > > > > > Like some home-brewn distribution that happens to configure their > > > > libudev and kernel to use the old method, uses already new userspace, > > > > and then upgrades the kernel that starts sending fine-grained hotplug > > > > events, resulting the display server randomly handling hotplug wrong. > > > > > > > > Reading Airlie's recent rant about kernel regression handling make this > > > > a scary scenario where you would have no other choice than to rip all > > > > the fine-grained uevents out again. > > > > > > > > Is there any difference in the kernel code between the old method and > > > > the netlink method? Would it be possible to send fine-grained hotplug > > > > events only through netlink, and fall back to the old 'HOTPLUG=1' for > > > > the old method? > > > > > > There's a lot of grey in kernel regressions, and for fringe setups used by > > > few people I wouldn't worry about this. If they expect their shit to keep > > > working when using new stuff and crappy old interfaces, they get to keep > > > all the pieces. > > > > It didn't sound gray at all, reading Dave Airlie's email about it. If > > someone updates the kernel, and something works worse after that, then > > it is by definition a kernel regression. Period. And the earliest > > regression wins, i.e. if a revert breaks other things, the revert will > > be done regardless. > > > > > Dave's recent rant was a bit special, since userspace is clearly smoking > > > some strong stuff (-modesetting's atomic is seriously not using atomic > > > correctly), but it was also affecting too many people, and changing the > > > boot setup meant you'd get a black screen on boot-up already. Instead of > > > just on the first modeset with more than 1 screen. > > > > Then I think I missed the context of Dave's email. Reading it again, I > > still do not see that context. > > > > Btw. how do you determine "not using atomic correctly"? Has some uAPI > > specification for atomic appeared? I wasn't aware there was any uAPI > > specs, so there is no "incorrect use" if it happened to work once. > > -modesetting atomic blows up with more than one screen (even if you > just move that screen between crtc). The breakage was that with the > fastboot changes we've put the one screen onto crtc 1, but by default > modesetting wants it on crtc 0, and it couldn't do that switch > anymore. Hi Daniel, what says the assumption of the only monitor being driven by CRTC 0 was a bad one? :-p It's probably not obvious that userspace needs to explicitly try to avoid invalid configuration combinations by inspecting the current full configuration and not just the one CRTC/connector it wants to use. > All current atomic in -modesetting can do is pageflip and dpms off/on > on the first screen on the first crtc. Anything more fancy goes boom, > like where you change the connector/crtc links. > > It's _really_ broken :-) But it worked exactly that much, until a kernel change broke it, right? Yes, I totally see the sillyness, but if it worked and we have these no-regression rules... > > I don't personally really like these rules, but if these are the rules, > > then so be it. In my opinion it would be a huge step forward to get and > > require uAPI specifications, that people could verify both kernel and > > userspace against. Verifying against kernel code with no spec is what > > leads to the -modesetting issue by the sounds of it. > > > > Documenting kernel internal interfaces is not it. People reading > > DRM internal interface docs would need to know how DRM works internally > > before they could map that information into uAPI, which makes it less > > useful if not even useless for userspace developers. > > vgem is the idea here for validation, but if people ship atomic code > that was never tested except for "boots on my laptop", then nothing i
Re: [Intel-gfx] [PATCH v7 09/11] drm: uevent for connector status change
On Tue, May 21, 2019 at 12:01:29PM +0300, Pekka Paalanen wrote: > Hi Daniel, > > what says the assumption of the only monitor being driven by CRTC 0 > was a bad one? :-p > > It's probably not obvious that userspace needs to explicitly try to > avoid invalid configuration combinations by inspecting the current full > configuration and not just the one CRTC/connector it wants to use. Well the entire point of atomic is that you do set the entire config. The -modesetting atomic conversation tried to just use the atomic ioctl by 1:1 replacing legacy ioctl calls, and they screwed things up. If it would have applied the entire configuration in one go, it would work. > > All current atomic in -modesetting can do is pageflip and dpms off/on > > on the first screen on the first crtc. Anything more fancy goes boom, > > like where you change the connector/crtc links. > > > > It's _really_ broken :-) > > But it worked exactly that much, until a kernel change broke it, right? > Yes, I totally see the sillyness, but if it worked and we have these > no-regression rules... Which is why the offending patch has been reverted. Any the way forward is to just disable atomic from the kernel for X.org, because the legacy path actually works. We also have patches to disable atomic in -modesetting, but they're stuck. > > > I don't personally really like these rules, but if these are the rules, > > > then so be it. In my opinion it would be a huge step forward to get and > > > require uAPI specifications, that people could verify both kernel and > > > userspace against. Verifying against kernel code with no spec is what > > > leads to the -modesetting issue by the sounds of it. > > > > > > Documenting kernel internal interfaces is not it. People reading > > > DRM internal interface docs would need to know how DRM works internally > > > before they could map that information into uAPI, which makes it less > > > useful if not even useless for userspace developers. > > > > vgem is the idea here for validation, but if people ship atomic code > > that was never tested except for "boots on my laptop", then nothing is > > going to help. > > A testing pattern library with vkms would be awesome indeed. > > > And yes we have a huge gap with uapi documentation. btw for properties > > those section are meant to be useful for userspace people too: > > > > https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#standard-connector-properties > > > > and all subsequent chapters. I guess it's a bit burried, but this part > > is meant to be the uapi spec for properties. Is that also failing your > > expectations? > > Yes: it is hard to find (it is in Driver Developer's Guide, buried > several chapters in), it is interleaved with lots of DRM internal > details, makes references to DRM internal functions, and probably > relies on DRM internals behaviour through the references by not > repeating what they do. > > It is useful once you find it, but I don't think it's enough for making > good use in userspace for someone who hasn't been a DRM kernel > developer. Summarizing our long irc chat on this: I agree, everyone else agrees, but it's a question of making it happen and having someone with sufficient tech writer experience to make it useful. What we have now is essentially what happens if I type uapi specs (I pushed for these property docs). As you can see, it ain't pretty :-/ I think at least the process v4l has, where missing docs for uapi causes the doc build to fail, is sound. I have no idea how to adapt that to what we do, both from a "this will take a few years to fill the gaps and I don't know how to write good specs" and more implementation pov - properties can be created anywhere, no changes to include/uapi required. So hard to spot automatically. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] kernel.h: Add non_block_start/end()
In some special cases we must not block, but there's not a
spinlock, preempt-off, irqs-off or similar critical section already
that arms the might_sleep() debug checks. Add a non_block_start/end()
pair to annotate these.
This will be used in the oom paths of mmu-notifiers, where blocking is
not allowed to make sure there's forward progress. Quoting Michal:
"The notifier is called from quite a restricted context - oom_reaper -
which shouldn't depend on any locks or sleepable conditionals. The code
should be swift as well but we mostly do care about it to make a forward
progress. Checking for sleepable context is the best thing we could come
up with that would describe these demands at least partially."
Peter also asked whether we want to catch spinlocks on top, but Michal
said those are less of a problem because spinlocks can't have an
indirect dependency upon the page allocator and hence close the loop
with the oom reaper.
Suggested by Michal Hocko.
v2:
- Improve commit message (Michal)
- Also check in schedule, not just might_sleep (Peter)
v3: It works better when I actually squash in the fixup I had lying
around :-/
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Andrew Morton
Cc: Michal Hocko
Cc: David Rientjes
Cc: "Christian König"
Cc: Daniel Vetter
Cc: "Jérôme Glisse"
Cc: linux...@kvack.org
Cc: Masahiro Yamada
Cc: Wei Wang
Cc: Andy Shevchenko
Cc: Thomas Gleixner
Cc: Jann Horn
Cc: Feng Tang
Cc: Kees Cook
Cc: Randy Dunlap
Cc: linux-ker...@vger.kernel.org
Acked-by: Christian König (v1)
Signed-off-by: Daniel Vetter
---
include/linux/kernel.h | 10 +-
include/linux/sched.h | 4
kernel/sched/core.c| 19 ++-
3 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 74b1ee9027f5..b5f2c2ff0eab 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -214,7 +214,9 @@ extern void __cant_sleep(const char *file, int line, int
preempt_offset);
* might_sleep - annotation for functions that can sleep
*
* this macro will print a stack trace if it is executed in an atomic
- * context (spinlock, irq-handler, ...).
+ * context (spinlock, irq-handler, ...). Additional sections where blocking is
+ * not allowed can be annotated with non_block_start() and non_block_end()
+ * pairs.
*
* This is a useful debugging help to be able to catch problems early and not
* be bitten later when the calling function happens to sleep when it is not
@@ -230,6 +232,10 @@ extern void __cant_sleep(const char *file, int line, int
preempt_offset);
# define cant_sleep() \
do { __cant_sleep(__FILE__, __LINE__, 0); } while (0)
# define sched_annotate_sleep()(current->task_state_change = 0)
+# define non_block_start() \
+ do { current->non_block_count++; } while (0)
+# define non_block_end() \
+ do { WARN_ON(current->non_block_count-- == 0); } while (0)
#else
static inline void ___might_sleep(const char *file, int line,
int preempt_offset) { }
@@ -238,6 +244,8 @@ extern void __cant_sleep(const char *file, int line, int
preempt_offset);
# define might_sleep() do { might_resched(); } while (0)
# define cant_sleep() do { } while (0)
# define sched_annotate_sleep() do { } while (0)
+# define non_block_start() do { } while (0)
+# define non_block_end() do { } while (0)
#endif
#define might_sleep_if(cond) do { if (cond) might_sleep(); } while (0)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 11837410690f..7f5b293e72df 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -908,6 +908,10 @@ struct task_struct {
struct mutex_waiter *blocked_on;
#endif
+#ifdef CONFIG_DEBUG_ATOMIC_SLEEP
+ int non_block_count;
+#endif
+
#ifdef CONFIG_TRACE_IRQFLAGS
unsigned intirq_events;
unsigned long hardirq_enable_ip;
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 102dfcf0a29a..ed7755a28465 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3264,13 +3264,22 @@ static noinline void __schedule_bug(struct task_struct
*prev)
/*
* Various schedule()-time debugging checks and statistics:
*/
-static inline void schedule_debug(struct task_struct *prev)
+static inline void schedule_debug(struct task_struct *prev, bool preempt)
{
#ifdef CONFIG_SCHED_STACK_END_CHECK
if (task_stack_end_corrupted(prev))
panic("corrupted stack end detected inside scheduler\n");
#endif
+#ifdef CONFIG_DEBUG_ATOMIC_SLEEP
+ if (!preempt && prev->state && prev->non_block_count) {
+ printk(KERN_ERR "BUG: scheduling in a non-blocking section:
%s/%d/%i\n",
+ prev->comm, prev->pid, prev->non_block_count);
+ dump_stack();
+ add_taint(TAINT_WARN, LOCKDEP_STILL_OK);
+ }
+#endif
+
if (unlikely(in_atomic_preempt_off())) {
Re: [Intel-gfx] [PATCH v8 2/6] drm: Rename struct edp_vsc_psr to struct dp_sdp
Hello Jani,
On Tue, May 21, 2019 at 09:44:04AM +0300, Jani Nikula wrote:
> On Mon, 20 May 2019, Gwan-gyeong Mun wrote:
> > VSC SDP Payload for PSR is one of data block type of SDP (Secondaray Data
> > Packet). In order to generalize SDP packet structure name, it renames
> > struct edp_vsc_psr to struct dp_sdp. And each SDP data blocks have
> > different usages, each SDP type has different reserved data blocks and
> > Video_Stream_Configuration Extension VESA SDP might use all of Data Blocks
> > as Extended INFORFRAME Data Byte. so it makes Data Block variables as
> > array type. And it adds comments of details of DB of VSC SDP Payload
> > for Pixel Encoding/Colorimetry Format. This comments follows DP 1.4a spec,
> > section 2.2.5.7.5, chapter "VSC SDP Payload for Pixel Encoding/Colorimetry
> > Format".
> >
> > v7: Addressed review comments from Ville.
> >
> > Cc: Ville Syrjälä
> > Signed-off-by: Gwan-gyeong Mun
> > Reviewed-by: Maarten Lankhorst
>
> Andrzej, Laurent -
>
> Seven versions of the patch and looks like we've failed to loop you in
> on this. Sorry. May I have your ack on the patch please?
Please see below for one comment.
> Is it too much to ask to have this merged via drm-intel along with the
> rest of the series?
Provided the potential conflicts are handled I have no issue with that.
> > ---
> > .../drm/bridge/analogix/analogix_dp_core.c| 12 +++
> > .../drm/bridge/analogix/analogix_dp_core.h| 2 +-
> > .../gpu/drm/bridge/analogix/analogix_dp_reg.c | 10 +++---
> > drivers/gpu/drm/i915/intel_psr.c | 2 +-
> > include/drm/drm_dp_helper.h | 33 +--
> > 5 files changed, 36 insertions(+), 23 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > index 225f5e5dd69b..d1c2659d0cce 100644
> > --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > @@ -115,7 +115,7 @@ EXPORT_SYMBOL_GPL(analogix_dp_psr_enabled);
> >
> > int analogix_dp_enable_psr(struct analogix_dp_device *dp)
> > {
> > - struct edp_vsc_psr psr_vsc;
> > + struct dp_sdp psr_vsc;
> >
> > if (!dp->psr_enable)
> > return 0;
> > @@ -127,8 +127,8 @@ int analogix_dp_enable_psr(struct analogix_dp_device
> > *dp)
> > psr_vsc.sdp_header.HB2 = 0x2;
> > psr_vsc.sdp_header.HB3 = 0x8;
> >
> > - psr_vsc.DB0 = 0;
> > - psr_vsc.DB1 = EDP_VSC_PSR_STATE_ACTIVE | EDP_VSC_PSR_CRC_VALUES_VALID;
> > + psr_vsc.DB[0] = 0;
> > + psr_vsc.DB[1] = EDP_VSC_PSR_STATE_ACTIVE | EDP_VSC_PSR_CRC_VALUES_VALID;
> >
> > return analogix_dp_send_psr_spd(dp, &psr_vsc, true);
> > }
> > @@ -136,7 +136,7 @@ EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
> >
> > int analogix_dp_disable_psr(struct analogix_dp_device *dp)
> > {
> > - struct edp_vsc_psr psr_vsc;
> > + struct dp_sdp psr_vsc;
> > int ret;
> >
> > if (!dp->psr_enable)
> > @@ -149,8 +149,8 @@ int analogix_dp_disable_psr(struct analogix_dp_device
> > *dp)
> > psr_vsc.sdp_header.HB2 = 0x2;
> > psr_vsc.sdp_header.HB3 = 0x8;
> >
> > - psr_vsc.DB0 = 0;
> > - psr_vsc.DB1 = 0;
> > + psr_vsc.DB[0] = 0;
> > + psr_vsc.DB[1] = 0;
> >
> > ret = drm_dp_dpcd_writeb(&dp->aux, DP_SET_POWER, DP_SET_POWER_D0);
> > if (ret != 1) {
> > diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> > b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> > index 769255dc6e99..3e5fe90edf71 100644
> > --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> > +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> > @@ -254,7 +254,7 @@ void analogix_dp_enable_scrambling(struct
> > analogix_dp_device *dp);
> > void analogix_dp_disable_scrambling(struct analogix_dp_device *dp);
> > void analogix_dp_enable_psr_crc(struct analogix_dp_device *dp);
> > int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
> > -struct edp_vsc_psr *vsc, bool blocking);
> > +struct dp_sdp *vsc, bool blocking);
> > ssize_t analogix_dp_transfer(struct analogix_dp_device *dp,
> > struct drm_dp_aux_msg *msg);
> >
> > diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> > b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> > index a5f2763d72e4..f591810ef1be 100644
> > --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> > +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> > @@ -1041,7 +1041,7 @@ static ssize_t analogix_dp_get_psr_status(struct
> > analogix_dp_device *dp)
> > }
> >
> > int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
> > -struct edp_vsc_psr *vsc, bool blocking)
> > +struct dp_sdp *vsc, bool blocking)
> > {
> > unsigned int val;
> > int ret;
> > @@ -1069,8 +1069,8 @@ int analogix_dp_send_psr_spd(struct
> > analogix_dp_device *dp,
> > writel(0x
Re: [Intel-gfx] [PATCH] kernel.h: Add non_block_start/end()
On 2019/05/21 19:06, Daniel Vetter wrote:
> In some special cases we must not block, but there's not a
> spinlock, preempt-off, irqs-off or similar critical section already
> that arms the might_sleep() debug checks. Add a non_block_start/end()
> pair to annotate these.
>
> This will be used in the oom paths of mmu-notifiers, where blocking is
> not allowed to make sure there's forward progress. Quoting Michal:
>
> "The notifier is called from quite a restricted context - oom_reaper -
> which shouldn't depend on any locks or sleepable conditionals. The code
> should be swift as well but we mostly do care about it to make a forward
> progress. Checking for sleepable context is the best thing we could come
> up with that would describe these demands at least partially."
>
Can this be checked for OOM notifier as well?
if (!is_memcg_oom(oc)) {
+ non_block_start();
blocking_notifier_call_chain(&oom_notify_list, 0, &freed);
+ non_block_end();
if (freed > 0)
/* Got some memory back in the last second. */
return true;
}
It is not clear whether i915's oom_notifier function has such dependency.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] kernel.h: Add non_block_start/end()
On Tue 21-05-19 12:06:11, Daniel Vetter wrote:
> In some special cases we must not block, but there's not a
> spinlock, preempt-off, irqs-off or similar critical section already
> that arms the might_sleep() debug checks. Add a non_block_start/end()
> pair to annotate these.
>
> This will be used in the oom paths of mmu-notifiers, where blocking is
> not allowed to make sure there's forward progress. Quoting Michal:
>
> "The notifier is called from quite a restricted context - oom_reaper -
> which shouldn't depend on any locks or sleepable conditionals. The code
> should be swift as well but we mostly do care about it to make a forward
> progress. Checking for sleepable context is the best thing we could come
> up with that would describe these demands at least partially."
>
> Peter also asked whether we want to catch spinlocks on top, but Michal
> said those are less of a problem because spinlocks can't have an
> indirect dependency upon the page allocator and hence close the loop
> with the oom reaper.
>
> Suggested by Michal Hocko.
>
> v2:
> - Improve commit message (Michal)
> - Also check in schedule, not just might_sleep (Peter)
>
> v3: It works better when I actually squash in the fixup I had lying
> around :-/
>
> Cc: Peter Zijlstra
> Cc: Ingo Molnar
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: David Rientjes
> Cc: "Christian König"
> Cc: Daniel Vetter
> Cc: "Jérôme Glisse"
> Cc: linux...@kvack.org
> Cc: Masahiro Yamada
> Cc: Wei Wang
> Cc: Andy Shevchenko
> Cc: Thomas Gleixner
> Cc: Jann Horn
> Cc: Feng Tang
> Cc: Kees Cook
> Cc: Randy Dunlap
> Cc: linux-ker...@vger.kernel.org
> Acked-by: Christian König (v1)
> Signed-off-by: Daniel Vetter
I like this in general. The implementation looks reasonable to me but I
didn't check deeply enough to give my R-by or A-by.
> ---
> include/linux/kernel.h | 10 +-
> include/linux/sched.h | 4
> kernel/sched/core.c| 19 ++-
> 3 files changed, 27 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 74b1ee9027f5..b5f2c2ff0eab 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -214,7 +214,9 @@ extern void __cant_sleep(const char *file, int line, int
> preempt_offset);
> * might_sleep - annotation for functions that can sleep
> *
> * this macro will print a stack trace if it is executed in an atomic
> - * context (spinlock, irq-handler, ...).
> + * context (spinlock, irq-handler, ...). Additional sections where blocking
> is
> + * not allowed can be annotated with non_block_start() and non_block_end()
> + * pairs.
> *
> * This is a useful debugging help to be able to catch problems early and not
> * be bitten later when the calling function happens to sleep when it is not
> @@ -230,6 +232,10 @@ extern void __cant_sleep(const char *file, int line, int
> preempt_offset);
> # define cant_sleep() \
> do { __cant_sleep(__FILE__, __LINE__, 0); } while (0)
> # define sched_annotate_sleep() (current->task_state_change = 0)
> +# define non_block_start() \
> + do { current->non_block_count++; } while (0)
> +# define non_block_end() \
> + do { WARN_ON(current->non_block_count-- == 0); } while (0)
> #else
>static inline void ___might_sleep(const char *file, int line,
> int preempt_offset) { }
> @@ -238,6 +244,8 @@ extern void __cant_sleep(const char *file, int line, int
> preempt_offset);
> # define might_sleep() do { might_resched(); } while (0)
> # define cant_sleep() do { } while (0)
> # define sched_annotate_sleep() do { } while (0)
> +# define non_block_start() do { } while (0)
> +# define non_block_end() do { } while (0)
> #endif
>
> #define might_sleep_if(cond) do { if (cond) might_sleep(); } while (0)
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 11837410690f..7f5b293e72df 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -908,6 +908,10 @@ struct task_struct {
> struct mutex_waiter *blocked_on;
> #endif
>
> +#ifdef CONFIG_DEBUG_ATOMIC_SLEEP
> + int non_block_count;
> +#endif
> +
> #ifdef CONFIG_TRACE_IRQFLAGS
> unsigned intirq_events;
> unsigned long hardirq_enable_ip;
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 102dfcf0a29a..ed7755a28465 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -3264,13 +3264,22 @@ static noinline void __schedule_bug(struct
> task_struct *prev)
> /*
> * Various schedule()-time debugging checks and statistics:
> */
> -static inline void schedule_debug(struct task_struct *prev)
> +static inline void schedule_debug(struct task_struct *prev, bool preempt)
> {
> #ifdef CONFIG_SCHED_STACK_END_CHECK
> if (task_stack_end_corrupted(prev))
> panic("corrupted stack end detected inside scheduler\n");
> #endif
>
> +#ifdef CONFI
Re: [Intel-gfx] [PATCH] kernel.h: Add non_block_start/end()
On Tue 21-05-19 19:44:01, Tetsuo Handa wrote:
> On 2019/05/21 19:06, Daniel Vetter wrote:
> > In some special cases we must not block, but there's not a
> > spinlock, preempt-off, irqs-off or similar critical section already
> > that arms the might_sleep() debug checks. Add a non_block_start/end()
> > pair to annotate these.
> >
> > This will be used in the oom paths of mmu-notifiers, where blocking is
> > not allowed to make sure there's forward progress. Quoting Michal:
> >
> > "The notifier is called from quite a restricted context - oom_reaper -
> > which shouldn't depend on any locks or sleepable conditionals. The code
> > should be swift as well but we mostly do care about it to make a forward
> > progress. Checking for sleepable context is the best thing we could come
> > up with that would describe these demands at least partially."
> >
>
> Can this be checked for OOM notifier as well?
>
> if (!is_memcg_oom(oc)) {
> + non_block_start();
> blocking_notifier_call_chain(&oom_notify_list, 0, &freed);
> + non_block_end();
> if (freed > 0)
> /* Got some memory back in the last second. */
> return true;
> }
>
> It is not clear whether i915's oom_notifier function has such dependency.
It is not but then we should be using the non-blocking API if this is
a real problem. The above code just doesn't make any sense. We have a
blocking API called and wrapped by non-blocking one.
--
Michal Hocko
SUSE Labs
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 19/33] fbdev: unify unlink_framebufer paths
^Typo in subject.
Op 20-05-2019 om 10:22 schreef Daniel Vetter:
> For some reasons the pm_vt_switch_unregister call was missing from the
> direct unregister_framebuffer path. Fix this.
>
> v2: fbinfo->dev is used to decided whether unlink_framebuffer has been
> called already. I botched that in v1. Make this all clearer by
> inlining __unlink_framebuffer.
>
> Signed-off-by: Daniel Vetter
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Daniel Vetter
> Cc: "Michał Mirosław"
> Cc: Peter Rosin
> Cc: Hans de Goede
> Cc: Mikulas Patocka
> ---
> drivers/video/fbdev/core/fbmem.c | 47 ++--
> 1 file changed, 20 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbmem.c
> b/drivers/video/fbdev/core/fbmem.c
> index 032506576aa0..f059b0b1a030 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1714,15 +1714,30 @@ static void unbind_console(struct fb_info *fb_info)
> console_unlock();
> }
>
> -static void __unlink_framebuffer(struct fb_info *fb_info);
> -
> -static void do_unregister_framebuffer(struct fb_info *fb_info)
> +void unlink_framebuffer(struct fb_info *fb_info)
> {
> - unbind_console(fb_info);
> + int i;
> +
> + i = fb_info->node;
> + if (WARN_ON(i < 0 || i >= FB_MAX || registered_fb[i] != fb_info))
> + return;
> +
> + if (!fb_info->dev)
> + return;
> +
> + device_destroy(fb_class, MKDEV(FB_MAJOR, i));
>
> pm_vt_switch_unregister(fb_info->dev);
>
> - __unlink_framebuffer(fb_info);
> + unbind_console(fb_info);
> +
> + fb_info->dev = NULL;
> +}
> +EXPORT_SYMBOL(unlink_framebuffer);
> +
> +static void do_unregister_framebuffer(struct fb_info *fb_info)
> +{
> + unlink_framebuffer(fb_info);
> if (fb_info->pixmap.addr &&
> (fb_info->pixmap.flags & FB_PIXMAP_DEFAULT))
> kfree(fb_info->pixmap.addr);
> @@ -1738,28 +1753,6 @@ static void do_unregister_framebuffer(struct fb_info
> *fb_info)
> put_fb_info(fb_info);
> }
>
> -static void __unlink_framebuffer(struct fb_info *fb_info)
> -{
> - int i;
> -
> - i = fb_info->node;
> - if (WARN_ON(i < 0 || i >= FB_MAX || registered_fb[i] != fb_info))
> - return;
> -
> - if (fb_info->dev) {
> - device_destroy(fb_class, MKDEV(FB_MAJOR, i));
> - fb_info->dev = NULL;
> - }
> -}
> -
> -void unlink_framebuffer(struct fb_info *fb_info)
> -{
> - __unlink_framebuffer(fb_info);
> -
> - unbind_console(fb_info);
> -}
> -EXPORT_SYMBOL(unlink_framebuffer);
> -
> /**
> * remove_conflicting_framebuffers - remove firmware-configured framebuffers
> * @a: memory range, users of which are to be removed
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 29/33] fbcon: replace FB_EVENT_MODE_CHANGE/_ALL with direct calls
Op 20-05-2019 om 10:22 schreef Daniel Vetter:
> Create a new wrapper function for this, feels like there's some
> refactoring room here between the two modes.
>
> Signed-off-by: Daniel Vetter
> Cc: Lee Jones
> Cc: Daniel Thompson
> Cc: Jingoo Han
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Daniel Vetter
> Cc: Hans de Goede
> Cc: Yisheng Xie
> Cc: "Michał Mirosław"
> Cc: Peter Rosin
> Cc: Mikulas Patocka
> Cc: linux-fb...@vger.kernel.org
> ---
> drivers/video/backlight/lcd.c | 2 --
> drivers/video/fbdev/core/fbcon.c | 15 +--
> drivers/video/fbdev/core/fbmem.c | 13 ++---
> drivers/video/fbdev/sh_mobile_lcdcfb.c | 11 +--
> include/linux/fb.h | 4
> include/linux/fbcon.h | 2 ++
> 6 files changed, 14 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/video/backlight/lcd.c b/drivers/video/backlight/lcd.c
> index 4b40c6a4d441..16298041b141 100644
> --- a/drivers/video/backlight/lcd.c
> +++ b/drivers/video/backlight/lcd.c
> @@ -32,8 +32,6 @@ static int fb_notifier_callback(struct notifier_block *self,
> /* If we aren't interested in this event, skip it immediately ... */
> switch (event) {
> case FB_EVENT_BLANK:
> - case FB_EVENT_MODE_CHANGE:
> - case FB_EVENT_MODE_CHANGE_ALL:
> case FB_EARLY_EVENT_BLANK:
> case FB_R_EARLY_EVENT_BLANK:
> break;
Below it performs a call to set_mode() if it's none of the blanking events; it
can be removed. :)
> diff --git a/drivers/video/fbdev/core/fbcon.c
> b/drivers/video/fbdev/core/fbcon.c
> index c1a7476e980f..8cc62d340387 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -3005,6 +3005,15 @@ static void fbcon_set_all_vcs(struct fb_info *info)
> fbcon_modechanged(info);
> }
>
> +
> +void fbcon_update_vcs(struct fb_info *info, bool all)
> +{
> + if (all)
> + fbcon_set_all_vcs(info);
> + else
> + fbcon_modechanged(info);
> +}
> +
> int fbcon_mode_deleted(struct fb_info *info,
> struct fb_videomode *mode)
> {
> @@ -3314,12 +3323,6 @@ static int fbcon_event_notify(struct notifier_block
> *self,
> int idx, ret = 0;
>
> switch(action) {
> - case FB_EVENT_MODE_CHANGE:
> - fbcon_modechanged(info);
> - break;
> - case FB_EVENT_MODE_CHANGE_ALL:
> - fbcon_set_all_vcs(info);
> - break;
> case FB_EVENT_SET_CONSOLE_MAP:
> /* called with console lock held */
> con2fb = event->data;
> diff --git a/drivers/video/fbdev/core/fbmem.c
> b/drivers/video/fbdev/core/fbmem.c
> index cbd58ba8a59d..55b88163edc2 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1039,17 +1039,8 @@ fb_set_var(struct fb_info *info, struct
> fb_var_screeninfo *var)
> !list_empty(&info->modelist))
> ret = fb_add_videomode(&mode, &info->modelist);
>
> - if (!ret && (flags & FBINFO_MISC_USEREVENT)) {
> - struct fb_event event;
> - int evnt = (activate & FB_ACTIVATE_ALL) ?
> - FB_EVENT_MODE_CHANGE_ALL :
> - FB_EVENT_MODE_CHANGE;
> -
> - info->flags &= ~FBINFO_MISC_USEREVENT;
> - event.info = info;
> - event.data = &mode;
> - fb_notifier_call_chain(evnt, &event);
> - }
> + if (!ret && (flags & FBINFO_MISC_USEREVENT))
> + fbcon_update_vcs(info, activate & FB_ACTIVATE_ALL);
>
> return ret;
> }
> diff --git a/drivers/video/fbdev/sh_mobile_lcdcfb.c
> b/drivers/video/fbdev/sh_mobile_lcdcfb.c
> index 0d7a044852d7..bb1a610d0363 100644
> --- a/drivers/video/fbdev/sh_mobile_lcdcfb.c
> +++ b/drivers/video/fbdev/sh_mobile_lcdcfb.c
> @@ -1776,8 +1776,6 @@ static void sh_mobile_fb_reconfig(struct fb_info *info)
> struct sh_mobile_lcdc_chan *ch = info->par;
> struct fb_var_screeninfo var;
> struct fb_videomode mode;
> - struct fb_event event;
> - int evnt = FB_EVENT_MODE_CHANGE_ALL;
>
> if (ch->use_count > 1 || (ch->use_count == 1 && !info->fbcon_par))
> /* More framebuffer users are active */
> @@ -1799,14 +1797,7 @@ static void sh_mobile_fb_reconfig(struct fb_info *info)
> /* Couldn't reconfigure, hopefully, can continue as before */
> return;
>
> - /*
> - * fb_set_var() calls the notifier change internally, only if
> - * FBINFO_MISC_USEREVENT flag is set. Since we do not want to fake a
> - * user event, we have to call the chain ourselves.
> - */
> - event.info = info;
> - event.data = &ch->display.mode;
> - fb_notifier_call_chain(evnt, &event);
> + fbcon_update_vcs(info, true);
> }
>
> /*
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index 4b9b882f8f52..54d6bee09121 100644
> --- a/include/linux/fb.h
> +++ b/include/li
Re: [Intel-gfx] [PATCH v2] drm/i915/huc: Don't try to check HuC status if it's not loaded
There are two users of I915_PARAM_HUC_STATUS, the intel-media driver and
the legacy intel-vaapi-driver.
Both drivers check the return value like this:
has_huc = !! ret_value;
So the ABI change will break the existing stack because negative values
are treated as 1, won't it?
On 5/20/2019 8:16 PM, Michal Wajdeczko wrote:
On Mon, 20 May 2019 12:44:43 +0200, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2019-05-20 11:24:37)
On Mon, 20 May 2019 11:35:26 +0200, Chris Wilson
wrote:
> Quoting Michal Wajdeczko (2019-05-19 22:50:43)
>> If we never attempted to load HuC firmware, or we already wedged
>> or reset GuC/HuC, then there is no reason to wake up the device
>> to check one bit in the register that will be for sure cleared.
>>
>> v2: check if HuC was enabled; subtle change in ABI
>> reuse hus_is_load helper
>>
>> Suggested-by: Chris Wilson
>> Signed-off-by: Michal Wajdeczko
>> Cc: Chris Wilson
>> Cc: Tony Ye
>> ---
>> drivers/gpu/drm/i915/intel_huc.c | 20
>> drivers/gpu/drm/i915/intel_huc.h | 5 +
>> 2 files changed, 17 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_huc.c
>> b/drivers/gpu/drm/i915/intel_huc.c
>> index 1ff1fb015e58..bfdebec1cfc8 100644
>> --- a/drivers/gpu/drm/i915/intel_huc.c
>> +++ b/drivers/gpu/drm/i915/intel_huc.c
>> @@ -113,7 +113,7 @@ int intel_huc_auth(struct intel_huc *huc)
>> u32 status;
>> int ret;
>>
>> - if (huc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
>> + if (!intel_huc_is_loaded(huc))
>> return -ENOEXEC;
>>
>> ret = intel_guc_auth_huc(guc,
>> @@ -150,21 +150,25 @@ int intel_huc_auth(struct intel_huc *huc)
>> * This function reads status register to verify if HuC
>> * firmware was successfully loaded.
>> *
>> - * Returns: 1 if HuC firmware is loaded and verified,
>> - * 0 if HuC firmware is not loaded and -ENODEV if HuC
>> - * is not present on this platform.
>> + * Returns: 1 if HuC firmware is loaded and verified, 0 if HuC
>> firmware is not
>> + * enabled, -ENOPKG if HuC firmware is not loaded and -ENODEV if
HuC
>> is not
>> + * present on this platform.
>> */
>> int intel_huc_check_status(struct intel_huc *huc)
>> {
>> struct drm_i915_private *dev_priv = huc_to_i915(huc);
>> intel_wakeref_t wakeref;
>> - bool status = false;
>> + bool verified = false;
>>
>> if (!HAS_HUC(dev_priv))
>> return -ENODEV;
>>
>> - with_intel_runtime_pm(dev_priv, wakeref)
>> - status = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
>> + if (!USES_HUC(dev_priv))
>> + return 0;
>
> Hmm, EOPNOTSUPP here for the user disabled case?
I'm not sure that user disabled case shall be reported as error,
since it perfectly fits into legacy ABI 0="not loaded".
The only small change is that now 0="not loaded (not enabled by user)"
The only requirement for the intel-media driver seems to "HUC_STATUS
> 0".
That's our only user, so I think we have the liberty to redefine <=0 as
befits error reporting.
>
> Then
>
> if (!intel_huc_is_loaded(huc))
> return -ENOPKG;
>
> bool verified = false;
> with_intel_runtime_pm(dev_priv, wakeref)
> verified = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
> return verified.
>
> That keeps it a bit flatter with the special casing separate and
the 0/1
> result as given by the register status. Then if negative, we know
one of
> the preconditions for using HuC is not available, and if 0
something went
> wrong in mmio setup.
>
> Does that make sense?
IMHO, if something went wrong it is better to report it as error rather
then weak 0 status. Compare:
I disagree, <0 is the weak case. 0 is the HW reports something went
wrong (and only that). 1 is the HW reports all went well.
But I was assuming that we're defining ABI here, not simply exposing
unified
register value. Since we want 1 to report all ok, and we can fail for
many
reasons (no hw, no fw blob, wrong fw, bad signature, ...) we should at
least
try to match all these failures into error code (today just ENOPKG,
but later
we can extend into ENOEXEC=bad fw, ENOSPC=can't fit into WOPCM, ...).
On other hand, at least for me, user decision to disable HuC should not
be treated the same way as other real failures, so 0 seems like
perfect match.
Then we'll have: 1 = enabled, 0 = disabled, <0 = problem
If we have more ways we can report the HW went wrong, sure expand that
into extra error codes, but I don't see that. And if it's in the regs,
why are not exporting them via reg_read_ioctl?
+---+---+---+---+
no hardware -ENODEV -ENODEV -ENODEV
fw disabled 0 0 -ENOTSUP
fw not loaded 0 -ENOPKG -ENOPKG
fw not verified* 0 -ENOPKG 0
fw verified* 1 1 1
+---+---+---+---+
*) registry access
Note that in your case, fw verification problem can be reported both
as -ENOPKG
Re: [Intel-gfx] [PATCH] kernel.h: Add non_block_start/end()
On 2019/05/21 19:51, Michal Hocko wrote:
> On Tue 21-05-19 19:44:01, Tetsuo Handa wrote:
>> On 2019/05/21 19:06, Daniel Vetter wrote:
>>> In some special cases we must not block, but there's not a
>>> spinlock, preempt-off, irqs-off or similar critical section already
>>> that arms the might_sleep() debug checks. Add a non_block_start/end()
>>> pair to annotate these.
>>>
>>> This will be used in the oom paths of mmu-notifiers, where blocking is
>>> not allowed to make sure there's forward progress. Quoting Michal:
>>>
>>> "The notifier is called from quite a restricted context - oom_reaper -
>>> which shouldn't depend on any locks or sleepable conditionals. The code
>>> should be swift as well but we mostly do care about it to make a forward
>>> progress. Checking for sleepable context is the best thing we could come
>>> up with that would describe these demands at least partially."
>>>
>>
>> Can this be checked for OOM notifier as well?
>>
>> if (!is_memcg_oom(oc)) {
>> +non_block_start();
>> blocking_notifier_call_chain(&oom_notify_list, 0, &freed);
>> +non_block_end();
>> if (freed > 0)
>> /* Got some memory back in the last second. */
>> return true;
>> }
>>
>> It is not clear whether i915's oom_notifier function has such dependency.
>
> It is not but then we should be using the non-blocking API if this is
> a real problem. The above code just doesn't make any sense. We have a
> blocking API called and wrapped by non-blocking one.
OOM notifiers should not depend on any locks or sleepable conditionals.
If some lock directly or indirectly depended on __GFP_DIRECT_RECLAIM,
it will deadlock. Thus, despite blocking API, this should effectively be
non-blocking. All OOM notifier users except i915 seems to be atomic, but
I can't evaluate i915 part...
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/huc: Don't try to check HuC status if it's not loaded
On Tue, 21 May 2019 13:04:12 +0200, Ye, Tony wrote:
There are two users of I915_PARAM_HUC_STATUS, the intel-media driver and
the legacy intel-vaapi-driver.
Both drivers check the return value like this:
has_huc = !! ret_value;
So the ABI change will break the existing stack because negative values
are treated as 1, won't it?
No, since negative errors returned by i915 intel_huc_check_status()
function
will be only used to indicate ioctl() call failure and then stored in
errno.
Note that your "ret_value" will be modified only when ioctl is successful.
Michal
On 5/20/2019 8:16 PM, Michal Wajdeczko wrote:
On Mon, 20 May 2019 12:44:43 +0200, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2019-05-20 11:24:37)
On Mon, 20 May 2019 11:35:26 +0200, Chris Wilson
wrote:
> Quoting Michal Wajdeczko (2019-05-19 22:50:43)
>> If we never attempted to load HuC firmware, or we already wedged
>> or reset GuC/HuC, then there is no reason to wake up the device
>> to check one bit in the register that will be for sure cleared.
>>
>> v2: check if HuC was enabled; subtle change in ABI
>> reuse hus_is_load helper
>>
>> Suggested-by: Chris Wilson
>> Signed-off-by: Michal Wajdeczko
>> Cc: Chris Wilson
>> Cc: Tony Ye
>> ---
>> drivers/gpu/drm/i915/intel_huc.c | 20
>> drivers/gpu/drm/i915/intel_huc.h | 5 +
>> 2 files changed, 17 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_huc.c
>> b/drivers/gpu/drm/i915/intel_huc.c
>> index 1ff1fb015e58..bfdebec1cfc8 100644
>> --- a/drivers/gpu/drm/i915/intel_huc.c
>> +++ b/drivers/gpu/drm/i915/intel_huc.c
>> @@ -113,7 +113,7 @@ int intel_huc_auth(struct intel_huc *huc)
>> u32 status;
>> int ret;
>>
>> - if (huc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
>> + if (!intel_huc_is_loaded(huc))
>> return -ENOEXEC;
>>
>> ret = intel_guc_auth_huc(guc,
>> @@ -150,21 +150,25 @@ int intel_huc_auth(struct intel_huc *huc)
>> * This function reads status register to verify if HuC
>> * firmware was successfully loaded.
>> *
>> - * Returns: 1 if HuC firmware is loaded and verified,
>> - * 0 if HuC firmware is not loaded and -ENODEV if HuC
>> - * is not present on this platform.
>> + * Returns: 1 if HuC firmware is loaded and verified, 0 if HuC
>> firmware is not
>> + * enabled, -ENOPKG if HuC firmware is not loaded and -ENODEV if
HuC
>> is not
>> + * present on this platform.
>> */
>> int intel_huc_check_status(struct intel_huc *huc)
>> {
>> struct drm_i915_private *dev_priv = huc_to_i915(huc);
>> intel_wakeref_t wakeref;
>> - bool status = false;
>> + bool verified = false;
>>
>> if (!HAS_HUC(dev_priv))
>> return -ENODEV;
>>
>> - with_intel_runtime_pm(dev_priv, wakeref)
>> - status = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
>> + if (!USES_HUC(dev_priv))
>> + return 0;
>
> Hmm, EOPNOTSUPP here for the user disabled case?
I'm not sure that user disabled case shall be reported as error,
since it perfectly fits into legacy ABI 0="not loaded".
The only small change is that now 0="not loaded (not enabled by user)"
The only requirement for the intel-media driver seems to "HUC_STATUS >
0".
That's our only user, so I think we have the liberty to redefine <=0 as
befits error reporting.
>
> Then
>
> if (!intel_huc_is_loaded(huc))
> return -ENOPKG;
>
> bool verified = false;
> with_intel_runtime_pm(dev_priv, wakeref)
> verified = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
> return verified.
>
> That keeps it a bit flatter with the special casing separate and
the 0/1
> result as given by the register status. Then if negative, we know
one of
> the preconditions for using HuC is not available, and if 0
something went
> wrong in mmio setup.
>
> Does that make sense?
IMHO, if something went wrong it is better to report it as error
rather
then weak 0 status. Compare:
I disagree, <0 is the weak case. 0 is the HW reports something went
wrong (and only that). 1 is the HW reports all went well.
But I was assuming that we're defining ABI here, not simply exposing
unified
register value. Since we want 1 to report all ok, and we can fail for
many
reasons (no hw, no fw blob, wrong fw, bad signature, ...) we should at
least
try to match all these failures into error code (today just ENOPKG, but
later
we can extend into ENOEXEC=bad fw, ENOSPC=can't fit into WOPCM, ...).
On other hand, at least for me, user decision to disable HuC should not
be treated the same way as other real failures, so 0 seems like perfect
match.
Then we'll have: 1 = enabled, 0 = disabled, <0 = problem
If we have more ways we can report the HW went wrong, sure expand that
into extra error codes, but I don't see that. And if it's in the regs,
why are not exporting them via reg_read_ioctl?
+---+---+---+---+
no hardware -ENODEV -EN
Re: [Intel-gfx] [PATCH] kernel.h: Add non_block_start/end()
On Tue 21-05-19 20:04:34, Tetsuo Handa wrote:
> On 2019/05/21 19:51, Michal Hocko wrote:
> > On Tue 21-05-19 19:44:01, Tetsuo Handa wrote:
> >> On 2019/05/21 19:06, Daniel Vetter wrote:
> >>> In some special cases we must not block, but there's not a
> >>> spinlock, preempt-off, irqs-off or similar critical section already
> >>> that arms the might_sleep() debug checks. Add a non_block_start/end()
> >>> pair to annotate these.
> >>>
> >>> This will be used in the oom paths of mmu-notifiers, where blocking is
> >>> not allowed to make sure there's forward progress. Quoting Michal:
> >>>
> >>> "The notifier is called from quite a restricted context - oom_reaper -
> >>> which shouldn't depend on any locks or sleepable conditionals. The code
> >>> should be swift as well but we mostly do care about it to make a forward
> >>> progress. Checking for sleepable context is the best thing we could come
> >>> up with that would describe these demands at least partially."
> >>>
> >>
> >> Can this be checked for OOM notifier as well?
> >>
> >>if (!is_memcg_oom(oc)) {
> >> + non_block_start();
> >>blocking_notifier_call_chain(&oom_notify_list, 0, &freed);
> >> + non_block_end();
> >>if (freed > 0)
> >>/* Got some memory back in the last second. */
> >>return true;
> >>}
> >>
> >> It is not clear whether i915's oom_notifier function has such dependency.
> >
> > It is not but then we should be using the non-blocking API if this is
> > a real problem. The above code just doesn't make any sense. We have a
> > blocking API called and wrapped by non-blocking one.
>
> OOM notifiers should not depend on any locks or sleepable conditionals.
> If some lock directly or indirectly depended on __GFP_DIRECT_RECLAIM,
> it will deadlock. Thus, despite blocking API, this should effectively be
> non-blocking. All OOM notifier users except i915 seems to be atomic, but
> I can't evaluate i915 part...
Read again what I've written, please
--
Michal Hocko
SUSE Labs
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 32/33] fbcon: Document what I learned about fbcon locking
Op 20-05-2019 om 10:22 schreef Daniel Vetter:
> It's not pretty.
>
> Signed-off-by: Daniel Vetter
> Cc: Daniel Vetter
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Hans de Goede
> Cc: Yisheng Xie
> ---
> drivers/video/fbdev/core/fbcon.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c
> b/drivers/video/fbdev/core/fbcon.c
> index b40b56702c61..cbbcf7a795f2 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -87,6 +87,25 @@
> # define DPRINTK(fmt, args...)
> #endif
>
> +/*
> + * FIXME: Locking
> + *
> + * - fbcon state itself is protected by the console_lock, and the code does a
> + * pretty good job at making sure that lock is held everywhere it's needed.
> + *
> + * - access to the registered_fb array is entirely unprotected. This should
> use
> + * proper object lifetime handling, i.e. get/put_fb_info. This also means
> + * switching from indices to proper pointers for fb_info everywhere.
> + *
> + * - fbcon doesn't bother with fb_lock/unlock at all. This is buggy, since it
> + * means concurrent access to the same fbdev from both fbcon and userspace
> + * will blow up. To fix this all fbcon calls from fbmem.c need to be moved
> out
> + * of fb_lock/unlock protected sections, since otherwise we'll recurse and
> + * deadlock eventually. Aside: Due to these deadlock issues the fbdev code
> in
> + * fbmem.c cannot use locking asserts, and there's lots of callers which
> get
> + * the rules wrong, e.g. fbsysfs.c entirely missed fb_lock/unlock calls
> too.
> + */
> +
> enum {
> FBCON_LOGO_CANSHOW = -1, /* the logo can be shown */
> FBCON_LOGO_DRAW = -2, /* draw the logo to a console */
I did a casual review, so for whole series with the small nitpicks I had, and
any feedback by others, kbuild and the arm mess being fixed up:
Reviewed-by: Maarten Lankhorst
However, according to reviewer's statement of oversight:
While I have reviewed the patch and believe it to be sound, I do not (unless
explicitly stated elsewhere)
make any warranties or guarantees that it will achieve its stated purpose or
function properly in any given situation.
:)
~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] kernel.h: Add non_block_start/end()
On 2019/05/21 20:11, Michal Hocko wrote:
> On Tue 21-05-19 20:04:34, Tetsuo Handa wrote:
>> On 2019/05/21 19:51, Michal Hocko wrote:
>>> On Tue 21-05-19 19:44:01, Tetsuo Handa wrote:
On 2019/05/21 19:06, Daniel Vetter wrote:
> In some special cases we must not block, but there's not a
> spinlock, preempt-off, irqs-off or similar critical section already
> that arms the might_sleep() debug checks. Add a non_block_start/end()
> pair to annotate these.
>
> This will be used in the oom paths of mmu-notifiers, where blocking is
> not allowed to make sure there's forward progress. Quoting Michal:
>
> "The notifier is called from quite a restricted context - oom_reaper -
> which shouldn't depend on any locks or sleepable conditionals. The code
> should be swift as well but we mostly do care about it to make a forward
> progress. Checking for sleepable context is the best thing we could come
> up with that would describe these demands at least partially."
>
Can this be checked for OOM notifier as well?
if (!is_memcg_oom(oc)) {
+ non_block_start();
blocking_notifier_call_chain(&oom_notify_list, 0, &freed);
+ non_block_end();
if (freed > 0)
/* Got some memory back in the last second. */
return true;
}
It is not clear whether i915's oom_notifier function has such dependency.
>>>
>>> It is not but then we should be using the non-blocking API if this is
>>> a real problem. The above code just doesn't make any sense. We have a
>>> blocking API called and wrapped by non-blocking one.
>>
>> OOM notifiers should not depend on any locks or sleepable conditionals.
>> If some lock directly or indirectly depended on __GFP_DIRECT_RECLAIM,
>> it will deadlock. Thus, despite blocking API, this should effectively be
>> non-blocking. All OOM notifier users except i915 seems to be atomic, but
>> I can't evaluate i915 part...
>
> Read again what I've written, please
>
Question to Daniel: Is i915's oom_notifier function atomic?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: add i2c symlink under hdmi connector (rev2)
== Series Details ==
Series: drm/i915: add i2c symlink under hdmi connector (rev2)
URL : https://patchwork.freedesktop.org/series/60866/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6110 -> Patchwork_13053
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13053/
Known issues
Here are the changes found in Patchwork_13053 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_contexts:
- fi-bdw-gvtdvm: [PASS][1] -> [DMESG-FAIL][2] ([fdo#110235])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6110/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13053/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
* igt@i915_selftest@live_hangcheck:
- fi-skl-iommu: [PASS][3] -> [INCOMPLETE][4] ([fdo#108602] /
[fdo#108744])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6110/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13053/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
Possible fixes
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][5] ([fdo#109485]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6110/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13053/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602
[fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
[fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
[fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235
Participating hosts (49 -> 43)
--
Additional (2): fi-icl-u2 fi-gdg-551
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-apl-guc fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6110 -> Patchwork_13053
CI_DRM_6110: ae35264eb9f700d5f9856552bf98e20ec2b74739 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4999: eee6e9ea7a7e22a64afc029a696b80da8053bc3c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13053: 48df4de334a009d498d729bfc014be1f0c94f77f @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
48df4de334a0 drm/i915: add i2c symlink under hdmi connector
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13053/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Allow modeset on unregisted connectors unconditionally (rev2)
== Series Details == Series: drm: Allow modeset on unregisted connectors unconditionally (rev2) URL : https://patchwork.freedesktop.org/series/60871/ State : success == Summary == CI Bug Log - changes from CI_DRM_6110 -> Patchwork_13054 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13054/ Known issues Here are the changes found in Patchwork_13054 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@read_all_entries: - fi-ilk-650: [PASS][1] -> [DMESG-WARN][2] ([fdo#106387]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6110/fi-ilk-650/igt@debugfs_test@read_all_entries.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13054/fi-ilk-650/igt@debugfs_test@read_all_entries.html Possible fixes * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [FAIL][3] ([fdo#109485]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6110/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13054/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html Warnings * igt@i915_selftest@live_hangcheck: - fi-apl-guc: [DMESG-FAIL][5] ([fdo#110620]) -> [FAIL][6] ([fdo#110623]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6110/fi-apl-guc/igt@i915_selftest@live_hangcheck.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13054/fi-apl-guc/igt@i915_selftest@live_hangcheck.html [fdo#106387]: https://bugs.freedesktop.org/show_bug.cgi?id=106387 [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485 [fdo#110620]: https://bugs.freedesktop.org/show_bug.cgi?id=110620 [fdo#110623]: https://bugs.freedesktop.org/show_bug.cgi?id=110623 Participating hosts (49 -> 43) -- Additional (2): fi-icl-u2 fi-gdg-551 Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-pnv-d510 fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_6110 -> Patchwork_13054 CI_DRM_6110: ae35264eb9f700d5f9856552bf98e20ec2b74739 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4999: eee6e9ea7a7e22a64afc029a696b80da8053bc3c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_13054: 949e61ed7490fb4da9dd29729084af60a1174d4d @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 949e61ed7490 drm: Allow modeset on unregisted connectors unconditionally == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13054/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 2/6] drm: Rename struct edp_vsc_psr to struct dp_sdp
On Tue, 2019-05-21 at 13:14 +0300, Laurent Pinchart wrote:
> Hello Jani,
>
> On Tue, May 21, 2019 at 09:44:04AM +0300, Jani Nikula wrote:
> > On Mon, 20 May 2019, Gwan-gyeong Mun
> > wrote:
> > > VSC SDP Payload for PSR is one of data block type of SDP
> > > (Secondaray Data
> > > Packet). In order to generalize SDP packet structure name, it
> > > renames
> > > struct edp_vsc_psr to struct dp_sdp. And each SDP data blocks
> > > have
> > > different usages, each SDP type has different reserved data
> > > blocks and
> > > Video_Stream_Configuration Extension VESA SDP might use all of
> > > Data Blocks
> > > as Extended INFORFRAME Data Byte. so it makes Data Block
> > > variables as
> > > array type. And it adds comments of details of DB of VSC SDP
> > > Payload
> > > for Pixel Encoding/Colorimetry Format. This comments follows DP
> > > 1.4a spec,
> > > section 2.2.5.7.5, chapter "VSC SDP Payload for Pixel
> > > Encoding/Colorimetry
> > > Format".
> > >
> > > v7: Addressed review comments from Ville.
> > >
> > > Cc: Ville Syrjälä
> > > Signed-off-by: Gwan-gyeong Mun
> > > Reviewed-by: Maarten Lankhorst > > >
> >
> > Andrzej, Laurent -
> >
> > Seven versions of the patch and looks like we've failed to loop you
> > in
> > on this. Sorry. May I have your ack on the patch please?
>
> Please see below for one comment.
>
> > Is it too much to ask to have this merged via drm-intel along with
> > the
> > rest of the series?
>
> Provided the potential conflicts are handled I have no issue with
> that.
>
Andrzej, Laurent -
I am Sorry that I missed you on previous loops.
And thank you for reviewing the series.
Jani,
Thank you for asking the series to Andrzej and Laurent.
> > > ---
> > > .../drm/bridge/analogix/analogix_dp_core.c| 12 +++
> > > .../drm/bridge/analogix/analogix_dp_core.h| 2 +-
> > > .../gpu/drm/bridge/analogix/analogix_dp_reg.c | 10 +++---
> > > drivers/gpu/drm/i915/intel_psr.c | 2 +-
> > > include/drm/drm_dp_helper.h | 33
> > > +--
> > > 5 files changed, 36 insertions(+), 23 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > > b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > > index 225f5e5dd69b..d1c2659d0cce 100644
> > > --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > > +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > > @@ -115,7 +115,7 @@ EXPORT_SYMBOL_GPL(analogix_dp_psr_enabled);
> > >
> > > int analogix_dp_enable_psr(struct analogix_dp_device *dp)
> > > {
> > > - struct edp_vsc_psr psr_vsc;
> > > + struct dp_sdp psr_vsc;
> > >
> > > if (!dp->psr_enable)
> > > return 0;
> > > @@ -127,8 +127,8 @@ int analogix_dp_enable_psr(struct
> > > analogix_dp_device *dp)
> > > psr_vsc.sdp_header.HB2 = 0x2;
> > > psr_vsc.sdp_header.HB3 = 0x8;
> > >
> > > - psr_vsc.DB0 = 0;
> > > - psr_vsc.DB1 = EDP_VSC_PSR_STATE_ACTIVE |
> > > EDP_VSC_PSR_CRC_VALUES_VALID;
> > > + psr_vsc.DB[0] = 0;
> > > + psr_vsc.DB[1] = EDP_VSC_PSR_STATE_ACTIVE |
> > > EDP_VSC_PSR_CRC_VALUES_VALID;
> > >
> > > return analogix_dp_send_psr_spd(dp, &psr_vsc, true);
> > > }
> > > @@ -136,7 +136,7 @@ EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
> > >
> > > int analogix_dp_disable_psr(struct analogix_dp_device *dp)
> > > {
> > > - struct edp_vsc_psr psr_vsc;
> > > + struct dp_sdp psr_vsc;
> > > int ret;
> > >
> > > if (!dp->psr_enable)
> > > @@ -149,8 +149,8 @@ int analogix_dp_disable_psr(struct
> > > analogix_dp_device *dp)
> > > psr_vsc.sdp_header.HB2 = 0x2;
> > > psr_vsc.sdp_header.HB3 = 0x8;
> > >
> > > - psr_vsc.DB0 = 0;
> > > - psr_vsc.DB1 = 0;
> > > + psr_vsc.DB[0] = 0;
> > > + psr_vsc.DB[1] = 0;
> > >
> > > ret = drm_dp_dpcd_writeb(&dp->aux, DP_SET_POWER,
> > > DP_SET_POWER_D0);
> > > if (ret != 1) {
> > > diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> > > b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> > > index 769255dc6e99..3e5fe90edf71 100644
> > > --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> > > +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> > > @@ -254,7 +254,7 @@ void analogix_dp_enable_scrambling(struct
> > > analogix_dp_device *dp);
> > > void analogix_dp_disable_scrambling(struct analogix_dp_device
> > > *dp);
> > > void analogix_dp_enable_psr_crc(struct analogix_dp_device *dp);
> > > int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
> > > - struct edp_vsc_psr *vsc, bool blocking);
> > > + struct dp_sdp *vsc, bool blocking);
> > > ssize_t analogix_dp_transfer(struct analogix_dp_device *dp,
> > >struct drm_dp_aux_msg *msg);
> > >
> > > diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> > > b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> > > index a5f2763d72e4..f591810ef1be 100644
> > > --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> > > +++ b/drivers/gpu/drm/bridge/analo
[Intel-gfx] [PATCH v9 2/6] drm: Rename struct edp_vsc_psr to struct dp_sdp
VSC SDP Payload for PSR is one of data block type of SDP (Secondaray Data
Packet). In order to generalize SDP packet structure name, it renames
struct edp_vsc_psr to struct dp_sdp. And each SDP data blocks have
different usages, each SDP type has different reserved data blocks and
Video_Stream_Configuration Extension VESA SDP might use all of Data Blocks
as Extended INFORFRAME Data Byte. so it makes Data Block variables as
array type. And it adds comments of details of DB of VSC SDP Payload
for Pixel Encoding/Colorimetry Format. This comments follows DP 1.4a spec,
section 2.2.5.7.5, chapter "VSC SDP Payload for Pixel Encoding/Colorimetry
Format".
v7: Addressed review comments from Ville.
v9: Rename a member value name DB to db on struct dp_sdp [Laurent]
Cc: Ville Syrjälä
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Maarten Lankhorst
Acked-by: Laurent Pinchart
---
.../drm/bridge/analogix/analogix_dp_core.c| 12 +++
.../drm/bridge/analogix/analogix_dp_core.h| 2 +-
.../gpu/drm/bridge/analogix/analogix_dp_reg.c | 10 +++---
drivers/gpu/drm/i915/intel_psr.c | 2 +-
include/drm/drm_dp_helper.h | 33 +--
5 files changed, 36 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 225f5e5dd69b..257d69b21d99 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -115,7 +115,7 @@ EXPORT_SYMBOL_GPL(analogix_dp_psr_enabled);
int analogix_dp_enable_psr(struct analogix_dp_device *dp)
{
- struct edp_vsc_psr psr_vsc;
+ struct dp_sdp psr_vsc;
if (!dp->psr_enable)
return 0;
@@ -127,8 +127,8 @@ int analogix_dp_enable_psr(struct analogix_dp_device *dp)
psr_vsc.sdp_header.HB2 = 0x2;
psr_vsc.sdp_header.HB3 = 0x8;
- psr_vsc.DB0 = 0;
- psr_vsc.DB1 = EDP_VSC_PSR_STATE_ACTIVE | EDP_VSC_PSR_CRC_VALUES_VALID;
+ psr_vsc.db[0] = 0;
+ psr_vsc.db[1] = EDP_VSC_PSR_STATE_ACTIVE | EDP_VSC_PSR_CRC_VALUES_VALID;
return analogix_dp_send_psr_spd(dp, &psr_vsc, true);
}
@@ -136,7 +136,7 @@ EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
int analogix_dp_disable_psr(struct analogix_dp_device *dp)
{
- struct edp_vsc_psr psr_vsc;
+ struct dp_sdp psr_vsc;
int ret;
if (!dp->psr_enable)
@@ -149,8 +149,8 @@ int analogix_dp_disable_psr(struct analogix_dp_device *dp)
psr_vsc.sdp_header.HB2 = 0x2;
psr_vsc.sdp_header.HB3 = 0x8;
- psr_vsc.DB0 = 0;
- psr_vsc.DB1 = 0;
+ psr_vsc.db[0] = 0;
+ psr_vsc.db[1] = 0;
ret = drm_dp_dpcd_writeb(&dp->aux, DP_SET_POWER, DP_SET_POWER_D0);
if (ret != 1) {
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 769255dc6e99..3e5fe90edf71 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -254,7 +254,7 @@ void analogix_dp_enable_scrambling(struct
analogix_dp_device *dp);
void analogix_dp_disable_scrambling(struct analogix_dp_device *dp);
void analogix_dp_enable_psr_crc(struct analogix_dp_device *dp);
int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
-struct edp_vsc_psr *vsc, bool blocking);
+struct dp_sdp *vsc, bool blocking);
ssize_t analogix_dp_transfer(struct analogix_dp_device *dp,
struct drm_dp_aux_msg *msg);
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index a5f2763d72e4..cf17e2e21b15 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -1041,7 +1041,7 @@ static ssize_t analogix_dp_get_psr_status(struct
analogix_dp_device *dp)
}
int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
-struct edp_vsc_psr *vsc, bool blocking)
+struct dp_sdp *vsc, bool blocking)
{
unsigned int val;
int ret;
@@ -1069,8 +1069,8 @@ int analogix_dp_send_psr_spd(struct analogix_dp_device
*dp,
writel(0x5D, dp->reg_base + ANALOGIX_DP_SPD_PB3);
/* configure DB0 / DB1 values */
- writel(vsc->DB0, dp->reg_base + ANALOGIX_DP_VSC_SHADOW_DB0);
- writel(vsc->DB1, dp->reg_base + ANALOGIX_DP_VSC_SHADOW_DB1);
+ writel(vsc->db[0], dp->reg_base + ANALOGIX_DP_VSC_SHADOW_DB0);
+ writel(vsc->db[1], dp->reg_base + ANALOGIX_DP_VSC_SHADOW_DB1);
/* set reuse spd inforframe */
val = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_3);
@@ -1092,8 +1092,8 @@ int analogix_dp_send_psr_spd(struct analogix_dp_device
*dp,
ret = readx_poll_timeout(analogix_dp_get_psr_status, dp, psr_status,
psr_status >= 0 &&
- (
[Intel-gfx] [PATCH v9 5/6] drm/i915/dp: Change a link bandwidth computation for DP
Data M/N calculations were assumed a bpp as RGB format. But when we are
using YCbCr 4:2:0 output format on DP, we should change bpp calculations
as YCbCr 4:2:0 format. The pipe_bpp value was assumed RGB format,
therefore, it was multiplied with 3. But YCbCr 4:2:0 requires a multiplier
value to 1.5.
Therefore we need to divide pipe_bpp to 2 while DP output uses YCbCr4:2:0
format.
- RGB format bpp = bpc x 3
- YCbCr 4:2:0 format bpp = bpc x 1.5
But Link M/N values are calculated and applied based on the Full Clock for
YCbCr 4:2:0. And DP YCbCr 4:2:0 does not need to pixel clock double for
a dotclock caluation. Only for HDMI YCbCr 4:2:0 needs to pixel clock double
for a dot clock calculation.
It only affects dp and edp port which use YCbCr 4:2:0 output format.
And for now, it does not consider a use case of DSC + YCbCr 4:2:0.
v2:
Addressed review comments from Ville.
Remove a changing of pipe_bpp on intel_ddi_set_pipe_settings().
Because the pipe is running at the full bpp, keep pipe_bpp as RGB
even though YCbCr 4:2:0 output format is used.
Add a link bandwidth computation for YCbCr4:2:0 output format.
v3:
Addressed reivew comments from Ville.
In order to make codes simple, it adds and uses intel_dp_output_bpp()
function.
v6:
Link M/N values are calculated and applied based on the Full Clock for
YCbCr420. The Bit per Pixel needs to be adjusted for YUV420 mode as it
requires only half of the RGB case.
- Link M/N values are calculated and applied based on the Full Clock
- Data M/N values needs to be calculated considering the data is half
due to subsampling
Remove a doubling of pixel clock on a dot clock calculator for
DP YCbCr 4:2:0.
Rebase and remove a duplicate setting of vsc_sdp.DB17.
Add a setting of dynamic range bit to vsc_sdp.DB17.
Change Content Type bit to "Graphics" from "Not defined".
Change a dividing of pipe_bpp to muliplying to constant values on a
switch-case statement.
v7:
Addressed review comments from Ville.
Move a setting of dynamic range bit and a setting of bpc which is based
on pipe_bpp to a "drm/i915/dp: Program VSC Header and DB for Pixel
Encoding/Colorimetry Format" commit.
Change Content Type bit to "Not defined" from "Graphics".
Cc: Ville Syrjälä
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_ddi.c | 3 ++-
drivers/gpu/drm/i915/intel_dp.c | 15 ++-
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 3f247f091d4c..df06e5bb4764 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1457,7 +1457,8 @@ static void ddi_dotclock_get(struct intel_crtc_state
*pipe_config)
else
dotclock = pipe_config->port_clock;
- if (pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
+ if (pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR420 &&
+ !intel_crtc_has_dp_encoder(pipe_config))
dotclock *= 2;
if (pipe_config->pixel_multiplier)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 06b1dc274196..d62f0898360e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1850,6 +1850,19 @@ intel_dp_adjust_compliance_config(struct intel_dp
*intel_dp,
}
}
+static int intel_dp_output_bpp(const struct intel_crtc_state *crtc_state, int
bpp)
+{
+ /*
+* bpp value was assumed to RGB format. And YCbCr 4:2:0 output
+* format of the number of bytes per pixel will be half the number
+* of bytes of RGB pixel.
+*/
+ if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
+ bpp /= 2;
+
+ return bpp;
+}
+
/* Optimize link config in order: max bpp, min clock, min lanes */
static int
intel_dp_compute_link_config_wide(struct intel_dp *intel_dp,
@@ -2223,7 +2236,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
if (pipe_config->dsc_params.compression_enable)
output_bpp = pipe_config->dsc_params.compressed_bpp;
else
- output_bpp = pipe_config->pipe_bpp;
+ output_bpp = intel_dp_output_bpp(pipe_config,
pipe_config->pipe_bpp);
intel_link_compute_m_n(output_bpp,
pipe_config->lane_count,
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 1/6] drm/i915/dp: Add a config function for YCBCR420 outputs
This patch checks a support of YCBCR420 outputs on an encoder level.
If the input mode is YCBCR420-only mode then it prepares DP as an YCBCR420
output, else it continues with RGB output mode.
It set output_format to INTEL_OUTPUT_FORMAT_YCBCR420 in order to using
a pipe scaler as RGB to YCbCr 4:4:4.
v2:
Addressed review comments from Ville.
Style fixed with few naming.
%s/config/crtc_state/
%s/intel_crtc/crtc/
If lscon is active, it makes not to call intel_dp_ycbcr420_config()
to avoid to clobber of lspcon_ycbcr420_config() routine.
And it move the 420_only check into the intel_dp_ycbcr420_config().
v3: Fix uninitialized return value and it is reported by Dan Carpenter.
v4:
Addressed review comments from Ville.
In order to avoid the extra indentation, it inverts if-clause on
intel_dp_ycbcr420_config().
Remove the error print where no errors print are allowed.
v6: Rebase
v7:
Move intel_dp_get_colorimetry_status() to intel_dp from intel_psr.
intel_dp_get_colorimetry_status() checks
VSC_SDP_EXTENSION_FOR_COLORIMETRY_SUPPORTED bit in the
DPRX_FEATURE_ENUMERATION_LIST register.
And intel_dp_ycbcr420_config() uses intel_dp_get_colorimetry_status().
Cc: Ville Syrjälä
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_dp.c | 48 +++-
drivers/gpu/drm/i915/intel_dp.h | 1 +
drivers/gpu/drm/i915/intel_psr.c | 10 ---
3 files changed, 48 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 77ba4da6b981..0b495176382e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2093,6 +2093,36 @@ intel_dp_compute_link_config(struct intel_encoder
*encoder,
return 0;
}
+static int
+intel_dp_ycbcr420_config(struct intel_dp *intel_dp,
+struct drm_connector *connector,
+struct intel_crtc_state *crtc_state)
+{
+ const struct drm_display_info *info = &connector->display_info;
+ const struct drm_display_mode *adjusted_mode =
+ &crtc_state->base.adjusted_mode;
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ int ret;
+
+ if (!drm_mode_is_420_only(info, adjusted_mode) ||
+ !intel_dp_get_colorimetry_status(intel_dp) ||
+ !connector->ycbcr_420_allowed)
+ return 0;
+
+ crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
+
+ /* YCBCR 420 output conversion needs a scaler */
+ ret = skl_update_scaler_crtc(crtc_state);
+ if (ret) {
+ DRM_DEBUG_KMS("Scaler allocation for output failed\n");
+ return ret;
+ }
+
+ intel_pch_panel_fitting(crtc, crtc_state, DRM_MODE_SCALE_FULLSCREEN);
+
+ return 0;
+}
+
bool intel_dp_limited_color_range(const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
{
@@ -2132,7 +2162,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
to_intel_digital_connector_state(conn_state);
bool constant_n = drm_dp_has_quirk(&intel_dp->desc,
DP_DPCD_QUIRK_CONSTANT_N);
- int ret, output_bpp;
+ int ret = 0, output_bpp;
if (HAS_PCH_SPLIT(dev_priv) && !HAS_DDI(dev_priv) && port != PORT_A)
pipe_config->has_pch_encoder = true;
@@ -2140,6 +2170,12 @@ intel_dp_compute_config(struct intel_encoder *encoder,
pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
if (lspcon->active)
lspcon_ycbcr420_config(&intel_connector->base, pipe_config);
+ else
+ ret = intel_dp_ycbcr420_config(intel_dp, &intel_connector->base,
+ pipe_config);
+
+ if (ret)
+ return ret;
pipe_config->has_drrs = false;
if (IS_G4X(dev_priv) || port == PORT_A)
@@ -4059,6 +4095,16 @@ intel_dp_read_dpcd(struct intel_dp *intel_dp)
return intel_dp->dpcd[DP_DPCD_REV] != 0;
}
+bool intel_dp_get_colorimetry_status(struct intel_dp *intel_dp)
+{
+ u8 dprx = 0;
+
+ if (drm_dp_dpcd_readb(&intel_dp->aux, DP_DPRX_FEATURE_ENUMERATION_LIST,
+ &dprx) != 1)
+ return false;
+ return dprx & DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED;
+}
+
static void intel_dp_get_dsc_sink_cap(struct intel_dp *intel_dp)
{
/*
diff --git a/drivers/gpu/drm/i915/intel_dp.h b/drivers/gpu/drm/i915/intel_dp.h
index 5e9e8d13de6e..da70b1a41c83 100644
--- a/drivers/gpu/drm/i915/intel_dp.h
+++ b/drivers/gpu/drm/i915/intel_dp.h
@@ -108,6 +108,7 @@ u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp,
int mode_clock,
int mode_hdisplay);
bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
+bool intel_dp_get_colorimetry_status(struct intel_dp *intel_dp);
int int
[Intel-gfx] [PATCH v9 0/6] drm/i915/dp: Support for DP YCbCr4:2:0 outputs
On Gen 11 platform, to enable resolutions like 5K@120 (or higher) we need
to use DSC (DP 1.4) or YCbCr4:2:0 (DP 1.3 or 1.4) on DP.
In order to support YCbCr4:2:0 on DP we need to program YCBCR 4:2:0
to MSA and VSC SDP.
And Link M/N values are calculated and applied based on the Full Clock
forYCbCr420.
The Bit per Pixel needs to be adjusted for YUV420 mode as it requires only
half of the RGB case.
- Link M/N values are calculated and applied based on the Full Clock
- Data M/N values needs to be calculated considering the data is half
due to subsampling
These patches add a VSC structure for handling Pixel Encoding/Colorimetry
Formats and program YCBCR 4:2:0 to MSA and VSC SDP. And it changes a link
bandwidth computation for DP.
These patches tested on below test environment.
Test Environment:
- Tested System: Gen11 platform
- Monitor: Wasabi Mango UHD430 REAL4K HDMI 2.0 Slim HDR DUAL DP i20
(This monitor supports HDMI YCbCr 4:2:0)
- DP to HDMI Adaptor (Dongle) : Club3D CAC-1080 (This dongle supports
DP YCbCr 4:2:0 pass through feature.)
- To enable DP YCbCr 4:2:0 forcely, test enviromnent uses work arounds
patches. You can find these on
https://gitlab.freedesktop.org/elongbug/drm-tip/tree/dp_ycbcr420_work
The idea of a scaling (RGB -> YCbCr4:4:4 -> YCbCr 4:2:0) is to follow the
same approach used in YCbCr 4:2:0 on HDMI.
v2: Addressed Maarten's review comments, fixed minor coding and block comment
style. And reordered a first patch ("drm/i915/dp: Support DP ports
YUV 4:2:0 output to GEN11") as a last patch.
v3: Addressed Ville's review comments.
Style fixed with few naming.
If lscon is active, it makes not to call intel_dp_ycbcr420_config() to avoid
to clobber of lspcon_ycbcr420_config() routine.
And it move the 420_only check into the intel_dp_ycbcr420_config().
Remove a changing of pipe_bpp on intel_ddi_set_pipe_settings().
Because the pipe is running at the full bpp, keep pipe_bpp as RGB even though
YCbCr 4:2:0 output format is used.
Add a link bandwidth computation for YCbCr4:2:0 output format.
v4: Fix uninitialized return value which is reported by Dan Carpenter.
v5: Addressed reivew comments from Ville.
In order to make codes simple, it adds and uses intel_dp_output_bpp() function.
In order to avoid the extra indentation, it inverts if-clause on
intel_dp_ycbcr420_config().
Remove the error print where no errors print are allowed.
v6:
Link M/N values are calculated and applied based on the Full Clock for
YCbCr420. The Bit per Pixel needs to be adjusted for YUV420 mode as it
requires only half of the RGB case.
- Link M/N values are calculated and applied based on the Full Clock
- Data M/N values needs to be calculated considering the data is half due
to subsampling
Remove a doubling of pixel clock on a dot clock calculator for DP YCbCr 4:2:0.
Rebase and remove a duplicate setting of vsc_sdp.DB17.
Add a setting of dynamic range bit to vsc_sdp.DB17.
Change Content Type bit to "Graphics" from "Not defined".
Change a dividing of pipe_bpp to muliplying to constant values on a switch-case
statement.
Fix an wrong setting of MSA MISC1 fields for Pixel Encoding/Colorimetry
Format indication. As per DP 1.4a spec Table 2-96 [MSA MISC1 and MISC0
Fields for Pixel Encoding/Colorimetry Format Indication] When MISC1, bit 6,
is Set to 1, a Source device uses a VSC SDP to indicate the Pixel
Encoding/Colorimetry Format. On the wrong version it set a bit 5 of MISC1,
now it set a bit 6 of MISC1.
v7:
Addressed review comments from Ville.
Move intel_dp_get_colorimetry_status() to intel_dp from intel_psr.
Move a setting of dynamic range bit and a setting of bpc which is based
on pipe_bpp to a "drm/i915/dp: Program VSC Header and DB for Pixel
Encoding/Colorimetry Format" commit.
Change Content Type bit to "Not defined" from "Graphics".
Fix non-standard comment format.
Remove a referring to specific commit.
Remove duplicated checking of connector's ycbcr_420_allowed from
intel_pixel_encoding_setup_vsc().
v8:
A missing of setting bpc to VSC setup is the pretty fatal case, it replaces
DRM_DEBUG_KMS() to MISSING_CASE(). [Maarten]
v9: Rename a member value name DB to db on struct dp_sdp [Laurent]
References: https://patchwork.freedesktop.org/series/56059/
Gwan-gyeong Mun (6):
drm/i915/dp: Add a config function for YCBCR420 outputs
drm: Rename struct edp_vsc_psr to struct dp_sdp
drm/i915/dp: Program VSC Header and DB for Pixel Encoding/Colorimetry
Format
drm/i915/dp: Add a support of YCBCR 4:2:0 to DP MSA
drm/i915/dp: Change a link bandwidth computation for DP
drm/i915/dp: Support DP ports YUV 4:2:0 output to GEN11
.../drm/bridge/analogix/analogix_dp_core.c| 12 +-
.../drm/bridge/analogix/analogix_dp_core.h| 2 +-
.../gpu/drm/bridge/analogix/analogix_dp_reg.c | 10 +-
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_ddi.c | 12 +-
drivers/gpu/drm/i915/intel_dp.c | 15
[Intel-gfx] [PATCH v9 3/6] drm/i915/dp: Program VSC Header and DB for Pixel Encoding/Colorimetry Format
Function intel_pixel_encoding_setup_vsc handles vsc header and data block
setup for pixel encoding / colorimetry format.
Setup VSC header and data block in function intel_pixel_encoding_setup_vsc
for pixel encoding / colorimetry format as per dp 1.4a spec,
section 2.2.5.7.1, table 2-119: VSC SDP Header Bytes, section 2.2.5.7.5,
table 2-120:VSC SDP Payload for DB16 through DB18.
v2:
Minor style fix. [Maarten]
Refer to commit ids instead of patchwork. [Maarten]
v6: Rebase
v7:
Rebase and addressed review comments from Ville.
Use a structure initializer instead of memset().
Fix non-standard comment format.
Remove a referring to specific commit.
Add a setting of dynamic range bit to vsc_sdp.DB17.
Add a setting of bpc which is based on pipe_bpp.
Remove duplicated checking of connector's ycbcr_420_allowed from
intel_pixel_encoding_setup_vsc(). It is already checked from
intel_dp_ycbcr420_config().
Remove comments for VSC_SDP_EXTENSION_FOR_COLORIMETRY_SUPPORTED. It is
already implemented on intel_dp_get_colorimetry_status().
v8:
A missing of setting bpc to VSC setup is the pretty fatal case, it
replaces DRM_DEBUG_KMS() to MISSING_CASE(). [Maarten]
v9: Use a changed member name of struct dp_sdp. it renamed to db from DB.
Cc: Maarten Lankhorst
Cc: Ville Syrjälä
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_ddi.c | 1 +
drivers/gpu/drm/i915/intel_dp.c | 90
drivers/gpu/drm/i915/intel_drv.h | 2 +
3 files changed, 93 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 0af47f343faa..b29e61b74961 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3389,6 +3389,7 @@ static void intel_enable_ddi_dp(struct intel_encoder
*encoder,
intel_edp_backlight_on(crtc_state, conn_state);
intel_psr_enable(intel_dp, crtc_state);
+ intel_dp_ycbcr_420_enable(intel_dp, crtc_state);
intel_edp_drrs_enable(intel_dp, crtc_state);
if (crtc_state->has_audio)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 0b495176382e..06b1dc274196 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4415,6 +4415,96 @@ u8 intel_dp_dsc_get_slice_count(struct intel_dp
*intel_dp,
return 0;
}
+static void
+intel_pixel_encoding_setup_vsc(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *crtc_state)
+{
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct dp_sdp vsc_sdp = {};
+
+ /* Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119 */
+ vsc_sdp.sdp_header.HB0 = 0;
+ vsc_sdp.sdp_header.HB1 = 0x7;
+
+ /*
+* VSC SDP supporting 3D stereo, PSR2, and Pixel Encoding/
+* Colorimetry Format indication.
+*/
+ vsc_sdp.sdp_header.HB2 = 0x5;
+
+ /*
+* VSC SDP supporting 3D stereo, + PSR2, + Pixel Encoding/
+* Colorimetry Format indication (HB2 = 05h).
+*/
+ vsc_sdp.sdp_header.HB3 = 0x13;
+
+ /*
+* YCbCr 420 = 3h DB16[7:4] ITU-R BT.601 = 0h, ITU-R BT.709 = 1h
+* DB16[3:0] DP 1.4a spec, Table 2-120
+*/
+ vsc_sdp.db[16] = 0x3 << 4; /* 0x3 << 4 , YCbCr 420*/
+ /* RGB->YCBCR color conversion uses the BT.709 color space. */
+ vsc_sdp.db[16] |= 0x1; /* 0x1, ITU-R BT.709 */
+
+ /*
+* For pixel encoding formats YCbCr444, YCbCr422, YCbCr420, and Y Only,
+* the following Component Bit Depth values are defined:
+* 001b = 8bpc.
+* 010b = 10bpc.
+* 011b = 12bpc.
+* 100b = 16bpc.
+*/
+ switch (crtc_state->pipe_bpp) {
+ case 24: /* 8bpc */
+ vsc_sdp.db[17] = 0x1;
+ break;
+ case 30: /* 10bpc */
+ vsc_sdp.db[17] = 0x2;
+ break;
+ case 36: /* 12bpc */
+ vsc_sdp.db[17] = 0x3;
+ break;
+ case 48: /* 16bpc */
+ vsc_sdp.db[17] = 0x4;
+ break;
+ default:
+ MISSING_CASE(crtc_state->pipe_bpp);
+ break;
+ }
+
+ /*
+* Dynamic Range (Bit 7)
+* 0 = VESA range, 1 = CTA range.
+* all YCbCr are always limited range
+*/
+ vsc_sdp.db[17] |= 0x80;
+
+ /*
+* Content Type (Bits 2:0)
+* 000b = Not defined.
+* 001b = Graphics.
+* 010b = Photo.
+* 011b = Video.
+* 100b = Game
+* All other values are RESERVED.
+* Note: See CTA-861-G for the definition and expected
+* processing by a stream sink for the above contect types.
+*/
+ vsc_sdp.db[18] = 0;
+
+ intel_dig_port->write_infoframe(&intel_dig_port->base,
+ crtc_state, DP_SDP_VSC, &vsc_sdp, sizeof(vsc_sdp));
+}
+
+v
[Intel-gfx] [PATCH v9 6/6] drm/i915/dp: Support DP ports YUV 4:2:0 output to GEN11
Bspec describes that GEN10 only supports capability of YUV 4:2:0 output to HDMI port and GEN11 supports capability of YUV 4:2:0 output to both DP and HDMI ports. v2: Minor style fix. Signed-off-by: Gwan-gyeong Mun Reviewed-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_dp.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index d62f0898360e..24b56b2a76c8 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -7395,6 +7395,9 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port, connector->interlace_allowed = true; connector->doublescan_allowed = 0; + if (INTEL_GEN(dev_priv) >= 11) + connector->ycbcr_420_allowed = true; + intel_encoder->hpd_pin = intel_hpd_pin_default(dev_priv, port); intel_dp_aux_init(intel_dp); -- 2.21.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 4/6] drm/i915/dp: Add a support of YCBCR 4:2:0 to DP MSA
When YCBCR 4:2:0 outputs is used for DP, we should program YCBCR 4:2:0 to
MSA and VSC SDP.
As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication of Color
Encoding Format and Content Color Gamut] while sending YCBCR 420 signals
we should program MSA MISC1 fields which indicate VSC SDP for the Pixel
Encoding/Colorimetry Format.
v2: Block comment style fix.
v6:
Fix an wrong setting of MSA MISC1 fields for Pixel Encoding/Colorimetry
Format indication. As per DP 1.4a spec Table 2-96 [MSA MISC1 and MISC0
Fields for Pixel Encoding/Colorimetry Format Indication]
When MISC1, bit 6, is Set to 1, a Source device uses a VSC SDP to
indicate the Pixel Encoding/Colorimetry Format. On the wrong version
it set a bit 5 of MISC1, now it set a bit 6 of MISC1.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_ddi.c | 8
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e97c47fca645..2ad98e62034f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9524,6 +9524,7 @@ enum skl_power_gate {
#define TRANS_MSA_12_BPC (3 << 5)
#define TRANS_MSA_16_BPC (4 << 5)
#define TRANS_MSA_CEA_RANGE (1 << 3)
+#define TRANS_MSA_USE_VSC_SDP (1 << 14)
/* LCPLL Control */
#define LCPLL_CTL _MMIO(0x130040)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index b29e61b74961..3f247f091d4c 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1717,6 +1717,14 @@ void intel_ddi_set_pipe_settings(const struct
intel_crtc_state *crtc_state)
*/
if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444)
temp |= TRANS_MSA_SAMPLING_444 | TRANS_MSA_CLRSP_YCBCR;
+ /*
+* As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication
+* of Color Encoding Format and Content Color Gamut] while sending
+* YCBCR 420 signals we should program MSA MISC1 fields which
+* indicate VSC SDP for the Pixel Encoding/Colorimetry Format.
+*/
+ if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
+ temp |= TRANS_MSA_USE_VSC_SDP;
I915_WRITE(TRANS_MSA_MISC(cpu_transcoder), temp);
}
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] gvt-fixes
Quoting Zhenyu Wang (2019-05-21 09:24:08) > > Hi, > > Here's gvt-fixes for 5.2-rc. It contains vgpu reset fix with > proper timeline handling, fixes for guest TRTT setting which > should be handled in context state instead of pushing directly > to hardware and one error return fix. This is now pulled. Thanks for the PR. Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 29/33] fbcon: replace FB_EVENT_MODE_CHANGE/_ALL with direct calls
On Tue, May 21, 2019 at 12:56:30PM +0200, Maarten Lankhorst wrote:
> Op 20-05-2019 om 10:22 schreef Daniel Vetter:
> > Create a new wrapper function for this, feels like there's some
> > refactoring room here between the two modes.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Lee Jones
> > Cc: Daniel Thompson
> > Cc: Jingoo Han
> > Cc: Bartlomiej Zolnierkiewicz
> > Cc: Daniel Vetter
> > Cc: Hans de Goede
> > Cc: Yisheng Xie
> > Cc: "Michał Mirosław"
> > Cc: Peter Rosin
> > Cc: Mikulas Patocka
> > Cc: linux-fb...@vger.kernel.org
> > ---
> > drivers/video/backlight/lcd.c | 2 --
> > drivers/video/fbdev/core/fbcon.c | 15 +--
> > drivers/video/fbdev/core/fbmem.c | 13 ++---
> > drivers/video/fbdev/sh_mobile_lcdcfb.c | 11 +--
> > include/linux/fb.h | 4
> > include/linux/fbcon.h | 2 ++
> > 6 files changed, 14 insertions(+), 33 deletions(-)
> >
> > diff --git a/drivers/video/backlight/lcd.c b/drivers/video/backlight/lcd.c
> > index 4b40c6a4d441..16298041b141 100644
> > --- a/drivers/video/backlight/lcd.c
> > +++ b/drivers/video/backlight/lcd.c
> > @@ -32,8 +32,6 @@ static int fb_notifier_callback(struct notifier_block
> > *self,
> > /* If we aren't interested in this event, skip it immediately ... */
> > switch (event) {
> > case FB_EVENT_BLANK:
> > - case FB_EVENT_MODE_CHANGE:
> > - case FB_EVENT_MODE_CHANGE_ALL:
> > case FB_EARLY_EVENT_BLANK:
> > case FB_R_EARLY_EVENT_BLANK:
> > break;
>
> Below it performs a call to set_mode() if it's none of the blanking events;
> it can be removed. :)
Oops ... I think I'll insert a patch here to create a new MODESET event
for backlights. We still need this one I think (maybe not for kms, but for
old fbdev drivers). And maybe a wrapper for fb_backlight_notify on top ...
Thanks for spotting this.
-Daniel
>
> > diff --git a/drivers/video/fbdev/core/fbcon.c
> > b/drivers/video/fbdev/core/fbcon.c
> > index c1a7476e980f..8cc62d340387 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -3005,6 +3005,15 @@ static void fbcon_set_all_vcs(struct fb_info *info)
> > fbcon_modechanged(info);
> > }
> >
> > +
> > +void fbcon_update_vcs(struct fb_info *info, bool all)
> > +{
> > + if (all)
> > + fbcon_set_all_vcs(info);
> > + else
> > + fbcon_modechanged(info);
> > +}
> > +
> > int fbcon_mode_deleted(struct fb_info *info,
> >struct fb_videomode *mode)
> > {
> > @@ -3314,12 +3323,6 @@ static int fbcon_event_notify(struct notifier_block
> > *self,
> > int idx, ret = 0;
> >
> > switch(action) {
> > - case FB_EVENT_MODE_CHANGE:
> > - fbcon_modechanged(info);
> > - break;
> > - case FB_EVENT_MODE_CHANGE_ALL:
> > - fbcon_set_all_vcs(info);
> > - break;
> > case FB_EVENT_SET_CONSOLE_MAP:
> > /* called with console lock held */
> > con2fb = event->data;
> > diff --git a/drivers/video/fbdev/core/fbmem.c
> > b/drivers/video/fbdev/core/fbmem.c
> > index cbd58ba8a59d..55b88163edc2 100644
> > --- a/drivers/video/fbdev/core/fbmem.c
> > +++ b/drivers/video/fbdev/core/fbmem.c
> > @@ -1039,17 +1039,8 @@ fb_set_var(struct fb_info *info, struct
> > fb_var_screeninfo *var)
> > !list_empty(&info->modelist))
> > ret = fb_add_videomode(&mode, &info->modelist);
> >
> > - if (!ret && (flags & FBINFO_MISC_USEREVENT)) {
> > - struct fb_event event;
> > - int evnt = (activate & FB_ACTIVATE_ALL) ?
> > - FB_EVENT_MODE_CHANGE_ALL :
> > - FB_EVENT_MODE_CHANGE;
> > -
> > - info->flags &= ~FBINFO_MISC_USEREVENT;
> > - event.info = info;
> > - event.data = &mode;
> > - fb_notifier_call_chain(evnt, &event);
> > - }
> > + if (!ret && (flags & FBINFO_MISC_USEREVENT))
> > + fbcon_update_vcs(info, activate & FB_ACTIVATE_ALL);
> >
> > return ret;
> > }
> > diff --git a/drivers/video/fbdev/sh_mobile_lcdcfb.c
> > b/drivers/video/fbdev/sh_mobile_lcdcfb.c
> > index 0d7a044852d7..bb1a610d0363 100644
> > --- a/drivers/video/fbdev/sh_mobile_lcdcfb.c
> > +++ b/drivers/video/fbdev/sh_mobile_lcdcfb.c
> > @@ -1776,8 +1776,6 @@ static void sh_mobile_fb_reconfig(struct fb_info
> > *info)
> > struct sh_mobile_lcdc_chan *ch = info->par;
> > struct fb_var_screeninfo var;
> > struct fb_videomode mode;
> > - struct fb_event event;
> > - int evnt = FB_EVENT_MODE_CHANGE_ALL;
> >
> > if (ch->use_count > 1 || (ch->use_count == 1 && !info->fbcon_par))
> > /* More framebuffer users are active */
> > @@ -1799,14 +1797,7 @@ static void sh_mobile_fb_reconfig(struct fb_info
> > *info)
> > /* Couldn't reconfigure, hopefully, can continue as before */
> > return;
> >
> > - /*
> > -* fb_set_var() calls the notifier
[Intel-gfx] [CI 04/10] drm/i915: Re-expose SINGLE_TIMELINE flags for context creation
The SINGLE_TIMELINE flag can be used to create a context such that all
engine instances within that context share a common timeline. This can
be useful for mixing operations between real and virtual engines, or
when using a composite context for a single client API context.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_context.c | 4
include/uapi/drm/i915_drm.h | 3 ++-
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 5fdb44714a5c..9cd671298daf 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -96,8 +96,6 @@
#include "i915_trace.h"
#include "i915_user_extensions.h"
-#define I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE (1 << 1)
-
#define ALL_L3_SLICES(dev) (1 << NUM_L3_SLICES(dev)) - 1
static struct i915_global_gem_context {
@@ -505,8 +503,6 @@ i915_gem_create_context(struct drm_i915_private *dev_priv,
unsigned int flags)
lockdep_assert_held(&dev_priv->drm.struct_mutex);
- BUILD_BUG_ON(I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE &
-~I915_CONTEXT_CREATE_FLAGS_UNKNOWN);
if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE &&
!HAS_EXECLISTS(dev_priv))
return ERR_PTR(-EINVAL);
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 82bd488ed0d1..957ba8e60e02 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1469,8 +1469,9 @@ struct drm_i915_gem_context_create_ext {
__u32 ctx_id; /* output: id of new context*/
__u32 flags;
#define I915_CONTEXT_CREATE_FLAGS_USE_EXTENSIONS (1u << 0)
+#define I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE (1u << 1)
#define I915_CONTEXT_CREATE_FLAGS_UNKNOWN \
- (-(I915_CONTEXT_CREATE_FLAGS_USE_EXTENSIONS << 1))
+ (-(I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE << 1))
__u64 extensions;
};
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 09/10] drm/i915/execlists: Virtual engine bonding
Some users require that when a master batch is executed on one particular
engine, a companion batch is run simultaneously on a specific slave
engine. For this purpose, we introduce virtual engine bonding, allowing
maps of master:slaves to be constructed to constrain which physical
engines a virtual engine may select given a fence on a master engine.
For the moment, we continue to ignore the issue of preemption deferring
the master request for later. Ideally, we would like to then also remove
the slave and run something else rather than have it stall the pipeline.
With load balancing, we should be able to move workload around it, but
there is a similar stall on the master pipeline while it may wait for
the slave to be executed. At the cost of more latency for the bonded
request, it may be interesting to launch both on their engines in
lockstep. (Bubbles abound.)
Opens: Also what about bonding an engine as its own master? It doesn't
break anything internally, so allow the silliness.
v2: Emancipate the bonds
v3: Couple in delayed scheduling for the selftests
v4: Handle invalid mutually exclusive bonding
v5: Mention what the uapi does
v6: s/nbond/num_bonds/
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine_types.h | 7 +
drivers/gpu/drm/i915/gt/intel_lrc.c | 98 +
drivers/gpu/drm/i915/gt/intel_lrc.h | 4 +
drivers/gpu/drm/i915/gt/selftest_lrc.c| 191 ++
drivers/gpu/drm/i915/i915_gem_context.c | 84
drivers/gpu/drm/i915/selftests/lib_sw_fence.c | 3 +
include/uapi/drm/i915_drm.h | 44
7 files changed, 431 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 7b47e00fa082..f3fc2e8acc90 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -405,6 +405,13 @@ struct intel_engine_cs {
*/
void(*submit_request)(struct i915_request *rq);
+ /*
+* Called on signaling of a SUBMIT_FENCE, passing along the signaling
+* request down to the bonded pairs.
+*/
+ void(*bond_execute)(struct i915_request *rq,
+ struct dma_fence *signal);
+
/*
* Call when the priority on a request has changed and it and its
* dependencies may need rescheduling. Note the request itself may
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 0b4d29d4816b..1f7bee0cae0c 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -189,6 +189,18 @@ struct virtual_engine {
int prio;
} nodes[I915_NUM_ENGINES];
+ /*
+* Keep track of bonded pairs -- restrictions upon on our selection
+* of physical engines any particular request may be submitted to.
+* If we receive a submit-fence from a master engine, we will only
+* use one of sibling_mask physical engines.
+*/
+ struct ve_bond {
+ const struct intel_engine_cs *master;
+ intel_engine_mask_t sibling_mask;
+ } *bonds;
+ unsigned int num_bonds;
+
/* And finally, which physical engines this virtual engine maps onto. */
unsigned int num_siblings;
struct intel_engine_cs *siblings[0];
@@ -960,6 +972,7 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
rb_erase_cached(rb, &execlists->virtual);
RB_CLEAR_NODE(rb);
+ GEM_BUG_ON(!(rq->execution_mask & engine->mask));
rq->engine = engine;
if (engine != ve->siblings[0]) {
@@ -3069,6 +3082,8 @@ static void virtual_context_destroy(struct kref *kref)
if (ve->context.state)
__execlists_context_fini(&ve->context);
+ kfree(ve->bonds);
+
i915_timeline_fini(&ve->base.timeline);
kfree(ve);
}
@@ -3265,6 +3280,38 @@ static void virtual_submit_request(struct i915_request
*rq)
tasklet_schedule(&ve->base.execlists.tasklet);
}
+static struct ve_bond *
+virtual_find_bond(struct virtual_engine *ve,
+ const struct intel_engine_cs *master)
+{
+ int i;
+
+ for (i = 0; i < ve->num_bonds; i++) {
+ if (ve->bonds[i].master == master)
+ return &ve->bonds[i];
+ }
+
+ return NULL;
+}
+
+static void
+virtual_bond_execute(struct i915_request *rq, struct dma_fence *signal)
+{
+ struct virtual_engine *ve = to_virtual_engine(rq->engine);
+ struct ve_bond *bond;
+
+ bond = virtual_find_bond(ve, to_request(signal)->engine);
+ if (bond) {
+ intel_engine_mask_t old, new, cmp;
+
+ cmp = READ_ONCE(rq->execution_mask);
+
[Intel-gfx] [CI 02/10] drm/i915: Allow a context to define its set of engines
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with an API for the user to construct a map of engines
to capabilities. Into this picture, we then add a challenge of virtual
engines; one user engine that maps behind the scenes to any number of
physical engines. To keep it general, we want the user to have full
control over that mapping. To that end, we allow the user to constrain a
context to define the set of engines that it can access, order fully
controlled by the user via (class, instance). With such precise control
in context setup, we can continue to use the existing execbuf uABI of
specifying a single index; only now it doesn't automagically map onto
the engines, it uses the user defined engine map from the context.
v2: Fixup freeing of local on success of get_engines()
v3: Allow empty engines[]
v4: s/nengine/num_engines/
v5: Replace 64 limit on num_engines with a note that execbuf is
currently limited to only using the first 64 engines.
v6: Actually use the engines_mutex to guard the ctx->engines.
Testcase: igt/gem_ctx_engines
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_context.c | 239 +-
drivers/gpu/drm/i915/i915_gem_context.h | 18 ++
drivers/gpu/drm/i915/i915_gem_context_types.h | 1 +
drivers/gpu/drm/i915/i915_gem_execbuffer.c| 5 +-
drivers/gpu/drm/i915/i915_utils.h | 34 +++
include/uapi/drm/i915_drm.h | 31 +++
6 files changed, 315 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 413c4529191d..21bfcd529097 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -90,7 +90,6 @@
#include
#include "gt/intel_lrc_reg.h"
-#include "gt/intel_workarounds.h"
#include "i915_drv.h"
#include "i915_globals.h"
@@ -141,15 +140,31 @@ static void lut_close(struct i915_gem_context *ctx)
}
static struct intel_context *
-lookup_user_engine(struct i915_gem_context *ctx, u16 class, u16 instance)
+lookup_user_engine(struct i915_gem_context *ctx,
+ unsigned long flags,
+ const struct i915_engine_class_instance *ci)
+#define LOOKUP_USER_INDEX BIT(0)
{
- struct intel_engine_cs *engine;
+ int idx;
- engine = intel_engine_lookup_user(ctx->i915, class, instance);
- if (!engine)
+ if (!!(flags & LOOKUP_USER_INDEX) != i915_gem_context_user_engines(ctx))
return ERR_PTR(-EINVAL);
- return i915_gem_context_get_engine(ctx, engine->id);
+ if (!i915_gem_context_user_engines(ctx)) {
+ struct intel_engine_cs *engine;
+
+ engine = intel_engine_lookup_user(ctx->i915,
+ ci->engine_class,
+ ci->engine_instance);
+ if (!engine)
+ return ERR_PTR(-EINVAL);
+
+ idx = engine->id;
+ } else {
+ idx = ci->engine_instance;
+ }
+
+ return i915_gem_context_get_engine(ctx, idx);
}
static inline int new_hw_id(struct drm_i915_private *i915, gfp_t gfp)
@@ -257,6 +272,17 @@ static void free_engines(struct i915_gem_engines *e)
__free_engines(e, e->num_engines);
}
+static void free_engines_rcu(struct work_struct *wrk)
+{
+ struct i915_gem_engines *e =
+ container_of(wrk, struct i915_gem_engines, rcu.work);
+ struct drm_i915_private *i915 = e->i915;
+
+ mutex_lock(&i915->drm.struct_mutex);
+ free_engines(e);
+ mutex_unlock(&i915->drm.struct_mutex);
+}
+
static struct i915_gem_engines *default_engines(struct i915_gem_context *ctx)
{
struct intel_engine_cs *engine;
@@ -1352,9 +1378,7 @@ static int set_sseu(struct i915_gem_context *ctx,
if (user_sseu.flags || user_sseu.rsvd)
return -EINVAL;
- ce = lookup_user_engine(ctx,
- user_sseu.engine.engine_class,
- user_sseu.engine.engine_instance);
+ ce = lookup_user_engine(ctx, 0, &user_sseu.engine);
if (IS_ERR(ce))
return PTR_ERR(ce);
@@ -1379,6 +1403,191 @@ static int set_sseu(struct i915_gem_context *ctx,
return ret;
}
+struct set_engines {
+ struct i915_gem_context *ctx;
+ struct i915_gem_engines *engines;
+};
+
+static const i915_user_extension_fn set_engines__extensions[] = {
+};
+
+static int
+set_engines(struct i915_gem_context *ctx,
+ const struct drm_i915_gem_context_param *args)
+{
+ struct i915_context_param_engines __user *user =
+ u64_to_user
[Intel-gfx] [CI 01/10] drm/i915: Restore control over ppgtt for context creation ABI
Having hid the partially exposed new ABI from the PR, put it back again
for completion of context recovery. A significant part of context
recovery is the ability to reuse as much of the old context as is
feasible (to avoid expensive reconstruction). The biggest chunk kept
hidden at the moment is fine-control over the ctx->ppgtt (the GPU page
tables and associated translation tables and kernel maps), so make
control over the ctx->ppgtt explicit.
This allows userspace to create and share virtual memory address spaces
(within the limits of a single fd) between contexts they own, along with
the ability to query the contexts for the vm state.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.c | 2 ++
drivers/gpu/drm/i915/i915_gem_context.c | 5 -
include/uapi/drm/i915_drm.h | 15 +++
3 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 2c7a4318d13c..5061cb32856b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -3164,6 +3164,8 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_PERF_ADD_CONFIG, i915_perf_add_config_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_PERF_REMOVE_CONFIG,
i915_perf_remove_config_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_QUERY, i915_query_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_VM_CREATE, i915_gem_vm_create_ioctl,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_VM_DESTROY, i915_gem_vm_destroy_ioctl,
DRM_RENDER_ALLOW),
};
static struct drm_driver driver = {
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 65cefc520e79..413c4529191d 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -98,7 +98,6 @@
#include "i915_user_extensions.h"
#define I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE (1 << 1)
-#define I915_CONTEXT_PARAM_VM 0x9
#define ALL_L3_SLICES(dev) (1 << NUM_L3_SLICES(dev)) - 1
@@ -966,8 +965,6 @@ static int get_ppgtt(struct drm_i915_file_private
*file_priv,
struct i915_hw_ppgtt *ppgtt;
int ret;
- return -EINVAL; /* nothing to see here; please move along */
-
if (!ctx->ppgtt)
return -ENODEV;
@@ -1066,8 +1063,6 @@ static int set_ppgtt(struct drm_i915_file_private
*file_priv,
struct i915_hw_ppgtt *ppgtt, *old;
int err;
- return -EINVAL; /* nothing to see here; please move along */
-
if (args->size)
return -EINVAL;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 3a73f5316766..d6ad4a15b2b9 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -355,6 +355,8 @@ typedef struct _drm_i915_sarea {
#define DRM_I915_PERF_ADD_CONFIG 0x37
#define DRM_I915_PERF_REMOVE_CONFIG0x38
#define DRM_I915_QUERY 0x39
+#define DRM_I915_GEM_VM_CREATE 0x3a
+#define DRM_I915_GEM_VM_DESTROY0x3b
/* Must be kept compact -- no holes */
#define DRM_IOCTL_I915_INITDRM_IOW( DRM_COMMAND_BASE +
DRM_I915_INIT, drm_i915_init_t)
@@ -415,6 +417,8 @@ typedef struct _drm_i915_sarea {
#define DRM_IOCTL_I915_PERF_ADD_CONFIG DRM_IOW(DRM_COMMAND_BASE +
DRM_I915_PERF_ADD_CONFIG, struct drm_i915_perf_oa_config)
#define DRM_IOCTL_I915_PERF_REMOVE_CONFIG DRM_IOW(DRM_COMMAND_BASE +
DRM_I915_PERF_REMOVE_CONFIG, __u64)
#define DRM_IOCTL_I915_QUERY DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_QUERY, struct drm_i915_query)
+#define DRM_IOCTL_I915_GEM_VM_CREATE DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_CREATE, struct drm_i915_gem_vm_control)
+#define DRM_IOCTL_I915_GEM_VM_DESTROY DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_VM_DESTROY, struct drm_i915_gem_vm_control)
/* Allow drivers to submit batchbuffers directly to hardware, relying
* on the security mechanisms provided by hardware.
@@ -1507,6 +1511,17 @@ struct drm_i915_gem_context_param {
* On creation, all new contexts are marked as recoverable.
*/
#define I915_CONTEXT_PARAM_RECOVERABLE 0x8
+
+ /*
+* The id of the associated virtual memory address space (ppGTT) of
+* this context. Can be retrieved and passed to another context
+* (on the same fd) for both to use the same ppGTT and so share
+* address layouts, and avoid reloading the page tables on context
+* switches between themselves.
+*
+* See DRM_I915_GEM_VM_CREATE and DRM_I915_GEM_VM_DESTROY.
+*/
+#define I915_CONTEXT_PARAM_VM 0x9
/* Must be kept compact -- no holes and well documented */
__u64 value;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailma
[Intel-gfx] [CI 05/10] drm/i915: Allow userspace to clone contexts on creation
A usecase arose out of handling context recovery in mesa, whereby they
wish to recreate a context with fresh logical state but preserving all
other details of the original. Currently, they create a new context and
iterate over which bits they want to copy across, but it would much more
convenient if they were able to just pass in a target context to clone
during creation. This essentially extends the setparam during creation
to pull the details from a target context instead of the user supplied
parameters.
The ideal here is that we don't expose control over anything more than
can be obtained via CONTEXT_PARAM. That is userspace retains explicit
control over all features, and this api is just convenience.
For example, you could replace
struct context_param p = { .param = CONTEXT_PARAM_VM };
param.ctx_id = old_id;
gem_context_get_param(&p.param);
new_id = gem_context_create();
param.ctx_id = new_id;
gem_context_set_param(&p.param);
gem_vm_destroy(param.value); /* drop the ref to VM_ID handle */
with
struct create_ext_param p = {
{ .name = CONTEXT_CREATE_CLONE },
.clone_id = old_id,
.flags = CLONE_FLAGS_VM
}
new_id = gem_context_create_ext(&p);
and not have to worry about stray namespace pollution etc.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_context.c | 206
include/uapi/drm/i915_drm.h | 15 ++
2 files changed, 221 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 9cd671298daf..040c0b770c21 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -1697,8 +1697,214 @@ static int create_setparam(struct i915_user_extension
__user *ext, void *data)
return ctx_setparam(arg->fpriv, arg->ctx, &local.param);
}
+static int clone_engines(struct i915_gem_context *dst,
+struct i915_gem_context *src)
+{
+ struct i915_gem_engines *e = i915_gem_context_lock_engines(src);
+ struct i915_gem_engines *clone;
+ bool user_engines;
+ unsigned long n;
+
+ clone = kmalloc(struct_size(e, engines, e->num_engines), GFP_KERNEL);
+ if (!clone)
+ goto err_unlock;
+
+ clone->i915 = dst->i915;
+ for (n = 0; n < e->num_engines; n++) {
+ if (!e->engines[n]) {
+ clone->engines[n] = NULL;
+ continue;
+ }
+
+ clone->engines[n] =
+ intel_context_create(dst, e->engines[n]->engine);
+ if (!clone->engines[n]) {
+ __free_engines(clone, n);
+ goto err_unlock;
+ }
+ }
+ clone->num_engines = n;
+
+ user_engines = i915_gem_context_user_engines(src);
+ i915_gem_context_unlock_engines(src);
+
+ free_engines(dst->engines);
+ RCU_INIT_POINTER(dst->engines, clone);
+ if (user_engines)
+ i915_gem_context_set_user_engines(dst);
+ else
+ i915_gem_context_clear_user_engines(dst);
+ return 0;
+
+err_unlock:
+ i915_gem_context_unlock_engines(src);
+ return -ENOMEM;
+}
+
+static int clone_flags(struct i915_gem_context *dst,
+ struct i915_gem_context *src)
+{
+ dst->user_flags = src->user_flags;
+ return 0;
+}
+
+static int clone_schedattr(struct i915_gem_context *dst,
+ struct i915_gem_context *src)
+{
+ dst->sched = src->sched;
+ return 0;
+}
+
+static int clone_sseu(struct i915_gem_context *dst,
+ struct i915_gem_context *src)
+{
+ struct i915_gem_engines *e = i915_gem_context_lock_engines(src);
+ struct i915_gem_engines *clone;
+ unsigned long n;
+ int err;
+
+ clone = dst->engines; /* no locking required; sole access */
+ if (e->num_engines != clone->num_engines) {
+ err = -EINVAL;
+ goto unlock;
+ }
+
+ for (n = 0; n < e->num_engines; n++) {
+ struct intel_context *ce = e->engines[n];
+
+ if (clone->engines[n]->engine->class != ce->engine->class) {
+ /* Must have compatible engine maps! */
+ err = -EINVAL;
+ goto unlock;
+ }
+
+ /* serialises with set_sseu */
+ err = intel_context_lock_pinned(ce);
+ if (err)
+ goto unlock;
+
+ clone->engines[n]->sseu = ce->sseu;
+ intel_context_unlock_pinned(ce);
+ }
+
+ err = 0;
+unlock:
+ i915_gem_context_unlock_engines(src);
+ return err;
+}
+
+static int clone_timeline(struct i915_gem_context *dst,
+ struct i915_gem_context *src)
+{
+
[Intel-gfx] [CI 08/10] drm/i915: Extend execution fence to support a callback
In the next patch, we will want to configure the slave request
depending on which physical engine the master request is executed on.
For this, we introduce a callback from the execute fence to convey this
information.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 84 +++--
drivers/gpu/drm/i915/i915_request.h | 4 ++
2 files changed, 83 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 809d6ee10da6..18b34b0bf872 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -38,6 +38,8 @@ struct execute_cb {
struct list_head link;
struct irq_work work;
struct i915_sw_fence *fence;
+ void (*hook)(struct i915_request *rq, struct dma_fence *signal);
+ struct i915_request *signal;
};
static struct i915_global_request {
@@ -329,6 +331,17 @@ static void irq_execute_cb(struct irq_work *wrk)
kmem_cache_free(global.slab_execute_cbs, cb);
}
+static void irq_execute_cb_hook(struct irq_work *wrk)
+{
+ struct execute_cb *cb = container_of(wrk, typeof(*cb), work);
+
+ cb->hook(container_of(cb->fence, struct i915_request, submit),
+&cb->signal->fence);
+ i915_request_put(cb->signal);
+
+ irq_execute_cb(wrk);
+}
+
static void __notify_execute_cb(struct i915_request *rq)
{
struct execute_cb *cb;
@@ -355,14 +368,19 @@ static void __notify_execute_cb(struct i915_request *rq)
}
static int
-i915_request_await_execution(struct i915_request *rq,
-struct i915_request *signal,
-gfp_t gfp)
+__i915_request_await_execution(struct i915_request *rq,
+ struct i915_request *signal,
+ void (*hook)(struct i915_request *rq,
+ struct dma_fence *signal),
+ gfp_t gfp)
{
struct execute_cb *cb;
- if (i915_request_is_active(signal))
+ if (i915_request_is_active(signal)) {
+ if (hook)
+ hook(rq, &signal->fence);
return 0;
+ }
cb = kmem_cache_alloc(global.slab_execute_cbs, gfp);
if (!cb)
@@ -372,8 +390,18 @@ i915_request_await_execution(struct i915_request *rq,
i915_sw_fence_await(cb->fence);
init_irq_work(&cb->work, irq_execute_cb);
+ if (hook) {
+ cb->hook = hook;
+ cb->signal = i915_request_get(signal);
+ cb->work.func = irq_execute_cb_hook;
+ }
+
spin_lock_irq(&signal->lock);
if (i915_request_is_active(signal)) {
+ if (hook) {
+ hook(rq, &signal->fence);
+ i915_request_put(signal);
+ }
i915_sw_fence_complete(cb->fence);
kmem_cache_free(global.slab_execute_cbs, cb);
} else {
@@ -834,7 +862,7 @@ emit_semaphore_wait(struct i915_request *to,
return err;
/* Only submit our spinner after the signaler is running! */
- err = i915_request_await_execution(to, from, gfp);
+ err = __i915_request_await_execution(to, from, NULL, gfp);
if (err)
return err;
@@ -970,6 +998,52 @@ i915_request_await_dma_fence(struct i915_request *rq,
struct dma_fence *fence)
return 0;
}
+int
+i915_request_await_execution(struct i915_request *rq,
+struct dma_fence *fence,
+void (*hook)(struct i915_request *rq,
+ struct dma_fence *signal))
+{
+ struct dma_fence **child = &fence;
+ unsigned int nchild = 1;
+ int ret;
+
+ if (dma_fence_is_array(fence)) {
+ struct dma_fence_array *array = to_dma_fence_array(fence);
+
+ /* XXX Error for signal-on-any fence arrays */
+
+ child = array->fences;
+ nchild = array->num_fences;
+ GEM_BUG_ON(!nchild);
+ }
+
+ do {
+ fence = *child++;
+ if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
+ continue;
+
+ /*
+* We don't squash repeated fence dependencies here as we
+* want to run our callback in all cases.
+*/
+
+ if (dma_fence_is_i915(fence))
+ ret = __i915_request_await_execution(rq,
+to_request(fence),
+hook,
+I915_FENCE_GFP);
+ else
+ ret = i915_sw_fence_await_dma_fence(&rq->submit, fence,
+
[Intel-gfx] [CI 10/10] drm/i915: Allow specification of parallel execbuf
There is a desire to split a task onto two engines and have them run at
the same time, e.g. scanline interleaving to spread the workload evenly.
Through the use of the out-fence from the first execbuf, we can
coordinate secondary execbuf to only become ready simultaneously with
the first, so that with all things idle the second execbufs are executed
in parallel with the first. The key difference here between the new
EXEC_FENCE_SUBMIT and the existing EXEC_FENCE_IN is that the in-fence
waits for the completion of the first request (so that all of its
rendering results are visible to the second execbuf, the more common
userspace fence requirement).
Since we only have a single input fence slot, userspace cannot mix an
in-fence and a submit-fence. It has to use one or the other! This is not
such a harsh requirement, since by virtue of the submit-fence, the
secondary execbuf inherit all of the dependencies from the first
request, and for the application the dependencies should be common
between the primary and secondary execbuf.
Suggested-by: Tvrtko Ursulin
Testcase: igt/gem_exec_fence/parallel
Link: https://github.com/intel/media-driver/pull/546
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.c| 1 +
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 25 +-
include/uapi/drm/i915_drm.h| 17 ++-
3 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 5061cb32856b..83d2eb9e74cb 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -443,6 +443,7 @@ static int i915_getparam_ioctl(struct drm_device *dev, void
*data,
case I915_PARAM_HAS_EXEC_CAPTURE:
case I915_PARAM_HAS_EXEC_BATCH_FIRST:
case I915_PARAM_HAS_EXEC_FENCE_ARRAY:
+ case I915_PARAM_HAS_EXEC_SUBMIT_FENCE:
/* For the time being all of these are always true;
* if some supported hardware does not have one of these
* features this value needs to be provided from
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 729860188c1a..8b85c91c3ea4 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -2319,6 +2319,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
{
struct i915_execbuffer eb;
struct dma_fence *in_fence = NULL;
+ struct dma_fence *exec_fence = NULL;
struct sync_file *out_fence = NULL;
int out_fence_fd = -1;
int err;
@@ -2361,11 +2362,24 @@ i915_gem_do_execbuffer(struct drm_device *dev,
return -EINVAL;
}
+ if (args->flags & I915_EXEC_FENCE_SUBMIT) {
+ if (in_fence) {
+ err = -EINVAL;
+ goto err_in_fence;
+ }
+
+ exec_fence = sync_file_get_fence(lower_32_bits(args->rsvd2));
+ if (!exec_fence) {
+ err = -EINVAL;
+ goto err_in_fence;
+ }
+ }
+
if (args->flags & I915_EXEC_FENCE_OUT) {
out_fence_fd = get_unused_fd_flags(O_CLOEXEC);
if (out_fence_fd < 0) {
err = out_fence_fd;
- goto err_in_fence;
+ goto err_exec_fence;
}
}
@@ -2495,6 +2509,13 @@ i915_gem_do_execbuffer(struct drm_device *dev,
goto err_request;
}
+ if (exec_fence) {
+ err = i915_request_await_execution(eb.request, exec_fence,
+ eb.engine->bond_execute);
+ if (err < 0)
+ goto err_request;
+ }
+
if (fences) {
err = await_fence_array(&eb, fences);
if (err)
@@ -2556,6 +2577,8 @@ i915_gem_do_execbuffer(struct drm_device *dev,
err_out_fence:
if (out_fence_fd != -1)
put_unused_fd(out_fence_fd);
+err_exec_fence:
+ dma_fence_put(exec_fence);
err_in_fence:
dma_fence_put(in_fence);
return err;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index e2da9027bcdf..bdb00ec1f8be 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -604,6 +604,12 @@ typedef struct drm_i915_irq_wait {
*/
#define I915_PARAM_MMAP_GTT_COHERENT 52
+/*
+ * Query whether DRM_I915_GEM_EXECBUFFER2 supports coordination of parallel
+ * execution through use of explicit fence support.
+ * See I915_EXEC_FENCE_OUT and I915_EXEC_FENCE_SUBMIT.
+ */
+#define I915_PARAM_HAS_EXEC_SUBMIT_FENCE 53
/* Must be kept compact -- no holes and well documented */
typedef struct drm_i915_getparam {
@@ -1126,7 +1132,16 @@ struct drm_i915_gem_execbuffer2 {
*/
#define I915_EX
[Intel-gfx] [CI 03/10] drm/i915: Extend I915_CONTEXT_PARAM_SSEU to support local ctx->engine[]
Allow the user to specify a local engine index (as opposed to
class:index) that they can use to refer to a preset engine inside the
ctx->engine[] array defined by an earlier I915_CONTEXT_PARAM_ENGINES.
This will be useful for setting SSEU parameters on virtual engines that
are local to the context and do not have a valid global class:instance
lookup.
Note that due to the ambiguity in using class:instance with
ctx->engines[], if a user supplied engine map is active the user must
specify the engine to alter by its index into the ctx->engines[].
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_context.c | 24
include/uapi/drm/i915_drm.h | 3 ++-
2 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 21bfcd529097..5fdb44714a5c 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -1363,6 +1363,7 @@ static int set_sseu(struct i915_gem_context *ctx,
struct drm_i915_gem_context_param_sseu user_sseu;
struct intel_context *ce;
struct intel_sseu sseu;
+ unsigned long lookup;
int ret;
if (args->size < sizeof(user_sseu))
@@ -1375,10 +1376,17 @@ static int set_sseu(struct i915_gem_context *ctx,
sizeof(user_sseu)))
return -EFAULT;
- if (user_sseu.flags || user_sseu.rsvd)
+ if (user_sseu.rsvd)
return -EINVAL;
- ce = lookup_user_engine(ctx, 0, &user_sseu.engine);
+ if (user_sseu.flags & ~(I915_CONTEXT_SSEU_FLAG_ENGINE_INDEX))
+ return -EINVAL;
+
+ lookup = 0;
+ if (user_sseu.flags & I915_CONTEXT_SSEU_FLAG_ENGINE_INDEX)
+ lookup |= LOOKUP_USER_INDEX;
+
+ ce = lookup_user_engine(ctx, lookup, &user_sseu.engine);
if (IS_ERR(ce))
return PTR_ERR(ce);
@@ -1795,6 +1803,7 @@ static int get_sseu(struct i915_gem_context *ctx,
{
struct drm_i915_gem_context_param_sseu user_sseu;
struct intel_context *ce;
+ unsigned long lookup;
int err;
if (args->size == 0)
@@ -1806,10 +1815,17 @@ static int get_sseu(struct i915_gem_context *ctx,
sizeof(user_sseu)))
return -EFAULT;
- if (user_sseu.flags || user_sseu.rsvd)
+ if (user_sseu.rsvd)
return -EINVAL;
- ce = lookup_user_engine(ctx, 0, &user_sseu.engine);
+ if (user_sseu.flags & ~(I915_CONTEXT_SSEU_FLAG_ENGINE_INDEX))
+ return -EINVAL;
+
+ lookup = 0;
+ if (user_sseu.flags & I915_CONTEXT_SSEU_FLAG_ENGINE_INDEX)
+ lookup |= LOOKUP_USER_INDEX;
+
+ ce = lookup_user_engine(ctx, lookup, &user_sseu.engine);
if (IS_ERR(ce))
return PTR_ERR(ce);
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 8e1bb22926e4..82bd488ed0d1 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1576,9 +1576,10 @@ struct drm_i915_gem_context_param_sseu {
struct i915_engine_class_instance engine;
/*
-* Unused for now. Must be cleared to zero.
+* Unknown flags must be cleared to zero.
*/
__u32 flags;
+#define I915_CONTEXT_SSEU_FLAG_ENGINE_INDEX (1u << 0)
/*
* Mask of slices to enable for the context. Valid values are a subset
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 07/10] drm/i915: Apply an execution_mask to the virtual_engine
Allow the user to direct which physical engines of the virtual engine
they wish to execute one, as sometimes it is necessary to override the
load balancing algorithm.
v2: Only kick the virtual engines on context-out if required
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c| 67 +
drivers/gpu/drm/i915/gt/selftest_lrc.c | 131 +
drivers/gpu/drm/i915/i915_request.c| 1 +
drivers/gpu/drm/i915/i915_request.h| 3 +
4 files changed, 202 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index affa5e2dfce1..0b4d29d4816b 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -509,6 +509,15 @@ execlists_context_schedule_in(struct i915_request *rq)
rq->hw_context->active = rq->engine;
}
+static void kick_siblings(struct i915_request *rq)
+{
+ struct virtual_engine *ve = to_virtual_engine(rq->hw_context->engine);
+ struct i915_request *next = READ_ONCE(ve->request);
+
+ if (next && next->execution_mask & ~rq->execution_mask)
+ tasklet_schedule(&ve->base.execlists.tasklet);
+}
+
static inline void
execlists_context_schedule_out(struct i915_request *rq, unsigned long status)
{
@@ -516,6 +525,18 @@ execlists_context_schedule_out(struct i915_request *rq,
unsigned long status)
intel_engine_context_out(rq->engine);
execlists_context_status_change(rq, status);
trace_i915_request_out(rq);
+
+ /*
+* If this is part of a virtual engine, its next request may have
+* been blocked waiting for access to the active context. We have
+* to kick all the siblings again in case we need to switch (e.g.
+* the next request is not runnable on this engine). Hopefully,
+* we will already have submitted the next request before the
+* tasklet runs and do not need to rebuild each virtual tree
+* and kick everyone again.
+*/
+ if (rq->engine != rq->hw_context->engine)
+ kick_siblings(rq);
}
static u64 execlists_update_context(struct i915_request *rq)
@@ -745,6 +766,9 @@ static bool virtual_matches(const struct virtual_engine *ve,
{
const struct intel_engine_cs *active;
+ if (!(rq->execution_mask & engine->mask)) /* We peeked too soon! */
+ return false;
+
/*
* We track when the HW has completed saving the context image
* (i.e. when we have seen the final CS event switching out of
@@ -3118,12 +3142,44 @@ static const struct intel_context_ops
virtual_context_ops = {
.destroy = virtual_context_destroy,
};
+static intel_engine_mask_t virtual_submission_mask(struct virtual_engine *ve)
+{
+ struct i915_request *rq;
+ intel_engine_mask_t mask;
+
+ rq = READ_ONCE(ve->request);
+ if (!rq)
+ return 0;
+
+ /* The rq is ready for submission; rq->execution_mask is now stable. */
+ mask = rq->execution_mask;
+ if (unlikely(!mask)) {
+ /* Invalid selection, submit to a random engine in error */
+ i915_request_skip(rq, -ENODEV);
+ mask = ve->siblings[0]->mask;
+ }
+
+ GEM_TRACE("%s: rq=%llx:%lld, mask=%x, prio=%d\n",
+ ve->base.name,
+ rq->fence.context, rq->fence.seqno,
+ mask, ve->base.execlists.queue_priority_hint);
+
+ return mask;
+}
+
static void virtual_submission_tasklet(unsigned long data)
{
struct virtual_engine * const ve = (struct virtual_engine *)data;
const int prio = ve->base.execlists.queue_priority_hint;
+ intel_engine_mask_t mask;
unsigned int n;
+ rcu_read_lock();
+ mask = virtual_submission_mask(ve);
+ rcu_read_unlock();
+ if (unlikely(!mask))
+ return;
+
local_irq_disable();
for (n = 0; READ_ONCE(ve->request) && n < ve->num_siblings; n++) {
struct intel_engine_cs *sibling = ve->siblings[n];
@@ -3131,6 +3187,17 @@ static void virtual_submission_tasklet(unsigned long
data)
struct rb_node **parent, *rb;
bool first;
+ if (unlikely(!(mask & sibling->mask))) {
+ if (!RB_EMPTY_NODE(&node->rb)) {
+ spin_lock(&sibling->timeline.lock);
+ rb_erase_cached(&node->rb,
+ &sibling->execlists.virtual);
+ RB_CLEAR_NODE(&node->rb);
+ spin_unlock(&sibling->timeline.lock);
+ }
+ continue;
+ }
+
spin_lock(&sibling->timeline.lock);
if (!RB_EMPTY_NODE(&node->rb)) {
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/
Re: [Intel-gfx] linux-next: Fixes tag needs some work in the drm-intel tree
Quoting Stephen Rothwell (2019-05-20 15:15:38)
> Hi all,
>
> In commit
>
> 0d90ccb70211 ("drm/i915: Delay semaphore submission until the start of the
> signaler")
>
> Fixes tag
>
> Fixes: e88619646971 ("drm/i915: Use HW semaphores for inter-engine synchroni
>
> has these problem(s):
>
> - Subject has leading but no trailing parentheses
> - Subject has leading but no trailing quotes
>
> Please don't split Fixes tags across more than one line.
Thanks for the report.
This was a copy'n paste mishap, detected by our tooling (and fixed by
me) at the time of creating a PR. Unfortunately the check was not being
enforced by tooling at commit time. We'll fix that.
Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 06/10] drm/i915: Load balancing across a virtual engine
Having allowed the user to define a set of engines that they will want
to only use, we go one step further and allow them to bind those engines
into a single virtual instance. Submitting a batch to the virtual engine
will then forward it to any one of the set in a manner as best to
distribute load. The virtual engine has a single timeline across all
engines (it operates as a single queue), so it is not able to concurrently
run batches across multiple engines by itself; that is left up to the user
to submit multiple concurrent batches to multiple queues. Multiple users
will be load balanced across the system.
The mechanism used for load balancing in this patch is a late greedy
balancer. When a request is ready for execution, it is added to each
engine's queue, and when an engine is ready for its next request it
claims it from the virtual engine. The first engine to do so, wins, i.e.
the request is executed at the earliest opportunity (idle moment) in the
system.
As not all HW is created equal, the user is still able to skip the
virtual engine and execute the batch on a specific engine, all within the
same queue. It will then be executed in order on the correct engine,
with execution on other virtual engines being moved away due to the load
detection.
A couple of areas for potential improvement left!
- The virtual engine always take priority over equal-priority tasks.
Mostly broken up by applying FQ_CODEL rules for prioritising new clients,
and hopefully the virtual and real engines are not then congested (i.e.
all work is via virtual engines, or all work is to the real engine).
- We require the breadcrumb irq around every virtual engine request. For
normal engines, we eliminate the need for the slow round trip via
interrupt by using the submit fence and queueing in order. For virtual
engines, we have to allow any job to transfer to a new ring, and cannot
coalesce the submissions, so require the completion fence instead,
forcing the persistent use of interrupts.
- We only drip feed single requests through each virtual engine and onto
the physical engines, even if there was enough work to fill all ELSP,
leaving small stalls with an idle CS event at the end of every request.
Could we be greedy and fill both slots? Being lazy is virtuous for load
distribution on less-than-full workloads though.
Other areas of improvement are more general, such as reducing lock
contention, reducing dispatch overhead, looking at direct submission
rather than bouncing around tasklets etc.
sseu: Lift the restriction to allow sseu to be reconfigured on virtual
engines composed of RENDER_CLASS (rcs).
v2: macroize check_user_mbz()
v3: Cancel virtual engines on wedging
v4: Commence commenting
v5: Replace 64b sibling_mask with a list of class:instance
v6: Drop the one-element array in the uabi
v7: Assert it is an virtual engine in to_virtual_engine()
v8: Skip over holes in [class][inst] so we can selftest with (vcs0, vcs2)
Link: https://github.com/intel/media-driver/pull/283
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine_types.h | 8 +
drivers/gpu/drm/i915/gt/intel_lrc.c | 680 ++-
drivers/gpu/drm/i915/gt/intel_lrc.h | 9 +
drivers/gpu/drm/i915/gt/selftest_lrc.c | 180 +
drivers/gpu/drm/i915/i915_gem.h | 5 +
drivers/gpu/drm/i915/i915_gem_context.c | 116 +++-
drivers/gpu/drm/i915/i915_scheduler.c| 19 +-
drivers/gpu/drm/i915/i915_timeline_types.h | 1 +
include/uapi/drm/i915_drm.h | 39 ++
9 files changed, 1029 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index e381c1c73902..7b47e00fa082 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -227,6 +227,7 @@ struct intel_engine_execlists {
* @queue: queue of requests, in priority lists
*/
struct rb_root_cached queue;
+ struct rb_root_cached virtual;
/**
* @csb_write: control register for Context Switch buffer
@@ -445,6 +446,7 @@ struct intel_engine_cs {
#define I915_ENGINE_HAS_PREEMPTION BIT(2)
#define I915_ENGINE_HAS_SEMAPHORES BIT(3)
#define I915_ENGINE_NEEDS_BREADCRUMB_TASKLET BIT(4)
+#define I915_ENGINE_IS_VIRTUAL BIT(5)
unsigned int flags;
/*
@@ -534,6 +536,12 @@ intel_engine_needs_breadcrumb_tasklet(const struct
intel_engine_cs *engine)
return engine->flags & I915_ENGINE_NEEDS_BREADCRUMB_TASKLET;
}
+static inline bool
+intel_engine_is_virtual(const struct intel_engine_cs *engine)
+{
+ return engine->flags & I915_ENGINE_IS_VIRTUAL;
+}
+
#define instdone_slice_mask(dev_priv__) \
(IS_GEN(dev_priv__, 7) ? \
1 : RUNTIME_INFO(dev_priv__)->sseu.slice_mask)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
i
[Intel-gfx] Comments in Fixes: line (Was: Re: linux-next: Fixes tag needs some work in the drm-intel tree)
We also have an incoming patch where the Fixes: line has a comment in it. Does your tooling account for this when checking the Fixes: line? Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 02/27] trace.pl: Ignore signaling on non i915 fences
On 21/05/2019 08:57, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-20 15:47:14)
From: Tvrtko Ursulin
gem_wsim uses the sw_fence timeline and confuses the script.
v2:
* Check the correct timeline as well. (Chris)
Signed-off-by: Tvrtko Ursulin
---
scripts/trace.pl | 3 +++
1 file changed, 3 insertions(+)
diff --git a/scripts/trace.pl b/scripts/trace.pl
index 8c896cfde6b0..ac141a514055 100755
--- a/scripts/trace.pl
+++ b/scripts/trace.pl
@@ -443,6 +443,9 @@ while (<>) {
} elsif ($tp_name eq 'dma_fence:dma_fence_signaled:') {
my $nkey;
+ next unless $tp{'driver'} eq 'i915' and
+ $tp{'timeline'} eq 'signaled';
Hopefully that remains unique...
Reviewed-by: Chris Wilson
I do recall wanting to remove the strings from all the tracepoints :-p
Eeek.. let's try and not make the request tracing ability even more useless.
Because for trace.pl the decoupled from actual request completion nature
of dma_fence_signaled is depressing enough. I wonder how better tracing
tools view/cope with this.
And I'd also write to Santa to wire me up a real request start, to
distinguish semaphores vs batch execution. In the realm of impossible
wishes yeah.
Persistent breadcrumbs while tracing is another one for which even there
was a patch some time back.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix the interpretation of MAX_PRE-EMPHASIS_REACHED bit inorder to pass Link Layer compliance test number 400.3.1.15
On Mon, May 20, 2019 at 04:25:41PM -0700, Khaled Almahallawy wrote:
> According to DP 1.4 standard, if the source supports four pre-emphasis
> levels, then the source shall set the bit MAX_PRE-EMPHASIS_REACHED = 1 only
> when trasmitter programmed PRE-EMPHASIS_SET field (bits 4:3) to 11b (Level
> 3). Pre-emphasis level 3 is the maximum pre-emphasis level that the source
> supports.
> Currently the MAX_PRE-EMPHASIS_REACHED bit is interpreted as the Max
> Pre-Emphasis level for certain Swing Level. This interpretation fails Link
> Layer compliance test 400.3.1.15 step 17 according to the following Fail
> condition: TRAINING_LANEx_SET.MAX_PRE-EMPHASIS_REACHED = 1 (check all active
> lanes) and the Source DUT supports pre-emphasis level 3 (9.5db).
Hmm. I guess that's correct. The spec doesn't say anything about
per-vswing pre-emphasis when talking about the 'max reached' bit.
>
> Cc: Clint Taylor
> Cc: Manasi Navare
> Signed-off-by: Khaled Almahallawy
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 20
> drivers/gpu/drm/i915/intel_dp.c | 2 +-
> 2 files changed, 1 insertion(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 0af47f343faa..6540c979c098 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2239,26 +2239,6 @@ u8 intel_ddi_dp_voltage_max(struct intel_encoder
> *encoder)
> DP_TRAIN_VOLTAGE_SWING_MASK;
> }
>
> -/*
> - * We assume that the full set of pre-emphasis values can be
> - * used on all DDI platforms. Should that change we need to
> - * rethink this code.
> - */
> -u8 intel_ddi_dp_pre_emphasis_max(struct intel_encoder *encoder, u8
> voltage_swing)
> -{
> - switch (voltage_swing & DP_TRAIN_VOLTAGE_SWING_MASK) {
> - case DP_TRAIN_VOLTAGE_SWING_LEVEL_0:
> - return DP_TRAIN_PRE_EMPH_LEVEL_3;
> - case DP_TRAIN_VOLTAGE_SWING_LEVEL_1:
> - return DP_TRAIN_PRE_EMPH_LEVEL_2;
> - case DP_TRAIN_VOLTAGE_SWING_LEVEL_2:
> - return DP_TRAIN_PRE_EMPH_LEVEL_1;
> - case DP_TRAIN_VOLTAGE_SWING_LEVEL_3:
> - default:
> - return DP_TRAIN_PRE_EMPH_LEVEL_0;
> - }
> -}
> -
> static void cnl_ddi_vswing_program(struct intel_encoder *encoder,
> int level, enum intel_output_type type)
> {
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 77ba4da6b981..f94759e45862 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3541,7 +3541,7 @@ intel_dp_pre_emphasis_max(struct intel_dp *intel_dp, u8
> voltage_swing)
> enum port port = encoder->port;
>
> if (HAS_DDI(dev_priv)) {
> - return intel_ddi_dp_pre_emphasis_max(encoder, voltage_swing);
> + return DP_TRAIN_PRE_EMPH_LEVEL_3;
We're going to have to change this for all platforms.
Also we need to update the code to pick the correct swing/pre-emphasis
when we can't do what is being requested.
The spec says:
"When the combination of the requested pre-emphasis level and voltage
swing exceeds the capability of a DPTX, the DPTX shall set the pre-emphasis
level according to the request and use the highest voltage swing it can
output with the given pre-emphasis level."
and
"When a DPTX reads a request beyond the limits of this Standard, the
DPTX shall set the pre-emphasis level according to the request and set
the highest voltage swing level it can output with the given pre-emphasis
level. If a DPTX is requested for 9.5dB of pre-emphasis level (may be
supported for a DPTX) and cannot support that level, it shall set the
pre-emphasis level to the next highest level, 6dB."
> } else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> switch (voltage_swing & DP_TRAIN_VOLTAGE_SWING_MASK) {
> case DP_TRAIN_VOLTAGE_SWING_LEVEL_0:
> --
> 2.17.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v6][PATCH 03/12] drm/i915: Add intel_color_lut_equal() to compare hw and sw gamma/degamma lut values
On 14-May-19 9:40 PM, Ville Syrjälä wrote:
On Tue, May 14, 2019 at 03:13:21PM +0530, Swati Sharma wrote:
v3: -Rebase
v4: -Renamed intel_compare_color_lut() to intel_color_lut_equal() [Jani]
-Added the default label above the correct label [Jani]
-Corrected smatch warn "variable dereferenced before check" [Dan Carpenter]
v5: -Added condition (!blob1 && !blob2) return true [Jani]
-Called PIPE_CONF_CHECK_COLOR_LUT inside if (!adjust) [Jani]
-Added #undef PIPE_CONF_CHECK_COLOR_LUT [Jani]
v6: -Added func intel_color_get_bit_precision() to get bit precision for
gamma and degamma lut readout depending upon platform and
corresponding to load_luts() [Ankit]
-Added debug log for color para in intel_dump_pipe_config [Jani]
-Made patch11 as patch3 [Jani]
I could think of adding intel_color_get_bit_precision() to be the way
to get away with bit precision problem for degamma and gamma (its like a table
having hard coded values depening on gamma_mode).
If anybody could think of better way then this then please guide.
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i915/intel_color.c | 93
drivers/gpu/drm/i915/intel_color.h | 7 +++
drivers/gpu/drm/i915/intel_display.c | 24 ++
3 files changed, 124 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 50b98ee..1e60369 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -1251,6 +1251,99 @@ static int icl_color_check(struct intel_crtc_state
*crtc_state)
return 0;
}
+void intel_color_get_bit_precision(struct intel_crtc_state *crtc_state, int *bp_gamma)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+
+ if (HAS_GMCH(dev_priv)) {
+ if (IS_CHERRYVIEW(dev_priv)) {
+ if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT) {
+ *bp_gamma = 8;
+ return;
Functions can actually return values.
Not sure I particularly like this function though. We can't fit
the gamma vs. degamm stuff in here neatly. I think per-platform
stuff to determine the precision is required to make this sane.
And it should probably got into intel_color.c to keep things
neatly contained.
Something along the lines of:
i9xx_gamma_precision()
{
if (!gamma_enable)
return 0;
switch (gamma_mode) {
case GAMMA_MODE_MODE_8BIT:
return 8;
case GAMMA_MODE_MODE_10BIT:
return 16;
}
}
chv_gamma_precision()
{
if (cgm_mode & CGM_PIPE_MODE_GAMMA)
return 10;
else
return i9xx_gamma_precision();
}
chv_degamma_precision(crtc_state)
{
if (cgm_mode & CGM_PIPE_MODE_DEGAMMA)
return 14;
else
return 0
}
ilk_gamma_precision()
{
if (!gamma_enable)
return 0;
if ((csc_mode & CSC_POSITION_BEFORE_GAMMA) == 0)
return 0;
switch (gamma_mode) {
case GAMMA_MODE_MODE_8BIT:
return 8;
case GAMMA_MODE_MODE_10BIT:
return 10;
}
}
ilk_degamma_precision()
{
if (!gamma_enable)
return 0;
if ((csc_mode & CSC_POSITION_BEFORE_GAMMA) != 0)
return 0;
switch (gamma_mode) {
case GAMMA_MODE_MODE_8BIT:
return 8;
case GAMMA_MODE_MODE_10BIT:
return 10;
}
}
... extend to ivb, glk, and icl variants too.
ok..will do like this. thanks! sorry i was on leave.
2 queries:
(1) Since intel_color_get_bit_precision() will be used to set bit precision for
gamma and degamma both, it will
return multiple values..should i return values as struct? or sending as
pointer is ok?
if (HAS_GMCH(dev_priv)) {
if (IS_CHERRYVIEW(dev_priv))
*bp_gamma = chv_gamma_precision(crtc_state);
(2) (or) if this method is not fine, should we have function ptr for the same?
Please suggest the best method?
+ }
+ if (crtc_state->cgm_mode == CGM_PIPE_MODE_GAMMA)
+ *bp_gamma = 10;
+ } else if (INTEL_GEN(dev_priv) >= 4) {
+ if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT)
+ *bp_gamma = 8;
+ else
+ *bp_gamma = 16;
+ } else {
+ *bp_gamma = 8;
+ }
+ } else {
+ if (INTEL_GEN(dev_priv) >= 11) {
+ if ((crtc_state->gamma_mode & GAMMA_MODE_MODE_MASK) ==
+ GAMMA_MODE_MODE_8BIT)
+ *bp_gamma = 8;
+
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 24/27] gem_wsim: Discover engines
Hi Tvrtko, On Mon, May 20, 2019 at 03:47:36PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Instead of hardcoding the VCS balancing engines, discover, both with the > new engines query, or with the legacy get_param in the fallback case, so > class based addressing always works. > > v2: > * Simplify has_engine_query check. (Andi) > * Fix assert on uninitialized variable. (Andi) > > Signed-off-by: Tvrtko Ursulin Reviewed-by: Andi Shyti Thanks, Andi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] drm/i915/perf: allow holding preemption on filtered ctx
We would like to make use of perf in Vulkan. The Vulkan API is much
lower level than OpenGL, with applications directly exposed to the
concept of command buffers (pretty much equivalent to our batch
buffers). In Vulkan, queries are always limited in scope to a command
buffer. In OpenGL, the lack of command buffer concept meant that
queries' duration could span multiple command buffers.
With that restriction gone in Vulkan, we would like to simplify
measuring performance just by measuring the deltas between the counter
snapshots written by 2 MI_RECORD_PERF_COUNT commands, rather than the
more complex scheme we currently have in the GL driver, using 2
MI_RECORD_PERF_COUNT commands and doing some post processing on the
stream of OA reports, coming from the global OA buffer, to remove any
unrelated deltas in between the 2 MI_RECORD_PERF_COUNT.
Disabling preemption only apply to a single context with which want to
query performance counters for and is considered a privileged
operation, by default protected by CAP_SYS_ADMIN. It is possible to
enable it for a normal user by disabling the paranoid stream setting.
v2: Store preemption setting in intel_context (Chris)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/gt/intel_context.c | 1 +
drivers/gpu/drm/i915/gt/intel_context_types.h | 3 ++
drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +-
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_perf.c | 35 +++
include/uapi/drm/i915_drm.h | 10 ++
6 files changed, 44 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 5b31e1e05ddd..68a4b888fb1a 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -117,6 +117,7 @@ intel_context_init(struct intel_context *ce,
ce->ops = engine->cops;
ce->sseu = engine->sseu;
ce->saturated = 0;
+ ce->arb_enable = MI_ARB_ENABLE;
INIT_LIST_HEAD(&ce->signal_link);
INIT_LIST_HEAD(&ce->signals);
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 963a312430e6..07f586e3608d 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -65,6 +65,9 @@ struct intel_context {
/** sseu: Control eu/slice partitioning */
struct intel_sseu sseu;
+
+ /** arb_enable: Control preemption */
+ u32 arb_enable;
};
#endif /* __INTEL_CONTEXT_TYPES__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index f263a8374273..2ad95977f7a8 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2085,7 +2085,7 @@ static int gen9_emit_bb_start(struct i915_request *rq,
if (IS_ERR(cs))
return PTR_ERR(cs);
- *cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
+ *cs++ = MI_ARB_ON_OFF | rq->hw_context->arb_enable;
*cs++ = MI_BATCH_BUFFER_START_GEN8 |
(flags & I915_DISPATCH_SECURE ? 0 : BIT(8));
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index f309a0b2ccfc..5871e0cfbab0 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -470,7 +470,7 @@ static int i915_getparam_ioctl(struct drm_device *dev, void
*data,
value = INTEL_INFO(dev_priv)->has_coherent_ggtt;
break;
case I915_PARAM_PERF_REVISION:
- value = 1;
+ value = 2;
break;
default:
DRM_DEBUG("Unknown parameter %d\n", param->param);
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index c4995d5a16d2..8c7fa7f7014b 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -355,6 +355,7 @@ struct perf_open_properties {
u32 sample_flags;
u64 single_context:1;
+ u64 context_disable_preemption:1;
u64 ctx_handle;
/* OA sampling state */
@@ -1201,7 +1202,8 @@ static int i915_oa_read(struct i915_perf_stream *stream,
}
static struct intel_context *oa_pin_context(struct drm_i915_private *i915,
- struct i915_gem_context *ctx)
+ struct i915_gem_context *ctx,
+ bool disable_preemption)
{
struct i915_gem_engines_iter it;
struct intel_context *ce;
@@ -1222,6 +1224,7 @@ static struct intel_context *oa_pin_context(struct
drm_i915_private *i915,
err = intel_context_pin(ce);
if (err == 0) {
i915->perf.oa.pinned_ctx = ce;
+ ce->arb_enable = MI_ARB_DISABLE;
break;
}
}
@@ -1237,19 +1240,22 @@ static s
[Intel-gfx] [PATCH 4/5] drm/i915: add a new perf configuration execbuf parameter
We want the ability to dispatch a set of command buffer to the
hardware, each with a different OA configuration. To achieve this, we
reuse a couple of fields from the execbuf2 struct (I CAN HAZ
execbuf3?) to notify what OA configuration should be used for a batch
buffer. This requires the process making the execbuf with this flag to
also own the perf fd at the time of execbuf.
v2: Add a emit_oa_config() vfunc in the intel_engine_cs (Chris)
Move oa_config vma to active (Chris)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/gt/intel_engine_types.h | 7 ++
drivers/gpu/drm/i915/gt/intel_lrc.c | 1 +
drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 4 +-
drivers/gpu/drm/i915/i915_drv.c | 4 +
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 113 ---
drivers/gpu/drm/i915/i915_perf.c | 14 +--
include/uapi/drm/i915_drm.h | 20 +++-
8 files changed, 142 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index e381c1c73902..766fbbede430 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -445,6 +445,7 @@ struct intel_engine_cs {
#define I915_ENGINE_HAS_PREEMPTION BIT(2)
#define I915_ENGINE_HAS_SEMAPHORES BIT(3)
#define I915_ENGINE_NEEDS_BREADCRUMB_TASKLET BIT(4)
+#define I915_ENGINE_HAS_OA BIT(5)
unsigned int flags;
/*
@@ -534,6 +535,12 @@ intel_engine_needs_breadcrumb_tasklet(const struct
intel_engine_cs *engine)
return engine->flags & I915_ENGINE_NEEDS_BREADCRUMB_TASKLET;
}
+static inline bool
+intel_engine_has_oa(const struct intel_engine_cs *engine)
+{
+ return engine->flags & I915_ENGINE_HAS_OA;
+}
+
#define instdone_slice_mask(dev_priv__) \
(IS_GEN(dev_priv__, 7) ? \
1 : RUNTIME_INFO(dev_priv__)->sseu.slice_mask)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 2ad95977f7a8..cad6fca4ba0f 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2395,6 +2395,7 @@ int intel_execlists_submission_setup(struct
intel_engine_cs *engine)
engine->init_context = gen8_init_rcs_context;
engine->emit_flush = gen8_emit_flush_render;
engine->emit_fini_breadcrumb = gen8_emit_fini_breadcrumb_rcs;
+ engine->flags |= I915_ENGINE_HAS_OA;
}
return 0;
diff --git a/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
b/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
index f0d60affdba3..dc85a3e474b9 100644
--- a/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
@@ -2210,8 +2210,10 @@ static void setup_rcs(struct intel_engine_cs *engine)
engine->irq_enable_mask = I915_USER_INTERRUPT;
}
- if (IS_HASWELL(i915))
+ if (IS_HASWELL(i915)) {
engine->emit_bb_start = hsw_emit_bb_start;
+ engine->flags |= I915_ENGINE_HAS_OA;
+ }
engine->resume = rcs_resume;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 5871e0cfbab0..6d9a15642342 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -472,6 +472,10 @@ static int i915_getparam_ioctl(struct drm_device *dev,
void *data,
case I915_PARAM_PERF_REVISION:
value = 2;
break;
+ case I915_PARAM_HAS_EXEC_PERF_CONFIG:
+ /* Obviously requires perf support. */
+ value = dev_priv->perf.initialized;
+ break;
default:
DRM_DEBUG("Unknown parameter %d\n", param->param);
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index abd564bfa03b..25860d99ffc6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3154,6 +3154,7 @@ int i915_perf_get_oa_config(struct drm_i915_private *i915,
int metrics_set,
struct i915_oa_config **out_config,
struct drm_i915_gem_object **out_obj);
+void i915_oa_config_put(struct i915_oa_config *oa_config);
/* i915_gem_evict.c */
int __must_check i915_gem_evict_something(struct i915_address_space *vm,
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 361c232dde83..3794c6ce71e3 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -288,6 +288,9 @@ struct i915_execbuffer {
*/
int lut_size;
struct hlist_head *buckets; /** ht for relocation handles */
+
+ struct i915_oa_config *oa_config; /** HW configuration for OA, NULL is
not needed. */
+ struct drm_i915_gem_o
[Intel-gfx] [PATCH 1/5] drm/i915/perf: introduce a versioning of the i915-perf uapi
Reporting this version will help application figure out what level of
the support the running kernel provides.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.c | 3 +++
include/uapi/drm/i915_drm.h | 20
2 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 2c7a4318d13c..f309a0b2ccfc 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -469,6 +469,9 @@ static int i915_getparam_ioctl(struct drm_device *dev, void
*data,
case I915_PARAM_MMAP_GTT_COHERENT:
value = INTEL_INFO(dev_priv)->has_coherent_ggtt;
break;
+ case I915_PARAM_PERF_REVISION:
+ value = 1;
+ break;
default:
DRM_DEBUG("Unknown parameter %d\n", param->param);
return -EINVAL;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 3a73f5316766..ad8a3e4f6355 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -598,6 +598,12 @@ typedef struct drm_i915_irq_wait {
*/
#define I915_PARAM_MMAP_GTT_COHERENT 52
+/*
+ * Revision of the i915-perf uAPI. The value returned helps determine what
+ * i915-perf features are available. See drm_i915_perf_property_id.
+ */
+#define I915_PARAM_PERF_REVISION 53
+
/* Must be kept compact -- no holes and well documented */
typedef struct drm_i915_getparam {
@@ -1682,23 +1688,31 @@ enum drm_i915_perf_property_id {
* Open the stream for a specific context handle (as used with
* execbuffer2). A stream opened for a specific context this way
* won't typically require root privileges.
+*
+* This property is available in perf revision 1.
*/
DRM_I915_PERF_PROP_CTX_HANDLE = 1,
/**
* A value of 1 requests the inclusion of raw OA unit reports as
* part of stream samples.
+*
+* This property is available in perf revision 1.
*/
DRM_I915_PERF_PROP_SAMPLE_OA,
/**
* The value specifies which set of OA unit metrics should be
* be configured, defining the contents of any OA unit reports.
+*
+* This property is available in perf revision 1.
*/
DRM_I915_PERF_PROP_OA_METRICS_SET,
/**
* The value specifies the size and layout of OA unit reports.
+*
+* This property is available in perf revision 1.
*/
DRM_I915_PERF_PROP_OA_FORMAT,
@@ -1708,6 +1722,8 @@ enum drm_i915_perf_property_id {
* from this exponent as follows:
*
* 80ns * 2^(period_exponent + 1)
+*
+* This property is available in perf revision 1.
*/
DRM_I915_PERF_PROP_OA_EXPONENT,
@@ -1739,6 +1755,8 @@ struct drm_i915_perf_open_param {
* to close and re-open a stream with the same configuration.
*
* It's undefined whether any pending data for the stream will be lost.
+ *
+ * This ioctl is available in perf revision 1.
*/
#define I915_PERF_IOCTL_ENABLE _IO('i', 0x0)
@@ -1746,6 +1764,8 @@ struct drm_i915_perf_open_param {
* Disable data capture for a stream.
*
* It is an error to try and read a stream that is disabled.
+ *
+ * This ioctl is available in perf revision 1.
*/
#define I915_PERF_IOCTL_DISABLE_IO('i', 0x1)
--
2.21.0.392.gf8f6787159e
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] drm/i915: add support for perf configuration queries
Listing configurations at the moment is supported only through sysfs.
This might cause issues for applications wanting to list
configurations from a container where sysfs isn't available.
This change adds a way to query the number of configurations and their
content through the i915 query uAPI.
v2: Fix sparse warnings (Lionel)
Add support to query configuration using uuid (Lionel)
v3: Fix some inconsistency in uapi header (Lionel)
Fix unlocking when not locked issue (Lionel)
Add debug messages (Lionel)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 6 +
drivers/gpu/drm/i915/i915_perf.c | 4 +
drivers/gpu/drm/i915/i915_query.c | 277 ++
include/uapi/drm/i915_drm.h | 62 ++-
4 files changed, 348 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 25860d99ffc6..6127c6890e0b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1875,6 +1875,12 @@ struct drm_i915_private {
*/
struct list_head metrics_buffers;
+ /*
+* Number of dynamic configurations, you need to hold
+* dev_priv->perf.metrics_lock to access it.
+*/
+ u32 n_metrics;
+
/*
* Lock associated with anything below within this structure
* except exclusive_stream.
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 7b861f12f161..6ab414e0ba1c 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -3432,6 +3432,8 @@ int i915_perf_add_config_ioctl(struct drm_device *dev,
void *data,
goto sysfs_err;
}
+ dev_priv->perf.n_metrics++;
+
mutex_unlock(&dev_priv->perf.metrics_lock);
DRM_DEBUG("Added config %s id=%i\n", oa_config->uuid, oa_config->id);
@@ -3493,6 +3495,8 @@ int i915_perf_remove_config_ioctl(struct drm_device *dev,
void *data,
idr_remove(&dev_priv->perf.metrics_idr, *arg);
+ dev_priv->perf.n_metrics--;
+
DRM_DEBUG("Removed config %s id=%i\n", oa_config->uuid, oa_config->id);
i915_oa_config_put(oa_config);
diff --git a/drivers/gpu/drm/i915/i915_query.c
b/drivers/gpu/drm/i915/i915_query.c
index 782183b78f49..82bd6d973527 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -96,9 +96,286 @@ static int query_topology_info(struct drm_i915_private
*dev_priv,
return total_length;
}
+static int can_copy_perf_config_registers_or_number(u32 user_n_regs,
+ u64 user_regs_ptr,
+ u32 kernel_n_regs)
+{
+ /*
+* We'll just put the number of registers, and won't copy the
+* register.
+*/
+ if (user_n_regs == 0)
+ return 0;
+
+ if (user_n_regs < kernel_n_regs)
+ return -EINVAL;
+
+ if (!access_ok(u64_to_user_ptr(user_regs_ptr),
+ 2 * sizeof(u32) * kernel_n_regs))
+ return -EFAULT;
+
+ return 0;
+}
+
+static int copy_perf_config_registers_or_number(const struct i915_oa_reg
*kernel_regs,
+ u32 kernel_n_regs,
+ u64 user_regs_ptr,
+ u32 *user_n_regs)
+{
+ u32 r;
+
+ if (*user_n_regs == 0) {
+ *user_n_regs = kernel_n_regs;
+ return 0;
+ }
+
+ *user_n_regs = kernel_n_regs;
+
+ for (r = 0; r < kernel_n_regs; r++) {
+ u32 __user *user_reg_ptr =
+ u64_to_user_ptr(user_regs_ptr + sizeof(u32) * r * 2);
+ u32 __user *user_val_ptr =
+ u64_to_user_ptr(user_regs_ptr + sizeof(u32) * r * 2 +
+ sizeof(u32));
+ int ret;
+
+ ret = __put_user(i915_mmio_reg_offset(kernel_regs[r].addr),
+user_reg_ptr);
+ if (ret)
+ return -EFAULT;
+
+ ret = __put_user(kernel_regs[r].value, user_val_ptr);
+ if (ret)
+ return -EFAULT;
+ }
+
+ return 0;
+}
+
+static int query_perf_config_data(struct drm_i915_private *i915,
+ struct drm_i915_query_item *query_item,
+ bool use_uuid)
+{
+ struct drm_i915_query_perf_config __user *user_query_config_ptr =
+ u64_to_user_ptr(query_item->data_ptr);
+ struct drm_i915_perf_oa_config __user *user_config_ptr =
+ u64_to_user_ptr(query_item->data_ptr +
+ sizeof(struct drm_i915_query_perf_config));
+ struct drm_i915_perf_oa_conf
[Intel-gfx] [PATCH 0/5] drm/i915: Vulkan performance query support
Hi all, This small (but maybe not to everybody's taste) series enables us to support performance queries on Vulkan. We've gone through the process to define this as a Vulkan INTEL extension (it should appear on [1] soonish). We'll publish the Mesa side shortly. Cheers, [1] : https://github.com/KhronosGroup/Vulkan-Docs Lionel Landwerlin (5): drm/i915/perf: introduce a versioning of the i915-perf uapi drm/i915/perf: allow holding preemption on filtered ctx drm/i915/perf: allow for CS OA configs to be created lazily drm/i915: add a new perf configuration execbuf parameter drm/i915: add support for perf configuration queries drivers/gpu/drm/i915/gt/intel_context.c | 1 + drivers/gpu/drm/i915/gt/intel_context_types.h | 3 + drivers/gpu/drm/i915/gt/intel_engine_types.h | 7 + drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 1 + drivers/gpu/drm/i915/gt/intel_lrc.c | 3 +- drivers/gpu/drm/i915/gt/intel_ringbuffer.c| 4 +- drivers/gpu/drm/i915/i915_drv.c | 7 + drivers/gpu/drm/i915/i915_drv.h | 29 +- drivers/gpu/drm/i915/i915_gem_execbuffer.c| 113 ++- drivers/gpu/drm/i915/i915_perf.c | 226 +++--- drivers/gpu/drm/i915/i915_query.c | 277 ++ include/uapi/drm/i915_drm.h | 112 ++- 12 files changed, 727 insertions(+), 56 deletions(-) -- 2.21.0.392.gf8f6787159e ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] drm/i915/perf: allow for CS OA configs to be created lazily
Here we introduce a mechanism by which the execbuf part of the i915
driver will be able to request that a batch buffer containing the
programming for a particular OA config be created.
We'll execute these OA configuration buffers right before executing a
set of userspace commands so that a particular user batchbuffer be
executed with a given OA configuration.
This mechanism essentially allows the userspace driver to go through
several OA configuration without having to open/close the i915/perf
stream.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 1 +
drivers/gpu/drm/i915/i915_drv.h | 22 ++-
drivers/gpu/drm/i915/i915_perf.c | 187 ---
3 files changed, 178 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index a34ece53a771..bbcb80cf2a85 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -126,6 +126,7 @@
*/
#define MI_LOAD_REGISTER_IMM(x)MI_INSTR(0x22, 2*(x)-1)
#define MI_LRI_FORCE_POSTED (1<<12)
+#define MI_LOAD_REGISTER_IMM_MAX_REGS (126)
#define MI_STORE_REGISTER_MEMMI_INSTR(0x24, 1)
#define MI_STORE_REGISTER_MEM_GEN8 MI_INSTR(0x24, 2)
#define MI_SRM_LRM_GLOBAL_GTT(1<<22)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1ad3818d2676..abd564bfa03b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1274,6 +1274,10 @@ struct i915_oa_config {
struct attribute *attrs[2];
struct device_attribute sysfs_metric_id;
+ struct drm_i915_gem_object *obj;
+
+ struct list_head vma_link;
+
atomic_t ref_count;
};
@@ -1856,11 +1860,21 @@ struct drm_i915_private {
struct mutex metrics_lock;
/*
-* List of dynamic configurations, you need to hold
-* dev_priv->perf.metrics_lock to access it.
+* List of dynamic configurations (struct i915_oa_config), you
+* need to hold dev_priv->perf.metrics_lock to access it.
*/
struct idr metrics_idr;
+ /*
+* List of dynamic configurations (struct i915_oa_config)
+* which have an allocated buffer in GGTT for reconfiguration,
+* you need to hold dev_priv->perf.metrics_lock to access it.
+* Elements are added to the list lazilly on execbuf (when a
+* particular configuration is requested). The list is freed
+* upon closing the perf stream.
+*/
+ struct list_head metrics_buffers;
+
/*
* Lock associated with anything below within this structure
* except exclusive_stream.
@@ -3136,6 +3150,10 @@ int i915_perf_remove_config_ioctl(struct drm_device
*dev, void *data,
void i915_oa_init_reg_state(struct intel_engine_cs *engine,
struct intel_context *ce,
u32 *reg_state);
+int i915_perf_get_oa_config(struct drm_i915_private *i915,
+ int metrics_set,
+ struct i915_oa_config **out_config,
+ struct drm_i915_gem_object **out_obj);
/* i915_gem_evict.c */
int __must_check i915_gem_evict_something(struct i915_address_space *vm,
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 8c7fa7f7014b..7e0ebd4bc8f2 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -365,9 +365,16 @@ struct perf_open_properties {
int oa_period_exponent;
};
-static void free_oa_config(struct drm_i915_private *dev_priv,
- struct i915_oa_config *oa_config)
+static void put_oa_config(struct i915_oa_config *oa_config)
{
+ if (!atomic_dec_and_test(&oa_config->ref_count))
+ return;
+
+ if (oa_config->obj) {
+ list_del(&oa_config->vma_link);
+ i915_gem_object_put(oa_config->obj);
+ }
+
if (!PTR_ERR(oa_config->flex_regs))
kfree(oa_config->flex_regs);
if (!PTR_ERR(oa_config->b_counter_regs))
@@ -377,38 +384,142 @@ static void free_oa_config(struct drm_i915_private
*dev_priv,
kfree(oa_config);
}
-static void put_oa_config(struct drm_i915_private *dev_priv,
- struct i915_oa_config *oa_config)
+static u32 *write_cs_mi_lri(u32 *cs, const struct i915_oa_reg *reg_data, u32
n_regs)
{
- if (!atomic_dec_and_test(&oa_config->ref_count))
- return;
+ u32 i;
+
+ for (i = 0; i < n_regs; i++) {
+ if ((i % MI_LOAD_REGISTER_IMM_MAX_REGS) == 0) {
+ u32 n_lri = min(n_regs - i,
+
[Intel-gfx] [PATCH] fbcon: Remove fbcon_has_exited
This is unused code since
commit 6104c37094e729f3d4ce65797002112735d49cd1
Author: Daniel Vetter
Date: Tue Aug 1 17:32:07 2017 +0200
fbcon: Make fbcon a built-time depency for fbdev
when fbcon was made a compile-time static dependency of fbdev. We
can't exit fbcon anymore without exiting fbdev first, which only works
if all fbdev drivers have unloaded already. Hence this is all dead
code.
v2: I missed that fbcon_exit is also called from con_deinit stuff, and
there fbcon_has_exited prevents double-cleanup. But we can fix that
by properly resetting con2fb_map[] to all -1, which is used everywhere
else to indicate "no fb_info allocate to this console". With that
change the double-cleanup (which resulted in a module refcount underflow,
among other things) is prevented.
Aside: con2fb_map is a signed char, so don't register more than 128 fb_info
or hilarity will ensue.
v3: CI showed me that I still didn't fully understand what's going on
here. The leaked references in con2fb_map have been used upon
rebinding the fb console in fbcon_init. It worked because fbdev
unregistering still cleaned out con2fb_map, and reset it to info_idx.
If the last fbdev driver unregistered, then it also reset info_idx,
and unregistered the fbcon driver.
Imo that's all a bit fragile, so let's keep the con2fb_map reset to
-1, and in fbcon_init pick info_idx if we're starting fresh. That
means unbinding and rebinding will cleanse the mapping, but why are
you doing that if you want to retain the mapping, so should be fine.
Also, I think info_idx == -1 is impossible in fbcon_init - we
unregister the fbcon in that case. So catch&warn about that.
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
Cc: Hans de Goede
Cc: "Noralf Trønnes"
Cc: Yisheng Xie
Cc: Konstantin Khorenko
Cc: Prarit Bhargava
Cc: Kees Cook
---
drivers/video/fbdev/core/fbcon.c | 39 +---
1 file changed, 6 insertions(+), 33 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 5424051c8e1a..622d336cfc81 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -112,7 +112,6 @@ static int softback_lines;
static int first_fb_vc;
static int last_fb_vc = MAX_NR_CONSOLES - 1;
static int fbcon_is_default = 1;
-static int fbcon_has_exited;
static int primary_device = -1;
static int fbcon_has_console_bind;
@@ -1050,7 +1049,6 @@ static const char *fbcon_startup(void)
info->var.bits_per_pixel);
fbcon_add_cursor_timer(info);
- fbcon_has_exited = 0;
return display_desc;
}
@@ -1064,9 +1062,13 @@ static void fbcon_init(struct vc_data *vc, int init)
int logo = 1, new_rows, new_cols, rows, cols, charcnt = 256;
int cap, ret;
- if (info_idx == -1 || info == NULL)
+ if (WARN_ON(info_idx == -1))
return;
+ if (con2fb_map[vc->vc_num] == -1)
+ con2fb_map[vc->vc_num] = info_idx;
+
+ info = registered_fb[con2fb_map[vc->vc_num]];
cap = info->flags;
if (logo_shown < 0 && console_loglevel <= CONSOLE_LOGLEVEL_QUIET)
@@ -3336,14 +3338,6 @@ static int fbcon_event_notify(struct notifier_block
*self,
struct fb_blit_caps *caps;
int idx, ret = 0;
- /*
-* ignore all events except driver registration and deregistration
-* if fbcon is not active
-*/
- if (fbcon_has_exited && !(action == FB_EVENT_FB_REGISTERED ||
- action == FB_EVENT_FB_UNREGISTERED))
- goto done;
-
switch(action) {
case FB_EVENT_SUSPEND:
fbcon_suspended(info);
@@ -3396,7 +3390,6 @@ static int fbcon_event_notify(struct notifier_block *self,
fbcon_remap_all(idx);
break;
}
-done:
return ret;
}
@@ -3443,9 +3436,6 @@ static ssize_t store_rotate(struct device *device,
int rotate, idx;
char **last = NULL;
- if (fbcon_has_exited)
- return count;
-
console_lock();
idx = con2fb_map[fg_console];
@@ -3468,9 +3458,6 @@ static ssize_t store_rotate_all(struct device *device,
int rotate, idx;
char **last = NULL;
- if (fbcon_has_exited)
- return count;
-
console_lock();
idx = con2fb_map[fg_console];
@@ -3491,9 +3478,6 @@ static ssize_t show_rotate(struct device *device,
struct fb_info *info;
int rotate = 0, idx;
- if (fbcon_has_exited)
- return 0;
-
console_lock();
idx = con2fb_map[fg_console];
@@ -3514,9 +3498,6 @@ static ssize_t show_cursor_blink(struct device *device,
struct fbcon_ops *ops;
int idx, blink = -1;
- if (fbcon_has_exited)
- return 0;
-
console_lock();
idx = con2fb_map[fg_console];
@@ -3543,9 +3524,6 @@ static ssize_t store_cursor_blink
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Fix the interpretation of MAX_PRE-EMPHASIS_REACHED bit inorder to pass Link Layer compliance test number 400.3.1.15 (rev2)
== Series Details == Series: drm/i915: Fix the interpretation of MAX_PRE-EMPHASIS_REACHED bit inorder to pass Link Layer compliance test number 400.3.1.15 (rev2) URL : https://patchwork.freedesktop.org/series/60880/ State : warning == Summary == $ dim checkpatch origin/drm-tip ee90db0cb06a drm/i915: Fix the interpretation of MAX_PRE-EMPHASIS_REACHED bit inorder to pass Link Layer compliance test number 400.3.1.15 -:7: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #7: According to DP 1.4 standard, if the source supports four pre-emphasis levels, then the source shall set the bit MAX_PRE-EMPHASIS_REACHED = 1 only when trasmitter programmed PRE-EMPHASIS_SET field (bits 4:3) to 11b (Level 3). Pre-emphasis level 3 is the maximum pre-emphasis level that the source supports. total: 0 errors, 1 warnings, 0 checks, 34 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] kernel.h: Add non_block_start/end()
On Tue, May 21, 2019 at 08:24:53PM +0900, Tetsuo Handa wrote:
> On 2019/05/21 20:11, Michal Hocko wrote:
> > On Tue 21-05-19 20:04:34, Tetsuo Handa wrote:
> >> On 2019/05/21 19:51, Michal Hocko wrote:
> >>> On Tue 21-05-19 19:44:01, Tetsuo Handa wrote:
> On 2019/05/21 19:06, Daniel Vetter wrote:
> > In some special cases we must not block, but there's not a
> > spinlock, preempt-off, irqs-off or similar critical section already
> > that arms the might_sleep() debug checks. Add a non_block_start/end()
> > pair to annotate these.
> >
> > This will be used in the oom paths of mmu-notifiers, where blocking is
> > not allowed to make sure there's forward progress. Quoting Michal:
> >
> > "The notifier is called from quite a restricted context - oom_reaper -
> > which shouldn't depend on any locks or sleepable conditionals. The code
> > should be swift as well but we mostly do care about it to make a forward
> > progress. Checking for sleepable context is the best thing we could come
> > up with that would describe these demands at least partially."
> >
>
> Can this be checked for OOM notifier as well?
>
> if (!is_memcg_oom(oc)) {
> +non_block_start();
> blocking_notifier_call_chain(&oom_notify_list, 0,
> &freed);
> +non_block_end();
> if (freed > 0)
> /* Got some memory back in the last second. */
> return true;
> }
>
> It is not clear whether i915's oom_notifier function has such dependency.
> >>>
> >>> It is not but then we should be using the non-blocking API if this is
> >>> a real problem. The above code just doesn't make any sense. We have a
> >>> blocking API called and wrapped by non-blocking one.
> >>
> >> OOM notifiers should not depend on any locks or sleepable conditionals.
> >> If some lock directly or indirectly depended on __GFP_DIRECT_RECLAIM,
> >> it will deadlock. Thus, despite blocking API, this should effectively be
> >> non-blocking. All OOM notifier users except i915 seems to be atomic, but
> >> I can't evaluate i915 part...
> >
> > Read again what I've written, please
> >
>
> Question to Daniel: Is i915's oom_notifier function atomic?
It's supposed to not block too much at least, I don't think it's entirely
atomic. Waking up the device (which we need to write some of the ptes)
will take some time and I think acquires a few mutexes, but not 100% sure.
If you want to see, send a patch to intel-gfx m-l and CI will pick it up
and test with our farm of machines.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix the interpretation of MAX_PRE-EMPHASIS_REACHED bit inorder to pass Link Layer compliance test number 400.3.1.15 (rev2)
== Series Details ==
Series: drm/i915: Fix the interpretation of MAX_PRE-EMPHASIS_REACHED bit
inorder to pass Link Layer compliance test number 400.3.1.15 (rev2)
URL : https://patchwork.freedesktop.org/series/60880/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6113 -> Patchwork_13055
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13055/
Known issues
Here are the changes found in Patchwork_13055 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_contexts:
- fi-bdw-gvtdvm: [PASS][1] -> [DMESG-FAIL][2] ([fdo#110235])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6113/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13055/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
- fi-skl-gvtdvm: [PASS][3] -> [DMESG-FAIL][4] ([fdo#110235])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6113/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13055/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html
* igt@i915_selftest@live_hangcheck:
- fi-skl-iommu: [PASS][5] -> [INCOMPLETE][6] ([fdo#108602] /
[fdo#108744])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6113/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13055/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [PASS][7] -> [DMESG-WARN][8] ([fdo#102614])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6113/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13055/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
Possible fixes
* igt@gem_mmap_gtt@basic-copy:
- {fi-icl-u3}:[DMESG-WARN][9] ([fdo#107724]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6113/fi-icl-u3/igt@gem_mmap_...@basic-copy.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13055/fi-icl-u3/igt@gem_mmap_...@basic-copy.html
* igt@kms_frontbuffer_tracking@basic:
- {fi-icl-u2}:[FAIL][11] ([fdo#103167]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6113/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13055/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
Warnings
* igt@i915_selftest@live_hangcheck:
- fi-apl-guc: [INCOMPLETE][13] ([fdo#103927] / [fdo#110624]) ->
[DMESG-FAIL][14] ([fdo#110620])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6113/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13055/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
* igt@runner@aborted:
- fi-apl-guc: [FAIL][15] ([fdo#110624]) -> [FAIL][16] ([fdo#110622])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6113/fi-apl-guc/igt@run...@aborted.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13055/fi-apl-guc/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#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602
[fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
[fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235
[fdo#110620]: https://bugs.freedesktop.org/show_bug.cgi?id=110620
[fdo#110622]: https://bugs.freedesktop.org/show_bug.cgi?id=110622
[fdo#110624]: https://bugs.freedesktop.org/show_bug.cgi?id=110624
Participating hosts (52 -> 45)
--
Additional (1): fi-cml-u2
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-pnv-d510 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6113 -> Patchwork_13055
CI_DRM_6113: ae8881a51dd975344f22da2fbb53b9bf498f4592 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5000: f9961d14d76b3a0fa1296e547f7c065e2f93955c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13055: ee90db0cb06a2d54156db4f8a30660baefb0ed32 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ee90db0cb06a drm/i915: Fix the interpretation of MAX_PRE-EMPHASIS_REACHED bit
inorder to pass Link Layer compliance test number 400.3.1.15
== Logs ==
For m
Re: [Intel-gfx] [PATCH] kernel.h: Add non_block_start/end()
On Tue 21-05-19 14:43:38, Cristopher Lameter wrote: > On Tue, 21 May 2019, Daniel Vetter wrote: > > > In some special cases we must not block, but there's not a > > spinlock, preempt-off, irqs-off or similar critical section already > > that arms the might_sleep() debug checks. Add a non_block_start/end() > > pair to annotate these. > > Just putting preempt on/off around these is not sufficient? It is not a critical section. It is a _debugging_ facility to help discover blocking contexts. -- Michal Hocko SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] kernel.h: Add non_block_start/end()
In some special cases we must not block, but there's not a
spinlock, preempt-off, irqs-off or similar critical section already
that arms the might_sleep() debug checks. Add a non_block_start/end()
pair to annotate these.
This will be used in the oom paths of mmu-notifiers, where blocking is
not allowed to make sure there's forward progress. Quoting Michal:
"The notifier is called from quite a restricted context - oom_reaper -
which shouldn't depend on any locks or sleepable conditionals. The code
should be swift as well but we mostly do care about it to make a forward
progress. Checking for sleepable context is the best thing we could come
up with that would describe these demands at least partially."
Peter also asked whether we want to catch spinlocks on top, but Michal
said those are less of a problem because spinlocks can't have an
indirect dependency upon the page allocator and hence close the loop
with the oom reaper.
Suggested by Michal Hocko.
v2:
- Improve commit message (Michal)
- Also check in schedule, not just might_sleep (Peter)
v3: It works better when I actually squash in the fixup I had lying
around :-/
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Andrew Morton
Cc: Michal Hocko
Cc: David Rientjes
Cc: "Christian König"
Cc: Daniel Vetter
Cc: "Jérôme Glisse"
Cc: linux...@kvack.org
Cc: Masahiro Yamada
Cc: Wei Wang
Cc: Andy Shevchenko
Cc: Thomas Gleixner
Cc: Jann Horn
Cc: Feng Tang
Cc: Kees Cook
Cc: Randy Dunlap
Cc: linux-ker...@vger.kernel.org
Acked-by: Christian König (v1)
Signed-off-by: Daniel Vetter
---
include/linux/kernel.h | 10 +-
include/linux/sched.h | 4
kernel/sched/core.c| 19 ++-
3 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 74b1ee9027f5..b5f2c2ff0eab 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -214,7 +214,9 @@ extern void __cant_sleep(const char *file, int line, int
preempt_offset);
* might_sleep - annotation for functions that can sleep
*
* this macro will print a stack trace if it is executed in an atomic
- * context (spinlock, irq-handler, ...).
+ * context (spinlock, irq-handler, ...). Additional sections where blocking is
+ * not allowed can be annotated with non_block_start() and non_block_end()
+ * pairs.
*
* This is a useful debugging help to be able to catch problems early and not
* be bitten later when the calling function happens to sleep when it is not
@@ -230,6 +232,10 @@ extern void __cant_sleep(const char *file, int line, int
preempt_offset);
# define cant_sleep() \
do { __cant_sleep(__FILE__, __LINE__, 0); } while (0)
# define sched_annotate_sleep()(current->task_state_change = 0)
+# define non_block_start() \
+ do { current->non_block_count++; } while (0)
+# define non_block_end() \
+ do { WARN_ON(current->non_block_count-- == 0); } while (0)
#else
static inline void ___might_sleep(const char *file, int line,
int preempt_offset) { }
@@ -238,6 +244,8 @@ extern void __cant_sleep(const char *file, int line, int
preempt_offset);
# define might_sleep() do { might_resched(); } while (0)
# define cant_sleep() do { } while (0)
# define sched_annotate_sleep() do { } while (0)
+# define non_block_start() do { } while (0)
+# define non_block_end() do { } while (0)
#endif
#define might_sleep_if(cond) do { if (cond) might_sleep(); } while (0)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 11837410690f..7f5b293e72df 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -908,6 +908,10 @@ struct task_struct {
struct mutex_waiter *blocked_on;
#endif
+#ifdef CONFIG_DEBUG_ATOMIC_SLEEP
+ int non_block_count;
+#endif
+
#ifdef CONFIG_TRACE_IRQFLAGS
unsigned intirq_events;
unsigned long hardirq_enable_ip;
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 102dfcf0a29a..ed7755a28465 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3264,13 +3264,22 @@ static noinline void __schedule_bug(struct task_struct
*prev)
/*
* Various schedule()-time debugging checks and statistics:
*/
-static inline void schedule_debug(struct task_struct *prev)
+static inline void schedule_debug(struct task_struct *prev, bool preempt)
{
#ifdef CONFIG_SCHED_STACK_END_CHECK
if (task_stack_end_corrupted(prev))
panic("corrupted stack end detected inside scheduler\n");
#endif
+#ifdef CONFIG_DEBUG_ATOMIC_SLEEP
+ if (!preempt && prev->state && prev->non_block_count) {
+ printk(KERN_ERR "BUG: scheduling in a non-blocking section:
%s/%d/%i\n",
+ prev->comm, prev->pid, prev->non_block_count);
+ dump_stack();
+ add_taint(TAINT_WARN, LOCKDEP_STILL_OK);
+ }
+#endif
+
if (unlikely(in_atomic_preempt_off())) {
Re: [Intel-gfx] [PATCH] kernel.h: Add non_block_start/end()
On Tue, May 21, 2019 at 12:46:38PM +0200, Michal Hocko wrote:
> On Tue 21-05-19 12:06:11, Daniel Vetter wrote:
> > In some special cases we must not block, but there's not a
> > spinlock, preempt-off, irqs-off or similar critical section already
> > that arms the might_sleep() debug checks. Add a non_block_start/end()
> > pair to annotate these.
> >
> > This will be used in the oom paths of mmu-notifiers, where blocking is
> > not allowed to make sure there's forward progress. Quoting Michal:
> >
> > "The notifier is called from quite a restricted context - oom_reaper -
> > which shouldn't depend on any locks or sleepable conditionals. The code
> > should be swift as well but we mostly do care about it to make a forward
> > progress. Checking for sleepable context is the best thing we could come
> > up with that would describe these demands at least partially."
> >
> > Peter also asked whether we want to catch spinlocks on top, but Michal
> > said those are less of a problem because spinlocks can't have an
> > indirect dependency upon the page allocator and hence close the loop
> > with the oom reaper.
> >
> > Suggested by Michal Hocko.
> >
> > v2:
> > - Improve commit message (Michal)
> > - Also check in schedule, not just might_sleep (Peter)
> >
> > v3: It works better when I actually squash in the fixup I had lying
> > around :-/
> >
> > Cc: Peter Zijlstra
> > Cc: Ingo Molnar
> > Cc: Andrew Morton
> > Cc: Michal Hocko
> > Cc: David Rientjes
> > Cc: "Christian König"
> > Cc: Daniel Vetter
> > Cc: "Jérôme Glisse"
> > Cc: linux...@kvack.org
> > Cc: Masahiro Yamada
> > Cc: Wei Wang
> > Cc: Andy Shevchenko
> > Cc: Thomas Gleixner
> > Cc: Jann Horn
> > Cc: Feng Tang
> > Cc: Kees Cook
> > Cc: Randy Dunlap
> > Cc: linux-ker...@vger.kernel.org
> > Acked-by: Christian König (v1)
> > Signed-off-by: Daniel Vetter
>
> I like this in general. The implementation looks reasonable to me but I
> didn't check deeply enough to give my R-by or A-by.
Thanks for all your comments. I'll ask Jerome Glisse to look into this, I
think it'd could be useful for all the HMM work too.
And I sent this out without reply-to the patch it's supposed to replace,
will need to do that again so patchwork and 0day pick up the correct
series. Sry about that noise :-/
-Daniel
>
> > ---
> > include/linux/kernel.h | 10 +-
> > include/linux/sched.h | 4
> > kernel/sched/core.c| 19 ++-
> > 3 files changed, 27 insertions(+), 6 deletions(-)
> >
> > diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> > index 74b1ee9027f5..b5f2c2ff0eab 100644
> > --- a/include/linux/kernel.h
> > +++ b/include/linux/kernel.h
> > @@ -214,7 +214,9 @@ extern void __cant_sleep(const char *file, int line,
> > int preempt_offset);
> > * might_sleep - annotation for functions that can sleep
> > *
> > * this macro will print a stack trace if it is executed in an atomic
> > - * context (spinlock, irq-handler, ...).
> > + * context (spinlock, irq-handler, ...). Additional sections where
> > blocking is
> > + * not allowed can be annotated with non_block_start() and non_block_end()
> > + * pairs.
> > *
> > * This is a useful debugging help to be able to catch problems early and
> > not
> > * be bitten later when the calling function happens to sleep when it is
> > not
> > @@ -230,6 +232,10 @@ extern void __cant_sleep(const char *file, int line,
> > int preempt_offset);
> > # define cant_sleep() \
> > do { __cant_sleep(__FILE__, __LINE__, 0); } while (0)
> > # define sched_annotate_sleep()(current->task_state_change = 0)
> > +# define non_block_start() \
> > + do { current->non_block_count++; } while (0)
> > +# define non_block_end() \
> > + do { WARN_ON(current->non_block_count-- == 0); } while (0)
> > #else
> >static inline void ___might_sleep(const char *file, int line,
> >int preempt_offset) { }
> > @@ -238,6 +244,8 @@ extern void __cant_sleep(const char *file, int line,
> > int preempt_offset);
> > # define might_sleep() do { might_resched(); } while (0)
> > # define cant_sleep() do { } while (0)
> > # define sched_annotate_sleep() do { } while (0)
> > +# define non_block_start() do { } while (0)
> > +# define non_block_end() do { } while (0)
> > #endif
> >
> > #define might_sleep_if(cond) do { if (cond) might_sleep(); } while (0)
> > diff --git a/include/linux/sched.h b/include/linux/sched.h
> > index 11837410690f..7f5b293e72df 100644
> > --- a/include/linux/sched.h
> > +++ b/include/linux/sched.h
> > @@ -908,6 +908,10 @@ struct task_struct {
> > struct mutex_waiter *blocked_on;
> > #endif
> >
> > +#ifdef CONFIG_DEBUG_ATOMIC_SLEEP
> > + int non_block_count;
> > +#endif
> > +
> > #ifdef CONFIG_TRACE_IRQFLAGS
> > unsigned intirq_events;
> > unsigned long hardirq_enable_ip;
> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>
Re: [Intel-gfx] [PATCH] kernel.h: Add non_block_start/end()
On Tue, 21 May 2019, Daniel Vetter wrote: > In some special cases we must not block, but there's not a > spinlock, preempt-off, irqs-off or similar critical section already > that arms the might_sleep() debug checks. Add a non_block_start/end() > pair to annotate these. Just putting preempt on/off around these is not sufficient? If not and you need to add another type of critical section then would this not need to be added to the preempt counters? See include/linux/preempt.h? Looks like there are sufficient bits left to put the counter in there. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for linux-next: manual merge of the drm-misc tree with Linus' tree (rev2)
== Series Details ==
Series: linux-next: manual merge of the drm-misc tree with Linus' tree (rev2)
URL : https://patchwork.freedesktop.org/series/60886/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9ade394d0944 linux-next: manual merge of the drm-misc tree with Linus' tree
-:15: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 8122de54602e ("dt-bindings:
Convert vendor prefixes to json-schema")'
#15:
8122de54602e ("dt-bindings: Convert vendor prefixes to json-schema")
-:19: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit b4a2c0055a4f ("dt-bindings: Add
vendor prefix for VXT Ltd")'
#19:
b4a2c0055a4f ("dt-bindings: Add vendor prefix for VXT Ltd")
-:20: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#20:
b1b0d36bdb15 ("dt-bindings: drm/panel: simple: Add binding for TFC
S9700RTWV43TR-01B")
-:20: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit b1b0d36bdb15 ("dt-bindings:
drm/panel: simple: Add binding for TFC S9700RTWV43TR-01B")'
#20:
b1b0d36bdb15 ("dt-bindings: drm/panel: simple: Add binding for TFC
S9700RTWV43TR-01B")
-:21: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit fbd8b69ab616 ("dt-bindings: Add
vendor prefix for Evervision Electronics")'
#21:
fbd8b69ab616 ("dt-bindings: Add vendor prefix for Evervision Electronics")
-:62: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s)
total: 5 errors, 1 warnings, 0 checks, 24 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/33] fbcon: call fbcon_fb_(un)registered directly
On Mon, May 20, 2019 at 10:37:53AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 20.05.19 um 10:33 schrieb Thomas Zimmermann:
> > Hi
> >
> > Am 20.05.19 um 10:21 schrieb Daniel Vetter:
> > ...
> >> diff --git a/drivers/video/fbdev/core/fbmem.c
> >> b/drivers/video/fbdev/core/fbmem.c
> >> index fc3d34a8ea5b..ae2db31eeba7 100644
> >> --- a/drivers/video/fbdev/core/fbmem.c
> >> +++ b/drivers/video/fbdev/core/fbmem.c
> >> @@ -1660,7 +1660,6 @@ MODULE_PARM_DESC(lockless_register_fb,
> >> static int do_register_framebuffer(struct fb_info *fb_info)
> >> {
> >>int i, ret;
> >> - struct fb_event event;
> >>struct fb_videomode mode;
> >>
> >>if (fb_check_foreignness(fb_info))
> >> @@ -1723,7 +1722,6 @@ static int do_register_framebuffer(struct fb_info
> >> *fb_info)
> >>fb_add_videomode(&mode, &fb_info->modelist);
> >>registered_fb[i] = fb_info;
> >>
> >> - event.info = fb_info;
> >>if (!lockless_register_fb)
> >>console_lock();
> >>else
> >> @@ -1732,9 +1730,8 @@ static int do_register_framebuffer(struct fb_info
> >> *fb_info)
> >>ret = -ENODEV;
> >>goto unlock_console;
> >>}
> >> - ret = 0;
> >>
> >> - fb_notifier_call_chain(FB_EVENT_FB_REGISTERED, &event);
> >> + ret = fbcon_fb_registered(fb_info);
> >
> > What about backlight drivers? [1] Apparently these also use the
> > notifiers. [2] From my understanding, backlight drivers would stop
> > working with this change.
>
> I just saw that backlight drivers only care about blanking and
> unblanking. Never mind then.
I did screw this up for one event for the mode changes. But should be
fixed in the next series.
I also added a patch to simplify the backlight/lcd notifier, since it
doesn't need to filter events anymore after this series - the only events
left are the ones backlight cares about.
Cheers, Daniel
>
> Best regards
> Thomas
>
> >
> > Best regards
> > Thomas
> >
> > [1]
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/video/backlight
> > [2]
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/video/backlight/backlight.c#n40
> >
> >>unlock_fb_info(fb_info);
> >> unlock_console:
> >>if (!lockless_register_fb)
> >> @@ -1771,7 +1768,6 @@ static int __unlink_framebuffer(struct fb_info
> >> *fb_info);
> >>
> >> static int do_unregister_framebuffer(struct fb_info *fb_info)
> >> {
> >> - struct fb_event event;
> >>int ret;
> >>
> >>ret = unbind_console(fb_info);
> >> @@ -1789,9 +1785,8 @@ static int do_unregister_framebuffer(struct fb_info
> >> *fb_info)
> >>registered_fb[fb_info->node] = NULL;
> >>num_registered_fb--;
> >>fb_cleanup_device(fb_info);
> >> - event.info = fb_info;
> >>console_lock();
> >> - fb_notifier_call_chain(FB_EVENT_FB_UNREGISTERED, &event);
> >> + fbcon_fb_unregistered(fb_info);
> >>console_unlock();
> >>
> >>/* this may free fb info */
> >> diff --git a/include/linux/fb.h b/include/linux/fb.h
> >> index f52ef0ad6781..701abaf79c87 100644
> >> --- a/include/linux/fb.h
> >> +++ b/include/linux/fb.h
> >> @@ -136,10 +136,6 @@ struct fb_cursor_user {
> >> #define FB_EVENT_RESUME 0x03
> >> /* An entry from the modelist was removed */
> >> #define FB_EVENT_MODE_DELETE0x04
> >> -/* A driver registered itself */
> >> -#define FB_EVENT_FB_REGISTERED 0x05
> >> -/* A driver unregistered itself */
> >> -#define FB_EVENT_FB_UNREGISTERED0x06
> >> /* CONSOLE-SPECIFIC: get console to framebuffer mapping */
> >> #define FB_EVENT_GET_CONSOLE_MAP0x07
> >> /* CONSOLE-SPECIFIC: set console to framebuffer mapping */
> >> diff --git a/include/linux/fbcon.h b/include/linux/fbcon.h
> >> index f68a7db14165..94a71e9e1257 100644
> >> --- a/include/linux/fbcon.h
> >> +++ b/include/linux/fbcon.h
> >> @@ -4,9 +4,13 @@
> >> #ifdef CONFIG_FRAMEBUFFER_CONSOLE
> >> void __init fb_console_init(void);
> >> void __exit fb_console_exit(void);
> >> +int fbcon_fb_registered(struct fb_info *info);
> >> +void fbcon_fb_unregistered(struct fb_info *info);
> >> #else
> >> static inline void fb_console_init(void) {}
> >> static inline void fb_console_exit(void) {}
> >> +static inline int fbcon_fb_registered(struct fb_info *info) { return 0; }
> >> +static inline void fbcon_fb_unregistered(struct fb_info *info) {}
> >> #endif
> >>
> >> #endif /* _LINUX_FBCON_H */
> >>
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
> GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
> HRB 21284 (AG Nürnberg)
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for linux-next: manual merge of the drm-misc tree with Linus' tree (rev2)
== Series Details ==
Series: linux-next: manual merge of the drm-misc tree with Linus' tree (rev2)
URL : https://patchwork.freedesktop.org/series/60886/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6114 -> Patchwork_13056
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13056/
Known issues
Here are the changes found in Patchwork_13056 that come from known issues:
### IGT changes ###
Possible fixes
* igt@gem_basic@create-fd-close:
- {fi-icl-u3}:[DMESG-WARN][1] ([fdo#107724]) -> [PASS][2] +2
similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-icl-u3/igt@gem_ba...@create-fd-close.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13056/fi-icl-u3/igt@gem_ba...@create-fd-close.html
* igt@i915_selftest@live_contexts:
- fi-skl-gvtdvm: [DMESG-FAIL][3] ([fdo#110235]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13056/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html
* igt@i915_selftest@live_hangcheck:
- {fi-icl-y}: [INCOMPLETE][5] ([fdo#107713] / [fdo#108569]) ->
[PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-icl-y/igt@i915_selftest@live_hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13056/fi-icl-y/igt@i915_selftest@live_hangcheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235
Participating hosts (53 -> 45)
--
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-bsw-n3050
fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6114 -> Patchwork_13056
CI_DRM_6114: 8691fe536e41c852d3d420ed09b1d5f9916031e7 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5000: f9961d14d76b3a0fa1296e547f7c065e2f93955c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13056: 9ade394d094435126ce59cff5f9dd70bd0891de0 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
9ade394d0944 linux-next: manual merge of the drm-misc tree with Linus' tree
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13056/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 02/27] trace.pl: Ignore signaling on non i915 fences
Quoting Tvrtko Ursulin (2019-05-21 14:22:18)
>
> On 21/05/2019 08:57, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-05-20 15:47:14)
> >> From: Tvrtko Ursulin
> >>
> >> gem_wsim uses the sw_fence timeline and confuses the script.
> >>
> >> v2:
> >> * Check the correct timeline as well. (Chris)
> >>
> >> Signed-off-by: Tvrtko Ursulin
> >> ---
> >> scripts/trace.pl | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/scripts/trace.pl b/scripts/trace.pl
> >> index 8c896cfde6b0..ac141a514055 100755
> >> --- a/scripts/trace.pl
> >> +++ b/scripts/trace.pl
> >> @@ -443,6 +443,9 @@ while (<>) {
> >> } elsif ($tp_name eq 'dma_fence:dma_fence_signaled:') {
> >> my $nkey;
> >>
> >> + next unless $tp{'driver'} eq 'i915' and
> >> + $tp{'timeline'} eq 'signaled';
> >
> > Hopefully that remains unique...
> > Reviewed-by: Chris Wilson
> >
> > I do recall wanting to remove the strings from all the tracepoints :-p
>
> Eeek.. let's try and not make the request tracing ability even more useless.
You have the context id, which is supposed to be unique (so long as we don't
run for a few years, should be). Actually, wouldn't that be better here?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for kernel.h: Add non_block_start/end()
== Series Details ==
Series: kernel.h: Add non_block_start/end()
URL : https://patchwork.freedesktop.org/series/60896/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
945d83c6e58d kernel.h: Add non_block_start/end()
-:77: WARNING:SINGLE_STATEMENT_DO_WHILE_MACRO: Single statement macros should
not use a do {} while (0) loop
#77: FILE: include/linux/kernel.h:235:
+# define non_block_start() \
+ do { current->non_block_count++; } while (0)
-:79: WARNING:SINGLE_STATEMENT_DO_WHILE_MACRO: Single statement macros should
not use a do {} while (0) loop
#79: FILE: include/linux/kernel.h:237:
+# define non_block_end() \
+ do { WARN_ON(current->non_block_count-- == 0); } while (0)
-:126: WARNING:PREFER_PR_LEVEL: Prefer [subsystem eg:
netdev]_err([subsystem]dev, ... then dev_err(dev, ... then pr_err(... to
printk(KERN_ERR ...
#126: FILE: kernel/sched/core.c:3276:
+ printk(KERN_ERR "BUG: scheduling in a non-blocking section:
%s/%d/%i\n",
-:127: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#127: FILE: kernel/sched/core.c:3277:
+ printk(KERN_ERR "BUG: scheduling in a non-blocking section:
%s/%d/%i\n",
+ prev->comm, prev->pid, prev->non_block_count);
-:164: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 4 warnings, 1 checks, 87 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] mm, notifier: Catch sleeping/blocking for !blockable
On Mon, May 20, 2019 at 11:39:44PM +0200, Daniel Vetter wrote:
> We need to make sure implementations don't cheat and don't have a
> possible schedule/blocking point deeply burried where review can't
> catch it.
>
> I'm not sure whether this is the best way to make sure all the
> might_sleep() callsites trigger, and it's a bit ugly in the code flow.
> But it gets the job done.
>
> Inspired by an i915 patch series which did exactly that, because the
> rules haven't been entirely clear to us.
>
> v2: Use the shiny new non_block_start/end annotations instead of
> abusing preempt_disable/enable.
>
> v3: Rebase on top of Glisse's arg rework.
>
> v4: Rebase on top of more Glisse rework.
>
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: David Rientjes
> Cc: "Christian König"
> Cc: Daniel Vetter
> Cc: "Jérôme Glisse"
> Cc: linux...@kvack.org
> Reviewed-by: Christian König
> Signed-off-by: Daniel Vetter
> ---
> mm/mmu_notifier.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
> index c05e406a7cd7..a09e737711d5 100644
> --- a/mm/mmu_notifier.c
> +++ b/mm/mmu_notifier.c
> @@ -176,7 +176,13 @@ int __mmu_notifier_invalidate_range_start(struct
> mmu_notifier_range *range)
> id = srcu_read_lock(&srcu);
> hlist_for_each_entry_rcu(mn, &range->mm->mmu_notifier_mm->list, hlist) {
> if (mn->ops->invalidate_range_start) {
> - int _ret = mn->ops->invalidate_range_start(mn, range);
> + int _ret;
> +
> + if (!mmu_notifier_range_blockable(range))
> + non_block_start();
> + _ret = mn->ops->invalidate_range_start(mn, range);
> + if (!mmu_notifier_range_blockable(range))
> + non_block_end();
This is a taste thing so feel free to ignore it as maybe other
will dislike more what i prefer:
+ if (!mmu_notifier_range_blockable(range)) {
+ non_block_start();
+ _ret = mn->ops->invalidate_range_start(mn,
range);
+ non_block_end();
+ } else
+ _ret = mn->ops->invalidate_range_start(mn,
range);
If only we had predicate on CPU like on GPU :)
In any case:
Reviewed-by: Jérôme Glisse
> if (_ret) {
> pr_info("%pS callback failed with %d in
> %sblockable context.\n",
> mn->ops->invalidate_range_start, _ret,
> --
> 2.20.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] mm, notifier: Add a lockdep map for invalidate_range_start
On Mon, May 20, 2019 at 11:39:45PM +0200, Daniel Vetter wrote: > This is a similar idea to the fs_reclaim fake lockdep lock. It's > fairly easy to provoke a specific notifier to be run on a specific > range: Just prep it, and then munmap() it. > > A bit harder, but still doable, is to provoke the mmu notifiers for > all the various callchains that might lead to them. But both at the > same time is really hard to reliable hit, especially when you want to > exercise paths like direct reclaim or compaction, where it's not > easy to control what exactly will be unmapped. > > By introducing a lockdep map to tie them all together we allow lockdep > to see a lot more dependencies, without having to actually hit them > in a single challchain while testing. > > Aside: Since I typed this to test i915 mmu notifiers I've only rolled > this out for the invaliate_range_start callback. If there's > interest, we should probably roll this out to all of them. But my > undestanding of core mm is seriously lacking, and I'm not clear on > whether we need a lockdep map for each callback, or whether some can > be shared. I need to read more on lockdep but it is legal to have mmu notifier invalidation within each other. For instance when you munmap you might split a huge pmd and it will trigger a second invalidate range while the munmap one is not done yet. Would that trigger the lockdep here ? Worst case i can think of is 2 invalidate_range_start chain one after the other. I don't think you can triggers a 3 levels nesting but maybe. Cheers, Jérôme ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] mm: Check if mmu notifier callbacks are allowed to fail
On Mon, May 20, 2019 at 11:39:42PM +0200, Daniel Vetter wrote:
> Just a bit of paranoia, since if we start pushing this deep into
> callchains it's hard to spot all places where an mmu notifier
> implementation might fail when it's not allowed to.
>
> Inspired by some confusion we had discussing i915 mmu notifiers and
> whether we could use the newly-introduced return value to handle some
> corner cases. Until we realized that these are only for when a task
> has been killed by the oom reaper.
>
> An alternative approach would be to split the callback into two
> versions, one with the int return value, and the other with void
> return value like in older kernels. But that's a lot more churn for
> fairly little gain I think.
>
> Summary from the m-l discussion on why we want something at warning
> level: This allows automated tooling in CI to catch bugs without
> humans having to look at everything. If we just upgrade the existing
> pr_info to a pr_warn, then we'll have false positives. And as-is, no
> one will ever spot the problem since it's lost in the massive amounts
> of overall dmesg noise.
>
> v2: Drop the full WARN_ON backtrace in favour of just a pr_warn for
> the problematic case (Michal Hocko).
>
> v3: Rebase on top of Glisse's arg rework.
>
> v4: More rebase on top of Glisse reworking everything.
>
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: "Christian König"
> Cc: David Rientjes
> Cc: Daniel Vetter
> Cc: "Jérôme Glisse"
> Cc: linux...@kvack.org
> Cc: Paolo Bonzini
> Reviewed-by: Christian König
> Signed-off-by: Daniel Vetter
Reviewed-by: Jérôme Glisse
> ---
> mm/mmu_notifier.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
> index ee36068077b6..c05e406a7cd7 100644
> --- a/mm/mmu_notifier.c
> +++ b/mm/mmu_notifier.c
> @@ -181,6 +181,9 @@ int __mmu_notifier_invalidate_range_start(struct
> mmu_notifier_range *range)
> pr_info("%pS callback failed with %d in
> %sblockable context.\n",
> mn->ops->invalidate_range_start, _ret,
> !mmu_notifier_range_blockable(range) ?
> "non-" : "");
> + if (!mmu_notifier_range_blockable(range))
> + pr_warn("%pS callback failure not
> allowed\n",
> +
> mn->ops->invalidate_range_start);
> ret = _ret;
> }
> }
> --
> 2.20.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for kernel.h: Add non_block_start/end()
== Series Details ==
Series: kernel.h: Add non_block_start/end()
URL : https://patchwork.freedesktop.org/series/60896/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6114 -> Patchwork_13057
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13057/
Known issues
Here are the changes found in Patchwork_13057 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13057/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-skl-6600u: [PASS][3] -> [FAIL][4] ([fdo#107707])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-skl-6600u/igt@i915_pm_...@basic-pci-d3-state.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13057/fi-skl-6600u/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq: [PASS][5] -> [FAIL][6] ([fdo#108511])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13057/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live_hangcheck:
- fi-skl-iommu: [PASS][7] -> [INCOMPLETE][8] ([fdo#108602] /
[fdo#108744])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13057/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
Possible fixes
* igt@gem_basic@create-fd-close:
- {fi-icl-u3}:[DMESG-WARN][9] ([fdo#107724]) -> [PASS][10] +2
similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-icl-u3/igt@gem_ba...@create-fd-close.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13057/fi-icl-u3/igt@gem_ba...@create-fd-close.html
* igt@i915_selftest@live_contexts:
- fi-bdw-gvtdvm: [DMESG-FAIL][11] ([fdo#110235]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13057/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
* igt@i915_selftest@live_hangcheck:
- {fi-icl-y}: [INCOMPLETE][13] ([fdo#107713] / [fdo#108569]) ->
[PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-icl-y/igt@i915_selftest@live_hangcheck.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13057/fi-icl-y/igt@i915_selftest@live_hangcheck.html
Warnings
* igt@i915_selftest@live_hangcheck:
- fi-apl-guc: [FAIL][15] ([fdo#110623]) -> [DMESG-FAIL][16]
([fdo#110620])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13057/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107707]: https://bugs.freedesktop.org/show_bug.cgi?id=107707
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602
[fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
[fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235
[fdo#110620]: https://bugs.freedesktop.org/show_bug.cgi?id=110620
[fdo#110623]: https://bugs.freedesktop.org/show_bug.cgi?id=110623
Participating hosts (53 -> 44)
--
Missing(9): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-gdg-551 fi-pnv-d510 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6114 -> Patchwork_13057
CI_DRM_6114: 8691fe536e41c852d3d420ed09b1d5f9916031e7 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5000: f9961d14d76b3a0fa1296e547f7c065e2f93955c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13057: 945d83c6e58dc19eb0eabf72d9b8ea5a4331341d @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
945d83c6e58d kernel.h: Add non_block_start/end()
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Expand subslice mask
On Thu, 2019-05-16 at 15:40 -0700, Daniele Ceraolo Spurio wrote:
>
>
> > --- a/drivers/gpu/drm/i915/gt/intel_sseu.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_sseu.h
> > @@ -9,16 +9,18 @@
> >
> > #include
> > #include
> > +#include
>
> AFAICS this header is not needed anymore. With it removed:
>
> Reviewed-by: Daniele Ceraolo Spurio
Thanks for the review!
I do not believe I have push rights to drm-tip at this point. Can you
help with merging this series?
Thanks,
Stuart
>
> Daniele
>
> >
> > struct drm_i915_private;
> >
> > #define GEN_MAX_SLICES(6) /* CNL upper bound */
> > #define GEN_MAX_SUBSLICES (8) /* ICL upper bound */
> > #define GEN_SSEU_STRIDE(max_entries) DIV_ROUND_UP(max_entries,
> > BITS_PER_BYTE)
> > +#define GEN_MAX_SUBSLICE_STRIDE GEN_SSEU_STRIDE(GEN_MAX_SUBSLICES)
> >
> > struct sseu_dev_info {
> > u8 slice_mask;
> > - u8 subslice_mask[GEN_MAX_SLICES];
> > + u8 subslice_mask[GEN_MAX_SLICES * GEN_MAX_SUBSLICE_STRIDE];
> > u16 eu_total;
> > u8 eu_per_subslice;
> > u8 min_eu_in_pool;
> > @@ -33,6 +35,9 @@ struct sseu_dev_info {
> > u8 max_subslices;
> > u8 max_eus_per_subslice;
> >
> > + u8 ss_stride;
> > + u8 eu_stride;
> > +
> > /* We don't have more than 8 eus per subslice at the moment and
> > as we
> > * store eus enabled using bits, no need to multiply by eus per
> > * subslice.
> > @@ -63,12 +68,33 @@ intel_sseu_from_device_info(const struct
> > sseu_dev_info *sseu)
> > return value;
> > }
> >
> > +static inline bool
> > +intel_sseu_has_subslice(const struct sseu_dev_info *sseu, int
> > slice,
> > + int subslice)
> > +{
> > + u8 mask = sseu->subslice_mask[slice * sseu->ss_stride +
> > + subslice / BITS_PER_BYTE];
> > +
> > + return mask & BIT(subslice % BITS_PER_BYTE);
> > +}
> > +
> > +void intel_sseu_set_info(struct sseu_dev_info *sseu, u8
> > max_slices,
> > +u8 max_subslices, u8 max_eus_per_subslice);
> > +
> > unsigned int
> > intel_sseu_subslice_total(const struct sseu_dev_info *sseu);
> >
> > unsigned int
> > intel_sseu_subslices_per_slice(const struct sseu_dev_info *sseu,
> > u8 slice);
> >
> > +void intel_sseu_copy_subslices(const struct sseu_dev_info *sseu,
> > int slice,
> > + u8 *to_mask);
> > +
> > +u32 intel_sseu_get_subslices(const struct sseu_dev_info *sseu, u8
> > slice);
> > +
> > +void intel_sseu_set_subslices(struct sseu_dev_info *sseu, int
> > slice,
> > + u32 ss_mask);
> > +
> > u32 intel_sseu_make_rpcs(struct drm_i915_private *i915,
> > const struct intel_sseu *req_sseu);
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > index 43e290306551..8437f9d918ec 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > @@ -767,7 +767,7 @@ wa_init_mcr(struct drm_i915_private *i915,
> > struct i915_wa_list *wal)
> > u32 slice = fls(sseu->slice_mask);
> > u32 fuse3 =
> > intel_uncore_read(&i915->uncore,
> > GEN10_MIRROR_FUSE3);
> > - u8 ss_mask = sseu->subslice_mask[slice];
> > + u32 ss_mask = intel_sseu_get_subslices(sseu, slice);
> >
> > u8 enabled_mask = (ss_mask | ss_mask >>
> >GEN10_L3BANK_PAIR_COUNT) &
> > GEN10_L3BANK_MASK;
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index a26015722405..46365ab957e6 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -1259,6 +1259,7 @@ static void i915_instdone_info(struct
> > drm_i915_private *dev_priv,
> >struct seq_file *m,
> >struct intel_instdone *instdone)
> > {
> > + struct sseu_dev_info *sseu = &RUNTIME_INFO(dev_priv)->sseu;
> > int slice;
> > int subslice;
> >
> > @@ -1274,11 +1275,11 @@ static void i915_instdone_info(struct
> > drm_i915_private *dev_priv,
> > if (INTEL_GEN(dev_priv) <= 6)
> > return;
> >
> > - for_each_instdone_slice_subslice(dev_priv, slice, subslice)
> > + for_each_instdone_slice_subslice(dev_priv, sseu, slice,
> > subslice)
> > seq_printf(m, "\t\tSAMPLER_INSTDONE[%d][%d]: 0x%08x\n",
> >slice, subslice, instdone-
> > >sampler[slice][subslice]);
> >
> > - for_each_instdone_slice_subslice(dev_priv, slice, subslice)
> > + for_each_instdone_slice_subslice(dev_priv, sseu, slice,
> > subslice)
> > seq_printf(m, "\t\tROW_INSTDONE[%d][%d]: 0x%08x\n",
> >slice, subslice, instdone-
> > >row[slice][subslice]);
> > }
> > @@ -4072,7 +4073,7 @@ static void gen10_sseu_device_status(struct
> > drm_i915_private *dev_priv,
> >
Re: [Intel-gfx] [PATCH 4/4] mm, notifier: Add a lockdep map for invalidate_range_start
On Tue, May 21, 2019 at 5:41 PM Jerome Glisse wrote: > > On Mon, May 20, 2019 at 11:39:45PM +0200, Daniel Vetter wrote: > > This is a similar idea to the fs_reclaim fake lockdep lock. It's > > fairly easy to provoke a specific notifier to be run on a specific > > range: Just prep it, and then munmap() it. > > > > A bit harder, but still doable, is to provoke the mmu notifiers for > > all the various callchains that might lead to them. But both at the > > same time is really hard to reliable hit, especially when you want to > > exercise paths like direct reclaim or compaction, where it's not > > easy to control what exactly will be unmapped. > > > > By introducing a lockdep map to tie them all together we allow lockdep > > to see a lot more dependencies, without having to actually hit them > > in a single challchain while testing. > > > > Aside: Since I typed this to test i915 mmu notifiers I've only rolled > > this out for the invaliate_range_start callback. If there's > > interest, we should probably roll this out to all of them. But my > > undestanding of core mm is seriously lacking, and I'm not clear on > > whether we need a lockdep map for each callback, or whether some can > > be shared. > > I need to read more on lockdep but it is legal to have mmu notifier > invalidation within each other. For instance when you munmap you > might split a huge pmd and it will trigger a second invalidate range > while the munmap one is not done yet. Would that trigger the lockdep > here ? Depends how it's nesting. I'm wrapping the annotation only just around the individual mmu notifier callback, so if the nesting is just - munmap starts - invalidate_range_start #1 - we noticed that there's a huge pmd we need to split - invalidate_range_start #2 - invalidate_reange_end #2 - invalidate_range_end #1 - munmap is done But if otoh it's ok to trigger the 2nd invalidate range from within an mmu_notifier->invalidate_range_start callback, then lockdep will be pissed about that. > Worst case i can think of is 2 invalidate_range_start chain one after > the other. I don't think you can triggers a 3 levels nesting but maybe. Lockdep has special nesting annotations. I think it'd be more an issue of getting those funneled through the entire call chain, assuming we really need that. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: Support for DP YCbCr4:2:0 outputs (rev4)
== Series Details ==
Series: drm/i915/dp: Support for DP YCbCr4:2:0 outputs (rev4)
URL : https://patchwork.freedesktop.org/series/60404/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6114 -> Patchwork_13058
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13058/
Known issues
Here are the changes found in Patchwork_13058 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13058/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
* igt@i915_selftest@live_evict:
- fi-bsw-kefka: [PASS][3] -> [DMESG-WARN][4] ([fdo#107709])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-bsw-kefka/igt@i915_selftest@live_evict.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13058/fi-bsw-kefka/igt@i915_selftest@live_evict.html
Possible fixes
* igt@gem_basic@create-fd-close:
- {fi-icl-u3}:[DMESG-WARN][5] ([fdo#107724]) -> [PASS][6] +2
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-icl-u3/igt@gem_ba...@create-fd-close.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13058/fi-icl-u3/igt@gem_ba...@create-fd-close.html
* igt@i915_selftest@live_contexts:
- fi-bdw-gvtdvm: [DMESG-FAIL][7] ([fdo#110235]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13058/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
* igt@i915_selftest@live_guc:
- fi-apl-guc: [INCOMPLETE][9] ([fdo#103927]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-apl-guc/igt@i915_selftest@live_guc.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13058/fi-apl-guc/igt@i915_selftest@live_guc.html
* igt@i915_selftest@live_hangcheck:
- fi-apl-guc: [FAIL][11] ([fdo#110623]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13058/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
- {fi-icl-y}: [INCOMPLETE][13] ([fdo#107713] / [fdo#108569]) ->
[PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-icl-y/igt@i915_selftest@live_hangcheck.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13058/fi-icl-y/igt@i915_selftest@live_hangcheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235
[fdo#110623]: https://bugs.freedesktop.org/show_bug.cgi?id=110623
Participating hosts (53 -> 46)
--
Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6114 -> Patchwork_13058
CI_DRM_6114: 8691fe536e41c852d3d420ed09b1d5f9916031e7 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5000: f9961d14d76b3a0fa1296e547f7c065e2f93955c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13058: 76371746ff82abaf846f0af7bd7b7d9f5300e11c @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
76371746ff82 drm/i915/dp: Support DP ports YUV 4:2:0 output to GEN11
f29f4240b480 drm/i915/dp: Change a link bandwidth computation for DP
d912bcd4ae96 drm/i915/dp: Add a support of YCBCR 4:2:0 to DP MSA
24ed527b307e drm/i915/dp: Program VSC Header and DB for Pixel
Encoding/Colorimetry Format
7bb473545d41 drm: Rename struct edp_vsc_psr to struct dp_sdp
b70ff5d4a42f drm/i915/dp: Add a config function for YCBCR420 outputs
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13058/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,01/10] drm/i915: Restore control over ppgtt for context creation ABI
== Series Details ==
Series: series starting with [CI,01/10] drm/i915: Restore control over ppgtt
for context creation ABI
URL : https://patchwork.freedesktop.org/series/60909/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
0ef328fc3f6f drm/i915: Restore control over ppgtt for context creation ABI
-:81: WARNING:LONG_LINE: line over 100 characters
#81: FILE: include/uapi/drm/i915_drm.h:420:
+#define DRM_IOCTL_I915_GEM_VM_CREATE DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_CREATE, struct drm_i915_gem_vm_control)
-:82: WARNING:LONG_LINE: line over 100 characters
#82: FILE: include/uapi/drm/i915_drm.h:421:
+#define DRM_IOCTL_I915_GEM_VM_DESTROY DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_VM_DESTROY, struct drm_i915_gem_vm_control)
-:82: WARNING:SPACING: space prohibited between function name and open
parenthesis '('
#82: FILE: include/uapi/drm/i915_drm.h:421:
+#define DRM_IOCTL_I915_GEM_VM_DESTROY DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_VM_DESTROY, struct drm_i915_gem_vm_control)
-:82: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in
parentheses
#82: FILE: include/uapi/drm/i915_drm.h:421:
+#define DRM_IOCTL_I915_GEM_VM_DESTROY DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_VM_DESTROY, struct drm_i915_gem_vm_control)
total: 1 errors, 3 warnings, 0 checks, 64 lines checked
9575ded0c3bc drm/i915: Allow a context to define its set of engines
-:437: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'p' - possible side-effects?
#437: FILE: drivers/gpu/drm/i915/i915_utils.h:110:
+#define check_struct_size(p, member, n, sz) \
+ likely(__check_struct_size(sizeof(*(p)), \
+ sizeof(*(p)->member) +
__must_be_array((p)->member), \
+ n, sz))
-:437: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'member' - possible
side-effects?
#437: FILE: drivers/gpu/drm/i915/i915_utils.h:110:
+#define check_struct_size(p, member, n, sz) \
+ likely(__check_struct_size(sizeof(*(p)), \
+ sizeof(*(p)->member) +
__must_be_array((p)->member), \
+ n, sz))
-:437: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'member' may be better as
'(member)' to avoid precedence issues
#437: FILE: drivers/gpu/drm/i915/i915_utils.h:110:
+#define check_struct_size(p, member, n, sz) \
+ likely(__check_struct_size(sizeof(*(p)), \
+ sizeof(*(p)->member) +
__must_be_array((p)->member), \
+ n, sz))
total: 0 errors, 0 warnings, 3 checks, 428 lines checked
f90be06f5e03 drm/i915: Extend I915_CONTEXT_PARAM_SSEU to support local
ctx->engine[]
3a239b80d39c drm/i915: Re-expose SINGLE_TIMELINE flags for context creation
eed623f78dc9 drm/i915: Allow userspace to clone contexts on creation
-:213: ERROR:BRACKET_SPACE: space prohibited before open square bracket '['
#213: FILE: drivers/gpu/drm/i915/i915_gem_context.c:1858:
+#define MAP(x, y) [ilog2(I915_CONTEXT_CLONE_##x)] = y
total: 1 errors, 0 warnings, 0 checks, 235 lines checked
6ba4915637e0 drm/i915: Load balancing across a virtual engine
d9d685610224 drm/i915: Apply an execution_mask to the virtual_engine
e56185ca2f80 drm/i915: Extend execution fence to support a callback
3669fdc42a2b drm/i915/execlists: Virtual engine bonding
3e0369bc2177 drm/i915: Allow specification of parallel execbuf
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,01/10] drm/i915: Restore control over ppgtt for context creation ABI
== Series Details == Series: series starting with [CI,01/10] drm/i915: Restore control over ppgtt for context creation ABI URL : https://patchwork.freedesktop.org/series/60909/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Restore control over ppgtt for context creation ABI Okay! Commit: drm/i915: Allow a context to define its set of engines +drivers/gpu/drm/i915/i915_utils.h:87:13: error: incorrect type in conditional +drivers/gpu/drm/i915/i915_utils.h:87:13: error: undefined identifier '__builtin_mul_overflow' +drivers/gpu/drm/i915/i915_utils.h:87:13:got void +drivers/gpu/drm/i915/i915_utils.h:87:13: warning: call with no type! +drivers/gpu/drm/i915/i915_utils.h:90:13: error: incorrect type in conditional +drivers/gpu/drm/i915/i915_utils.h:90:13: error: undefined identifier '__builtin_add_overflow' +drivers/gpu/drm/i915/i915_utils.h:90:13:got void +drivers/gpu/drm/i915/i915_utils.h:90:13: warning: call with no type! -drivers/gpu/drm/i915/selftests/../i915_utils.h:186:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_utils.h:220:16: warning: expression using sizeof(void) +./include/linux/overflow.h:295:13: error: incorrect type in conditional +./include/linux/overflow.h:295:13: error: not a function +./include/linux/overflow.h:295:13:got void +./include/linux/overflow.h:297:13: error: incorrect type in conditional +./include/linux/overflow.h:297:13: error: not a function +./include/linux/overflow.h:297:13:got void Commit: drm/i915: Extend I915_CONTEXT_PARAM_SSEU to support local ctx->engine[] Okay! Commit: drm/i915: Re-expose SINGLE_TIMELINE flags for context creation Okay! Commit: drm/i915: Allow userspace to clone contexts on creation +drivers/gpu/drm/i915/i915_gem_context.c:1859:17: error: bad integer constant expression +drivers/gpu/drm/i915/i915_gem_context.c:1860:17: error: bad integer constant expression +drivers/gpu/drm/i915/i915_gem_context.c:1861:17: error: bad integer constant expression +drivers/gpu/drm/i915/i915_gem_context.c:1862:17: error: bad integer constant expression +drivers/gpu/drm/i915/i915_gem_context.c:1863:17: error: bad integer constant expression +drivers/gpu/drm/i915/i915_gem_context.c:1864:17: error: bad integer constant expression -drivers/gpu/drm/i915/i915_utils.h:87:13: warning: call with no type! -drivers/gpu/drm/i915/i915_utils.h:90:13: warning: call with no type! -drivers/gpu/drm/i915/selftests/i915_gem_context.c:1266:25: warning: expression using sizeof(void) -drivers/gpu/drm/i915/selftests/i915_gem_context.c:1266:25: warning: expression using sizeof(void) -drivers/gpu/drm/i915/selftests/i915_gem_context.c:454:16: warning: expression using sizeof(void) -drivers/gpu/drm/i915/selftests/i915_gem_context.c:571:33: warning: expression using sizeof(void) -drivers/gpu/drm/i915/selftests/i915_gem_context.c:571:33: warning: expression using sizeof(void) -drivers/gpu/drm/i915/selftests/i915_gem_context.c:693:33: warning: expression using sizeof(void) -drivers/gpu/drm/i915/selftests/i915_gem_context.c:693:33: warning: expression using sizeof(void) +./include/linux/overflow.h:295:13: error: incorrect type in conditional +./include/linux/overflow.h:295:13: error: not a function -./include/linux/overflow.h:295:13: warning: call with no type! +./include/linux/overflow.h:295:13:got void +./include/linux/overflow.h:297:13: error: incorrect type in conditional +./include/linux/overflow.h:297:13: error: not a function -./include/linux/overflow.h:297:13: warning: call with no type! +./include/linux/overflow.h:297:13:got void -./include/linux/slab.h:666:13: warning: call with no type! Commit: drm/i915: Load balancing across a virtual engine +./include/linux/overflow.h:295:13: error: incorrect type in conditional +./include/linux/overflow.h:295:13: error: undefined identifier '__builtin_mul_overflow' +./include/linux/overflow.h:295:13:got void +./include/linux/overflow.h:295:13: warning: call with no type! +./include/linux/overflow.h:297:13: error: incorrect type in conditional +./include/linux/overflow.h:297:13: error: undefined identifier '__builtin_add_overflow' +./include/linux/overflow.h:297:13:got void +./include/linux/overflow.h:297:13: warning: call with no type! +./include/linux/slab.h:666:13: error: not a function Commit: drm/i915: Apply an execution_mask to the virtual_engine Okay! Commit: drm/i915: Extend execution fence to support a callback Okay! Commit: drm/i915/execlists: Virtual engine bonding Okay! Commit: drm/i915: Allow specification of parallel execbuf Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] mm, notifier: Add a lockdep map for invalidate_range_start
On Tue, May 21, 2019 at 06:00:36PM +0200, Daniel Vetter wrote: > On Tue, May 21, 2019 at 5:41 PM Jerome Glisse wrote: > > > > On Mon, May 20, 2019 at 11:39:45PM +0200, Daniel Vetter wrote: > > > This is a similar idea to the fs_reclaim fake lockdep lock. It's > > > fairly easy to provoke a specific notifier to be run on a specific > > > range: Just prep it, and then munmap() it. > > > > > > A bit harder, but still doable, is to provoke the mmu notifiers for > > > all the various callchains that might lead to them. But both at the > > > same time is really hard to reliable hit, especially when you want to > > > exercise paths like direct reclaim or compaction, where it's not > > > easy to control what exactly will be unmapped. > > > > > > By introducing a lockdep map to tie them all together we allow lockdep > > > to see a lot more dependencies, without having to actually hit them > > > in a single challchain while testing. > > > > > > Aside: Since I typed this to test i915 mmu notifiers I've only rolled > > > this out for the invaliate_range_start callback. If there's > > > interest, we should probably roll this out to all of them. But my > > > undestanding of core mm is seriously lacking, and I'm not clear on > > > whether we need a lockdep map for each callback, or whether some can > > > be shared. > > > > I need to read more on lockdep but it is legal to have mmu notifier > > invalidation within each other. For instance when you munmap you > > might split a huge pmd and it will trigger a second invalidate range > > while the munmap one is not done yet. Would that trigger the lockdep > > here ? > > Depends how it's nesting. I'm wrapping the annotation only just around > the individual mmu notifier callback, so if the nesting is just > - munmap starts > - invalidate_range_start #1 > - we noticed that there's a huge pmd we need to split > - invalidate_range_start #2 > - invalidate_reange_end #2 > - invalidate_range_end #1 > - munmap is done Yeah this is how it looks. All the callback from range_start #1 would happens before range_start #2 happens so we should be fine. > > But if otoh it's ok to trigger the 2nd invalidate range from within an > mmu_notifier->invalidate_range_start callback, then lockdep will be > pissed about that. No that would be illegal for a callback to do that. There is no existing callback that would do that at least AFAIK. So we can just say that it is illegal. I would not see the point. > > > Worst case i can think of is 2 invalidate_range_start chain one after > > the other. I don't think you can triggers a 3 levels nesting but maybe. > > Lockdep has special nesting annotations. I think it'd be more an issue > of getting those funneled through the entire call chain, assuming we > really need that. I think we are fine. So this patch looks good. Reviewed-by: Jérôme Glisse ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,01/10] drm/i915: Restore control over ppgtt for context creation ABI
== Series Details ==
Series: series starting with [CI,01/10] drm/i915: Restore control over ppgtt
for context creation ABI
URL : https://patchwork.freedesktop.org/series/60909/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6114 -> Patchwork_13059
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13059/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_13059:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_suspend@basic-s4-devices:
- {fi-icl-u3}:[PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-icl-u3/igt@gem_exec_susp...@basic-s4-devices.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13059/fi-icl-u3/igt@gem_exec_susp...@basic-s4-devices.html
Known issues
Here are the changes found in Patchwork_13059 that come from known issues:
### IGT changes ###
Possible fixes
* igt@gem_basic@create-fd-close:
- {fi-icl-u3}:[DMESG-WARN][3] ([fdo#107724]) -> [PASS][4] +2
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-icl-u3/igt@gem_ba...@create-fd-close.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13059/fi-icl-u3/igt@gem_ba...@create-fd-close.html
* igt@i915_selftest@live_contexts:
- fi-bdw-gvtdvm: [DMESG-FAIL][5] ([fdo#110235]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13059/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
* igt@i915_selftest@live_hangcheck:
- {fi-icl-y}: [INCOMPLETE][7] ([fdo#107713] / [fdo#108569]) ->
[PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-icl-y/igt@i915_selftest@live_hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13059/fi-icl-y/igt@i915_selftest@live_hangcheck.html
Warnings
* igt@i915_selftest@live_hangcheck:
- fi-apl-guc: [FAIL][9] ([fdo#110623]) -> [DMESG-FAIL][10]
([fdo#110620])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13059/fi-apl-guc/igt@i915_selftest@live_hangcheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235
[fdo#110620]: https://bugs.freedesktop.org/show_bug.cgi?id=110620
[fdo#110623]: https://bugs.freedesktop.org/show_bug.cgi?id=110623
Participating hosts (53 -> 46)
--
Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6114 -> Patchwork_13059
CI_DRM_6114: 8691fe536e41c852d3d420ed09b1d5f9916031e7 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5000: f9961d14d76b3a0fa1296e547f7c065e2f93955c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13059: 3e0369bc2177435f07ea0c1d0f5329c8456420cb @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
3e0369bc2177 drm/i915: Allow specification of parallel execbuf
3669fdc42a2b drm/i915/execlists: Virtual engine bonding
e56185ca2f80 drm/i915: Extend execution fence to support a callback
d9d685610224 drm/i915: Apply an execution_mask to the virtual_engine
6ba4915637e0 drm/i915: Load balancing across a virtual engine
eed623f78dc9 drm/i915: Allow userspace to clone contexts on creation
3a239b80d39c drm/i915: Re-expose SINGLE_TIMELINE flags for context creation
f90be06f5e03 drm/i915: Extend I915_CONTEXT_PARAM_SSEU to support local
ctx->engine[]
9575ded0c3bc drm/i915: Allow a context to define its set of engines
0ef328fc3f6f drm/i915: Restore control over ppgtt for context creation ABI
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13059/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm/i915/perf: allow holding preemption on filtered ctx
Quoting Lionel Landwerlin (2019-05-21 15:08:52) > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c > b/drivers/gpu/drm/i915/gt/intel_lrc.c > index f263a8374273..2ad95977f7a8 100644 > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c > @@ -2085,7 +2085,7 @@ static int gen9_emit_bb_start(struct i915_request *rq, > if (IS_ERR(cs)) > return PTR_ERR(cs); > > - *cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE; > + *cs++ = MI_ARB_ON_OFF | rq->hw_context->arb_enable; My prediction is that this will result in this context being reset due to preemption timeouts and the context under profile being banned. Note that preemption timeouts will be the primary means for hang detection for endless batches. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Vulkan performance query support
== Series Details == Series: drm/i915: Vulkan performance query support URL : https://patchwork.freedesktop.org/series/60916/ State : warning == Summary == $ dim checkpatch origin/drm-tip 9577e457931d drm/i915/perf: introduce a versioning of the i915-perf uapi 3744cae4f12a drm/i915/perf: allow holding preemption on filtered ctx 9e8f734b8a37 drm/i915/perf: allow for CS OA configs to be created lazily -:120: CHECK:SPACING: No space is necessary after a cast #120: FILE: drivers/gpu/drm/i915/i915_perf.c:394: + (u32) MI_LOAD_REGISTER_IMM_MAX_REGS); total: 0 errors, 0 warnings, 1 checks, 334 lines checked e3b3246a741b drm/i915: add a new perf configuration execbuf parameter -:176: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #176: FILE: drivers/gpu/drm/i915/i915_gem_execbuffer.c:2089: + oa_vma = i915_vma_instance(eb->oa_bo, + &eb->engine->i915->ggtt.vm, NULL); -:200: CHECK:LINE_SPACING: Please don't use multiple blank lines #200: FILE: drivers/gpu/drm/i915/i915_gem_execbuffer.c:2113: + + -:203: CHECK:LINE_SPACING: Please don't use multiple blank lines #203: FILE: drivers/gpu/drm/i915/i915_gem_execbuffer.c:2116: + + -:370: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #370: FILE: include/uapi/drm/i915_drm.h:1144: +#define I915_EXEC_PERF_CONFIG (1<<20) ^ -:372: CHECK:LINE_SPACING: Please don't use multiple blank lines #372: FILE: include/uapi/drm/i915_drm.h:1146: + + -:373: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #373: FILE: include/uapi/drm/i915_drm.h:1147: +#define __I915_EXEC_UNKNOWN_FLAGS (-(I915_EXEC_PERF_CONFIG<<1)) ^ total: 0 errors, 0 warnings, 6 checks, 305 lines checked bc43d752f0ac drm/i915: add support for perf configuration queries ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Vulkan performance query support
== Series Details == Series: drm/i915: Vulkan performance query support URL : https://patchwork.freedesktop.org/series/60916/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/perf: introduce a versioning of the i915-perf uapi Okay! Commit: drm/i915/perf: allow holding preemption on filtered ctx Okay! Commit: drm/i915/perf: allow for CS OA configs to be created lazily +drivers/gpu/drm/i915/i915_perf.c:393:37: warning: expression using sizeof(void) Commit: drm/i915: add a new perf configuration execbuf parameter Okay! Commit: drm/i915: add support for perf configuration queries Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 1/2] drm/i915: Make sandybridge_pcode_read() deal with the second data register
From: Ville Syrjälä
The pcode mailbox has two data registers. So far we've only ever used
the one, but that's about to change. Expose the second data register to
the callers of sandybridge_pcode_read().
Signed-off-by: Ville Syrjälä
Reviewed-by: Clint Taylor
Reviewed-by: Radhakrishna Sripada
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
drivers/gpu/drm/i915/intel_pm.c | 12 +++-
drivers/gpu/drm/i915/intel_sideband.c | 15 +--
drivers/gpu/drm/i915/intel_sideband.h | 3 ++-
4 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 633a08c0f907..344beab229a0 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1500,7 +1500,7 @@ static int gen6_drpc_info(struct seq_file *m)
if (INTEL_GEN(dev_priv) <= 7)
sandybridge_pcode_read(dev_priv, GEN6_PCODE_READ_RC6VIDS,
- &rc6vids);
+ &rc6vids, NULL);
seq_printf(m, "RC1e Enabled: %s\n",
yesno(rcctl1 & GEN6_RC_CTL_RC1e_ENABLE));
@@ -1783,7 +1783,7 @@ static int i915_ring_freq_table(struct seq_file *m, void
*unused)
ia_freq = gpu_freq;
sandybridge_pcode_read(dev_priv,
GEN6_PCODE_READ_MIN_FREQ_TABLE,
- &ia_freq);
+ &ia_freq, NULL);
seq_printf(m, "%d\t\t%d\t\t\t\t%d\n",
intel_gpu_freq(dev_priv, (gpu_freq *
(IS_GEN9_BC(dev_priv) ||
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index decdd79c3805..8f82cb72d3a6 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2822,7 +2822,7 @@ static void intel_read_wm_latency(struct drm_i915_private
*dev_priv,
val = 0; /* data0 to be programmed to 0 for first set */
ret = sandybridge_pcode_read(dev_priv,
GEN9_PCODE_READ_MEM_LATENCY,
-&val);
+&val, NULL);
if (ret) {
DRM_ERROR("SKL Mailbox read error = %d\n", ret);
@@ -2841,7 +2841,7 @@ static void intel_read_wm_latency(struct drm_i915_private
*dev_priv,
val = 1; /* data0 to be programmed to 1 for second set */
ret = sandybridge_pcode_read(dev_priv,
GEN9_PCODE_READ_MEM_LATENCY,
-&val);
+&val, NULL);
if (ret) {
DRM_ERROR("SKL Mailbox read error = %d\n", ret);
return;
@@ -7072,7 +7072,7 @@ static void gen6_init_rps_frequencies(struct
drm_i915_private *dev_priv)
if (sandybridge_pcode_read(dev_priv,
HSW_PCODE_DYNAMIC_DUTY_CYCLE_CONTROL,
- &ddcc_status) == 0)
+ &ddcc_status, NULL) == 0)
rps->efficient_freq =
clamp_t(u8,
((ddcc_status >> 8) & 0xff),
@@ -7419,7 +7419,8 @@ static void gen6_enable_rc6(struct drm_i915_private
*dev_priv)
GEN6_RC_CTL_HW_ENABLE);
rc6vids = 0;
- ret = sandybridge_pcode_read(dev_priv, GEN6_PCODE_READ_RC6VIDS,
&rc6vids);
+ ret = sandybridge_pcode_read(dev_priv, GEN6_PCODE_READ_RC6VIDS,
+&rc6vids, NULL);
if (IS_GEN(dev_priv, 6) && ret) {
DRM_DEBUG_DRIVER("Couldn't check for BIOS workaround\n");
} else if (IS_GEN(dev_priv, 6) && (GEN6_DECODE_RC6_VID(rc6vids & 0xff)
< 450)) {
@@ -8566,7 +8567,8 @@ void intel_init_gt_powersave(struct drm_i915_private
*dev_priv)
IS_IVYBRIDGE(dev_priv) || IS_HASWELL(dev_priv)) {
u32 params = 0;
- sandybridge_pcode_read(dev_priv, GEN6_READ_OC_PARAMS, ¶ms);
+ sandybridge_pcode_read(dev_priv, GEN6_READ_OC_PARAMS,
+ ¶ms, NULL);
if (params & BIT(31)) { /* OC supported */
DRM_DEBUG_DRIVER("Overclocking supported, max: %dMHz,
overclock: %dMHz\n",
(rps->max_freq & 0xff) * 50,
diff --git a/drivers/gpu/drm/i915/intel_sideband.c
b/drivers/gpu/drm/i915/intel_sideband.c
index 87b5a14c7ca8..a115625e980c 100644
--- a/drivers/gpu/drm/i915/intel_sideband.c
+++ b/drivers/gpu/drm/i915/intel_sideband.c
@@ -374,7 +374,7 @@ static inline int gen7_check_mailbox_status(u32 mbox)
}
static int __
[Intel-gfx] [PATCH v5 2/2] drm/i915: Make sure we have enough memory bandwidth on ICL
From: Ville Syrjälä
ICL has so many planes that it can easily exceed the maximum
effective memory bandwidth of the system. We must therefore check
that we don't exceed that limit.
The algorithm is very magic number heavy and lacks sufficient
explanation for now. We also have no sane way to query the
memory clock and timings, so we must rely on a combination of
raw readout from the memory controller and hardcoded assumptions.
The memory controller values obviously change as the system
jumps between the different SAGV points, so we try to stabilize
it first by disabling SAGV for the duration of the readout.
The utilized bandwidth is tracked via a device wide atomic
private object. That is actually not robust because we can't
afford to enforce strict global ordering between the pipes.
Thus I think I'll need to change this to simply chop up the
available bandwidth between all the active pipes. Each pipe
can then do whatever it wants as long as it doesn't exceed
its budget. That scheme will also require that we assume that
any number of planes could be active at any time.
TODO: make it robust and deal with all the open questions
v2: Sleep longer after disabling SAGV
v3: Poll for the dclk to get raised (seen it take 250ms!)
If the system has 2133MT/s memory then we pointlessly
wait one full second :(
v4: Use the new pcode interface to get the qgv points rather
that using hardcoded numbers
v5: Move the pcode stuff into intel_bw.c (Matt)
s/intel_sagv_info/intel_qgv_info/
Do the NV12/P010 as per spec for now (Matt)
s/IS_ICELAKE/IS_GEN11/
Signed-off-by: Ville Syrjälä
Reviewed-by: Matt Roper
Acked-by: Clint Taylor
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_drv.c | 2 +
drivers/gpu/drm/i915/i915_drv.h | 8 +
drivers/gpu/drm/i915/i915_reg.h | 3 +
drivers/gpu/drm/i915/intel_atomic_plane.c | 27 ++
drivers/gpu/drm/i915/intel_atomic_plane.h | 2 +
drivers/gpu/drm/i915/intel_bw.c | 415 ++
drivers/gpu/drm/i915/intel_bw.h | 47 +++
drivers/gpu/drm/i915/intel_display.c | 40 ++-
drivers/gpu/drm/i915/intel_drv.h | 2 +
10 files changed, 546 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/intel_bw.c
create mode 100644 drivers/gpu/drm/i915/intel_bw.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 68106fe35a04..139a0fc19390 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -138,6 +138,7 @@ i915-y += intel_audio.o \
intel_atomic.o \
intel_atomic_plane.o \
intel_bios.o \
+ intel_bw.o \
intel_cdclk.o \
intel_color.o \
intel_combo_phy.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 2c7a4318d13c..52be525b8b2d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -60,6 +60,7 @@
#include "i915_vgpu.h"
#include "intel_acpi.h"
#include "intel_audio.h"
+#include "intel_bw.h"
#include "intel_cdclk.h"
#include "intel_csr.h"
#include "intel_dp.h"
@@ -1656,6 +1657,7 @@ static int i915_driver_init_hw(struct drm_i915_private
*dev_priv)
*/
intel_get_dram_info(dev_priv);
+ intel_bw_init_hw(dev_priv);
return 0;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1ad3818d2676..558d065db361 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -54,6 +54,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1841,6 +1842,13 @@ struct drm_i915_private {
} type;
} dram_info;
+ struct intel_bw_info {
+ int num_planes;
+ int deratedbw[3];
+ } max_bw[6];
+
+ struct drm_private_obj bw_obj;
+
struct i915_runtime_pm runtime_pm;
struct {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e97c47fca645..399366a41524 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8774,6 +8774,9 @@ enum {
#define GEN6_PCODE_WRITE_MIN_FREQ_TABLE 0x8
#define GEN6_PCODE_READ_MIN_FREQ_TABLE 0x9
#define GEN6_READ_OC_PARAMS 0xc
+#define ICL_PCODE_MEM_SUBSYSYSTEM_INFO 0xd
+#define ICL_PCODE_MEM_SS_READ_GLOBAL_INFO (0x0 << 8)
+#define ICL_PCODE_MEM_SS_READ_QGV_POINT_INFO(point)(((point) <<
16) | (0x1 << 8))
#define GEN6_PCODE_READ_D_COMP 0x10
#define GEN6_PCODE_WRITE_D_COMP 0x11
#define HSW_PCODE_DE_WRITE_FREQ_REQ 0x17
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index d11681d71add..58ea1b672a1a 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -114,6 +114,29 @@ intel_plane_destroy_state(s
Re: [Intel-gfx] [PATCH 3/5] drm/i915/perf: allow for CS OA configs to be created lazily
Quoting Lionel Landwerlin (2019-05-21 15:08:53)
> Here we introduce a mechanism by which the execbuf part of the i915
> driver will be able to request that a batch buffer containing the
> programming for a particular OA config be created.
>
> We'll execute these OA configuration buffers right before executing a
> set of userspace commands so that a particular user batchbuffer be
> executed with a given OA configuration.
>
> This mechanism essentially allows the userspace driver to go through
> several OA configuration without having to open/close the i915/perf
> stream.
>
> Signed-off-by: Lionel Landwerlin
> ---
> drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 1 +
> drivers/gpu/drm/i915/i915_drv.h | 22 ++-
> drivers/gpu/drm/i915/i915_perf.c | 187 ---
> 3 files changed, 178 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> index a34ece53a771..bbcb80cf2a85 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> @@ -126,6 +126,7 @@
> */
> #define MI_LOAD_REGISTER_IMM(x)MI_INSTR(0x22, 2*(x)-1)
> #define MI_LRI_FORCE_POSTED (1<<12)
> +#define MI_LOAD_REGISTER_IMM_MAX_REGS (126)
> #define MI_STORE_REGISTER_MEMMI_INSTR(0x24, 1)
> #define MI_STORE_REGISTER_MEM_GEN8 MI_INSTR(0x24, 2)
> #define MI_SRM_LRM_GLOBAL_GTT(1<<22)
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 1ad3818d2676..abd564bfa03b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1274,6 +1274,10 @@ struct i915_oa_config {
> struct attribute *attrs[2];
> struct device_attribute sysfs_metric_id;
>
> + struct drm_i915_gem_object *obj;
> +
> + struct list_head vma_link;
> +
> atomic_t ref_count;
> };
>
> @@ -1856,11 +1860,21 @@ struct drm_i915_private {
> struct mutex metrics_lock;
>
> /*
> -* List of dynamic configurations, you need to hold
> -* dev_priv->perf.metrics_lock to access it.
> +* List of dynamic configurations (struct i915_oa_config), you
> +* need to hold dev_priv->perf.metrics_lock to access it.
> */
> struct idr metrics_idr;
>
> + /*
> +* List of dynamic configurations (struct i915_oa_config)
> +* which have an allocated buffer in GGTT for reconfiguration,
> +* you need to hold dev_priv->perf.metrics_lock to access it.
> +* Elements are added to the list lazilly on execbuf (when a
> +* particular configuration is requested). The list is freed
> +* upon closing the perf stream.
> +*/
> + struct list_head metrics_buffers;
> +
> /*
> * Lock associated with anything below within this structure
> * except exclusive_stream.
> @@ -3136,6 +3150,10 @@ int i915_perf_remove_config_ioctl(struct drm_device
> *dev, void *data,
> void i915_oa_init_reg_state(struct intel_engine_cs *engine,
> struct intel_context *ce,
> u32 *reg_state);
> +int i915_perf_get_oa_config(struct drm_i915_private *i915,
> + int metrics_set,
> + struct i915_oa_config **out_config,
> + struct drm_i915_gem_object **out_obj);
>
> /* i915_gem_evict.c */
> int __must_check i915_gem_evict_something(struct i915_address_space *vm,
> diff --git a/drivers/gpu/drm/i915/i915_perf.c
> b/drivers/gpu/drm/i915/i915_perf.c
> index 8c7fa7f7014b..7e0ebd4bc8f2 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -365,9 +365,16 @@ struct perf_open_properties {
> int oa_period_exponent;
> };
>
> -static void free_oa_config(struct drm_i915_private *dev_priv,
> - struct i915_oa_config *oa_config)
> +static void put_oa_config(struct i915_oa_config *oa_config)
> {
> + if (!atomic_dec_and_test(&oa_config->ref_count))
> + return;
> +
> + if (oa_config->obj) {
> + list_del(&oa_config->vma_link);
> + i915_gem_object_put(oa_config->obj);
> + }
> +
> if (!PTR_ERR(oa_config->flex_regs))
> kfree(oa_config->flex_regs);
> if (!PTR_ERR(oa_config->b_counter_regs))
> @@ -377,38 +384,142 @@ static void free_oa_config(struct drm_i915_private
> *dev_priv,
> kfree(oa_config);
> }
>
> -static void put_oa_config(struct drm_i915_private *dev_priv,
> - struct i915_oa_config *oa_config)
> +static u32 *write_cs_mi_lri(u32 *cs, const struct i915_oa_reg *reg_data, u32
> n_regs)
> {
> -
Re: [Intel-gfx] [PATCH] drm/i915: add force_probe module parameter to replace alpha_support
On Mon, May 06, 2019 at 04:48:01PM +0300, Jani Nikula wrote: > The i915.alpha_support module parameter has caused some confusion along > the way. Add new i915.force_probe parameter to specify PCI IDs of > devices to probe, when the devices are recognized but not automatically > probed by the driver. The name is intended to reflect what the parameter > effectively does, avoiding any overloaded semantics of "alpha" and > "support". > > The parameter supports "" to disable, ",[,...]" to > enable force probe for one or more devices, and "*" to enable force > probe for all known devices. > > Also add new CONFIG_DRM_I915_FORCE_PROBE config option to replace the > DRM_I915_ALPHA_SUPPORT option. This defaults to "*" if > DRM_I915_ALPHA_SUPPORT=y. > > Instead of replacing i915.alpha_support immediately, let the two coexist > for a while, with a deprecation message, for a transition period. > > Cc: Joonas Lahtinen > Cc: Rodrigo Vivi First of all I'm sorry for the delay. I could swear that I had reviewed it already. > Signed-off-by: Jani Nikula > --- > drivers/gpu/drm/i915/Kconfig | 29 +- > drivers/gpu/drm/i915/i915_drv.h | 2 - > drivers/gpu/drm/i915/i915_params.c | 7 +++- > drivers/gpu/drm/i915/i915_params.h | 1 + > drivers/gpu/drm/i915/i915_pci.c | 51 +--- > drivers/gpu/drm/i915/intel_device_info.h | 2 +- > 6 files changed, 72 insertions(+), 20 deletions(-) > > diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig > index f05563..e7b617 100644 > --- a/drivers/gpu/drm/i915/Kconfig > +++ b/drivers/gpu/drm/i915/Kconfig > @@ -45,19 +45,28 @@ config DRM_I915 > config DRM_I915_ALPHA_SUPPORT > bool "Enable alpha quality support for new Intel hardware by default" > depends on DRM_I915 > - default n > help > - Choose this option if you have new Intel hardware and want to enable > - the alpha quality i915 driver support for the hardware in this kernel > - version. You can also enable the support at runtime using the module > - parameter i915.alpha_support=1; this option changes the default for > - that module parameter. > + This option is deprecated. Use DRM_I915_FORCE_PROBE option instead. > > - It is recommended to upgrade to a kernel version with proper support > - as soon as it is available. Generally fixes for platforms with alpha > - support are not backported to older kernels. > +config DRM_I915_FORCE_PROBE > + string "Force probe driver for selected new Intel hardware" > + depends on DRM_I915 > + default "*" if DRM_I915_ALPHA_SUPPORT > + help > + This is the default value for the i915.force_probe module > + parameter. Using the module parameter overrides this option. > > - If in doubt, say "N". > + Force probe the driver for new Intel graphics devices that are > + recognized but not properly supported by this kernel version. It is > + recommended to upgrade to a kernel version with proper support as soon > + as it is available. > + > + Use "" to disable force probe. If in doubt, use this. > + > + Use "[,,...]" to force probe the driver for listed This is kind of confusing "[]" suggest optional, but based on the line above "" is also allowed. > + devices. For example, "4500" or "4500,4571". But it is good that we have an example here so I won't worry much and it is up to you on how to proceed. > + > + Use "*" to force probe the driver for all known devices. > > config DRM_I915_CAPTURE_ERROR > bool "Enable capturing GPU state following a hang" > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index 64fa35..04415d 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -2435,8 +2435,6 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, > #define IS_ICL_WITH_PORT_F(dev_priv) \ > IS_SUBPLATFORM(dev_priv, INTEL_ICELAKE, INTEL_SUBPLATFORM_PORTF) > > -#define IS_ALPHA_SUPPORT(intel_info) ((intel_info)->is_alpha_support) We need to remove the usage of this on i915_pci.c... But I'm wondering how just kbuild bot got that and not CI? With this fixed, Reviewed-by: Rodrigo Vivi > - > #define SKL_REVID_A0 0x0 > #define SKL_REVID_B0 0x1 > #define SKL_REVID_C0 0x2 > diff --git a/drivers/gpu/drm/i915/i915_params.c > b/drivers/gpu/drm/i915/i915_params.c > index b5be0a..5b0776 100644 > --- a/drivers/gpu/drm/i915/i915_params.c > +++ b/drivers/gpu/drm/i915/i915_params.c > @@ -87,9 +87,12 @@ i915_param_named_unsafe(enable_psr, int, 0600, > "(0=disabled, 1=enabled) " > "Default: -1 (use per-chip default)"); > > +i915_param_named_unsafe(force_probe, charp, 0400, > + "Force probe the driver for specified devices. " > + "See CONFIG_DRM_I915_FORCE_PROBE for details."); > + > i915_param_named_unsafe(alpha_support, bool, 0
Re: [Intel-gfx] [PATCH 2/5] drm/i915/perf: allow holding preemption on filtered ctx
On 21/05/2019 17:36, Chris Wilson wrote: Quoting Lionel Landwerlin (2019-05-21 15:08:52) diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c index f263a8374273..2ad95977f7a8 100644 --- a/drivers/gpu/drm/i915/gt/intel_lrc.c +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c @@ -2085,7 +2085,7 @@ static int gen9_emit_bb_start(struct i915_request *rq, if (IS_ERR(cs)) return PTR_ERR(cs); - *cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE; + *cs++ = MI_ARB_ON_OFF | rq->hw_context->arb_enable; My prediction is that this will result in this context being reset due to preemption timeouts and the context under profile being banned. Note that preemption timeouts will be the primary means for hang detection for endless batches. -Chris Thanks, One question : how is that dealt with with compute workloads at the moment? I though those where still not fully preemptable. I need to rework this with a more "software" approach holding on preemption. Adding a condition in intel_lrc.c need_preempt() looks like the right direction? Cheers, -Lionel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/5] drm/i915/perf: allow for CS OA configs to be created lazily
On 21/05/2019 17:43, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-05-21 15:08:53)
Here we introduce a mechanism by which the execbuf part of the i915
driver will be able to request that a batch buffer containing the
programming for a particular OA config be created.
We'll execute these OA configuration buffers right before executing a
set of userspace commands so that a particular user batchbuffer be
executed with a given OA configuration.
This mechanism essentially allows the userspace driver to go through
several OA configuration without having to open/close the i915/perf
stream.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 1 +
drivers/gpu/drm/i915/i915_drv.h | 22 ++-
drivers/gpu/drm/i915/i915_perf.c | 187 ---
3 files changed, 178 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index a34ece53a771..bbcb80cf2a85 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -126,6 +126,7 @@
*/
#define MI_LOAD_REGISTER_IMM(x)MI_INSTR(0x22, 2*(x)-1)
#define MI_LRI_FORCE_POSTED (1<<12)
+#define MI_LOAD_REGISTER_IMM_MAX_REGS (126)
#define MI_STORE_REGISTER_MEMMI_INSTR(0x24, 1)
#define MI_STORE_REGISTER_MEM_GEN8 MI_INSTR(0x24, 2)
#define MI_SRM_LRM_GLOBAL_GTT(1<<22)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1ad3818d2676..abd564bfa03b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1274,6 +1274,10 @@ struct i915_oa_config {
struct attribute *attrs[2];
struct device_attribute sysfs_metric_id;
+ struct drm_i915_gem_object *obj;
+
+ struct list_head vma_link;
+
atomic_t ref_count;
};
@@ -1856,11 +1860,21 @@ struct drm_i915_private {
struct mutex metrics_lock;
/*
-* List of dynamic configurations, you need to hold
-* dev_priv->perf.metrics_lock to access it.
+* List of dynamic configurations (struct i915_oa_config), you
+* need to hold dev_priv->perf.metrics_lock to access it.
*/
struct idr metrics_idr;
+ /*
+* List of dynamic configurations (struct i915_oa_config)
+* which have an allocated buffer in GGTT for reconfiguration,
+* you need to hold dev_priv->perf.metrics_lock to access it.
+* Elements are added to the list lazilly on execbuf (when a
+* particular configuration is requested). The list is freed
+* upon closing the perf stream.
+*/
+ struct list_head metrics_buffers;
+
/*
* Lock associated with anything below within this structure
* except exclusive_stream.
@@ -3136,6 +3150,10 @@ int i915_perf_remove_config_ioctl(struct drm_device
*dev, void *data,
void i915_oa_init_reg_state(struct intel_engine_cs *engine,
struct intel_context *ce,
u32 *reg_state);
+int i915_perf_get_oa_config(struct drm_i915_private *i915,
+ int metrics_set,
+ struct i915_oa_config **out_config,
+ struct drm_i915_gem_object **out_obj);
/* i915_gem_evict.c */
int __must_check i915_gem_evict_something(struct i915_address_space *vm,
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 8c7fa7f7014b..7e0ebd4bc8f2 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -365,9 +365,16 @@ struct perf_open_properties {
int oa_period_exponent;
};
-static void free_oa_config(struct drm_i915_private *dev_priv,
- struct i915_oa_config *oa_config)
+static void put_oa_config(struct i915_oa_config *oa_config)
{
+ if (!atomic_dec_and_test(&oa_config->ref_count))
+ return;
+
+ if (oa_config->obj) {
+ list_del(&oa_config->vma_link);
+ i915_gem_object_put(oa_config->obj);
+ }
+
if (!PTR_ERR(oa_config->flex_regs))
kfree(oa_config->flex_regs);
if (!PTR_ERR(oa_config->b_counter_regs))
@@ -377,38 +384,142 @@ static void free_oa_config(struct drm_i915_private
*dev_priv,
kfree(oa_config);
}
-static void put_oa_config(struct drm_i915_private *dev_priv,
- struct i915_oa_config *oa_config)
+static u32 *write_cs_mi_lri(u32 *cs, const struct i915_oa_reg *reg_data, u32
n_regs)
{
- if (!atomic_dec_and_test(&oa_config->ref_count))
- return;
+ u32 i;
+
+ for (i = 0; i < n_regs; i++) {
+
Re: [Intel-gfx] [PATCH 4/5] drm/i915: add a new perf configuration execbuf parameter
Quoting Lionel Landwerlin (2019-05-21 15:08:54)
> + if (eb->oa_config &&
> + eb->oa_config != eb->i915->perf.oa.exclusive_stream->oa_config) {
But the oa_config is not ordered with respect to requests, and the
registers changed here are not context saved and so may be changed by a
third party before execution. The first party must presumably dropped
the perf_fd before then, so maybe you don't care? Hmm, doesn't even take
a third party as the perf_fd owner may change their mind for different
contexts and be surprised when the wrong set is used.
> + struct i915_vma *oa_vma;
> +
> + oa_vma = i915_vma_instance(eb->oa_bo,
> + &eb->engine->i915->ggtt.vm,
> NULL);
> + if (unlikely(IS_ERR(oa_vma))) {
> + err = PTR_ERR(oa_vma);
> + return err;
> + }
> +
> + err = i915_vma_pin(oa_vma, 0, 0, PIN_GLOBAL);
> + if (err)
> + return err;
> +
> + err = eb->engine->emit_bb_start(eb->request,
> + oa_vma->node.start,
> + 0, I915_DISPATCH_SECURE);
> + if (err) {
> + i915_vma_unpin(oa_vma);
> + return err;
> + }
> +
> + err = i915_vma_move_to_active(oa_vma, eb->request, 0);
Move to active first, so that the vma is not in use if the move fails.
> + if (err) {
> + i915_vma_unpin(oa_vma);
> + return err;
> + }
> +
> +
> + i915_vma_unpin(oa_vma);
> +
> +
> + swap(eb->oa_config,
> eb->i915->perf.oa.exclusive_stream->oa_config);
> + }
> +
> err = eb->engine->emit_bb_start(eb->request,
> eb->batch->node.start +
> eb->batch_start_offset,
> @@ -2341,6 +2410,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
> eb.buffer_count = args->buffer_count;
> eb.batch_start_offset = args->batch_start_offset;
> eb.batch_len = args->batch_len;
> + eb.oa_config = NULL;
>
> eb.batch_flags = 0;
> if (args->flags & I915_EXEC_SECURE) {
> @@ -2385,17 +2455,29 @@ i915_gem_do_execbuffer(struct drm_device *dev,
> */
> intel_gt_pm_get(eb.i915);
>
> - err = i915_mutex_lock_interruptible(dev);
> - if (err)
> - goto err_rpm;
> -
> err = eb_select_engine(&eb, file, args);
Lost the lock.
> if (unlikely(err))
> - goto err_unlock;
> + goto err_rpm;
> +
> + if (args->flags & I915_EXEC_PERF_CONFIG) {
> + if (!intel_engine_has_oa(eb.engine)) {
> + err = -ENODEV;
> + goto err_engine;
> + }
> +
> + err = get_execbuf_oa_config(eb.i915, args->DR1, args->DR4,
> + &eb.oa_config, &eb.oa_bo);
> + if (err)
> + goto err_engine;
> + }
> +
> + err = i915_mutex_lock_interruptible(dev);
> + if (err)
> + goto err_oa;
>
> err = eb_wait_for_ring(&eb); /* may temporarily drop struct_mutex */
> if (unlikely(err))
> - goto err_engine;
> + goto err_unlock;
>
> err = eb_relocate(&eb);
> if (err) {
> @@ -2541,10 +2623,15 @@ i915_gem_do_execbuffer(struct drm_device *dev,
> err_vma:
> if (eb.exec)
> eb_release_vmas(&eb);
> -err_engine:
> - eb_unpin_context(&eb);
> err_unlock:
> mutex_unlock(&dev->struct_mutex);
> +err_oa:
> + if (eb.oa_config) {
> + i915_gem_object_put(eb.oa_bo);
> + i915_oa_config_put(eb.oa_config);
> + }
> +err_engine:
> + eb_unpin_context(&eb);
Lost the lock.
> err_rpm:
> intel_gt_pm_put(eb.i915);
> i915_gem_context_put(eb.gem_context);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for fbcon notifier begone! (rev2)
== Series Details ==
Series: fbcon notifier begone! (rev2)
URL : https://patchwork.freedesktop.org/series/60843/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6712c9a81334 dummycon: Sprinkle locking checks
-:45: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 23 lines checked
a807564c5c46 fbdev: locking check for fb_set_suspend
-:34: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 8 lines checked
2b0293d8a972 vt: might_sleep() annotation for do_blank_screen
-:32: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 8 lines checked
1107db55b24f vt: More locking checks
-:70: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 38 lines checked
6b47d5be10cd fbdev/sa1100fb: Remove dead code
-:52: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 35 lines checked
ce4d9b2fd11a fbdev/cyber2000: Remove struct display
-:23: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 7 lines checked
79e09a42593a fbdev/aty128fb: Remove dead code
-:88: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 70 lines checked
c480f8ae010f fbcon: s/struct display/struct fbcon_display/
-:270: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#270: FILE: drivers/video/fbdev/core/fbcon.c:2117:
+static void updatescrollmode(struct fbcon_display *p,
struct fb_info *info,
-:384: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 1 checks, 317 lines checked
b1c755e3bb8f fbcon: Remove fbcon_has_exited
-:11: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 6104c37094e7 ("fbcon: Make fbcon
a built-time depency for fbdev")'
#11:
commit 6104c37094e729f3d4ce65797002112735d49cd1
-:83: WARNING:SUSPECT_CODE_INDENT: suspect code indent for conditional
statements (8, 12)
#83: FILE: drivers/video/fbdev/core/fbcon.c:1065:
+ if (WARN_ON(info_idx == -1))
return;
-:193: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 1 errors, 2 warnings, 0 checks, 119 lines checked
80033c659633 fbcon: call fbcon_fb_(un)registered directly
-:11: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 6104c37094e7 ("fbcon: Make fbcon
a built-time depency for fbdev")'
#11:
commit 6104c37094e729f3d4ce65797002112735d49cd1
-:168: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 1 errors, 1 warnings, 0 checks, 108 lines checked
684dfc3fee3d fbdev/sh_mobile: remove sh_mobile_lcdc_display_notify
b52f0088fedd fbdev/omap: sysfs files can't disappear before the device is gone
b65ada7e2f30 fbdev: sysfs files can't disappear before the device is gone
00c9c79479b0 staging/olpc: lock_fb_info can't fail
b5cd1d8e1556 fbdev/atyfb: lock_fb_info can't fail
3b25c5813357 fbdev: lock_fb_info cannot fail
-:11: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit c47747fde931 ("fbmem: make
read/write/ioctl use the frame buffer at open time")'
#11:
commit c47747fde931c02455683bd00ea43eaa62f35b0e
-:307: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 1 errors, 1 warnings, 0 checks, 212 lines checked
c18a204aafc8 fbcon: call fbcon_fb_bind directly
-:160: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 107 lines checked
8fac90eead5b fbdev: make unregister/unlink functions not fail
-:209: CHECK:AVOID_EXTERNS: extern prototypes should be avoided in .h files
#209: FILE: include/linux/fb.h:630:
+extern void unregister_framebuffer(struct fb_info *fb_info);
-:210: CHECK:AVOID_EXTERNS: extern prototypes should be avoided in .h files
#210: FILE: include/linux/fb.h:631:
+extern void unlink_framebuffer(struct fb_info *fb_info);
-:213: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 2 checks, 174 lines checked
0a4973898b2e fbdev: unify unlink_framebufer paths
-:92: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 63 lines checked
a391d
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: add i2c symlink under hdmi connector (rev2)
== Series Details == Series: drm/i915: add i2c symlink under hdmi connector (rev2) URL : https://patchwork.freedesktop.org/series/60866/ State : success == Summary == CI Bug Log - changes from CI_DRM_6110_full -> Patchwork_13053_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_13053_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-clear: - shard-hsw: [PASS][1] -> [INCOMPLETE][2] ([fdo#103540] / [fdo#110401]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6110/shard-hsw6/igt@gem_cre...@create-clear.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13053/shard-hsw5/igt@gem_cre...@create-clear.html * igt@gem_exec_suspend@basic-s3: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6110/shard-apl8/igt@gem_exec_susp...@basic-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13053/shard-apl2/igt@gem_exec_susp...@basic-s3.html * igt@gem_mmap_gtt@forked-basic-small-copy-xy: - shard-snb: [PASS][5] -> [INCOMPLETE][6] ([fdo#105411]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6110/shard-snb6/igt@gem_mmap_...@forked-basic-small-copy-xy.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13053/shard-snb7/igt@gem_mmap_...@forked-basic-small-copy-xy.html * igt@gem_mmap_gtt@medium-copy-xy: - shard-glk: [PASS][7] -> [INCOMPLETE][8] ([fdo#103359] / [k.org#198133]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6110/shard-glk9/igt@gem_mmap_...@medium-copy-xy.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13053/shard-glk4/igt@gem_mmap_...@medium-copy-xy.html * igt@gem_pwrite@big-gtt-fbr: - shard-kbl: [PASS][9] -> [INCOMPLETE][10] ([fdo#103665]) +4 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6110/shard-kbl7/igt@gem_pwr...@big-gtt-fbr.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13053/shard-kbl2/igt@gem_pwr...@big-gtt-fbr.html * igt@gem_pwrite@small-cpu-random: - shard-hsw: [PASS][11] -> [INCOMPLETE][12] ([fdo#103540]) +4 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6110/shard-hsw7/igt@gem_pwr...@small-cpu-random.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13053/shard-hsw2/igt@gem_pwr...@small-cpu-random.html * igt@gem_tiled_swapping@non-threaded: - shard-glk: [PASS][13] -> [DMESG-WARN][14] ([fdo#108686]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6110/shard-glk8/igt@gem_tiled_swapp...@non-threaded.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13053/shard-glk3/igt@gem_tiled_swapp...@non-threaded.html * igt@i915_pm_rpm@reg-read-ioctl: - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([fdo#107807]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6110/shard-skl9/igt@i915_pm_...@reg-read-ioctl.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13053/shard-skl4/igt@i915_pm_...@reg-read-ioctl.html * igt@kms_draw_crc@draw-method-rgb565-blt-untiled: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#103184] / [fdo#103232]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6110/shard-skl4/igt@kms_draw_...@draw-method-rgb565-blt-untiled.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13053/shard-skl6/igt@kms_draw_...@draw-method-rgb565-blt-untiled.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-skl: [PASS][19] -> [INCOMPLETE][20] ([fdo#104108]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6110/shard-skl1/igt@kms_frontbuffer_track...@fbc-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13053/shard-skl1/igt@kms_frontbuffer_track...@fbc-suspend.html Possible fixes * igt@gem_create@create-clear: - shard-kbl: [INCOMPLETE][21] ([fdo#103665] / [fdo#110401]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6110/shard-kbl4/igt@gem_cre...@create-clear.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13053/shard-kbl1/igt@gem_cre...@create-clear.html * igt@gem_mmap_gtt@basic-small-bo: - shard-hsw: [INCOMPLETE][23] ([fdo#103540]) -> [PASS][24] +3 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6110/shard-hsw8/igt@gem_mmap_...@basic-small-bo.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13053/shard-hsw6/igt@gem_mmap_...@basic-small-bo.html * igt@gem_ppgtt@blt-vs-render-ctx0: - shard-glk: [INCOMPLETE][25] ([fdo#103359] / [k.org#198133]) -> [PASS][26] +2 similar issues [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6110/shard-glk4/
Re: [Intel-gfx] [PATCH 2/5] drm/i915/perf: allow holding preemption on filtered ctx
Quoting Lionel Landwerlin (2019-05-21 17:50:30) > On 21/05/2019 17:36, Chris Wilson wrote: > > Quoting Lionel Landwerlin (2019-05-21 15:08:52) > >> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c > >> b/drivers/gpu/drm/i915/gt/intel_lrc.c > >> index f263a8374273..2ad95977f7a8 100644 > >> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c > >> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c > >> @@ -2085,7 +2085,7 @@ static int gen9_emit_bb_start(struct i915_request > >> *rq, > >> if (IS_ERR(cs)) > >> return PTR_ERR(cs); > >> > >> - *cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE; > >> + *cs++ = MI_ARB_ON_OFF | rq->hw_context->arb_enable; > > My prediction is that this will result in this context being reset due > > to preemption timeouts and the context under profile being banned. > > Note that preemption timeouts will be the primary means for hang > > detection for endless batches. -Chris > > Thanks, > > One question : how is that dealt with with compute workloads at the moment? > I though those where still not fully preemptable. Not blocking is the condition under which they get to use endless... compute jobs are preemptible from gen9 afaik, gen8 was problematic and so disabled. > I need to rework this with a more "software" approach holding on preemption. > Adding a condition in intel_lrc.c need_preempt() looks like the right > direction? Even less if that is our means of hangcheck. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm/i915: add a new perf configuration execbuf parameter
On 21/05/2019 18:07, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-05-21 15:08:54)
+ if (eb->oa_config &&
+ eb->oa_config != eb->i915->perf.oa.exclusive_stream->oa_config) {
But the oa_config is not ordered with respect to requests, and the
registers changed here are not context saved and so may be changed by a
third party before execution. The first party must presumably dropped
the perf_fd before then, so maybe you don't care? Hmm, doesn't even take
a third party as the perf_fd owner may change their mind for different
contexts and be surprised when the wrong set is used.
The OA config batch should be ordered with regard to the MI_BBS we're
doing just below right?
It's written before in the ring buffer.
That essentially all we need so that as the perf queries run in the
batch supplied by the application runs with the configuration needed.
If the application shares the perf FD and someone else runs another
configuration, it's the application fault.
It needs to hold the perf FD for as long as it's doing perf queries and
not allow anybody else to interact with the OA configuration.
This mechanism is unfortunately what we have resolve to because we don't
have per context performance counters.
The alternative is post processing the OA buffer (which we do in GL)
from the CPU which is not really compatible with Vulkan queries.
-Lionel
+ struct i915_vma *oa_vma;
+
+ oa_vma = i915_vma_instance(eb->oa_bo,
+ &eb->engine->i915->ggtt.vm, NULL);
+ if (unlikely(IS_ERR(oa_vma))) {
+ err = PTR_ERR(oa_vma);
+ return err;
+ }
+
+ err = i915_vma_pin(oa_vma, 0, 0, PIN_GLOBAL);
+ if (err)
+ return err;
+
+ err = eb->engine->emit_bb_start(eb->request,
+ oa_vma->node.start,
+ 0, I915_DISPATCH_SECURE);
+ if (err) {
+ i915_vma_unpin(oa_vma);
+ return err;
+ }
+
+ err = i915_vma_move_to_active(oa_vma, eb->request, 0);
Move to active first, so that the vma is not in use if the move fails.
+ if (err) {
+ i915_vma_unpin(oa_vma);
+ return err;
+ }
+
+
+ i915_vma_unpin(oa_vma);
+
+
+ swap(eb->oa_config,
eb->i915->perf.oa.exclusive_stream->oa_config);
+ }
+
err = eb->engine->emit_bb_start(eb->request,
eb->batch->node.start +
eb->batch_start_offset,
@@ -2341,6 +2410,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
eb.buffer_count = args->buffer_count;
eb.batch_start_offset = args->batch_start_offset;
eb.batch_len = args->batch_len;
+ eb.oa_config = NULL;
eb.batch_flags = 0;
if (args->flags & I915_EXEC_SECURE) {
@@ -2385,17 +2455,29 @@ i915_gem_do_execbuffer(struct drm_device *dev,
*/
intel_gt_pm_get(eb.i915);
- err = i915_mutex_lock_interruptible(dev);
- if (err)
- goto err_rpm;
-
err = eb_select_engine(&eb, file, args);
Lost the lock.
Whoops... I'll split the engine_has_oa() check away.
Thanks,
-Lionel
if (unlikely(err))
- goto err_unlock;
+ goto err_rpm;
+
+ if (args->flags & I915_EXEC_PERF_CONFIG) {
+ if (!intel_engine_has_oa(eb.engine)) {
+ err = -ENODEV;
+ goto err_engine;
+ }
+
+ err = get_execbuf_oa_config(eb.i915, args->DR1, args->DR4,
+ &eb.oa_config, &eb.oa_bo);
+ if (err)
+ goto err_engine;
+ }
+
+ err = i915_mutex_lock_interruptible(dev);
+ if (err)
+ goto err_oa;
err = eb_wait_for_ring(&eb); /* may temporarily drop struct_mutex */
if (unlikely(err))
- goto err_engine;
+ goto err_unlock;
err = eb_relocate(&eb);
if (err) {
@@ -2541,10 +2623,15 @@ i915_gem_do_execbuffer(struct drm_device *dev,
err_vma:
if (eb.exec)
eb_release_vmas(&eb);
-err_engine:
- eb_unpin_context(&eb);
err_unlock:
mutex_unlock(&dev->struct_mutex);
+err_oa:
+ if (eb.oa_config) {
+ i915_gem_object_put(eb.oa_bo);
+ i915_oa_config_put(eb.oa_config);
+ }
+err_engine:
+ eb_unpin_context(&eb);
Lost the lock.
err_rpm:
intel_gt_pm_put(eb.i915);
i915_gem_context_put(eb.gem_context);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for fbcon notifier begone! (rev2)
== Series Details == Series: fbcon notifier begone! (rev2) URL : https://patchwork.freedesktop.org/series/60843/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: dummycon: Sprinkle locking checks Okay! Commit: fbdev: locking check for fb_set_suspend Okay! Commit: vt: might_sleep() annotation for do_blank_screen Okay! Commit: vt: More locking checks Okay! Commit: fbdev/sa1100fb: Remove dead code Okay! Commit: fbdev/cyber2000: Remove struct display Okay! Commit: fbdev/aty128fb: Remove dead code Okay! Commit: fbcon: s/struct display/struct fbcon_display/ Okay! Commit: fbcon: Remove fbcon_has_exited Okay! Commit: fbcon: call fbcon_fb_(un)registered directly Okay! Commit: fbdev/sh_mobile: remove sh_mobile_lcdc_display_notify Okay! Commit: fbdev/omap: sysfs files can't disappear before the device is gone Okay! Commit: fbdev: sysfs files can't disappear before the device is gone Okay! Commit: staging/olpc: lock_fb_info can't fail Okay! Commit: fbdev/atyfb: lock_fb_info can't fail Okay! Commit: fbdev: lock_fb_info cannot fail Okay! Commit: fbcon: call fbcon_fb_bind directly Okay! Commit: fbdev: make unregister/unlink functions not fail Okay! Commit: fbdev: unify unlink_framebufer paths Okay! Commit: fbdev/sh_mob: Remove fb notifier callback Okay! Commit: fbdev: directly call fbcon_suspended/resumed Okay! Commit: fbcon: Call fbcon_mode_deleted/new_modelist directly Okay! Commit: fbdev: Call fbcon_get_requirement directly Okay! Commit: Revert "backlight/fbcon: Add FB_EVENT_CONBLANK" Okay! Commit: fbcon: directly call fbcon_fb_blanked Okay! Commit: fbmem: pull fbcon_fb_blanked out of fb_blank Okay! Commit: fbdev: remove FBINFO_MISC_USEREVENT around fb_blank Okay! Commit: fb: Flatten control flow in fb_set_var Okay! Commit: fbcon: replace FB_EVENT_MODE_CHANGE/_ALL with direct calls Okay! Commit: vgaswitcheroo: call fbcon_remap_all directly Okay! Commit: fbcon: Call con2fb_map functions directly Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm: Allow modeset on unregisted connectors unconditionally (rev2)
== Series Details == Series: drm: Allow modeset on unregisted connectors unconditionally (rev2) URL : https://patchwork.freedesktop.org/series/60871/ State : success == Summary == CI Bug Log - changes from CI_DRM_6110_full -> Patchwork_13054_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_13054_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-clear: - shard-hsw: [PASS][1] -> [INCOMPLETE][2] ([fdo#103540] / [fdo#110401]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6110/shard-hsw6/igt@gem_cre...@create-clear.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13054/shard-hsw1/igt@gem_cre...@create-clear.html * igt@gem_eio@in-flight-suspend: - shard-glk: [PASS][3] -> [FAIL][4] ([fdo#110667]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6110/shard-glk5/igt@gem_...@in-flight-suspend.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13054/shard-glk5/igt@gem_...@in-flight-suspend.html * igt@gem_exec_suspend@basic-s3: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6110/shard-apl8/igt@gem_exec_susp...@basic-s3.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13054/shard-apl4/igt@gem_exec_susp...@basic-s3.html * igt@gem_mmap_gtt@big-copy: - shard-snb: [PASS][7] -> [INCOMPLETE][8] ([fdo#105411]) +4 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6110/shard-snb2/igt@gem_mmap_...@big-copy.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13054/shard-snb7/igt@gem_mmap_...@big-copy.html * igt@gem_pwrite@big-gtt-fbr: - shard-kbl: [PASS][9] -> [INCOMPLETE][10] ([fdo#103665]) +5 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6110/shard-kbl7/igt@gem_pwr...@big-gtt-fbr.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13054/shard-kbl2/igt@gem_pwr...@big-gtt-fbr.html * igt@gem_pwrite@small-cpu-backwards: - shard-glk: [PASS][11] -> [INCOMPLETE][12] ([fdo#103359] / [k.org#198133]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6110/shard-glk8/igt@gem_pwr...@small-cpu-backwards.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13054/shard-glk4/igt@gem_pwr...@small-cpu-backwards.html * igt@gem_pwrite@small-cpu-random: - shard-hsw: [PASS][13] -> [INCOMPLETE][14] ([fdo#103540]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6110/shard-hsw7/igt@gem_pwr...@small-cpu-random.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13054/shard-hsw5/igt@gem_pwr...@small-cpu-random.html * igt@gem_tiled_swapping@non-threaded: - shard-glk: [PASS][15] -> [DMESG-WARN][16] ([fdo#108686]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6110/shard-glk8/igt@gem_tiled_swapp...@non-threaded.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13054/shard-glk1/igt@gem_tiled_swapp...@non-threaded.html * igt@i915_pm_rpm@reg-read-ioctl: - shard-skl: [PASS][17] -> [INCOMPLETE][18] ([fdo#107807]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6110/shard-skl9/igt@i915_pm_...@reg-read-ioctl.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13054/shard-skl2/igt@i915_pm_...@reg-read-ioctl.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes: - shard-skl: [PASS][19] -> [INCOMPLETE][20] ([fdo#104108]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6110/shard-skl7/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13054/shard-skl3/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145] / [fdo#110403]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6110/shard-skl10/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13054/shard-skl1/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html Possible fixes * igt@gem_mmap_gtt@basic-small-bo: - shard-hsw: [INCOMPLETE][23] ([fdo#103540]) -> [PASS][24] +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6110/shard-hsw8/igt@gem_mmap_...@basic-small-bo.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13054/shard-hsw6/igt@gem_mmap_...@basic-small-bo.html * igt@gem_mmap_gtt@forked-basic-small-copy-xy: - shard-kbl: [INCOMPLETE][25] ([fdo#103665]) -> [PASS][26] +3 similar issues [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6110/sha
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Vulkan performance query support
== Series Details == Series: drm/i915: Vulkan performance query support URL : https://patchwork.freedesktop.org/series/60916/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6114 -> Patchwork_13060 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_13060 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13060, 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_13060/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_13060: ### IGT changes ### Possible regressions * igt@gem_busy@basic-busy-default: - fi-apl-guc: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-apl-guc/igt@gem_b...@basic-busy-default.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13060/fi-apl-guc/igt@gem_b...@basic-busy-default.html - fi-glk-dsi: [PASS][3] -> [DMESG-WARN][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-glk-dsi/igt@gem_b...@basic-busy-default.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13060/fi-glk-dsi/igt@gem_b...@basic-busy-default.html - fi-ivb-3770:[PASS][5] -> [DMESG-WARN][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-ivb-3770/igt@gem_b...@basic-busy-default.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13060/fi-ivb-3770/igt@gem_b...@basic-busy-default.html - fi-skl-6600u: [PASS][7] -> [DMESG-WARN][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-skl-6600u/igt@gem_b...@basic-busy-default.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13060/fi-skl-6600u/igt@gem_b...@basic-busy-default.html - fi-kbl-guc: [PASS][9] -> [DMESG-WARN][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-kbl-guc/igt@gem_b...@basic-busy-default.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13060/fi-kbl-guc/igt@gem_b...@basic-busy-default.html - fi-bsw-kefka: [PASS][11] -> [DMESG-WARN][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-bsw-kefka/igt@gem_b...@basic-busy-default.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13060/fi-bsw-kefka/igt@gem_b...@basic-busy-default.html - fi-kbl-x1275: [PASS][13] -> [DMESG-WARN][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-kbl-x1275/igt@gem_b...@basic-busy-default.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13060/fi-kbl-x1275/igt@gem_b...@basic-busy-default.html - fi-kbl-7500u: [PASS][15] -> [DMESG-WARN][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-kbl-7500u/igt@gem_b...@basic-busy-default.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13060/fi-kbl-7500u/igt@gem_b...@basic-busy-default.html - fi-kbl-8809g: [PASS][17] -> [DMESG-WARN][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-kbl-8809g/igt@gem_b...@basic-busy-default.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13060/fi-kbl-8809g/igt@gem_b...@basic-busy-default.html - fi-whl-u: [PASS][19] -> [DMESG-WARN][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-whl-u/igt@gem_b...@basic-busy-default.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13060/fi-whl-u/igt@gem_b...@basic-busy-default.html - fi-skl-gvtdvm: [PASS][21] -> [DMESG-WARN][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-skl-gvtdvm/igt@gem_b...@basic-busy-default.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13060/fi-skl-gvtdvm/igt@gem_b...@basic-busy-default.html - fi-ilk-650: [PASS][23] -> [DMESG-WARN][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-ilk-650/igt@gem_b...@basic-busy-default.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13060/fi-ilk-650/igt@gem_b...@basic-busy-default.html - fi-bdw-gvtdvm: [PASS][25] -> [DMESG-WARN][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-bdw-gvtdvm/igt@gem_b...@basic-busy-default.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13060/fi-bdw-gvtdvm/igt@gem_b...@basic-busy-default.html - fi-bxt-j4205: [PASS][27] -> [DMESG-WARN][28] [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-bxt-j4205/igt@gem_b...@basic-busy-default.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13060/fi-bxt-j4205/igt@gem_b...@basic-busy-default.html - fi-cfl-guc: [PASS][29] -> [DMESG-WARN][30] [29]: https://intel-gfx-ci.01.org/tree/drm
[Intel-gfx] ✗ Fi.CI.BAT: failure for fbcon notifier begone! (rev2)
== Series Details == Series: fbcon notifier begone! (rev2) URL : https://patchwork.freedesktop.org/series/60843/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6114 -> Patchwork_13061 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_13061 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13061, 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_13061/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_13061: ### IGT changes ### Possible regressions * igt@prime_busy@basic-after-default: - fi-apl-guc: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-apl-guc/igt@prime_b...@basic-after-default.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13061/fi-apl-guc/igt@prime_b...@basic-after-default.html Known issues Here are the changes found in Patchwork_13061 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live_hangcheck: - fi-skl-iommu: [PASS][3] -> [INCOMPLETE][4] ([fdo#108602] / [fdo#108744]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13061/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [PASS][5] -> [FAIL][6] ([fdo#109485]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13061/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html Possible fixes * igt@i915_selftest@live_contexts: - fi-bdw-gvtdvm: [DMESG-FAIL][7] ([fdo#110235]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13061/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html - fi-skl-gvtdvm: [DMESG-FAIL][9] ([fdo#110235]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13061/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html Warnings * igt@i915_selftest@live_hangcheck: - fi-apl-guc: [FAIL][11] ([fdo#110623]) -> [DMESG-FAIL][12] ([fdo#110620]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6114/fi-apl-guc/igt@i915_selftest@live_hangcheck.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13061/fi-apl-guc/igt@i915_selftest@live_hangcheck.html [fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602 [fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744 [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485 [fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 [fdo#110620]: https://bugs.freedesktop.org/show_bug.cgi?id=110620 [fdo#110623]: https://bugs.freedesktop.org/show_bug.cgi?id=110623 Participating hosts (53 -> 43) -- Missing(10): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-icl-u3 fi-icl-y fi-icl-dsi fi-bdw-samus Build changes - * Linux: CI_DRM_6114 -> Patchwork_13061 CI_DRM_6114: 8691fe536e41c852d3d420ed09b1d5f9916031e7 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5000: f9961d14d76b3a0fa1296e547f7c065e2f93955c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_13061: f3dfc3547c56a5c790767e8690b5aea45dcdf2b3 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == f3dfc3547c56 staging/olpc_dcon: Add drm conversion to TODO 99cd5e3bdf8f fbcon: Document what I learned about fbcon locking 20c0d8a6a167 fbcon: Call con2fb_map functions directly a6b267d69013 vgaswitcheroo: call fbcon_remap_all directly a8e1ee647c16 fbcon: replace FB_EVENT_MODE_CHANGE/_ALL with direct calls 4d7bf4833e17 fb: Flatten control flow in fb_set_var efc27439fc17 fbdev: remove FBINFO_MISC_USEREVENT around fb_blank bbbe080b70df fbmem: pull fbcon_fb_blanked out of fb_blank b7dc5daa5c88 fbcon: directly call fbcon_fb_blanked e4067cf40df6 Revert "backlight/fbcon: Add FB_EVENT_CONBLANK" 16a60c108b07 fbdev: Call fbcon_get_requirement directly cdd591ad9935 fbcon: Call fbcon_mode_deleted/new_modelist directly d2190c7ac272 fbdev: directly call fbcon_suspended/resumed a391d13a2e4c fbdev/sh_mob: Remove fb notifier callback 0a4973898b2e fbdev: unify unlink_framebufer paths 8fac90eead5
Re: [Intel-gfx] [PATCH 4/5] drm/i915: add a new perf configuration execbuf parameter
Quoting Lionel Landwerlin (2019-05-21 18:19:50)
> On 21/05/2019 18:07, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2019-05-21 15:08:54)
> >> + if (eb->oa_config &&
> >> + eb->oa_config !=
> >> eb->i915->perf.oa.exclusive_stream->oa_config) {
> > But the oa_config is not ordered with respect to requests, and the
> > registers changed here are not context saved and so may be changed by a
> > third party before execution. The first party must presumably dropped
> > the perf_fd before then, so maybe you don't care? Hmm, doesn't even take
> > a third party as the perf_fd owner may change their mind for different
> > contexts and be surprised when the wrong set is used.
>
>
> The OA config batch should be ordered with regard to the MI_BBS we're
> doing just below right?
But you only emit if the oa_config has changed. Ergo, it may have
changed between submission and execution.
> It's written before in the ring buffer.
>
>
> That essentially all we need so that as the perf queries run in the
> batch supplied by the application runs with the configuration needed.
>
> If the application shares the perf FD and someone else runs another
> configuration, it's the application fault.
>
> It needs to hold the perf FD for as long as it's doing perf queries and
> not allow anybody else to interact with the OA configuration.
If one app is trying to use different configs on different contexts
(which seems reasonable if it is trying to sample different stats?) then
it can be caught out. The order of execution is not the same as the
order of submission (unless we enforce it by e.g. defining the
perf.oa_config as a barrier).
Another way would be to unconditionally emit the BB_START for the
oa_vma, and instead do the early exit with a MI_CONDITIONAL_BB_END by
comparing against a value stashed in the engine hwsp. You could do a
predicated BB_START instead, but that looks to be more of a nuisance.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
