Re: [Intel-gfx] [PATCH 06/18] drm: use ARRAY_SIZE
On Sun, 01 Oct 2017, Jérémy Lefaure wrote: > Using the ARRAY_SIZE macro improves the readability of the code. Also, > it is not always useful to use a variable to store this constant > calculated at compile time nor to re-invent the ARRAY_SIZE macro. > > Found with Coccinelle with the following semantic patch: > @r depends on (org || report)@ > type T; > T[] E; > position p; > @@ > ( > (sizeof(E)@p /sizeof(*E)) > | > (sizeof(E)@p /sizeof(E[...])) > | > (sizeof(E)@p /sizeof(T)) > ) > > Signed-off-by: Jérémy Lefaure Please split this up. Patch 1: > drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 9 + > drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 9 + Patch 2: > drivers/gpu/drm/gma500/psb_intel_sdvo.c | 9 - Patch 3: > drivers/gpu/drm/i915/gvt/vgpu.c | 3 ++- Patch 4: > drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c | 7 --- Patch 5: > drivers/gpu/drm/via/via_verifier.c | 10 -- BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/glk, cnl: Implement WaDisableScalarClockGating
On GLK and CNL enabling a pipe with its pipe scaler enabled will result in a FIFO underrun. This happens only once after driver loading or system/runtime resume, more specifically after power well 1 gets enabled; subsequent modesets seem to be free of underruns. The BSpec workaround for this is to disable the pipe scaler clock gating for the duration of modeset. Based on my tests disabling clock gating must be done before enabling pipe scaling and we can re-enable it after the pipe is enabled and one vblank has passed. For consistency I also checked if plane scaling would cause the same problem, but that doesn't seem to trigger this problem. The patch is based on an earlier version from Ander. v2 (Rodrigo): - Set also CLKGATE_DIS_PSL bits 8 and 9. - Add also the BSpec workaround ID. Cc: Ander Conselvan de Oliveira Cc: Rodrigo Vivi Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100302 Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/i915_reg.h | 10 ++ drivers/gpu/drm/i915/intel_display.c | 26 ++ 2 files changed, 36 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index ee0d4f14ac98..39ad9327e2a0 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3819,6 +3819,16 @@ enum { #define PWM2_GATING_DIS (1 << 14) #define PWM1_GATING_DIS (1 << 13) +#define _CLKGATE_DIS_PSL_A 0x46520 +#define _CLKGATE_DIS_PSL_B 0x46524 +#define _CLKGATE_DIS_PSL_C 0x46528 +#define DPF_GATING_DIS (1 << 10) +#define DPF_RAM_GATING_DIS (1 << 9) +#define DPFR_GATING_DIS (1 << 8) + +#define CLKGATE_DIS_PSL(pipe) \ + _MMIO_PIPE(pipe, _CLKGATE_DIS_PSL_A, _CLKGATE_DIS_PSL_B) + /* * GEN10 clock gating regs */ diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index c4b224a3a0ee..b7a6ddc6a66d 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -5459,6 +5459,20 @@ static bool hsw_crtc_supports_ips(struct intel_crtc *crtc) return HAS_IPS(to_i915(crtc->base.dev)) && crtc->pipe == PIPE_A; } +static void glk_pipe_scaler_clock_gating_wa(struct drm_i915_private *dev_priv, + enum pipe pipe, bool apply) +{ + u32 val = I915_READ(CLKGATE_DIS_PSL(pipe)); + u32 mask = DPF_GATING_DIS | DPF_RAM_GATING_DIS | DPFR_GATING_DIS; + + if (apply) + val |= mask; + else + val &= ~mask; + + I915_WRITE(CLKGATE_DIS_PSL(pipe), val); +} + static void haswell_crtc_enable(struct intel_crtc_state *pipe_config, struct drm_atomic_state *old_state) { @@ -5469,6 +5483,7 @@ static void haswell_crtc_enable(struct intel_crtc_state *pipe_config, enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder; struct intel_atomic_state *old_intel_state = to_intel_atomic_state(old_state); + bool psl_clkgate_wa; if (WARN_ON(intel_crtc->active)) return; @@ -5522,6 +5537,12 @@ static void haswell_crtc_enable(struct intel_crtc_state *pipe_config, if (!transcoder_is_dsi(cpu_transcoder)) intel_ddi_enable_pipe_clock(pipe_config); + /* Display WA #1180: WaDisableScalarClockGating: glk, cnl */ + psl_clkgate_wa = (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) && +intel_crtc->config->pch_pfit.enabled; + if (psl_clkgate_wa) + glk_pipe_scaler_clock_gating_wa(dev_priv, pipe, true); + if (INTEL_GEN(dev_priv) >= 9) skylake_pfit_enable(intel_crtc); else @@ -,6 +5576,11 @@ static void haswell_crtc_enable(struct intel_crtc_state *pipe_config, intel_encoders_enable(crtc, pipe_config, old_state); + if (psl_clkgate_wa) { + intel_wait_for_vblank(dev_priv, pipe); + glk_pipe_scaler_clock_gating_wa(dev_priv, pipe, false); + } + if (intel_crtc->config->has_pch_encoder) { intel_wait_for_vblank(dev_priv, pipe); intel_wait_for_vblank(dev_priv, pipe); -- 2.13.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/18] drm: use ARRAY_SIZE
On Sun, Oct 01, 2017 at 03:30:44PM -0400, Jérémy Lefaure wrote: > Using the ARRAY_SIZE macro improves the readability of the code. Also, > it is not always useful to use a variable to store this constant > calculated at compile time nor to re-invent the ARRAY_SIZE macro. > > Found with Coccinelle with the following semantic patch: > @r depends on (org || report)@ > type T; > T[] E; > position p; > @@ > ( > (sizeof(E)@p /sizeof(*E)) > | > (sizeof(E)@p /sizeof(E[...])) > | > (sizeof(E)@p /sizeof(T)) > ) > > Signed-off-by: Jérémy Lefaure > --- > drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 9 + > drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 9 + > drivers/gpu/drm/gma500/psb_intel_sdvo.c | 9 - > drivers/gpu/drm/i915/gvt/vgpu.c | 3 ++- > drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c | 7 --- > drivers/gpu/drm/via/via_verifier.c | 10 -- > 6 files changed, 24 insertions(+), 23 deletions(-) Reviewed-by: Thierry Reding signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Avoid using dev_priv->info.gen directly.
On Fri, 29 Sep 2017, Joonas Lahtinen wrote: > On Wed, 2017-09-27 at 12:32 -0700, Rodrigo Vivi wrote: >> On Wed, Sep 27, 2017 at 12:03 AM, Jani Nikula >> wrote: >> > On Tue, 26 Sep 2017, Rodrigo Vivi wrote: >> > > On Tue, Sep 26, 2017 at 09:21:43PM +, Paulo Zanoni wrote: >> > > > Em Ter, 2017-09-26 às 14:13 -0700, Rodrigo Vivi escreveu: >> > > > > Let's stop this usage before it spreads so much. >> > > > > >> > > > > 1. This check is not part of usual searches happening when adding >> > > > > new platform. >> > > > > 2. There is already a duplication here with INTEL_INFO(dev_priv)->gen >> > > > > and INTEL_GEN(dev_priv). >> > > > > >> > > > > So let's please avoid yet another way. >> > > > > >> > > > > Fixes: b22ca995ba1c ("drm/i915: prepare pipe for YCBCR420 output") >> > > > > Fixes: 27082493e9c6 ("drm/i915/skl: Update DDB values atomically with >> > > > > wms/plane attrs") >> > > > >> > > > Not sure if the Fixes tags are appropriate since this is not a bug fix. >> > > >> > > I wondered that... but since "dim fixes" provided me that tag along with >> > > the >> > > list of people I should cc I decided to include here. I thought it >> > > wouldn't hurt and also maybe good to propagate that to everywhere >> > > possible so >> > > we don't recieve more code based on that usage. >> > > >> > > But I won't merge today to give time to get Jani's view on that. >> > >> > Please only use Fixes: for functional fixes that need to be >> > backported. Like, nobody's going to be happier running a kernel they >> > know uses INTEL_GEN() consistently. >> >> Makes sense. >> Merged to dinq without the "Fixes:" tags. >> Thanks for all comments and reviews. > > We discussed this with Chris too, I ended up suggesting there could be > something along; "Backport: none" or "Backport: v4.0+", instead of the > horrible #v4.0 that is causing pain every now and then, by getting > mixed to the To: fields in a wrong way. > > Any thoughts on that? The "# v4.0" notation is described in stable-kernel-rules.rst, and if there are problems with it, they will get fixed. Git screwed it up, and AFAIK it has since been fixed. I think stick with what the stable team wants. > Fixes: is an interesting metric in other sense too, or then just decide > to use X-Fixes: when we don't want it to end up backported. IMO Fixes: should only be used for actual functional fixes, not cosmetic stuff. We don't need to track cosmetic fixes, nobody wants to backport them anywhere. Our tooling heavily relies on Fixes: to select fixes backports, and we'll just look silly sending "comment typo fix" style patches Linus' way at, say, -rc6 when stuff is supposed to abide by stable-kernel-rules.rst. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v12 03/11] drm/i915: Move i915_gem_restore_fences to i915_gem_resume
On Fri, 2017-09-29 at 19:29 +0530, Sagar Arun Kamble wrote: > > On 9/29/2017 5:18 PM, Joonas Lahtinen wrote: > > On Thu, 2017-09-28 at 12:18 +0530, Sagar Arun Kamble wrote: > > > i915_gem_restore_fences is GEM resumption task hence it is moved to > > > i915_gem_resume from i915_restore_state. > > > > + Chris > > > > Didn't I just review this patch elsewhere? Other thread explains that > > the emytology of fixing display checks out, what you suggest is more > > appropriate. Question is if we should note with a comment? > > > > PS. You seem to have sent this with --suppress-cc, which decreases the > > chances of getting the reviews :) > > No. this was sent without "--suppress-cc". I actually floated two > revisions yesterday so it might have been missed. > Sorry for the thrash. > How did you figure out "--suppress-cc"? Don't see in the headers There were Cc: entries in the text, but as the patch reached me, there were none. Could be the mailing list acting weird, too. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v12 05/11] drm/i915/guc: Introduce intel_uc_sanitize
On Fri, 2017-09-29 at 19:52 +0530, Sagar Arun Kamble wrote: > > On 9/29/2017 5:30 PM, Joonas Lahtinen wrote: > > On Thu, 2017-09-28 at 12:18 +0530, Sagar Arun Kamble wrote: > > > Currently GPU is reset at the end of suspend via i915_gem_sanitize. > > > On resume, GuC will not be loaded until intel_uc_init_hw happens > > > during GEM resume flow but action to exit sleep can be sent to GuC > > > considering the FW load status. To make sure we don't invoke that > > > action update GuC FW load status at the end of GPU reset as NONE. > > > load_status indicates HW state and it is sanitized through this new > > > function intel_uc_sanitize. > > > > > > v2: Rebase. > > > > > > v3: Removed intel_guc_sanitize. Marking load status as NONE at the > > > GPU reset point. (Chris/Michal) > > > > > > v4: Reinstated the uC function intel_uc_sanitize. (Michal Wajdeczko) > > > > > > Signed-off-by: Sagar Arun Kamble > > > Cc: Michal Wajdeczko > > > Cc: Michał Winiarski > > > Cc: Chris Wilson > > > > > > > > > @@ -508,6 +508,18 @@ int intel_uc_resume(struct drm_i915_private > > > *dev_priv) > > > return intel_guc_resume(dev_priv); > > > } > > > > > > +void intel_uc_sanitize(struct drm_i915_private *dev_priv) > > > +{ > > > + /* > > > + * FIXME: intel_uc_resume currently depends on load_status to resume > > > + * GuC. Since we are resetting Full GPU at the end of suspend, let us > > > + * mark the load status as NONE. Once intel_uc_resume is updated to take > > > + * into consideration GuC load state based on WOPCM, we can skip this > > > + * state update. > > > + */ > > > + dev_priv->guc.fw.load_status = INTEL_UC_FIRMWARE_NONE; > > > > With what I suggested to Michal, this would be call to > > intel_guc_sanitize() (and in future also intel_huc_sanitize() > > intel_dmc_sanitize()). > > Yes. > > > > > +++ b/drivers/gpu/drm/i915/intel_uncore.c > > > @@ -1763,6 +1763,9 @@ int intel_gpu_reset(struct drm_i915_private > > > *dev_priv, unsigned engine_mask) > > > } > > > intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL); > > > > > > + if (engine_mask == ALL_ENGINES) > > > + intel_uc_sanitize(dev_priv); > > > > We could propagate engine_mask to intel_uc_sanitize and let it decide > > what it does to keep a clear top level code flow. This also doesn't > > seem to depend on if GuC submission is enabled or not. > > Sure. will make this change. > > If we want to be unconditional, wouldn't intel_guc_select_fw would not > > be more appropriate in intel_uc_sanitize? > > Do we want to select different fw across resets? That would mean > changing i915.guc_firmware_path at runtime which I guess we don't want > do right? That's a good point, intel_uc_sanitize could call intel_guc_sanitize and intel_guc_sanitize could be called at the beginning of intel_guc_select_fw too. Quasi-randomly setting the guc firmware load status was odd. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v5 04/11] tests/perf: rc6: try to guess when rc6 is disabled
On Thu, Aug 31, 2017 at 11:35:08AM +0100, Lionel Landwerlin wrote: > Signed-off-by: Lionel Landwerlin > --- > tests/perf.c | 13 + > 1 file changed, 13 insertions(+) > > diff --git a/tests/perf.c b/tests/perf.c > index bd139bde..5fe0a332 100644 > --- a/tests/perf.c > +++ b/tests/perf.c > @@ -3463,6 +3463,17 @@ > gen8_test_single_ctx_render_target_writes_a_counter(void) > } while (WEXITSTATUS(child_ret) == EAGAIN); > } > > +static bool > +rc6_enabled(void) > +{ > + char *rc6_status = read_debugfs_record(drm_fd, "i915_drpc_info", > +"RC6 Enabled"); > + bool enabled = strcmp(rc6_status, "yes") == 0; > + > + free(rc6_status); > + return enabled; > +} Could we do some helper with that functionality? We are checking RC6 state in many places so maybe some global helper? I am just wondering could be that useful :) -- Ewelina > + > static void > test_rc6_disable(void) > { > @@ -3482,6 +3493,8 @@ test_rc6_disable(void) > }; > uint64_t n_events_start, n_events_end; > > + igt_skip_on(!rc6_enabled()); > + > stream_fd = __perf_open(drm_fd, ¶m); > > n_events_start = read_debugfs_u64_record(drm_fd, "i915_drpc_info", > -- > 2.14.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/9] drm/i915: Guc code reorg
On Fri, 2017-09-29 at 17:41 +, Michal Wajdeczko wrote: > Other pending series will try to fix current GuC code. > Lets move some functions to dedicated files now to > make place for these changes and preserve history. > > Cc: Joonas Lahtinen > Cc: Chris Wilson > Cc: Sagar Arun Kamble > > Michal Wajdeczko (9): > drm/i915: Drop unnecessary forward declaration > drm/i915: Move uC fw helper code into dedicated files > drm/i915: Move HuC declarations into dedicated header > drm/i915: Move GuC declarations into dedicated header > drm/i915: Move core GuC functions into dedicated file If these are new header files, then patch per new header would be good granularity. > drm/i915: Move intel_guc_sample_forcewake to guc.c > drm/i915: Move intel_guc_auth_huc to guc.c > drm/i915: Move intel_guc_suspend/resume to guc.c > drm/i915: Move intel_guc_allocate_vma to guc.c When you're moving functions to same file .c, you can do it in a single patch. There're no hard rules, just trying to keep the amount of patches reasonable vs. having enough GIT history of what was done. Then, don't do the s/dev_priv/i915/ together with the code motion even if it may feel convenient. Will be harder to notice from the GIT history that a mass s/dev_priv/i915/ was done and also the reviewer has to go through all the code that was moved to check for possible errors (in indent for example). Always think of the reviewer, and send code motion in front, so that can be reviewed based on what was moved where, then any changes so they can be reviewed for correctness. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] igt_command_line.sh: Fix bashism
On Fri, Sep 29, 2017 at 12:34:48PM +0300, Joonas Lahtinen wrote: > On Tue, 2017-09-26 at 14:01 +0200, Daniel Vetter wrote: > > On Mon, Sep 25, 2017 at 02:48:41PM +0300, Jani Nikula wrote: > > > On Mon, 25 Sep 2017, Petri Latvala wrote: > > > > [[ a != b ]] is a bashism. As it's just comparing $1 to an empty > > > > string, use -n with a normal [ ]. > > > > > > > > /bin/sh is dash in CI. > > > > > > There's probably /bin/bash around anyway, but I'm tired of fighting the > > > fight. So never mind about that. > > > > Yeah, let's just switch to /bin/bash and stop bothering with dash. At > > least I don't see any value in trying to be posix compliant, we're not > > going to run on anything that doesn't have bash anyway. > > I'm actively running I-G-T with busybox sh, so please cut with the > /bin/bash stuff, it's not that hard to be POSIX compliant. Is that a machine which doesn't have any bash at all, or is busysbox simply your /bin/sh? And yes it's imo not justified to be posix compliant if there's no use-case for it, afaiui we haven't ever made a decision for igt to be posix compliant when building (running might be a different thing, with android and all that). And this is a build-time script here. -Daniel > > Original patch is; > > Reviewed-by: Joonas Lahtinen > > Regards, Joonas > -- > Joonas Lahtinen > Open Source Technology Center > Intel Corporation -- 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
Re: [Intel-gfx] [PATCH v12 06/11] drm/i915/guc: Make GuC related disable/destroy functions not depend on i915.enable_guc_submission
On Sat, 2017-09-30 at 13:52 +0530, Sagar Arun Kamble wrote: > > On 9/29/2017 5:57 PM, Joonas Lahtinen wrote: > > On Thu, 2017-09-28 at 12:18 +0530, Sagar Arun Kamble wrote: > > > During GuC load/enable, state is setup by driver that can be looked at > > > while disabling. So remove the check for i915.enable_guc_submission > > > parameter in those functions. > > > > > > Suggested-by: Chris Wilson > > > Signed-off-by: Sagar Arun Kamble > > > Cc: Michal Wajdeczko > > > Cc: Michał Winiarski > > > > > > > > > @@ -1002,7 +1002,8 @@ static int guc_ads_create(struct intel_guc *guc) > > > > > > static void guc_ads_destroy(struct intel_guc *guc) > > > { > > > - i915_vma_unpin_and_release(&guc->ads_vma); > > > + if (guc->ads_vma) > > > > GEM_BUG_ON(!guc->ads_vma); > > This check was unnecessary. Suggestion from Chris was to make these > destroys be self-check based instead of invoking > based on module parameters like enable_guc_submission/loading. In my new > patch I have removed these checks. > https://patchwork.freedesktop.org/patch/179683/ I pinged Chris about this. I do prefer the symmetry, and I think we could have guc->enable_submission variable based on which i915_guc_submission_init/fini() would be executed on. No conditionals in the _init/_fini themselves. You can of course do the enable_submission check at the beginning of i915_guc_submission_init and _fini too, if that feels clearer for the upper level code flow. If _init is called and succeeds, _fini needs to be called. If _init fails, _fini is to never be called. The check outside or inside will both adhere to that. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 3/3] lib: Reduce dependency on glib
On Fri, Sep 29, 2017 at 03:09:02PM +0300, Arkadiusz Hiler wrote: > On Fri, Sep 29, 2017 at 01:51:59PM +0300, Petri Latvala wrote: > > In commit ebd6eb69f57b ("Make igtrc configuration common, with > > configurable suspend/resume delay") .igtrc handling was moved to > > igt_core from igt_chamelium. That made everything in IGT depend on > > GLIB by accident. > > > > In short, igt_core.h declared a variable of type GKeyFile*, requiring > > glib.h. Everything that tried to #include igt_core.h required glib.h > > to be available, by use of GLIB_CFLAGS. This "worked" so far because > > CAIRO_CFLAGS contained GLIB_CFLAGS. > > > > As the variable is only used by other stuff in lib/, stuff it in its > > own header file to leave igt_core.h without a dependency to glib.h. > > > > Also add a couple of missing #ifdef HAVE_GLIBs around. > > > > Reported-by: Felipe De Jesus Ruiz Garcia > > > > Signed-off-by: Petri Latvala > Reviewed-by: Arkadiusz Hiler > > The whole igtrc implementation has plenty of other issues (using asserts > in a wrong scope, etc). > > I have a bigger rework on my TODO list... Imo biggest is inversion of control, the core igtrc does all the parsing for all the other bits in igt, which means we leak all the submodule stuff into igt_core.c. Which isn't cool. Is there a JIRA or similar for this already where I could bikeshed? -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
Re: [Intel-gfx] [PATCH i-g-t 0/7] Dist cleanups
On Fri, Sep 29, 2017 at 03:59:45PM +0300, Petri Latvala wrote: > Distribute files that should be, remove files that shouldn't be even > in git. > > Notable inclusion: Meson build system files added to dist. With this > series, both a git checkout and tarball distribution build the same > results with either autotools or meson. Meson support looks to be > mature enough to get tarballed up. On the entire series: Acked-by: Daniel Vetter > > Petri Latvala (7): > benchmarks: Add wsim files to dist > benchmarks: Add ezbench.d files to dist > demos: Remove final file > lib: Remove media_fill.c > lib: Handle intel_aub.h like the other stub files > docs: Distribute audio.txt and chamelium.txt > meson: Distribute meson build system files > > Makefile.am | 5 + > assembler/Makefile.am| 1 + > benchmarks/Makefile.am | 7 ++- > benchmarks/ezbench.d/Makefile.am | 16 > benchmarks/wsim/Makefile.am | 31 +++ > configure.ac | 2 ++ > demos/Makefile.am| 12 > docs/Makefile.am | 5 + > lib/Makefile.am | 6 ++ > lib/media_fill.c | 16 > lib/tests/Makefile.am| 4 > man/Makefile.am | 8 +++- > overlay/Makefile.am | 5 - > tests/Makefile.am| 7 ++- > tools/Makefile.am| 3 +++ > tools/null_state_gen/Makefile.am | 4 > 16 files changed, 100 insertions(+), 32 deletions(-) > create mode 100644 benchmarks/ezbench.d/Makefile.am > create mode 100644 benchmarks/wsim/Makefile.am > delete mode 100644 demos/Makefile.am > delete mode 100644 lib/media_fill.c > > -- > 2.14.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- 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/glk, cnl: Implement WaDisableScalarClockGating (rev2)
== Series Details == Series: drm/i915/glk, cnl: Implement WaDisableScalarClockGating (rev2) URL : https://patchwork.freedesktop.org/series/31094/ State : success == Summary == Series 31094v2 drm/i915/glk, cnl: Implement WaDisableScalarClockGating https://patchwork.freedesktop.org/api/1.0/series/31094/revisions/2/mbox/ fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:458s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:471s fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 time:392s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:575s fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:289s fi-bxt-dsi total:289 pass:259 dwarn:0 dfail:0 fail:0 skip:30 time:535s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:532s fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34 time:542s fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38 time:534s fi-cfl-s total:289 pass:256 dwarn:1 dfail:0 fail:0 skip:32 time:564s fi-cnl-y total:289 pass:261 dwarn:1 dfail:0 fail:0 skip:27 time:620s fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:435s fi-glk-1 total:289 pass:257 dwarn:3 dfail:0 fail:0 skip:29 time:593s fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:440s fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:426s fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:467s fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:505s fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:479s fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:507s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:583s fi-kbl-7567u total:289 pass:265 dwarn:4 dfail:0 fail:0 skip:20 time:485s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:589s fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:657s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:473s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:543s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:591s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:473s fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38 time:584s fi-snb-2600 total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:433s b89a3b1a69f77be194ad4786906048a5e02b9975 drm-tip: 2017y-10m-02d-08h-07m-17s UTC integration manifest 27ae0ed67a28 drm/i915/glk, cnl: Implement WaDisableScalarClockGating == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5867/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v1] drm/i915: Enhanced for initialize partially filled pagetables
+ Zhenyu and Zhi On Sat, 2017-09-30 at 02:58 +, Zhang, Xiaolin wrote: > On 09/28/2017 10:25 PM, Joonas Lahtinen wrote: > > On Thu, 2017-09-28 at 10:09 +0800, Xiaolin Zhang wrote: > > > if vgpu active, the page table entry should be initialized after > > > allocation and then the hypersivor can ping pages succesuffly, > > > otherwise hypervisor will ping pages failed and the host will > > > print > > > a lot of annoying errors such as “ERROR gvt: guest page write > > > error -22, > > > gfn 0x7ada8, pa 0x7ada89a8, var 0x6, len 1” when create linux > > > guest. > > > > > > Signed-off-by: Xiaolin Zhang > > > > Why does the hypervisor try to access the entries prior to them > > being > > made valid for hardware? > > > > Regards, Joonas > > Hi Joonas, > thanks your comment. > I think what you ask is the point we got the error message in gvt since the > current gvt > implementation is that page under write protection and trapped should be > valid > with correct shadow page setup and p2m translation. My question is that if the hardware doesn't care about them being uninitialized at this point, how can GVT? If the GVT implementation relies heavily on how the i915 driver currently happens to behave, not on what contracts it has with the hardware, these breakages are bound to happen repeatedly. The code is being transformed and optimized on daily basis, how it currently behaves is not a solid foundation for implementing the host side virtualization. > Actually, to work with > “initialize partially filled pagetables" , there is a certain refine work to > do in gvt side > (maybe less or maybe large). but before refine work done, this patch is > trying to bring back > gvt behavior as before “initialize partially filled pagetables"patch. We should first minimize and then keep the vgpu specific checks to minimum. So this would need to be fixed on the GVT side of code. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] [PATCH] mm, oom: Offload OOM notify callback to a kernel thread.
[Hmm, I do not see the original patch which this has been a reply to] On Mon 02-10-17 06:59:12, Michael S. Tsirkin wrote: > On Sun, Oct 01, 2017 at 02:44:34PM +0900, Tetsuo Handa wrote: > > Tetsuo Handa wrote: > > > Michael S. Tsirkin wrote: > > > > On Mon, Sep 11, 2017 at 07:27:19PM +0900, Tetsuo Handa wrote: > > > > > Hello. > > > > > > > > > > I noticed that virtio_balloon is using register_oom_notifier() and > > > > > leak_balloon() from virtballoon_oom_notify() might depend on > > > > > __GFP_DIRECT_RECLAIM memory allocation. > > > > > > > > > > In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to > > > > > serialize against fill_balloon(). But in fill_balloon(), > > > > > alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY) > > > > > is > > > > > called with vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] > > > > > implies > > > > > __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, this allocation attempt > > > > > might > > > > > depend on somebody else's __GFP_DIRECT_RECLAIM | !__GFP_NORETRY memory > > > > > allocation. Such __GFP_DIRECT_RECLAIM | !__GFP_NORETRY allocation can > > > > > reach > > > > > __alloc_pages_may_oom() and hold oom_lock mutex and call > > > > > out_of_memory(). > > > > > And leak_balloon() is called by virtballoon_oom_notify() via > > > > > blocking_notifier_call_chain() callback when vb->balloon_lock mutex > > > > > is already > > > > > held by fill_balloon(). As a result, despite __GFP_NORETRY is > > > > > specified, > > > > > fill_balloon() can indirectly get stuck waiting for vb->balloon_lock > > > > > mutex > > > > > at leak_balloon(). This is really nasty! And I would argue that this is an abuse of the oom notifier interface from the virtio code. OOM notifiers are an ugly hack on its own but all its users have to be really careful to not depend on any allocation request because that is a straight deadlock situation. I do not think that making oom notifier API more complex is the way to go. Can we simply change the lock to try_lock? If the lock is held we would simply fall back to the normal OOM handling. As a follow up it would be great if virtio could use some other form of aging e.g. shrinker. -- 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 i-g-t v2] tests: add slice power programming test
On Fri, 2017-09-22 at 16:11 +0100, Lionel Landwerlin wrote: > Verifies that the kernel programs slices correctly based by reading > the value of PWR_CLK_STATE register. > > v2: Add subslice tests (Lionel) > Use MI_SET_PREDICATE for further verification when available (Lionel) > > Signed-off-by: Lionel Landwerlin > --- > tests/Makefile.sources | 1 + > tests/ctx_rpcs.c | 453 > + This should definitely be 'gem_ctx_rpcs' :) Unless I missed it, this test only checks that the registers are written to and get read. It doesn't functionally validate that the hardware actually performs differently based on what you set? Maybe under benchmarks/ it would be appropriate to compare the effect on processing power, and make sure performance improves with additional slices (except when it doesn't :P) Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gen9+: Set same power state before hibernation image save/restore
On Wed, Aug 16, 2017 at 04:50:01PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/gen9+: Set same power state before hibernation image > save/restore > URL : https://patchwork.freedesktop.org/series/28873/ > State : success Thanks for the review, pushed it to -dinq. > > == Summary == > > Series 28873v1 drm/i915/gen9+: Set same power state before hibernation image > save/restore > https://patchwork.freedesktop.org/api/1.0/series/28873/revisions/1/mbox/ > > Test kms_cursor_legacy: > Subgroup basic-busy-flip-before-cursor-atomic: > pass -> FAIL (fi-snb-2600) fdo#100215 > > fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 > > fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 > time:453s > fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 > time:434s > fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 > time:363s > fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 > time:559s > fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 > time:522s > fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 > time:538s > fi-byt-n2820 total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 > time:517s > fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 > time:609s > fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 > time:447s > fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 > time:421s > fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 > time:429s > fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > time:508s > fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > time:478s > fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > time:482s > fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 > time:597s > fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > time:599s > fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 > time:527s > fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 > time:477s > fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > time:477s > fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 > time:491s > fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 > time:445s > fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 > time:481s > fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 > time:542s > fi-snb-2600 total:279 pass:249 dwarn:0 dfail:0 fail:1 skip:29 > time:405s > > ada53b43f81fe618f3f0f1dfbd3dd776bb277323 drm-tip: 2017y-08m-16d-15h-18m-56s > UTC integration manifest > 58aa054f582c drm/i915/gen9+: Set same power state before hibernation image > save/restore > > == Logs == > > For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5416/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] dim: sign pull-request tags if the GPG key is configured
On Mon, 11 Sep 2017, Sean Paul wrote: > On Mon, Sep 11, 2017 at 9:16 AM, Jani Nikula wrote: >> Add new environment variable $DIM_GPG_KEYID for configuring the GPG key >> ID of the key to use for signing tags for pull requests. The tags will >> be signed if the key ID is set, otherwise annotated tags will be used >> like before. >> >> The drm-intel-testing tags are left unsigned, at least for now. >> >> Cc: Daniel Vetter >> Cc: Joonas Lahtinen >> Cc: Rodrigo Vivi >> Cc: Sean Paul >> Signed-off-by: Jani Nikula >> >> --- >> >> BEWARE OF THE LEOPARD! I didn't actually test this. I will try it when I >> need to tag something next. >> > > Just comment out git push and test this? Finally got around to trying this out, works fine: https://cgit.freedesktop.org/drm-intel/tag/?id=drm-intel-next-2017-09-29 The only snag is that now prep_pull_mail_overview() picks up the signature from the tag object to the overview too. Ack on merging these two out of the way, and fixing that separately (a tiny bit of sed)? BR, Jani. > > Sean > >> We should probably also add verification to dim apply-pull. >> --- >> dim | 9 ++--- >> dim.rst | 11 +++ >> 2 files changed, 17 insertions(+), 3 deletions(-) >> >> diff --git a/dim b/dim >> index 23dfccb5513d..4d7864d8f450 100755 >> --- a/dim >> +++ b/dim >> @@ -70,6 +70,9 @@ >> DIM_TEMPLATE_SIGNATURE=${DIM_TEMPLATE_SIGNATURE:-$HOME/.dim.template.signature} >> # dim pull-request tag summary template >> >> DIM_TEMPLATE_TAG_SUMMARY=${DIM_TEMPLATE_TAG_SUMMARY:-$HOME/.dim.template.tagsummary} >> >> +# GPG key id for signing tags. If unset, don't sign. >> +DIM_GPG_KEYID=${DIM_GPG_KEYID:+-u $DIM_GPG_KEYID} >> + >> # >> # Internal configuration. >> # >> @@ -1549,7 +1552,7 @@ function dim_update_next_continue >> tag_testing="drm-intel-testing-$today-$((++suffix))" >> done >> >> - $DRY git tag -a $tag $DIM_DRM_INTEL_REMOTE/drm-intel-next >> + $DRY git tag -a $DIM_GPG_KEYID $tag >> $DIM_DRM_INTEL_REMOTE/drm-intel-next >> git push $DRY_RUN $DIM_DRM_INTEL_REMOTE $tag >> >> echo "Updating drm-intel-testing to latest drm-tip" >> @@ -1589,7 +1592,7 @@ function dim_tag_next >> tag="drm-intel-next-$today-$((++suffix))" >> done >> >> - $DRY git tag -a $tag $DIM_DRM_INTEL_REMOTE/drm-intel-next >> + $DRY git tag -a $DIM_GPG_KEYID $tag >> $DIM_DRM_INTEL_REMOTE/drm-intel-next >> git push $DRY_RUN $DIM_DRM_INTEL_REMOTE $tag >> else >> echo "drm-intel-next not up-to-date, aborting" >> @@ -1650,7 +1653,7 @@ function dim_pull_request >> done >> gitk "$branch@{upstream}" ^$upstream & >> prep_pull_tag_summary | $DRY git tag -F- $tag >> "$branch@{upstream}" >> - $DRY git tag -a -f $tag >> + $DRY git tag -a $DIM_GPG_KEYID -f $tag >> $DRY git push $remote $tag >> prep_pull_mail $req_file $tag >> >> diff --git a/dim.rst b/dim.rst >> index 7aacc4e776e2..65e652e8bc75 100644 >> --- a/dim.rst >> +++ b/dim.rst >> @@ -349,6 +349,8 @@ recipients already set. >> Since the tag for the *branch* is date based, the pull request can be >> regenerated with the same commands if something goes wrong. >> >> +The tag will be signed using the key specified by \$DIM_GPG_KEYID, if set. >> + >> pull-request-fixes [*upstream*] >> --- >> **pull-request** shorthand for *drm-intel-fixes* as the branch and >> @@ -391,6 +393,8 @@ opened. >> Also checks that the drm-intel-fixes|-next-queued are fully >> merged into drm-tip to avoid operator error. >> >> +The tag will be signed using the key specified by \$DIM_GPG_KEYID, if set. >> + >> update-next-continue >> >> >> @@ -405,6 +409,8 @@ remote is up-to-date. Useful if drm-intel-next has been >> changed since the last >> run of the update-next command (e.g. to apply a hotfix before sending out >> the >> pull request). >> >> +The tag will be signed using the key specified by \$DIM_GPG_KEYID, if set. >> + >> DIM HELP COMMANDS >> = >> >> @@ -498,6 +504,11 @@ DIM_TEMPLATE_TAG_SUMMARY >> - >> Path to a file containing the template for dim pull-request tag summaries. >> >> +DIM_GPG_KEYID >> +- >> +GPG key ID to use for signing tags. If set, tags will be signed. If unset, >> the >> +default, tags will not be signed. >> + >> dim_alias_ >> - >> Make an alias for the subcommand defined as the value. For >> example, >> -- >> 2.11.0 >> -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [dim PATCH] dim: use git ls-files file matching instead of grep
Avoid extra pipelines for no good reason. Signed-off-by: Jani Nikula --- dim | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dim b/dim index 678f34d5f7bd..d2f165893161 100755 --- a/dim +++ b/dim @@ -602,7 +602,7 @@ function commit_rerere_cache return 1 fi git add ./*.patch >& /dev/null || true - for file in $(git ls-files | grep ^rr-cache); do + for file in $(git ls-files -- rr-cache); do if ! git log --since="60 days ago" --name-only -- $file | grep $file &> /dev/null; then git rm $file &> /dev/null || true fi -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [dim PATCH] dim: note the testing tag in the drm-intel-testing mail
Signed-off-by: Jani Nikula --- dim | 2 ++ 1 file changed, 2 insertions(+) diff --git a/dim b/dim index d2f165893161..bfa6ef010806 100755 --- a/dim +++ b/dim @@ -1612,6 +1612,8 @@ function dim_update_next_continue cat > $req_file <<-HERE Hi all, + The following changes tagged $tag_testing: + HERE obj=$(git rev-parse $tag) if [[ "$(git cat-file -t $obj)" == "tag" ]] ; then -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/gen8+: Init/reset display interrupts only if i915 IRQs are enabled
On Thu, Sep 28, 2017 at 11:44:52AM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/gen8+: Init/reset display interrupts only if i915 IRQs are > enabled > URL : https://patchwork.freedesktop.org/series/31058/ > State : warning > > == Summary == > > Series 31058v1 drm/i915/gen8+: Init/reset display interrupts only if i915 > IRQs are enabled > https://patchwork.freedesktop.org/api/1.0/series/31058/revisions/1/mbox/ > > Test chamelium: > Subgroup hdmi-crc-fast: > pass -> DMESG-WARN (fi-skl-6700k) fdo#103019 > Test gem_exec_suspend: > Subgroup basic-s3: > pass -> DMESG-WARN (fi-cfl-s) [ 208.434941] == [ 208.434941] WARNING: possible circular locking dependency detected [ 208.434942] 4.14.0-rc2-CI-Patchwork_5846+ #1 Tainted: G U [ 208.434943] -- [ 208.434944] rtcwake/3287 is trying to acquire lock: [ 208.434944] ((complete)&st->done){+.+.}, at: [] wait_for_completion+0x1d/0x20 [ 208.434948] but task is already holding lock: [ 208.434948] (sparse_irq_lock){+.+.}, at: [] irq_lock_sparse+0x17/0x20 looks like https://bugs.freedesktop.org/show_bug.cgi?id=103026 The rest look like independent pre-existing issues based on the fdo links. Thanks for the review, I pushed the patch to -dinq. > Subgroup basic-s4-devices: > dmesg-warn -> PASS (fi-cfl-s) fdo#102294 +20 > Test kms_frontbuffer_tracking: > Subgroup basic: > dmesg-warn -> PASS (fi-cfl-s) fdo#102374 > Test kms_pipe_crc_basic: > Subgroup nonblocking-crc-pipe-c: > incomplete -> SKIP (fi-cfl-s) fdo#103022 > Test drv_module_reload: > Subgroup basic-reload: > pass -> DMESG-WARN (fi-glk-1) fdo#102777 > > fdo#103019 https://bugs.freedesktop.org/show_bug.cgi?id=103019 > fdo#102294 https://bugs.freedesktop.org/show_bug.cgi?id=102294 > fdo#102374 https://bugs.freedesktop.org/show_bug.cgi?id=102374 > fdo#103022 https://bugs.freedesktop.org/show_bug.cgi?id=103022 > fdo#102777 https://bugs.freedesktop.org/show_bug.cgi?id=102777 > > fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 > time:443s > fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 > time:475s > fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 > time:425s > fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 > time:519s > fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 > time:280s > fi-bxt-dsi total:289 pass:259 dwarn:0 dfail:0 fail:0 skip:30 > time:505s > fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 > time:509s > fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34 > time:503s > fi-cfl-s total:289 pass:256 dwarn:1 dfail:0 fail:0 skip:32 > time:546s > fi-cnl-y total:289 pass:259 dwarn:0 dfail:0 fail:3 skip:27 > time:671s > fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 > time:420s > fi-glk-1 total:289 pass:259 dwarn:1 dfail:0 fail:0 skip:29 > time:568s > fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 > time:425s > fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 > time:405s > fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 > time:440s > fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 > time:495s > fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 > time:469s > fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 > time:471s > fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 > time:582s > fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 > time:589s > fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 > time:554s > fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 > time:455s > fi-skl-6700k total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 > time:756s > fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 > time:494s > fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 > time:476s > fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38 > time:570s > fi-snb-2600 total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 > time:429s > > c1ed501217782b35094792696924a1d22ee83c0f drm-tip: 2017y-09m-28d-04h-52m-47s > UTC integration manifest > 3b58c2e42208 drm/i915/gen8+: Init/reset display interrupts only if i915 IRQs > are enabled > > == Logs == > > For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Pa
Re: [Intel-gfx] [PATCH i-g-t v4 1/7] tests: Stop looking at plane private members
Op 29-09-17 om 15:13 schreef Mika Kahola: > On Fri, 2017-09-29 at 11:59 +0200, Maarten Lankhorst wrote: >> Most of these tests have no reason to look at those members, >> so try other ways of getting the information. >> >> Signed-off-by: Maarten Lankhorst > Reviewed-by: Mika Kahola Thanks, patch 1 & 7 pushed. :) ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [dim PATCH] dim: note the testing tag in the drm-intel-testing mail
On Mon, 2017-10-02 at 12:24 +0300, Jani Nikula wrote: > Signed-off-by: Jani Nikula Yay :) Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [dim PATCH] dim: use git ls-files file matching instead of grep
On Mon, 2017-10-02 at 12:23 +0300, Jani Nikula wrote: > Avoid extra pipelines for no good reason. > > Signed-off-by: Jani Nikula Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] dim: strip signatures out of the pull mail overviews
Signed tags have the signature at the end. Strip them out when preparing pull mail overviews. Signed-off-by: Jani Nikula --- dim | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dim b/dim index 866a420d4ef6..fc16d114632f 100755 --- a/dim +++ b/dim @@ -1483,7 +1483,7 @@ function prep_pull_mail_overview obj=$(git rev-parse $tag) if [[ "$(git cat-file -t $obj)" == "tag" ]] ; then echo $tag: - git cat-file -p $obj | tail -n+6 + git cat-file -p $obj | tail -n+6 | sed -n '/^-BEGIN PGP SIGNATURE-$/q;p' fi done fi -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] dim: use prep_pull_mail_overview for drm-intel-testing
It's not perfect or exactly the same, but prefer fewer lines of special casing anyway. Signed-off-by: Jani Nikula --- dim | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/dim b/dim index bfa6ef010806..866a420d4ef6 100755 --- a/dim +++ b/dim @@ -1615,12 +1615,8 @@ function dim_update_next_continue The following changes tagged $tag_testing: HERE - obj=$(git rev-parse $tag) - if [[ "$(git cat-file -t $obj)" == "tag" ]] ; then - git cat-file -p $obj | tail -n+6 >> $req_file - else - echo "*** CHANGELOG OVERVIEW HERE ***" >> $req_file - fi + + prep_pull_mail_overview "$tag" >> $req_file prep_pull_mail_signature >> $req_file $DRY $DIM_MUA -s "Updated drm-intel-testing" \ -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: enable to read CSB and CSB write pointer from HWSP in GVT-g VM
On Sat, 2017-09-30 at 13:57 +0800, Weinan Li wrote: > Let GVT-g VM read the CSB and CSB write pointer from virtual HWSP, not all > the host support this feature, need to check the BIT(3) of caps in PVINFO. > > Signed-off-by: Weinan Li > Cc: Chris Wilson > @@ -396,6 +393,12 @@ static bool csb_force_mmio(struct drm_i915_private *i915) > if (intel_vtd_active()) > return true; > > + /* GVT emulation depends upon host kernel implementation, check > + * support capbility by reading PV INFO before access HWSP. > + */ The comment can be dropped completely, the code is self-descriptive. > +++ b/drivers/gpu/drm/i915/intel_lrc.c > @@ -722,7 +722,12 @@ static void intel_lrc_irq_handler(unsigned long data) > &engine->status_page.page_addr[I915_HWS_CSB_BUF0_INDEX]; > unsigned int head, tail; > > - /* However GVT emulation depends upon intercepting CSB mmio */ > + /* However GVT-g emulation depends upon host kernel > + * implementation, need to check support capbility by reading PV > + * INFO before access HWSP. Beside from this, another special > + * configuration may also need to force use mmio, like IOMMU > + * enabled. > + */ s/capbility/capability/ and please rephrase this to be a kerneldoc for csb_use_mmio at the declaration. > if (unlikely(execlists->csb_use_mmio)) { > buf = (u32 * __force) > (dev_priv->regs + > i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0))); Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Silence compiler warning for hsw_power_well_enable()
Not all compilers are able to determine that pg is guarded by wait_fuses and so may think that pg is used uninitialized. Reported-by: Geert Uytterhoeven Fixes: b2891eb2531e ("drm/i915/hsw+: Add has_fuses power well attribute") Signed-off-by: Chris Wilson Cc: Imre Deak Cc: Arkadiusz Hiler --- drivers/gpu/drm/i915/intel_runtime_pm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c b/drivers/gpu/drm/i915/intel_runtime_pm.c index 7933d1bc6a1c..de207c93c063 100644 --- a/drivers/gpu/drm/i915/intel_runtime_pm.c +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c @@ -368,7 +368,7 @@ static void hsw_power_well_enable(struct drm_i915_private *dev_priv, { enum i915_power_well_id id = power_well->id; bool wait_fuses = power_well->hsw.has_fuses; - enum skl_power_gate pg; + enum skl_power_gate uninitialized_var(pg); u32 val; if (wait_fuses) { -- 2.14.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v4 2/7] lib/igt_kms: Change output->pending_crtc_idx_mask to output->pending_pipe
On Fri, 2017-09-29 at 11:59 +0200, Maarten Lankhorst wrote: > igt_output_set_pipe with PIPE_ANY used to mean that we bind the > output > to any pipe, but this is now a deprecated alias for PIPE_NONE, and > means the output will be unbound. > > Because of this it's better to change output->pending_crtc_idx_mask > to > an enum pipe, because only a single choice may be given for a pipe. > > Signed-off-by: Maarten Lankhorst Reviewed-by: Mika Kahola > --- > lib/igt_kms.c | 46 - > -- > lib/igt_kms.h | 2 +- > tests/kms_atomic_transition.c | 4 ++-- > tests/kms_busy.c | 2 +- > tests/kms_cursor_legacy.c | 2 +- > 5 files changed, 26 insertions(+), 30 deletions(-) > > diff --git a/lib/igt_kms.c b/lib/igt_kms.c > index 7bcafc072f70..a5db6bc493c2 100644 > --- a/lib/igt_kms.c > +++ b/lib/igt_kms.c > @@ -1561,9 +1561,10 @@ static void > igt_display_log_shift(igt_display_t *display, int shift) > static void igt_output_refresh(igt_output_t *output) > { > igt_display_t *display = output->display; > - unsigned long crtc_idx_mask; > + unsigned long crtc_idx_mask = 0; > > - crtc_idx_mask = output->pending_crtc_idx_mask; > + if (output->pending_pipe != PIPE_NONE) > + crtc_idx_mask = 1 << output->pending_pipe; > > kmstest_free_connector_config(&output->config); > > @@ -1587,11 +1588,8 @@ static void igt_output_refresh(igt_output_t > *output) > BROADCAST_RGB_FU > LL); > } > > - if (output->config.pipe == PIPE_NONE) > - return; > - > LOG(display, "%s: Selecting pipe %s\n", output->name, > - kmstest_pipe_name(output->config.pipe)); > + kmstest_pipe_name(output->pending_pipe)); > } > > static bool > @@ -1830,7 +1828,7 @@ void igt_display_init(igt_display_t *display, > int drm_fd) > * a pipe is set with igt_output_set_pipe(). > */ > output->force_reprobe = true; > - output->pending_crtc_idx_mask = 0; > + output->pending_pipe = PIPE_NONE; > output->id = resources->connectors[i]; > output->display = display; > > @@ -1960,10 +1958,12 @@ static void igt_display_refresh(igt_display_t > *display) > for (i = 0; i < display->n_outputs; i++) { > output = &display->outputs[i]; > > - if (pipes_in_use & output->pending_crtc_idx_mask) > - goto report_dup; > + if (output->pending_pipe != PIPE_NONE) { > + if (pipes_in_use & (1 << output- > >pending_pipe)) > + goto report_dup; > > - pipes_in_use |= output->pending_crtc_idx_mask; > + pipes_in_use |= 1 << output->pending_pipe; > + } > > if (output->force_reprobe) > igt_output_refresh(output); > @@ -1975,11 +1975,11 @@ report_dup: > for (; i > 0; i--) { > igt_output_t *b = &display->outputs[i - 1]; > > - igt_assert_f(output->pending_crtc_idx_mask != > - b->pending_crtc_idx_mask, > + igt_assert_f(output->pending_pipe != > + b->pending_pipe, > "%s and %s are both trying to use pipe > %s\n", > igt_output_name(output), > igt_output_name(b), > - kmstest_pipe_name(ffs(b- > >pending_crtc_idx_mask) - 1)); > + kmstest_pipe_name(output- > >pending_pipe)); > } > } > > @@ -1988,7 +1988,7 @@ static igt_pipe_t > *igt_output_get_driving_pipe(igt_output_t *output) > igt_display_t *display = output->display; > enum pipe pipe; > > - if (!output->pending_crtc_idx_mask) { > + if (output->pending_pipe == PIPE_NONE) { > /* > * The user hasn't specified a pipe to use, return > none. > */ > @@ -1998,7 +1998,7 @@ static igt_pipe_t > *igt_output_get_driving_pipe(igt_output_t *output) > * Otherwise, return the pending pipe (ie the pipe > that should > * drive this output after the commit() > */ > - pipe = ffs(output->pending_crtc_idx_mask) - 1; > + pipe = output->pending_pipe; > } > > igt_assert(pipe >= 0 && pipe < display->n_pipes); > @@ -2051,7 +2051,7 @@ static igt_output_t > *igt_pipe_get_output(igt_pipe_t *pipe) > for (i = 0; i < display->n_outputs; i++) { > igt_output_t *output = &display->outputs[i]; > > - if (output->pending_crtc_idx_mask == (1 << pipe- > >pipe)) > + if (output->pending_pipe == pipe->pipe) > return output; > } > > @@ -2860,22 +2860,18 @@ void igt_output_set_pipe(igt_output_t > *output, enum pipe pipe) > > igt_assert(output->name); >
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: enable to read CSB and CSB write pointer from HWSP in GVT-g VM
Quoting Joonas Lahtinen (2017-10-02 11:03:30) > On Sat, 2017-09-30 at 13:57 +0800, Weinan Li wrote: > > Let GVT-g VM read the CSB and CSB write pointer from virtual HWSP, not all > > the host support this feature, need to check the BIT(3) of caps in PVINFO. > > > > Signed-off-by: Weinan Li > > Cc: Chris Wilson > > > > > @@ -396,6 +393,12 @@ static bool csb_force_mmio(struct drm_i915_private > > *i915) > > if (intel_vtd_active()) > > return true; > > > > + /* GVT emulation depends upon host kernel implementation, check > > + * support capbility by reading PV INFO before access HWSP. > > + */ > > The comment can be dropped completely, the code is self-descriptive. > > > +++ b/drivers/gpu/drm/i915/intel_lrc.c > > @@ -722,7 +722,12 @@ static void intel_lrc_irq_handler(unsigned long data) > > > > &engine->status_page.page_addr[I915_HWS_CSB_BUF0_INDEX]; > > unsigned int head, tail; > > > > - /* However GVT emulation depends upon intercepting CSB mmio */ > > + /* However GVT-g emulation depends upon host kernel > > + * implementation, need to check support capbility by reading > > PV > > + * INFO before access HWSP. Beside from this, another special > > + * configuration may also need to force use mmio, like IOMMU > > + * enabled. > > + */ > > s/capbility/capability/ and please rephrase this to be a kerneldoc for > csb_use_mmio at the declaration. This is not a description of how to use the function or even on how csb_use_mmio work, this is why we want certain logic paths. Just a regular old comment. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/glk, cnl: Implement WaDisableScalarClockGating (rev2)
== Series Details == Series: drm/i915/glk, cnl: Implement WaDisableScalarClockGating (rev2) URL : https://patchwork.freedesktop.org/series/31094/ State : success == Summary == Test perf: Subgroup polling: pass -> FAIL (shard-hsw) fdo#102252 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-hswtotal:2429 pass:1329 dwarn:7 dfail:0 fail:10 skip:1083 time:10165s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5867/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Silence compiler warning for hsw_power_well_enable()
== Series Details == Series: drm/i915: Silence compiler warning for hsw_power_well_enable() URL : https://patchwork.freedesktop.org/series/31260/ State : warning == Summary == Series 31260v1 drm/i915: Silence compiler warning for hsw_power_well_enable() https://patchwork.freedesktop.org/api/1.0/series/31260/revisions/1/mbox/ Test kms_force_connector_basic: Subgroup prune-stale-modes: pass -> SKIP (fi-snb-2600) fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:463s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:473s fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 time:392s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:570s fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:292s fi-bxt-dsi total:289 pass:259 dwarn:0 dfail:0 fail:0 skip:30 time:528s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:532s fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34 time:540s fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38 time:531s fi-cfl-s total:289 pass:256 dwarn:1 dfail:0 fail:0 skip:32 time:555s fi-cnl-y total:289 pass:261 dwarn:1 dfail:0 fail:0 skip:27 time:623s fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:443s fi-glk-1 total:289 pass:257 dwarn:3 dfail:0 fail:0 skip:29 time:593s fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:442s fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:418s fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:467s fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:507s fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:478s fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:506s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:573s fi-kbl-7567u total:289 pass:265 dwarn:4 dfail:0 fail:0 skip:20 time:486s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:591s fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:659s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:471s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:534s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:589s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:478s fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38 time:586s fi-snb-2600 total:289 pass:249 dwarn:0 dfail:0 fail:0 skip:40 time:436s 2f14e319a2fd0125bcb06b00095afa6cab5134bd drm-tip: 2017y-10m-02d-09h-23m-23s UTC integration manifest bb31ea157693 drm/i915: Silence compiler warning for hsw_power_well_enable() == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5868/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] meson: Follow suit with the renaming of kms_pipe_color
CC: Maarten Lankhorst Signed-off-by: Petri Latvala --- tests/meson.build | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/meson.build b/tests/meson.build index 53d02d13..6cb3584a 100644 --- a/tests/meson.build +++ b/tests/meson.build @@ -157,6 +157,7 @@ test_progs = [ 'kms_busy', 'kms_ccs', 'kms_chv_cursor_fail', + 'kms_color', 'kms_concurrent', 'kms_crtc_background_color', 'kms_cursor_crc', @@ -177,7 +178,6 @@ test_progs = [ 'kms_mmio_vs_cs_flip', 'kms_panel_fitting', 'kms_pipe_b_c_ivb', - 'kms_pipe_color', 'kms_pipe_crc_basic', 'kms_plane', 'kms_plane_lowres', -- 2.14.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v4 3/7] lib/igt_kms: Commit primary plane when a modeset is forced on a pipe
On Fri, 2017-09-29 at 11:59 +0200, Maarten Lankhorst wrote: > In between tests, some tests can do the following sequence: > > (pipe C configured with FB) > igt_plane_set_fb(primary (pipe C), NULL); > /* Clear rotation property first */ > igt_display_commit2(display, COMMIT_UNIVERSAL); > > /* disable pipe */ > igt_display_commit2(display, COMMIT_LEGACY); > > This would result in PIPE_C not being properly disabled, which > will cause an error on the next mode. This can be seen when running > the full kms_rotation_crc testcase without --subtest, it will fail > on exhaust-fences because the bad-tiling subtest wasn't able to > disable pipe C correctly. > > Testcase: kms_rotation_crc > Signed-off-by: Maarten Lankhorst Reviewed-by: Mika Kahola > --- > lib/igt_kms.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lib/igt_kms.c b/lib/igt_kms.c > index a5db6bc493c2..d25090b05c70 100644 > --- a/lib/igt_kms.c > +++ b/lib/igt_kms.c > @@ -2332,7 +2332,7 @@ static int > igt_primary_plane_commit_legacy(igt_plane_t *primary, > igt_assert(!primary->rotation_changed); > > if (!primary->fb_changed && !primary->position_changed && > - !primary->size_changed) > + !primary->size_changed && !primary->pipe->mode_changed) > return 0; > > crtc_id = pipe->crtc_id; -- Mika Kahola - Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests/kms_sequence: Add tests for new CRTC get/queue sequence ioctls
On Sat, Sep 30, 2017 at 12:35:33PM -0700, kei...@keithp.com wrote: > From: Keith Packard > > These ioctls replace drmWaitVBlank and add ns time resolution and > 64-bit sequence numbers to comply with the Vulkan API specifications. > > The tests were derived from the existing kms_vblank tests with the > 'wait' variant elided as the new API doesn't provide a mechanism for > blocking in the kernel. > > Signed-off-by: Keith Packard > --- > lib/igt_kms.c | 2 +- > lib/igt_kms.h | 1 + > tests/Makefile.sources | 1 + > tests/kms_sequence.c | 289 > + > tests/meson.build | 1 + > 5 files changed, 293 insertions(+), 1 deletion(-) > create mode 100644 tests/kms_sequence.c > > diff --git a/lib/igt_kms.c b/lib/igt_kms.c > index 7bcafc07..61ecb1f2 100644 > --- a/lib/igt_kms.c > +++ b/lib/igt_kms.c > @@ -1983,7 +1983,7 @@ report_dup: > } > } > > -static igt_pipe_t *igt_output_get_driving_pipe(igt_output_t *output) > +igt_pipe_t *igt_output_get_driving_pipe(igt_output_t *output) > { Some documentation for this function is in order if it's made non-static. -- Petri Latvala ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: enable to read CSB and CSB write pointer from HWSP in GVT-g VM
On Mon, 2017-10-02 at 11:23 +0100, Chris Wilson wrote: > Quoting Joonas Lahtinen (2017-10-02 11:03:30) > > On Sat, 2017-09-30 at 13:57 +0800, Weinan Li wrote: > > > Let GVT-g VM read the CSB and CSB write pointer from virtual HWSP, not all > > > the host support this feature, need to check the BIT(3) of caps in PVINFO. > > > > > > Signed-off-by: Weinan Li > > > Cc: Chris Wilson > > > > > > > > > @@ -396,6 +393,12 @@ static bool csb_force_mmio(struct drm_i915_private > > > *i915) > > > if (intel_vtd_active()) > > > return true; > > > > > > + /* GVT emulation depends upon host kernel implementation, check > > > + * support capbility by reading PV INFO before access HWSP. > > > + */ > > > > The comment can be dropped completely, the code is self-descriptive. > > > > > +++ b/drivers/gpu/drm/i915/intel_lrc.c > > > @@ -722,7 +722,12 @@ static void intel_lrc_irq_handler(unsigned long data) > > > > > > &engine->status_page.page_addr[I915_HWS_CSB_BUF0_INDEX]; > > > unsigned int head, tail; > > > > > > - /* However GVT emulation depends upon intercepting CSB mmio > > > */ > > > + /* However GVT-g emulation depends upon host kernel > > > + * implementation, need to check support capbility by > > > reading PV > > > + * INFO before access HWSP. Beside from this, another > > > special > > > + * configuration may also need to force use mmio, like IOMMU > > > + * enabled. > > > + */ > > > > s/capbility/capability/ and please rephrase this to be a kerneldoc for > > csb_use_mmio at the declaration. > > This is not a description of how to use the function or even on how > csb_use_mmio work, this is why we want certain logic paths. Just a regular > old comment. That's why I asked to "rephrase" :) Anyway, it seems like there already is kerneldoc for the csb_use_mmio, so this comment can be dropped. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Silence compiler warning for hsw_power_well_enable()
On Mon, Oct 02, 2017 at 11:04:16AM +0100, Chris Wilson wrote: > Not all compilers are able to determine that pg is guarded by wait_fuses > and so may think that pg is used uninitialized. > > Reported-by: Geert Uytterhoeven > Fixes: b2891eb2531e ("drm/i915/hsw+: Add has_fuses power well attribute") > Signed-off-by: Chris Wilson > Cc: Imre Deak > Cc: Arkadiusz Hiler Reviewed-by: Imre Deak > --- > drivers/gpu/drm/i915/intel_runtime_pm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c > b/drivers/gpu/drm/i915/intel_runtime_pm.c > index 7933d1bc6a1c..de207c93c063 100644 > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c > @@ -368,7 +368,7 @@ static void hsw_power_well_enable(struct drm_i915_private > *dev_priv, > { > enum i915_power_well_id id = power_well->id; > bool wait_fuses = power_well->hsw.has_fuses; > - enum skl_power_gate pg; > + enum skl_power_gate uninitialized_var(pg); > u32 val; > > if (wait_fuses) { > -- > 2.14.2 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for meson: Follow suit with the renaming of kms_pipe_color
== Series Details == Series: meson: Follow suit with the renaming of kms_pipe_color URL : https://patchwork.freedesktop.org/series/31264/ State : success == Summary == IGT patchset tested on top of latest successful build 1e99f8b8d2563d7f5c4e82932bab15abc5eacaef meson: Distribute meson build system files with latest DRM-Tip kernel build CI_DRM_3162 2f14e319a2fd drm-tip: 2017y-10m-02d-09h-23m-23s UTC integration manifest No testlist changes. Test chamelium: Subgroup dp-crc-fast: pass -> FAIL (fi-kbl-7500u) fdo#102514 fdo#102514 https://bugs.freedesktop.org/show_bug.cgi?id=102514 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:457s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:474s fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 time:394s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:581s fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:292s fi-bxt-dsi total:289 pass:259 dwarn:0 dfail:0 fail:0 skip:30 time:532s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:537s fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34 time:549s fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38 time:537s fi-cfl-s total:289 pass:256 dwarn:1 dfail:0 fail:0 skip:32 time:561s fi-cnl-y total:289 pass:261 dwarn:1 dfail:0 fail:0 skip:27 time:631s fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:441s fi-glk-1 total:289 pass:257 dwarn:3 dfail:0 fail:0 skip:29 time:596s fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:442s fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:419s fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:468s fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:512s fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:485s fi-kbl-7500u total:289 pass:263 dwarn:1 dfail:0 fail:1 skip:24 time:498s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:583s fi-kbl-7567u total:289 pass:265 dwarn:4 dfail:0 fail:0 skip:20 time:503s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:587s fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:664s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:477s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:533s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:525s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:473s fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38 time:588s fi-snb-2600 total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:438s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_282/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] [PATCH] mm, oom: Offload OOM notify callback to a kernel thread.
On Mon 02-10-17 20:33:52, Tetsuo Handa wrote: > Michal Hocko wrote: > > [Hmm, I do not see the original patch which this has been a reply to] > > urbl.hostedemail.com and b.barracudacentral.org blocked my IP address, > and the rest are "Recipient address rejected: Greylisted" or > "Deferred: 451-4.3.0 Multiple destination domains per transaction is > unsupported.", > and after all dropped at the servers. Sad... > > > > > On Mon 02-10-17 06:59:12, Michael S. Tsirkin wrote: > > > On Sun, Oct 01, 2017 at 02:44:34PM +0900, Tetsuo Handa wrote: > > > > Tetsuo Handa wrote: > > > > > Michael S. Tsirkin wrote: > > > > > > On Mon, Sep 11, 2017 at 07:27:19PM +0900, Tetsuo Handa wrote: > > > > > > > Hello. > > > > > > > > > > > > > > I noticed that virtio_balloon is using register_oom_notifier() and > > > > > > > leak_balloon() from virtballoon_oom_notify() might depend on > > > > > > > __GFP_DIRECT_RECLAIM memory allocation. > > > > > > > > > > > > > > In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in > > > > > > > order to > > > > > > > serialize against fill_balloon(). But in fill_balloon(), > > > > > > > alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | > > > > > > > __GFP_NORETRY) is > > > > > > > called with vb->balloon_lock mutex held. Since > > > > > > > GFP_HIGHUSER[_MOVABLE] implies > > > > > > > __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, this allocation > > > > > > > attempt might > > > > > > > depend on somebody else's __GFP_DIRECT_RECLAIM | !__GFP_NORETRY > > > > > > > memory > > > > > > > allocation. Such __GFP_DIRECT_RECLAIM | !__GFP_NORETRY allocation > > > > > > > can reach > > > > > > > __alloc_pages_may_oom() and hold oom_lock mutex and call > > > > > > > out_of_memory(). > > > > > > > And leak_balloon() is called by virtballoon_oom_notify() via > > > > > > > blocking_notifier_call_chain() callback when vb->balloon_lock > > > > > > > mutex is already > > > > > > > held by fill_balloon(). As a result, despite __GFP_NORETRY is > > > > > > > specified, > > > > > > > fill_balloon() can indirectly get stuck waiting for > > > > > > > vb->balloon_lock mutex > > > > > > > at leak_balloon(). > > > > This is really nasty! And I would argue that this is an abuse of the oom > > notifier interface from the virtio code. OOM notifiers are an ugly hack > > on its own but all its users have to be really careful to not depend on > > any allocation request because that is a straight deadlock situation. > > Please describe such warning at > "int register_oom_notifier(struct notifier_block *nb)" definition. Yes, we can and should do that. Although I would prefer to simply document this API as deprecated. Care to send a patch? I am quite busy with other stuff. > > I do not think that making oom notifier API more complex is the way to > > go. Can we simply change the lock to try_lock? > > Using mutex_trylock(&vb->balloon_lock) alone is not sufficient. Inside the > mutex, __GFP_DIRECT_RECLAIM && !__GFP_NORETRY allocation attempt is used > which will fail to make progress due to oom_lock already held. Therefore, > virtballoon_oom_notify() needs to guarantee that all allocation attempts use > GFP_NOWAIT when called from virtballoon_oom_notify(). Ohh, I missed your point and thought the dependency is indirect and some other call path is allocating while holding the lock. But you seem to be right and leak_balloon tell_host virtqueue_add_outbuf virtqueue_add can do GFP_KERNEL allocation and this is clearly wrong. Nobody should try to allocate while we are in the OOM path. Michael, is there any way to drop this? -- 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 02/21] drm/i915: introduce simple gemfs
On Fri, 2017-09-29 at 17:10 +0100, Matthew Auld wrote: > Not a fully blown gemfs, just our very own tmpfs kernel mount. Doing so > moves us away from the shmemfs shm_mnt, and gives us the much needed > flexibility to do things like set our own mount options, namely huge= > which should allow us to enable the use of transparent-huge-pages for > our shmem backed objects. > > v2: various improvements suggested by Joonas > > v3: move gemfs instance to i915.mm and simplify now that we have > file_setup_with_mnt > > v4: fallback to tmpfs shm_mnt upon failure to setup gemfs > > v5: make tmpfs fallback kinder > > Signed-off-by: Matthew Auld > Cc: Joonas Lahtinen > Cc: Chris Wilson > Cc: Dave Hansen > Cc: Kirill A. Shutemov > Cc: Hugh Dickins > Cc: linux...@kvack.org > @@ -4251,6 +4252,29 @@ static const struct drm_i915_gem_object_ops > i915_gem_object_ops = { > .pwrite = i915_gem_object_pwrite_gtt, > }; > > +static int i915_gem_object_create_shmem(struct drm_device *dev, > + struct drm_gem_object *obj, > + size_t size) > +{ > + struct drm_i915_private *i915 = to_i915(dev); > + struct file *filp; > + > + drm_gem_private_object_init(dev, obj, size); > + > + if (i915->mm.gemfs) > + filp = shmem_file_setup_with_mnt(i915->mm.gemfs, "i915", size, > + VM_NORESERVE); > + else > + filp = shmem_file_setup("i915", size, VM_NORESERVE); Put that VM_NORESERVE to 'flags' variable. > @@ -4915,6 +4939,9 @@ i915_gem_load_init(struct drm_i915_private *dev_priv) > > spin_lock_init(&dev_priv->fb_tracking.lock); > > + if (i915_gemfs_init(dev_priv)) > + DRM_NOTE("Unable to create a private tmpfs mountpoint, hugepage > support will be disabled.\n"); s/mountpoint/mount/, as we're not creating a directory. Maybe also include the returned error for easier post-mortem? Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/21] drm/i915/gemfs: enable THP
On Fri, 2017-09-29 at 17:10 +0100, Matthew Auld wrote: > Enable transparent-huge-pages through gemfs by mounting with > huge=within_size. > > v2: sprinkle within_size comment > > Signed-off-by: Matthew Auld > Cc: Joonas Lahtinen > Cc: Chris Wilson > --- > drivers/gpu/drm/i915/i915_gemfs.c | 21 + > 1 file changed, 21 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_gemfs.c > b/drivers/gpu/drm/i915/i915_gemfs.c > index 168d0bd98f60..b1b4d13d8f97 100644 > --- a/drivers/gpu/drm/i915/i915_gemfs.c > +++ b/drivers/gpu/drm/i915/i915_gemfs.c > @@ -24,6 +24,7 @@ > > #include > #include > +#include > > #include "i915_drv.h" > #include "i915_gemfs.h" > @@ -41,6 +42,26 @@ int i915_gemfs_init(struct drm_i915_private *i915) > if (IS_ERR(gemfs)) > return PTR_ERR(gemfs); > > + /* > + * Enable huge-pages for objects that are at least HPAGE_PMD_SIZE, most > + * likely 2M. Note that within_size may overallocate huge-pages, if say > + * we allocate an object of size 2M + 4K, but under memory pressure Maybe append after "2M + 4K" "we may get 2M + 2M", to complete the sentence. Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/21] drm/i915: introduce vm set_pages/clear_pages
On Fri, 2017-09-29 at 17:10 +0100, Matthew Auld wrote: > Move the setting/clearing of the vma->pages to a vm operation. Doing so > neatens things up a little, but more importantly gives us a sane place > to also set/clear the vma->pages_sizes, which we introduce later in > preparation for supporting huge-pages. > > v2: remove redundant vma->pages check > > v3: GEM_BUG_ON(vma->pages) following i915_vma_remove > > Suggested-by: Chris Wilson > Signed-off-by: Matthew Auld > Cc: Joonas Lahtinen > Cc: Chris Wilson > Reviewed-by: Chris Wilson Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/21] drm/i915: align the vma start to the largest gtt page size
On Fri, 2017-09-29 at 17:10 +0100, Matthew Auld wrote: > For the 48b PPGTT try to align the vma start address to the required > page size boundary to guarantee we use said page size in the gtt. If we > are dealing with multiple page sizes, we can't guarantee anything and > just align to the largest. For soft pinning and objects which need to be > tightly packed into the lower 32bits we don't force any alignment. > > v2: various improvements suggested by Chris > > v3: use set_pages and better placement of page_sizes > > v4: prefer upper_32_bits() > > Signed-off-by: Matthew Auld > Cc: Joonas Lahtinen > Cc: Chris Wilson > Reviewed-by: Chris Wilson > @@ -238,6 +241,8 @@ static void clear_pages(struct i915_vma *vma) > kfree(vma->pages); > } > vma->pages = NULL; > + > + memset(&vma->page_sizes, 0, sizeof(struct i915_page_sizes)); sizeof(vma->page_sizes) > @@ -2538,6 +2543,9 @@ static int ggtt_set_pages(struct i915_vma *vma) > if (ret) > return ret; > > + vma->page_sizes.phys = vma->obj->mm.page_sizes.phys; > + vma->page_sizes.sg = vma->obj->mm.page_sizes.sg; Hmm, are we not able to assign vma->page_sizes = vma->obj->mm.page_sizes? Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/21] drm/i915: align 64K objects to 2M
On Fri, 2017-09-29 at 17:10 +0100, Matthew Auld wrote: > We can't mix 64K and 4K pte's in the same page-table, so for now we > align 64K objects to 2M to avoid any potential mixing. This is > potentially wasteful but in reality shouldn't be too bad since this only > applies to the virtual address space of a 48b PPGTT. > > v2: don't separate logically connected ops > > Suggested-by: Chris Wilson > Signed-off-by: Matthew Auld > Cc: Joonas Lahtinen > Cc: Chris Wilson > Reviewed-by: Chris Wilson > +++ b/drivers/gpu/drm/i915/i915_vma.c > @@ -501,9 +501,18 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64 > alignment, u64 flags) > if (upper_32_bits(end) && > vma->page_sizes.sg > I915_GTT_PAGE_SIZE) { Here. See below. > u64 page_alignment = > - rounddown_pow_of_two(vma->page_sizes.sg); > + rounddown_pow_of_two(vma->page_sizes.sg | > + I915_GTT_PAGE_SIZE_2M); > > alignment = max(alignment, page_alignment); > + > + /* > + * We can't mix 64K and 4K PTEs in the same page-table > (2M > + * block), and so to avoid the ugliness and complexity > of > + * coloring we opt for just aligning 64K objects to 2M. > + */ This is about size, the alignment is happening above, I'd lift the comment there. > + if (vma->page_sizes.sg & I915_GTT_PAGE_SIZE_64K) > + size = round_up(size, I915_GTT_PAGE_SIZE_2M); > } Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v4 4/7] lib/igt_kms: Rework connector properties to be more atomic, v2.
On Fri, 2017-09-29 at 11:59 +0200, Maarten Lankhorst wrote: > In the future I want to allow tests to commit more properties, > but for this to work I have to fix all properties to work better > with atomic commit. Instead of special casing each > property make a bitmask for all property changed flags, and try to > commit all properties. > > Changs since v1: > - Mention which properties we set to what. > - Assert the property to be set is valid. > > Signed-off-by: Maarten Lankhorst Reviewed-by: Mika Kahola > --- > lib/igt_kms.c| 44 +++--- > -- > lib/igt_kms.h| 35 +++--- > -- > tests/kms_atomic_interruptible.c | 4 ++-- > tests/kms_panel_fitting.c| 2 +- > 4 files changed, 45 insertions(+), 40 deletions(-) > > diff --git a/lib/igt_kms.c b/lib/igt_kms.c > index d25090b05c70..07d2074c2b1a 100644 > --- a/lib/igt_kms.c > +++ b/lib/igt_kms.c > @@ -248,7 +248,7 @@ igt_atomic_fill_connector_props(igt_display_t > *display, igt_output_t *output, > if (strcmp(prop->name, conn_prop_names[j]) > != 0) > continue; > > - output->config.atomic_props_connector[j] = > props->props[i]; > + output->props[j] = props->props[i]; > break; > } > > @@ -1834,7 +1834,7 @@ void igt_display_init(igt_display_t *display, > int drm_fd) > > igt_output_refresh(output); > > - output->config.pipe_changed = true; > + igt_output_set_prop_changed(output, > IGT_CONNECTOR_CRTC_ID); > } > > drmModeFreePlaneResources(plane_resources); > @@ -2514,23 +2514,24 @@ static void > igt_atomic_prepare_crtc_commit(igt_pipe_t *pipe_obj, drmModeAtomicRe > static void igt_atomic_prepare_connector_commit(igt_output_t > *output, drmModeAtomicReq *req) > { > > - struct kmstest_connector_config *config = &output->config; > + int i; > > - if (config->connector_scaling_mode_changed) > - igt_atomic_populate_connector_req(req, output, > IGT_CONNECTOR_SCALING_MODE, config->connector_scaling_mode); > + for (i = 0; i < IGT_NUM_CONNECTOR_PROPS; i++) { > + if (!igt_output_is_prop_changed(output, i)) > + continue; > > - if (config->pipe_changed) { > - uint32_t crtc_id = 0; > + /* it's an error to try an unsupported feature */ > + igt_assert(output->props[i]); > > - if (output->config.pipe != PIPE_NONE) > - crtc_id = output->config.crtc->crtc_id; > + igt_debug("%s: Setting property \"%s\" to > 0x%"PRIx64"/%"PRIi64"\n", > + igt_output_name(output), > igt_connector_prop_names[i], > + output->values[i], output->values[i]); > > - igt_atomic_populate_connector_req(req, output, > IGT_CONNECTOR_CRTC_ID, crtc_id); > + igt_assert_lt(0, drmModeAtomicAddProperty(req, > + output->config.connector- > >connector_id, > + output->props[i], > + output->values[i])); > } > - /* > - * TODO: Add all other connector level properties > here > - */ > - > } > > /* > @@ -2625,11 +2626,10 @@ display_commit_changed(igt_display_t > *display, enum igt_commit_style s) > for (i = 0; i < display->n_outputs; i++) { > igt_output_t *output = &display->outputs[i]; > > - if (s != COMMIT_UNIVERSAL) > - output->config.pipe_changed = false; > - > if (s == COMMIT_ATOMIC) > - output- > >config.connector_scaling_mode_changed = false; > + output->changed = 0; > + else if (s != COMMIT_UNIVERSAL) > + igt_output_clear_prop_changed(output, > IGT_CONNECTOR_CRTC_ID); > } > } > > @@ -2873,18 +2873,16 @@ void igt_output_set_pipe(igt_output_t > *output, enum pipe pipe) > if (pipe != PIPE_NONE) > display->pipes[pipe].mode_changed = true; > > - output->config.pipe_changed = true; > + igt_output_set_prop_value(output, IGT_CONNECTOR_CRTC_ID, > pipe == PIPE_NONE ? 0 : display->pipes[pipe].crtc_id); > > igt_output_refresh(output); > } > > void igt_output_set_scaling_mode(igt_output_t *output, uint64_t > scaling_mode) > { > - output->config.connector_scaling_mode_changed = true; > - > - output->config.connector_scaling_mode = scaling_mode; > + igt_output_set_prop_value(output, > IGT_CONNECTOR_SCALING_MODE, scaling_mode); > > - igt_require(output- > >config.atomic_props_connector[IGT_CONNECTOR_SCALING_MODE]); > + igt_require(output->props[IGT_CONNECTOR_SCALING_MODE]); > } > > igt_plane_t *igt_output_get_plane(igt_output_t *output, int > plane_idx) > diff --git a/lib/ig
Re: [Intel-gfx] [PATCH 10/21] drm/i915: enable IPS bit for 64K pages
On Fri, 2017-09-29 at 17:10 +0100, Matthew Auld wrote: > Before we can enable 64K pages through the IPS bit, we must first enable > it through MMIO, otherwise the page-walker will simply ignore it. > > v2: add comment mentioning that 64K is BDW+ > > v3: move to more suitable home > > Signed-off-by: Matthew Auld > Cc: Joonas Lahtinen > Cc: Chris Wilson > Cc: Mika Kuoppala > Reviewed-by: Mika Kuoppala Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/21] drm/i915: disable GTT cache for 2M pages
On Fri, 2017-09-29 at 17:10 +0100, Matthew Auld wrote: > When SW enables the use of 2M/1G pages, it must disable the GTT cache. > > v2: don't disable for Cherryview which doesn't even support 48b PPGTT! > > v3: explicitly check that the system does support 2M/1G pages > > Signed-off-by: Matthew Auld > Cc: Joonas Lahtinen > Cc: Chris Wilson > Cc: Mika Kuoppala > Reviewed-by: Mika Kuoppala > @@ -8483,10 +8483,11 @@ static void bdw_init_clock_gating(struct > drm_i915_private *dev_priv) > > /* >* WaGttCachingOffByDefault:bdw > - * GTT cache may not work with big pages, so if those > - * are ever enabled GTT cache may need to be disabled. > + * The GTT cache must be disabled if the system is using 2M/1G pages. >*/ > - I915_WRITE(HSW_GTT_CACHE_EN, GTT_CACHE_EN_ALL); > + I915_WRITE(HSW_GTT_CACHE_EN, > +HAS_PAGE_SIZES(dev_priv, I915_GTT_PAGE_SIZE_2M) ? 0 : > +GTT_CACHE_EN_ALL); Umm, this is mixing a known W/A with decision logic. bool can_use_gtt_cache = !HAS_PAGE_SIZES(dev_priv, I915_GTT_PAGE_SIZE_2M); /* WaGttCachingOffByDefault:bdw */ I915_WRITE(HSW_GTT_CACHE_EN, can_use_gtt_cache ? GTT_CACHE_EN_ALL : 0); The big question is that if everyone else has GTT caching enabled by default, should not we actively be disabling it on other code paths? I'm also feeling 'init_clock_gating' is not the best home for the code. We can find a new home later, but do separate the decision logic from the W/A. Also, do 1G pages imply 2M page support? It's bit on the theoritical side of science of course. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for meson: Follow suit with the renaming of kms_pipe_color
== Series Details == Series: meson: Follow suit with the renaming of kms_pipe_color URL : https://patchwork.freedesktop.org/series/31264/ State : success == Summary == Test gem_eio: Subgroup in-flight-contexts: pass -> DMESG-WARN (shard-hsw) fdo#102886 +1 Test kms_setmode: Subgroup basic: fail -> PASS (shard-hsw) fdo#99912 fdo#102886 https://bugs.freedesktop.org/show_bug.cgi?id=102886 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 shard-hswtotal:2429 pass:1331 dwarn:5 dfail:0 fail:10 skip:1083 time:10111s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_282/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Organize GLK_COLORS.
On Thu, 28 Sep 2017, Rodrigo Vivi wrote: > Let's organize this in a way that it gets more obvious > when looking to the platform colors and in a easier > way to get inherited. > > Signed-off-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/i915_pci.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c > index 9b54aafa2a0b..10537dcdd9c1 100644 > --- a/drivers/gpu/drm/i915/i915_pci.c > +++ b/drivers/gpu/drm/i915/i915_pci.c > @@ -54,6 +54,8 @@ > .color = { .degamma_lut_size = 512, .gamma_lut_size = 512 } > #define CHV_COLORS \ > .color = { .degamma_lut_size = 65, .gamma_lut_size = 257 } > +#define GLK_COLORS \ > + .color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 } > > /* Keep in gen based order, and chronological order within a gen */ > #define GEN2_FEATURES \ > @@ -495,7 +497,7 @@ static const struct intel_device_info > intel_geminilake_info __initconst = { > GEN9_LP_FEATURES, > .platform = INTEL_GEMINILAKE, > .ddb_size = 1024, > - .color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 } > + GLK_COLORS Please add he comma at the end. > }; > > #define KBL_PLATFORM \ > @@ -543,7 +545,7 @@ static const struct intel_device_info > intel_coffeelake_gt3_info __initconst = { > #define GEN10_FEATURES \ > GEN9_FEATURES, \ > .ddb_size = 1024, \ > - .color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 } > + GLK_COLORS Ditto. BR, Jani. > > static const struct intel_device_info intel_cannonlake_gt2_info __initconst > = { > GEN10_FEATURES, -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] meson: Follow suit with the renaming of kms_pipe_color
On Mon, Oct 02, 2017 at 01:50:05PM +0300, Petri Latvala wrote: > CC: Maarten Lankhorst > Signed-off-by: Petri Latvala Reviewed-by: Arkadiusz Hiler ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] dim: use prep_pull_mail_overview for drm-intel-testing
On Mon, Oct 02, 2017 at 12:45:19PM +0300, Jani Nikula wrote: > It's not perfect or exactly the same, but prefer fewer lines of special > casing anyway. > > Signed-off-by: Jani Nikula Ack on both patches in this series. -Daniel > --- > dim | 8 ++-- > 1 file changed, 2 insertions(+), 6 deletions(-) > > diff --git a/dim b/dim > index bfa6ef010806..866a420d4ef6 100755 > --- a/dim > +++ b/dim > @@ -1615,12 +1615,8 @@ function dim_update_next_continue > The following changes tagged $tag_testing: > > HERE > - obj=$(git rev-parse $tag) > - if [[ "$(git cat-file -t $obj)" == "tag" ]] ; then > - git cat-file -p $obj | tail -n+6 >> $req_file > - else > - echo "*** CHANGELOG OVERVIEW HERE ***" >> $req_file > - fi > + > + prep_pull_mail_overview "$tag" >> $req_file > prep_pull_mail_signature >> $req_file > > $DRY $DIM_MUA -s "Updated drm-intel-testing" \ > -- > 2.11.0 > -- 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
Re: [Intel-gfx] [PATCH 1/2] dim: use prep_pull_mail_overview for drm-intel-testing
On Mon, 02 Oct 2017, Daniel Vetter wrote: > On Mon, Oct 02, 2017 at 12:45:19PM +0300, Jani Nikula wrote: >> It's not perfect or exactly the same, but prefer fewer lines of special >> casing anyway. >> >> Signed-off-by: Jani Nikula > > Ack on both patches in this series. Pushed, thanks. BR, Jani. > -Daniel >> --- >> dim | 8 ++-- >> 1 file changed, 2 insertions(+), 6 deletions(-) >> >> diff --git a/dim b/dim >> index bfa6ef010806..866a420d4ef6 100755 >> --- a/dim >> +++ b/dim >> @@ -1615,12 +1615,8 @@ function dim_update_next_continue >> The following changes tagged $tag_testing: >> >> HERE >> -obj=$(git rev-parse $tag) >> -if [[ "$(git cat-file -t $obj)" == "tag" ]] ; then >> -git cat-file -p $obj | tail -n+6 >> $req_file >> -else >> -echo "*** CHANGELOG OVERVIEW HERE ***" >> $req_file >> -fi >> + >> +prep_pull_mail_overview "$tag" >> $req_file >> prep_pull_mail_signature >> $req_file >> >> $DRY $DIM_MUA -s "Updated drm-intel-testing" \ >> -- >> 2.11.0 >> -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/21] drm/i915: disable GTT cache for 2M pages
On 2 October 2017 at 13:31, Joonas Lahtinen wrote: > On Fri, 2017-09-29 at 17:10 +0100, Matthew Auld wrote: >> When SW enables the use of 2M/1G pages, it must disable the GTT cache. >> >> v2: don't disable for Cherryview which doesn't even support 48b PPGTT! >> >> v3: explicitly check that the system does support 2M/1G pages >> >> Signed-off-by: Matthew Auld >> Cc: Joonas Lahtinen >> Cc: Chris Wilson >> Cc: Mika Kuoppala >> Reviewed-by: Mika Kuoppala > > > >> @@ -8483,10 +8483,11 @@ static void bdw_init_clock_gating(struct >> drm_i915_private *dev_priv) >> >> /* >>* WaGttCachingOffByDefault:bdw >> - * GTT cache may not work with big pages, so if those >> - * are ever enabled GTT cache may need to be disabled. >> + * The GTT cache must be disabled if the system is using 2M/1G pages. >>*/ >> - I915_WRITE(HSW_GTT_CACHE_EN, GTT_CACHE_EN_ALL); >> + I915_WRITE(HSW_GTT_CACHE_EN, >> +HAS_PAGE_SIZES(dev_priv, I915_GTT_PAGE_SIZE_2M) ? 0 : >> +GTT_CACHE_EN_ALL); > > Umm, this is mixing a known W/A with decision logic. > > bool can_use_gtt_cache = !HAS_PAGE_SIZES(dev_priv, > I915_GTT_PAGE_SIZE_2M); > > /* WaGttCachingOffByDefault:bdw */ > I915_WRITE(HSW_GTT_CACHE_EN, can_use_gtt_cache ? GTT_CACHE_EN_ALL : > 0); > > The big question is that if everyone else has GTT caching enabled by > default, should not we actively be disabling it on other code paths? AFAIK it's *disabled* by default, bdw and chv are the only platforms which seek to enable it. I don't know why other platforms don't also follow suit... That WA is literally just: "WA to enable the caching if off by defaultboth at driver init and Resume". > I'm also feeling 'init_clock_gating' is not the best home for the code. > > We can find a new home later, but do separate the decision logic from > the W/A. > > Also, do 1G pages imply 2M page support? It's bit on the theoritical > side of science of course. I just assume not, since it doesn't explicitly state that anywhere. > > Regards, Joonas > -- > Joonas Lahtinen > Open Source Technology Center > Intel Corporation > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix DDI PHY init if it was already on
The common lane power down flag of a DPIO PHY has a funky semantic: after the initial enabling of the PHY (so from a disabled state) this flag will be clear. It will be set only after the PHY will be used for the first time (for instance due to enabling the corresponding pipe) and then become unused (due to disabling the pipe). During the initial PHY enablement we don't know which of the above phases we are in, so move the check for the flag where this is known, the HW readout code. This is where the rest of lane power down status checks are done anyway. This fixes at least a problem on GLK where after module reloading, the common lane power down flag of PHY1 is set, but the PHY is actually powered-on and properly set up. The GRC readout code for other PHYs will hence think that PHY1 is not powered initially and disable it after the GRC readout. This will cause the AUX power well related to PHY1 to get disabled in a stuck state, timing out when we try to enable it later. Cc: Ville Syrjala Fixes: e93da0a0137b ("drm/i915/bxt: Sanitiy check the PHY lane power down status") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102777 Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/intel_ddi.c | 3 ++- drivers/gpu/drm/i915/intel_dpio_phy.c | 20 2 files changed, 2 insertions(+), 21 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index 93cbbcbbc193..65f4b6786791 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -1713,7 +1713,8 @@ bool intel_ddi_get_hw_state(struct intel_encoder *encoder, out: if (ret && IS_GEN9_LP(dev_priv)) { tmp = I915_READ(BXT_PHY_CTL(port)); - if ((tmp & (BXT_PHY_LANE_POWERDOWN_ACK | + if ((tmp & (BXT_PHY_CMNLANE_POWERDOWN_ACK | + BXT_PHY_LANE_POWERDOWN_ACK | BXT_PHY_LANE_ENABLED)) != BXT_PHY_LANE_ENABLED) DRM_ERROR("Port %c enabled but PHY powered down? " "(PHY_CTL %08x)\n", port_name(port), tmp); diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c b/drivers/gpu/drm/i915/intel_dpio_phy.c index 09b670929786..de38d014ed39 100644 --- a/drivers/gpu/drm/i915/intel_dpio_phy.c +++ b/drivers/gpu/drm/i915/intel_dpio_phy.c @@ -208,12 +208,6 @@ static const struct bxt_ddi_phy_info glk_ddi_phy_info[] = { }, }; -static u32 bxt_phy_port_mask(const struct bxt_ddi_phy_info *phy_info) -{ - return (phy_info->dual_channel * BIT(phy_info->channel[DPIO_CH1].port)) | - BIT(phy_info->channel[DPIO_CH0].port); -} - static const struct bxt_ddi_phy_info * bxt_get_phy_list(struct drm_i915_private *dev_priv, int *count) { @@ -313,7 +307,6 @@ bool bxt_ddi_phy_is_enabled(struct drm_i915_private *dev_priv, enum dpio_phy phy) { const struct bxt_ddi_phy_info *phy_info; - enum port port; phy_info = bxt_get_phy_info(dev_priv, phy); @@ -335,19 +328,6 @@ bool bxt_ddi_phy_is_enabled(struct drm_i915_private *dev_priv, return false; } - for_each_port_masked(port, bxt_phy_port_mask(phy_info)) { - u32 tmp = I915_READ(BXT_PHY_CTL(port)); - - if (tmp & BXT_PHY_CMNLANE_POWERDOWN_ACK) { - DRM_DEBUG_DRIVER("DDI PHY %d powered, but common lane " -"for port %c powered down " -"(PHY_CTL %08x)\n", -phy, port_name(port), tmp); - - return false; - } - } - return true; } -- 2.13.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/6] drm/i915/uc: Drop unnecessary forward declaration
We don't need it here. Signed-off-by: Michal Wajdeczko Cc: Sagar Arun Kamble Reviewed-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/intel_uc.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h index 6966349..38ec880 100644 --- a/drivers/gpu/drm/i915/intel_uc.h +++ b/drivers/gpu/drm/i915/intel_uc.h @@ -30,8 +30,6 @@ #include "intel_guc_ct.h" #include "i915_vma.h" -struct drm_i915_gem_request; - /* * This structure primarily describes the GEM object shared with the GuC. * The specs sometimes refer to this object as a "GuC context", but we use -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/6] drm/i915/uc: Move uC fw helper code into dedicated files
This is a prerequisite to unblock next steps. Signed-off-by: Michal Wajdeczko Cc: Joonas Lahtinen Cc: Chris Wilson Cc: Sagar Arun Kamble Reviewed-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/intel_uc.c| 159 + drivers/gpu/drm/i915/intel_uc.h| 67 +- drivers/gpu/drm/i915/intel_uc_fw.c | 178 + drivers/gpu/drm/i915/intel_uc_fw.h | 95 5 files changed, 279 insertions(+), 221 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_uc_fw.c create mode 100644 drivers/gpu/drm/i915/intel_uc_fw.h diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index 5182e3d..4850f26 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -59,6 +59,7 @@ i915-y += i915_cmd_parser.o \ # general-purpose microcontroller (GuC) support i915-y += intel_uc.o \ + intel_uc_fw.o \ intel_guc_ct.o \ intel_guc_log.o \ intel_guc_loader.o \ diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index 2774778..201d23e 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -26,19 +26,6 @@ #include "intel_uc.h" #include -/* Cleans up uC firmware by releasing the firmware GEM obj. - */ -static void __intel_uc_fw_fini(struct intel_uc_fw *uc_fw) -{ - struct drm_i915_gem_object *obj; - - obj = fetch_and_zero(&uc_fw->obj); - if (obj) - i915_gem_object_put(obj); - - uc_fw->fetch_status = INTEL_UC_FIRMWARE_NONE; -} - /* Reset GuC providing us with fresh state for both GuC and HuC. */ static int __intel_uc_reset_hw(struct drm_i915_private *dev_priv) @@ -112,154 +99,16 @@ void intel_uc_init_early(struct drm_i915_private *dev_priv) guc->notify = gen8_guc_raise_irq; } -static void fetch_uc_fw(struct drm_i915_private *dev_priv, - struct intel_uc_fw *uc_fw) -{ - struct pci_dev *pdev = dev_priv->drm.pdev; - struct drm_i915_gem_object *obj; - const struct firmware *fw = NULL; - struct uc_css_header *css; - size_t size; - int err; - - if (!uc_fw->path) - return; - - uc_fw->fetch_status = INTEL_UC_FIRMWARE_PENDING; - - DRM_DEBUG_DRIVER("before requesting firmware: uC fw fetch status %s\n", -intel_uc_fw_status_repr(uc_fw->fetch_status)); - - err = request_firmware(&fw, uc_fw->path, &pdev->dev); - if (err) - goto fail; - if (!fw) - goto fail; - - DRM_DEBUG_DRIVER("fetch uC fw from %s succeeded, fw %p\n", -uc_fw->path, fw); - - /* Check the size of the blob before examining buffer contents */ - if (fw->size < sizeof(struct uc_css_header)) { - DRM_NOTE("Firmware header is missing\n"); - goto fail; - } - - css = (struct uc_css_header *)fw->data; - - /* Firmware bits always start from header */ - uc_fw->header_offset = 0; - uc_fw->header_size = (css->header_size_dw - css->modulus_size_dw - - css->key_size_dw - css->exponent_size_dw) * sizeof(u32); - - if (uc_fw->header_size != sizeof(struct uc_css_header)) { - DRM_NOTE("CSS header definition mismatch\n"); - goto fail; - } - - /* then, uCode */ - uc_fw->ucode_offset = uc_fw->header_offset + uc_fw->header_size; - uc_fw->ucode_size = (css->size_dw - css->header_size_dw) * sizeof(u32); - - /* now RSA */ - if (css->key_size_dw != UOS_RSA_SCRATCH_MAX_COUNT) { - DRM_NOTE("RSA key size is bad\n"); - goto fail; - } - uc_fw->rsa_offset = uc_fw->ucode_offset + uc_fw->ucode_size; - uc_fw->rsa_size = css->key_size_dw * sizeof(u32); - - /* At least, it should have header, uCode and RSA. Size of all three. */ - size = uc_fw->header_size + uc_fw->ucode_size + uc_fw->rsa_size; - if (fw->size < size) { - DRM_NOTE("Missing firmware components\n"); - goto fail; - } - - /* -* The GuC firmware image has the version number embedded at a -* well-known offset within the firmware blob; note that major / minor -* version are TWO bytes each (i.e. u16), although all pointers and -* offsets are defined in terms of bytes (u8). -*/ - switch (uc_fw->type) { - case INTEL_UC_FW_TYPE_GUC: - /* Header and uCode will be loaded to WOPCM. Size of the two. */ - size = uc_fw->header_size + uc_fw->ucode_size; - - /* Top 32k of WOPCM is reserved (8K stack + 24k RC6 context). */ - if (size > intel_guc_wopcm_size(dev_priv)) { - DRM_ERROR("Firmware is too large to fit in WOPCM\n"); - goto fail;
[Intel-gfx] [PATCH v2 4/6] drm/i915/huc: Move HuC declarations into dedicated header
We want to keep each uC specific code in separate files. Signed-off-by: Michal Wajdeczko Cc: Joonas Lahtinen Cc: Chris Wilson Cc: Sagar Arun Kamble Reviewed-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/intel_huc.h | 38 ++ drivers/gpu/drm/i915/intel_uc.h | 13 + 2 files changed, 39 insertions(+), 12 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_huc.h diff --git a/drivers/gpu/drm/i915/intel_huc.h b/drivers/gpu/drm/i915/intel_huc.h new file mode 100644 index 000..998912e --- /dev/null +++ b/drivers/gpu/drm/i915/intel_huc.h @@ -0,0 +1,38 @@ +/* + * Copyright © 2014-2017 Intel Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS + * IN THE SOFTWARE. + * + */ +#ifndef _INTEL_HUC_H_ +#define _INTEL_HUC_H_ + +struct intel_huc { + /* Generic uC firmware management */ + struct intel_uc_fw fw; + + /* HuC-specific additions */ +}; + +void intel_huc_select_fw(struct intel_huc *huc); +void intel_huc_init_hw(struct intel_huc *huc); +void intel_huc_auth(struct intel_huc *huc); + +#endif diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h index f0d5a3f..4fa091e 100644 --- a/drivers/gpu/drm/i915/intel_uc.h +++ b/drivers/gpu/drm/i915/intel_uc.h @@ -30,6 +30,7 @@ #include "intel_ringbuffer.h" #include "intel_guc_ct.h" #include "i915_vma.h" +#include "intel_huc.h" /* * This structure primarily describes the GEM object shared with the GuC. @@ -127,13 +128,6 @@ struct intel_guc { void (*notify)(struct intel_guc *guc); }; -struct intel_huc { - /* Generic uC firmware management */ - struct intel_uc_fw fw; - - /* HuC-specific additions */ -}; - /* intel_uc.c */ void intel_uc_sanitize_options(struct drm_i915_private *dev_priv); void intel_uc_init_early(struct drm_i915_private *dev_priv); @@ -186,9 +180,4 @@ static inline u32 guc_ggtt_offset(struct i915_vma *vma) return offset; } -/* intel_huc.c */ -void intel_huc_select_fw(struct intel_huc *huc); -void intel_huc_init_hw(struct intel_huc *huc); -void intel_huc_auth(struct intel_huc *huc); - #endif -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 6/6] drm/i915/guc: Move GuC declarations and functions into dedicated files
We want to keep GuC specific code in separated files. v2: move all functions in single patch (Joonas) fix old checkpatch issues (Sagar) Signed-off-by: Michal Wajdeczko Cc: Joonas Lahtinen Cc: Chris Wilson Cc: Sagar Arun Kamble Reviewed-by: Sagar Arun Kamble #1 --- drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/i915_guc_submission.c | 94 --- drivers/gpu/drm/i915/intel_guc.c | 262 + drivers/gpu/drm/i915/intel_guc.h | 178 drivers/gpu/drm/i915/intel_uc.c| 146 +--- drivers/gpu/drm/i915/intel_uc.h| 146 +--- 6 files changed, 444 insertions(+), 383 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_guc.c create mode 100644 drivers/gpu/drm/i915/intel_guc.h diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index 4850f26..51d0d29 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -60,6 +60,7 @@ i915-y += i915_cmd_parser.o \ # general-purpose microcontroller (GuC) support i915-y += intel_uc.o \ intel_uc_fw.o \ + intel_guc.o \ intel_guc_ct.o \ intel_guc_log.o \ intel_guc_loader.o \ diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c b/drivers/gpu/drm/i915/i915_guc_submission.c index 04f1281..89e2a9c 100644 --- a/drivers/gpu/drm/i915/i915_guc_submission.c +++ b/drivers/gpu/drm/i915/i915_guc_submission.c @@ -643,48 +643,6 @@ static void i915_guc_irq_handler(unsigned long data) * path of i915_guc_submit() above. */ -/** - * intel_guc_allocate_vma() - Allocate a GGTT VMA for GuC usage - * @guc: the guc - * @size: size of area to allocate (both virtual space and memory) - * - * This is a wrapper to create an object for use with the GuC. In order to - * use it inside the GuC, an object needs to be pinned lifetime, so we allocate - * both some backing storage and a range inside the Global GTT. We must pin - * it in the GGTT somewhere other than than [0, GUC_WOPCM_TOP) because that - * range is reserved inside GuC. - * - * Return: A i915_vma if successful, otherwise an ERR_PTR. - */ -struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, u32 size) -{ - struct drm_i915_private *dev_priv = guc_to_i915(guc); - struct drm_i915_gem_object *obj; - struct i915_vma *vma; - int ret; - - obj = i915_gem_object_create(dev_priv, size); - if (IS_ERR(obj)) - return ERR_CAST(obj); - - vma = i915_vma_instance(obj, &dev_priv->ggtt.base, NULL); - if (IS_ERR(vma)) - goto err; - - ret = i915_vma_pin(vma, 0, PAGE_SIZE, - PIN_GLOBAL | PIN_OFFSET_BIAS | GUC_WOPCM_TOP); - if (ret) { - vma = ERR_PTR(ret); - goto err; - } - - return vma; - -err: - i915_gem_object_put(obj); - return vma; -} - /* Check that a doorbell register is in the expected state */ static bool doorbell_ok(struct intel_guc *guc, u16 db_id) { @@ -1212,55 +1170,3 @@ void i915_guc_submission_disable(struct drm_i915_private *dev_priv) guc_client_free(guc->execbuf_client); guc->execbuf_client = NULL; } - -/** - * intel_guc_suspend() - notify GuC entering suspend state - * @dev_priv: i915 device private - */ -int intel_guc_suspend(struct drm_i915_private *dev_priv) -{ - struct intel_guc *guc = &dev_priv->guc; - struct i915_gem_context *ctx; - u32 data[3]; - - if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS) - return 0; - - gen9_disable_guc_interrupts(dev_priv); - - ctx = dev_priv->kernel_context; - - data[0] = INTEL_GUC_ACTION_ENTER_S_STATE; - /* any value greater than GUC_POWER_D0 */ - data[1] = GUC_POWER_D1; - /* first page is shared data with GuC */ - data[2] = guc_ggtt_offset(ctx->engine[RCS].state) + LRC_GUCSHR_PN * PAGE_SIZE; - - return intel_guc_send(guc, data, ARRAY_SIZE(data)); -} - -/** - * intel_guc_resume() - notify GuC resuming from suspend state - * @dev_priv: i915 device private - */ -int intel_guc_resume(struct drm_i915_private *dev_priv) -{ - struct intel_guc *guc = &dev_priv->guc; - struct i915_gem_context *ctx; - u32 data[3]; - - if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS) - return 0; - - if (i915_modparams.guc_log_level >= 0) - gen9_enable_guc_interrupts(dev_priv); - - ctx = dev_priv->kernel_context; - - data[0] = INTEL_GUC_ACTION_EXIT_S_STATE; - data[1] = GUC_POWER_D0; - /* first page is shared data with GuC */ - data[2] = guc_ggtt_offset(ctx->engine[RCS].state) + LRC_GUCSHR_PN * PAGE_SIZE; - - return intel_guc_send(guc, data, ARRAY_SIZE(data)); -} diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c new file mode 100644 index 000..f77e50b --- /d
[Intel-gfx] [PATCH v2 3/6] drm/i915/uc: Create intel_uc_init_mmio
From: Sagar Arun Kamble This patch adds new function intel_uc_init_mmio which will initialize MMIO access related variables prior to uc load/init. v2: Removed unnecessary export of guc_send_init_regs. Created intel_uc_init_mmio that currently wraps guc_init_send_regs. (Michal) Cc: Michal Wajdeczko Cc: Michał Winiarski Signed-off-by: Sagar Arun Kamble Signed-off-by: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_drv.c | 2 ++ drivers/gpu/drm/i915/intel_uc.c | 7 +-- drivers/gpu/drm/i915/intel_uc.h | 1 + 3 files changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 5cc2434..74a456f 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1007,6 +1007,8 @@ static int i915_driver_init_mmio(struct drm_i915_private *dev_priv) intel_uncore_init(dev_priv); + intel_uc_init_mmio(dev_priv); + ret = intel_engines_init_mmio(dev_priv); if (ret) goto err_uncore; diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index 201d23e..d921509 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -137,6 +137,11 @@ static void guc_init_send_regs(struct intel_guc *guc) guc->send_regs.fw_domains = fw_domains; } +void intel_uc_init_mmio(struct drm_i915_private *dev_priv) +{ + guc_init_send_regs(&dev_priv->guc); +} + static void guc_capture_load_err_log(struct intel_guc *guc) { if (!guc->log.vma || i915_modparams.guc_log_level < 0) @@ -158,8 +163,6 @@ static int guc_enable_communication(struct intel_guc *guc) { struct drm_i915_private *dev_priv = guc_to_i915(guc); - guc_init_send_regs(guc); - if (HAS_GUC_CT(dev_priv)) return intel_guc_enable_ct(guc); diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h index d111f79..f0d5a3f 100644 --- a/drivers/gpu/drm/i915/intel_uc.h +++ b/drivers/gpu/drm/i915/intel_uc.h @@ -137,6 +137,7 @@ struct intel_huc { /* intel_uc.c */ void intel_uc_sanitize_options(struct drm_i915_private *dev_priv); void intel_uc_init_early(struct drm_i915_private *dev_priv); +void intel_uc_init_mmio(struct drm_i915_private *dev_priv); void intel_uc_init_fw(struct drm_i915_private *dev_priv); void intel_uc_fini_fw(struct drm_i915_private *dev_priv); int intel_uc_init_hw(struct drm_i915_private *dev_priv); -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 5/6] drm/i915/guc: Move Guc early init into own function
We don't want to make aggregate uc functions to be too detailed. This will also make future patch easier. Signed-off-by: Michal Wajdeczko Cc: Sagar Arun Kamble --- drivers/gpu/drm/i915/intel_uc.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index d921509..616e0f1 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -88,10 +88,8 @@ static void gen8_guc_raise_irq(struct intel_guc *guc) I915_WRITE(GUC_SEND_INTERRUPT, GUC_SEND_TRIGGER); } -void intel_uc_init_early(struct drm_i915_private *dev_priv) +static void guc_init_early(struct intel_guc *guc) { - struct intel_guc *guc = &dev_priv->guc; - intel_guc_ct_init_early(&guc->ct); mutex_init(&guc->send_mutex); @@ -99,6 +97,11 @@ void intel_uc_init_early(struct drm_i915_private *dev_priv) guc->notify = gen8_guc_raise_irq; } +void intel_uc_init_early(struct drm_i915_private *dev_priv) +{ + guc_init_early(&dev_priv->guc); +} + void intel_uc_init_fw(struct drm_i915_private *dev_priv) { i915_fetch_uc_fw(dev_priv, &dev_priv->huc.fw); -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/6] drm/i915: Guc code reorg
Other pending series will try to fix current GuC code. Lets move some functions to dedicated files now to make place for these changes and preserve history. v2: move guc files in one step (Joonas) don't rename dev_priv (Joonas) uc_init_mmio (Sagar) Cc: Joonas Lahtinen Cc: Chris Wilson Cc: Sagar Arun Kamble Michal Wajdeczko (5): drm/i915/uc: Drop unnecessary forward declaration drm/i915/uc: Move uC fw helper code into dedicated files drm/i915/huc: Move HuC declarations into dedicated header drm/i915/guc: Move Guc early init into own function drm/i915/guc: Move GuC declarations and functions into dedicated files Sagar Arun Kamble (1): drm/i915/uc: Create intel_uc_init_mmio drivers/gpu/drm/i915/Makefile | 2 + drivers/gpu/drm/i915/i915_drv.c| 2 + drivers/gpu/drm/i915/i915_guc_submission.c | 94 - drivers/gpu/drm/i915/intel_guc.c | 262 + drivers/gpu/drm/i915/intel_guc.h | 178 + drivers/gpu/drm/i915/intel_huc.h | 38 drivers/gpu/drm/i915/intel_uc.c| 301 + drivers/gpu/drm/i915/intel_uc.h| 229 +- drivers/gpu/drm/i915/intel_uc_fw.c | 178 + drivers/gpu/drm/i915/intel_uc_fw.h | 95 + 10 files changed, 766 insertions(+), 613 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_guc.c create mode 100644 drivers/gpu/drm/i915/intel_guc.h create mode 100644 drivers/gpu/drm/i915/intel_huc.h create mode 100644 drivers/gpu/drm/i915/intel_uc_fw.c create mode 100644 drivers/gpu/drm/i915/intel_uc_fw.h -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] dim: sign pull-request tags if the GPG key is configured
On Mon, 02 Oct 2017, Jani Nikula wrote: > On Mon, 11 Sep 2017, Sean Paul wrote: >> On Mon, Sep 11, 2017 at 9:16 AM, Jani Nikula wrote: >>> Add new environment variable $DIM_GPG_KEYID for configuring the GPG key >>> ID of the key to use for signing tags for pull requests. The tags will >>> be signed if the key ID is set, otherwise annotated tags will be used >>> like before. >>> >>> The drm-intel-testing tags are left unsigned, at least for now. >>> >>> Cc: Daniel Vetter >>> Cc: Joonas Lahtinen >>> Cc: Rodrigo Vivi >>> Cc: Sean Paul >>> Signed-off-by: Jani Nikula >>> >>> --- >>> >>> BEWARE OF THE LEOPARD! I didn't actually test this. I will try it when I >>> need to tag something next. >>> >> >> Just comment out git push and test this? > > Finally got around to trying this out, works fine: > https://cgit.freedesktop.org/drm-intel/tag/?id=drm-intel-next-2017-09-29 > > The only snag is that now prep_pull_mail_overview() picks up the > signature from the tag object to the overview too. > > Ack on merging these two out of the way, and fixing that separately (a > tiny bit of sed)? I pushed these two and the sed bit to strip signatures with Daniel's acks. You can now add DIM_GPG_KEYID= to ~/.dimrc to have dim sign the tags. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] [PATCH] mm, oom: Offload OOM notify callback to a kernel thread.
On Mon, Oct 02, 2017 at 01:50:35PM +0200, Michal Hocko wrote: > On Mon 02-10-17 20:33:52, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > [Hmm, I do not see the original patch which this has been a reply to] > > > > urbl.hostedemail.com and b.barracudacentral.org blocked my IP address, > > and the rest are "Recipient address rejected: Greylisted" or > > "Deferred: 451-4.3.0 Multiple destination domains per transaction is > > unsupported.", > > and after all dropped at the servers. Sad... > > > > > > > > On Mon 02-10-17 06:59:12, Michael S. Tsirkin wrote: > > > > On Sun, Oct 01, 2017 at 02:44:34PM +0900, Tetsuo Handa wrote: > > > > > Tetsuo Handa wrote: > > > > > > Michael S. Tsirkin wrote: > > > > > > > On Mon, Sep 11, 2017 at 07:27:19PM +0900, Tetsuo Handa wrote: > > > > > > > > Hello. > > > > > > > > > > > > > > > > I noticed that virtio_balloon is using register_oom_notifier() > > > > > > > > and > > > > > > > > leak_balloon() from virtballoon_oom_notify() might depend on > > > > > > > > __GFP_DIRECT_RECLAIM memory allocation. > > > > > > > > > > > > > > > > In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in > > > > > > > > order to > > > > > > > > serialize against fill_balloon(). But in fill_balloon(), > > > > > > > > alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | > > > > > > > > __GFP_NORETRY) is > > > > > > > > called with vb->balloon_lock mutex held. Since > > > > > > > > GFP_HIGHUSER[_MOVABLE] implies > > > > > > > > __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, this allocation > > > > > > > > attempt might > > > > > > > > depend on somebody else's __GFP_DIRECT_RECLAIM | !__GFP_NORETRY > > > > > > > > memory > > > > > > > > allocation. Such __GFP_DIRECT_RECLAIM | !__GFP_NORETRY > > > > > > > > allocation can reach > > > > > > > > __alloc_pages_may_oom() and hold oom_lock mutex and call > > > > > > > > out_of_memory(). > > > > > > > > And leak_balloon() is called by virtballoon_oom_notify() via > > > > > > > > blocking_notifier_call_chain() callback when vb->balloon_lock > > > > > > > > mutex is already > > > > > > > > held by fill_balloon(). As a result, despite __GFP_NORETRY is > > > > > > > > specified, > > > > > > > > fill_balloon() can indirectly get stuck waiting for > > > > > > > > vb->balloon_lock mutex > > > > > > > > at leak_balloon(). > > > > > > This is really nasty! And I would argue that this is an abuse of the oom > > > notifier interface from the virtio code. OOM notifiers are an ugly hack > > > on its own but all its users have to be really careful to not depend on > > > any allocation request because that is a straight deadlock situation. > > > > Please describe such warning at > > "int register_oom_notifier(struct notifier_block *nb)" definition. > > Yes, we can and should do that. Although I would prefer to simply > document this API as deprecated. Care to send a patch? I am quite busy > with other stuff. > > > > I do not think that making oom notifier API more complex is the way to > > > go. Can we simply change the lock to try_lock? > > > > Using mutex_trylock(&vb->balloon_lock) alone is not sufficient. Inside the > > mutex, __GFP_DIRECT_RECLAIM && !__GFP_NORETRY allocation attempt is used > > which will fail to make progress due to oom_lock already held. Therefore, > > virtballoon_oom_notify() needs to guarantee that all allocation attempts use > > GFP_NOWAIT when called from virtballoon_oom_notify(). > > Ohh, I missed your point and thought the dependency is indirect I do think this is the case. See below. > and some > other call path is allocating while holding the lock. But you seem to be > right and > leak_balloon > tell_host > virtqueue_add_outbuf > virtqueue_add > > can do GFP_KERNEL allocation and this is clearly wrong. Nobody should > try to allocate while we are in the OOM path. Michael, is there any way > to drop this? Yes - in practice it won't ever allocate - that path is never taken with add_outbuf - it is for add_sgs only. IMHO the issue is balloon inflation which needs to allocate memory. It does it under a mutex, and oom handler tries to take the same mutex. > -- > Michal Hocko > SUSE Labs ___ 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 DDI PHY init if it was already on
== Series Details == Series: drm/i915: Fix DDI PHY init if it was already on URL : https://patchwork.freedesktop.org/series/31265/ State : success == Summary == Series 31265v1 drm/i915: Fix DDI PHY init if it was already on https://patchwork.freedesktop.org/api/1.0/series/31265/revisions/1/mbox/ Test chamelium: Subgroup hdmi-crc-fast: pass -> DMESG-WARN (fi-skl-6700k) fdo#103019 Test drv_module_reload: Subgroup basic-reload: dmesg-warn -> PASS (fi-glk-1) fdo#102777 +2 fdo#103019 https://bugs.freedesktop.org/show_bug.cgi?id=103019 fdo#102777 https://bugs.freedesktop.org/show_bug.cgi?id=102777 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:459s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:476s fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 time:393s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:578s fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:289s fi-bxt-dsi total:289 pass:259 dwarn:0 dfail:0 fail:0 skip:30 time:537s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:542s fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34 time:549s fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38 time:528s fi-cfl-s total:289 pass:256 dwarn:1 dfail:0 fail:0 skip:32 time:565s fi-cnl-y total:289 pass:261 dwarn:1 dfail:0 fail:0 skip:27 time:636s fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:442s fi-glk-1 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:592s fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:438s fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:424s fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:470s fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:511s fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:483s fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:508s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:583s fi-kbl-7567u total:289 pass:265 dwarn:4 dfail:0 fail:0 skip:20 time:501s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:592s fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:654s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:482s fi-skl-6700k total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:533s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:529s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:475s fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38 time:585s fi-snb-2600 total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:437s 2f14e319a2fd0125bcb06b00095afa6cab5134bd drm-tip: 2017y-10m-02d-09h-23m-23s UTC integration manifest 2ae7aaa119a9 drm/i915: Fix DDI PHY init if it was already on == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5869/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] [PATCH] mm, oom: Offload OOM notify callback to a kernel thread.
On Mon 02-10-17 17:11:55, Michael S. Tsirkin wrote: > On Mon, Oct 02, 2017 at 01:50:35PM +0200, Michal Hocko wrote: [...] > > and some > > other call path is allocating while holding the lock. But you seem to be > > right and > > leak_balloon > > tell_host > > virtqueue_add_outbuf > > virtqueue_add > > > > can do GFP_KERNEL allocation and this is clearly wrong. Nobody should > > try to allocate while we are in the OOM path. Michael, is there any way > > to drop this? > > Yes - in practice it won't ever allocate - that path is never taken > with add_outbuf - it is for add_sgs only. > > IMHO the issue is balloon inflation which needs to allocate > memory. It does it under a mutex, and oom handler tries to take the > same mutex. try_lock for the oom notifier path should heal the problem then, righ? At least for as a quick fix. -- Michal Hocko SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] [PATCH] mm, oom: Offload OOM notify callback to a kernel thread.
On Mon, Oct 02, 2017 at 04:19:00PM +0200, Michal Hocko wrote: > On Mon 02-10-17 17:11:55, Michael S. Tsirkin wrote: > > On Mon, Oct 02, 2017 at 01:50:35PM +0200, Michal Hocko wrote: > [...] > > > and some > > > other call path is allocating while holding the lock. But you seem to be > > > right and > > > leak_balloon > > > tell_host > > > virtqueue_add_outbuf > > > virtqueue_add > > > > > > can do GFP_KERNEL allocation and this is clearly wrong. Nobody should > > > try to allocate while we are in the OOM path. Michael, is there any way > > > to drop this? > > > > Yes - in practice it won't ever allocate - that path is never taken > > with add_outbuf - it is for add_sgs only. > > > > IMHO the issue is balloon inflation which needs to allocate > > memory. It does it under a mutex, and oom handler tries to take the > > same mutex. > > try_lock for the oom notifier path should heal the problem then, righ? > At least for as a quick fix. IMHO it definitely fixes the deadlock. But it does not fix the bug that balloon isn't sometimes deflated on oom even though the deflate on oom flag is set. > -- > Michal Hocko > SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] [PATCH] mm, oom: Offload OOM notify callback to a kernel thread.
On Mon 02-10-17 17:29:47, Michael S. Tsirkin wrote: > On Mon, Oct 02, 2017 at 04:19:00PM +0200, Michal Hocko wrote: > > On Mon 02-10-17 17:11:55, Michael S. Tsirkin wrote: > > > On Mon, Oct 02, 2017 at 01:50:35PM +0200, Michal Hocko wrote: > > [...] > > > > and some > > > > other call path is allocating while holding the lock. But you seem to be > > > > right and > > > > leak_balloon > > > > tell_host > > > > virtqueue_add_outbuf > > > > virtqueue_add > > > > > > > > can do GFP_KERNEL allocation and this is clearly wrong. Nobody should > > > > try to allocate while we are in the OOM path. Michael, is there any way > > > > to drop this? > > > > > > Yes - in practice it won't ever allocate - that path is never taken > > > with add_outbuf - it is for add_sgs only. > > > > > > IMHO the issue is balloon inflation which needs to allocate > > > memory. It does it under a mutex, and oom handler tries to take the > > > same mutex. > > > > try_lock for the oom notifier path should heal the problem then, righ? > > At least for as a quick fix. > > IMHO it definitely fixes the deadlock. But it does not fix the bug > that balloon isn't sometimes deflated on oom even though the deflate on > oom flag is set. Yes, that would require a more sophisticated fix. And I would argue that would require to drop oom handler and move deflate logic to a shrinker to better scale with the memory pressure rather than act on the very last moment. -- Michal Hocko SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Guc code reorg
== Series Details == Series: drm/i915: Guc code reorg URL : https://patchwork.freedesktop.org/series/31266/ State : failure == Summary == Series 31266v1 drm/i915: Guc code reorg https://patchwork.freedesktop.org/api/1.0/series/31266/revisions/1/mbox/ Test gem_ctx_switch: Subgroup basic-default: pass -> INCOMPLETE (fi-cnl-y) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> FAIL (fi-cfl-s) fdo#102673 fdo#102673 https://bugs.freedesktop.org/show_bug.cgi?id=102673 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:457s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:475s fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 time:392s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:564s fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:287s fi-bxt-dsi total:289 pass:259 dwarn:0 dfail:0 fail:0 skip:30 time:528s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:529s fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34 time:539s fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38 time:535s fi-cfl-s total:289 pass:255 dwarn:1 dfail:0 fail:1 skip:32 time:547s fi-cnl-y total:31 pass:21 dwarn:0 dfail:0 fail:0 skip:9 fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:440s fi-glk-1 total:289 pass:257 dwarn:3 dfail:0 fail:0 skip:29 time:592s fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:442s fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:422s fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:462s fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:500s fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:488s fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:506s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:578s fi-kbl-7567u total:289 pass:265 dwarn:4 dfail:0 fail:0 skip:20 time:491s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:590s fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:658s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:480s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:525s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:523s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:473s fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38 time:582s fi-snb-2600 total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:442s 2f14e319a2fd0125bcb06b00095afa6cab5134bd drm-tip: 2017y-10m-02d-09h-23m-23s UTC integration manifest 5865a7ce87af drm/i915/guc: Move GuC declarations and functions into dedicated files 324ea799d3a0 drm/i915/guc: Move Guc early init into own function b4dba4d4e843 drm/i915/huc: Move HuC declarations into dedicated header aa0e401af78b drm/i915/uc: Create intel_uc_init_mmio 1569c70765ba drm/i915/uc: Move uC fw helper code into dedicated files 1d29ef25f7af drm/i915/uc: Drop unnecessary forward declaration == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5870/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix DDI PHY init if it was already on
== Series Details == Series: drm/i915: Fix DDI PHY init if it was already on URL : https://patchwork.freedesktop.org/series/31265/ State : success == Summary == Test perf: Subgroup blocking: fail -> PASS (shard-hsw) fdo#102252 +1 Test kms_flip: Subgroup plain-flip-fb-recreate-interruptible: pass -> FAIL (shard-hsw) fdo#100368 Test prime_self_import: Subgroup reimport-vs-gem_close-race: fail -> PASS (shard-hsw) fdo#102655 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102655 https://bugs.freedesktop.org/show_bug.cgi?id=102655 shard-hswtotal:2429 pass:1332 dwarn:5 dfail:0 fail:9 skip:1083 time:10107s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5869/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/18] use ARRAY_SIZE macro
Em Sun, 1 Oct 2017 20:52:20 -0400 Jérémy Lefaure escreveu: > Anyway, I can tell to each maintainer that they can apply the patches > they're concerned about and next time I may send individual patches. In the case of media, we'll handle it as if they were individual ones. Thanks, Mauro ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/18] use ARRAY_SIZE macro
Thanks for the patch! :) 2017-10-01 22:30 GMT+03:00 Jérémy Lefaure : > Hi everyone, > Using ARRAY_SIZE improves the code readability. I used coccinelle (I > made a change to the array_size.cocci file [1]) to find several places > where ARRAY_SIZE could be used instead of other macros or sizeof > division. > > I tried to divide the changes into a patch per subsystem (excepted for > staging). If one of the patch should be split into several patches, let > me know. > > In order to reduce the size of the To: and Cc: lines, each patch of the > series is sent only to the maintainers and lists concerned by the patch. > This cover letter is sent to every list concerned by this series. > > This series is based on linux-next next-20170929. Each patch has been > tested by building the relevant files with W=1. > > This series contains the following patches: > [PATCH 01/18] sound: use ARRAY_SIZE > [PATCH 02/18] tracing/filter: use ARRAY_SIZE > [PATCH 03/18] media: use ARRAY_SIZE > [PATCH 04/18] IB/mlx5: Use ARRAY_SIZE > [PATCH 05/18] net: use ARRAY_SIZE > [PATCH 06/18] drm: use ARRAY_SIZE > [PATCH 07/18] scsi: bfa: use ARRAY_SIZE > [PATCH 08/18] ecryptfs: use ARRAY_SIZE > [PATCH 09/18] nfsd: use ARRAY_SIZE > [PATCH 10/18] orangefs: use ARRAY_SIZE > [PATCH 11/18] dm space map metadata: use ARRAY_SIZE > [PATCH 12/18] x86: use ARRAY_SIZE > [PATCH 13/18] tpm: use ARRAY_SIZE > [PATCH 14/18] ipmi: use ARRAY_SIZE > [PATCH 15/18] acpi: use ARRAY_SIZE > [PATCH 16/18] media: staging: atomisp: use ARRAY_SIZE > [PATCH 17/18] staging: rtl8723bs: use ARRAY_SIZE > [PATCH 18/18] staging: rtlwifi: use ARRAY_SIZE > > > [1]: https://lkml.org/lkml/2017/9/13/689 > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [maintainer-tools PATCH] dim: Add helpers to move fixes branches up.
One of main doubts I had when starting maintaining the fixes branches was when to move them, but also how, to-where, and when avoid moving and stay on the current one. So this scripts aims to avoid doubts and mistakes on fixes maintainance besides making all bases more clear and standardized. Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Daniel Vetter Signed-off-by: Rodrigo Vivi --- dim | 50 ++ dim.rst | 13 + 2 files changed, 63 insertions(+) diff --git a/dim b/dim index fc16d114632f..8643bafcd2a5 100755 --- a/dim +++ b/dim @@ -918,6 +918,56 @@ function dim_apply_pull return $rv } +function rebase_branch +{ + local branch newbase + + branch=${1:?$usage} + shift + newbase=${1:?$usage} + shift + + assert_branch $branch + assert_repo_clean + + $DRY git rebase $newbase "$@" +} + +dim_alias_rf=rebase-fixes +function dim_rebase_fixes +{ + local tag commit + + commit=$(git rev-list --tags --max-count=1 --remotes=$DIM_DRM_INTEL) + tag=$(git describe --tags $commit) + + if [[ $tag != *"-rc"* ]]; then + echoerr "Tag $tag is not an -rc one." + return 1; + fi + + rebase_branch drm-intel-fixes $tag "$@" + + if [ $DRY ]; then + return 0; + fi + + if [ $(git rev-parse HEAD) != $commit ]; then + git reset --hard $DIM_DRM_INTEL_REMOTE/drm-intel-fixes + echoerr "ERROR: fixes didn't fully propagated yet, aborting" + fi +} + +dim_alias_rnf=rebase-next-fixes +function dim_rebase_next_fixes +{ + local dim_drm_upstream_remote + + dim_drm_upstream_remote=$(url_to_remote $drm_upstream_git) + + rebase_branch drm-intel-next-fixes $dim_drm_upstream_remote/drm-next "$@" +} + function dim_backmerge { local branch upstream patch_file diff --git a/dim.rst b/dim.rst index 65e652e8bc75..a53ef8aa67e2 100644 --- a/dim.rst +++ b/dim.rst @@ -376,6 +376,19 @@ apply-pull *branch* --- Reads a pull request mail from stdin and merges it into the given *branch*. +rebase-fixes + +Rebases drm-intel-fixes to latest Linus tag. +This command is to be used following a Linus "-rc" tag, in order to move +drm-intel-fixes branch up. +It fails if tag is not an -rc tag. +It fails if your current fixes didn't fully propagated yet. + +rebase-fixes-next +- +Rebases drm-intel-next queued into drm-next. +This command is to be used after drm-next is closed for new features. + backmerge *branch* *upstream* - -- 2.13.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/glk, cnl: Implement WaDisableScalarClockGating
On Mon, Oct 02, 2017 at 07:55:57AM +, Imre Deak wrote: > On GLK and CNL enabling a pipe with its pipe scaler enabled will result > in a FIFO underrun. This happens only once after driver loading or > system/runtime resume, more specifically after power well 1 gets > enabled; subsequent modesets seem to be free of underruns. The BSpec > workaround for this is to disable the pipe scaler clock gating for the > duration of modeset. Based on my tests disabling clock gating must be > done before enabling pipe scaling and we can re-enable it after the pipe > is enabled and one vblank has passed. > > For consistency I also checked if plane scaling would cause the same > problem, but that doesn't seem to trigger this problem. > > The patch is based on an earlier version from Ander. > > v2 (Rodrigo): > - Set also CLKGATE_DIS_PSL bits 8 and 9. > - Add also the BSpec workaround ID. Thanks for this and for the explanation around the places where we need to protect. They make sense. > > Cc: Ander Conselvan de Oliveira > Cc: Rodrigo Vivi > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100302 > Signed-off-by: Imre Deak Reviewed-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/i915_reg.h | 10 ++ > drivers/gpu/drm/i915/intel_display.c | 26 ++ > 2 files changed, 36 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > index ee0d4f14ac98..39ad9327e2a0 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -3819,6 +3819,16 @@ enum { > #define PWM2_GATING_DIS(1 << 14) > #define PWM1_GATING_DIS(1 << 13) > > +#define _CLKGATE_DIS_PSL_A 0x46520 > +#define _CLKGATE_DIS_PSL_B 0x46524 > +#define _CLKGATE_DIS_PSL_C 0x46528 > +#define DPF_GATING_DIS (1 << 10) > +#define DPF_RAM_GATING_DIS (1 << 9) > +#define DPFR_GATING_DIS(1 << 8) > + > +#define CLKGATE_DIS_PSL(pipe) \ > + _MMIO_PIPE(pipe, _CLKGATE_DIS_PSL_A, _CLKGATE_DIS_PSL_B) > + > /* > * GEN10 clock gating regs > */ > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index c4b224a3a0ee..b7a6ddc6a66d 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -5459,6 +5459,20 @@ static bool hsw_crtc_supports_ips(struct intel_crtc > *crtc) > return HAS_IPS(to_i915(crtc->base.dev)) && crtc->pipe == PIPE_A; > } > > +static void glk_pipe_scaler_clock_gating_wa(struct drm_i915_private > *dev_priv, > + enum pipe pipe, bool apply) > +{ > + u32 val = I915_READ(CLKGATE_DIS_PSL(pipe)); > + u32 mask = DPF_GATING_DIS | DPF_RAM_GATING_DIS | DPFR_GATING_DIS; > + > + if (apply) > + val |= mask; > + else > + val &= ~mask; > + > + I915_WRITE(CLKGATE_DIS_PSL(pipe), val); > +} > + > static void haswell_crtc_enable(struct intel_crtc_state *pipe_config, > struct drm_atomic_state *old_state) > { > @@ -5469,6 +5483,7 @@ static void haswell_crtc_enable(struct intel_crtc_state > *pipe_config, > enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder; > struct intel_atomic_state *old_intel_state = > to_intel_atomic_state(old_state); > + bool psl_clkgate_wa; > > if (WARN_ON(intel_crtc->active)) > return; > @@ -5522,6 +5537,12 @@ static void haswell_crtc_enable(struct > intel_crtc_state *pipe_config, > if (!transcoder_is_dsi(cpu_transcoder)) > intel_ddi_enable_pipe_clock(pipe_config); > > + /* Display WA #1180: WaDisableScalarClockGating: glk, cnl */ > + psl_clkgate_wa = (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) && > + intel_crtc->config->pch_pfit.enabled; > + if (psl_clkgate_wa) > + glk_pipe_scaler_clock_gating_wa(dev_priv, pipe, true); > + > if (INTEL_GEN(dev_priv) >= 9) > skylake_pfit_enable(intel_crtc); > else > @@ -,6 +5576,11 @@ static void haswell_crtc_enable(struct > intel_crtc_state *pipe_config, > > intel_encoders_enable(crtc, pipe_config, old_state); > > + if (psl_clkgate_wa) { > + intel_wait_for_vblank(dev_priv, pipe); > + glk_pipe_scaler_clock_gating_wa(dev_priv, pipe, false); > + } > + > if (intel_crtc->config->has_pch_encoder) { > intel_wait_for_vblank(dev_priv, pipe); > intel_wait_for_vblank(dev_priv, pipe); > -- > 2.13.2 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/18] use ARRAY_SIZE macro
On Sun, Oct 01, 2017 at 03:30:38PM -0400, Jérémy Lefaure wrote: > Hi everyone, > Using ARRAY_SIZE improves the code readability. I used coccinelle (I > made a change to the array_size.cocci file [1]) to find several places > where ARRAY_SIZE could be used instead of other macros or sizeof > division. > > I tried to divide the changes into a patch per subsystem (excepted for > staging). If one of the patch should be split into several patches, let > me know. > > In order to reduce the size of the To: and Cc: lines, each patch of the > series is sent only to the maintainers and lists concerned by the patch. > This cover letter is sent to every list concerned by this series. Why don't you just send individual patches for each subsystem? I'm not a maintainer but I don't see how any one person is going to be able to apply this whole series, it is making it hard for maintainers if they have to pick patches out from among the series (if indeed any will bother doing that). I get that this will be more work for you but AFAIK we are optimizing for maintainers. Good luck, Tobin. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/18] use ARRAY_SIZE macro
On Mon, Oct 02, 2017 at 07:35:54AM +0200, Greg KH wrote: > On Sun, Oct 01, 2017 at 08:52:20PM -0400, Jérémy Lefaure wrote: > > On Mon, 2 Oct 2017 09:01:31 +1100 > > "Tobin C. Harding" wrote: > > > > > > In order to reduce the size of the To: and Cc: lines, each patch of the > > > > series is sent only to the maintainers and lists concerned by the patch. > > > > This cover letter is sent to every list concerned by this series. > > > > > > Why don't you just send individual patches for each subsystem? I'm not a > > > maintainer but I don't see > > > how any one person is going to be able to apply this whole series, it is > > > making it hard for > > > maintainers if they have to pick patches out from among the series (if > > > indeed any will bother > > > doing that). > > Yeah, maybe it would have been better to send individual patches. > > > > From my point of view it's a series because the patches are related (I > > did a git format-patch from my local branch). But for the maintainers > > point of view, they are individual patches. > > And the maintainers view is what matters here, if you wish to get your > patches reviewed and accepted... Mainly I'd just like to know which you're asking for. Do you want me to apply this, or to ACK it so someone else can? If it's sent as a series I tend to assume the latter. But in this case I'm assuming it's the former, so I'll pick up the nfsd one --b. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC] [PATCH] mm, oom: Offload OOM notify callback to a kernel thread.
Tetsuo Handa wrote: > Michael S. Tsirkin wrote: > > On Mon, Sep 11, 2017 at 07:27:19PM +0900, Tetsuo Handa wrote: > > > Hello. > > > > > > I noticed that virtio_balloon is using register_oom_notifier() and > > > leak_balloon() from virtballoon_oom_notify() might depend on > > > __GFP_DIRECT_RECLAIM memory allocation. > > > > > > In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to > > > serialize against fill_balloon(). But in fill_balloon(), > > > alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY) is > > > called with vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] > > > implies > > > __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, this allocation attempt might > > > depend on somebody else's __GFP_DIRECT_RECLAIM | !__GFP_NORETRY memory > > > allocation. Such __GFP_DIRECT_RECLAIM | !__GFP_NORETRY allocation can > > > reach > > > __alloc_pages_may_oom() and hold oom_lock mutex and call out_of_memory(). > > > And leak_balloon() is called by virtballoon_oom_notify() via > > > blocking_notifier_call_chain() callback when vb->balloon_lock mutex is > > > already > > > held by fill_balloon(). As a result, despite __GFP_NORETRY is specified, > > > fill_balloon() can indirectly get stuck waiting for vb->balloon_lock mutex > > > at leak_balloon(). > > > > That would be tricky to fix. I guess we'll need to drop the lock > > while allocating memory - not an easy fix. > > > > > Also, in leak_balloon(), virtqueue_add_outbuf(GFP_KERNEL) is called via > > > tell_host(). Reaching __alloc_pages_may_oom() from this > > > virtqueue_add_outbuf() > > > request from leak_balloon() from virtballoon_oom_notify() from > > > blocking_notifier_call_chain() from out_of_memory() leads to OOM lockup > > > because oom_lock mutex is already held before calling out_of_memory(). > > > > I guess we should just do > > > > GFP_KERNEL & ~__GFP_DIRECT_RECLAIM there then? > > Yes, but GFP_KERNEL & ~__GFP_DIRECT_RECLAIM will effectively be GFP_NOWAIT, > for > __GFP_IO and __GFP_FS won't make sense without __GFP_DIRECT_RECLAIM. It might > significantly increases possibility of memory allocation failure. > > > > > > > > > > > OOM notifier callback should not (directly or indirectly) depend on > > > __GFP_DIRECT_RECLAIM memory allocation attempt. Can you fix this > > > dependency? > > > > Another idea would be to use a kernel thread (or workqueue) so that > virtballoon_oom_notify() can wait with timeout. > > We could offload entire blocking_notifier_call_chain(&oom_notify_list, 0, > &freed) > call to a kernel thread (or workqueue) with timeout if MM folks agree. > Below is a patch which offloads blocking_notifier_call_chain() call. What do you think? [RFC] [PATCH] mm,oom: Offload OOM notify callback to a kernel thread. Since oom_notify_list is traversed via blocking_notifier_call_chain(), it is legal to sleep inside OOM notifier callback function. However, since oom_notify_list is traversed with oom_lock held, __GFP_DIRECT_RECLAIM && !__GFP_NORETRY memory allocation attempt cannot fail when traversing oom_notify_list entries. Therefore, OOM notifier callback function should not (directly or indirectly) depend on __GFP_DIRECT_RECLAIM && !__GFP_NORETRY memory allocation attempt. Currently there are 5 register_oom_notifier() users in the mainline kernel. arch/powerpc/platforms/pseries/cmm.c arch/s390/mm/cmm.c drivers/gpu/drm/i915/i915_gem_shrinker.c drivers/virtio/virtio_balloon.c kernel/rcu/tree_plugin.h Among these users, at least virtio_balloon.c has possibility of OOM lockup because it is using mutex which can depend on GFP_KERNEL memory allocations. (Both cmm.c seem to be safe as they use spinlocks. I'm not sure about tree_plugin.h and i915_gem_shrinker.c . Please check.) But converting such allocations to use GFP_NOWAIT is not only prone to allocation failures under memory pressure but also difficult to audit whether all locations are converted to use GFP_NOWAIT. Therefore, this patch offloads blocking_notifier_call_chain() call to a dedicated kernel thread and wait for completion with timeout of 5 seconds so that we can completely forget about possibility of OOM lockup due to OOM notifier callback function. (5 seconds is chosen from my guess that blocking_notifier_call_chain() should not take long, for we are using mutex_trylock(&oom_lock) at __alloc_pages_may_oom() based on an assumption that out_of_memory() should reclaim memory shortly.) The kernel thread is created upon first register_oom_notifier() call. Thus, those environments which do not use register_oom_notifier() will not waste resource for the dedicated kernel thread. Signed-off-by: Tetsuo Handa --- mm/oom_kill.c | 40 1 file changed, 36 insertions(+), 4 deletions(-) diff --git a/mm/oom_kill.c b/mm/oom_kill.c index dee0f75..d9744f7 100644 --- a/mm/oom_kill.c +++ b/mm/oom_kill.c @@ -981,9 +981,37 @@ static void chec
[Intel-gfx] [PATCH v2] drm/i915: Replace *_reference/unreference() or *_ref/unref with _get/put()
Replace instances of drm_framebuffer_reference/unreference() with *_get/put() suffixes and drm_dev_unref with *_put() suffix because get/put is shorter and consistent with the kernel use of *_get/put suffixes. Done with following coccinelle semantic patch @@ expression ex; @@ ( -drm_framebuffer_unreference(ex); +drm_framebuffer_put(ex); | -drm_dev_unref(ex); +drm_dev_put(ex); | -drm_framebuffer_reference(ex); +drm_framebuffer_get(ex); ) Signed-off-by: Harsha Sharma --- Changes in v2: -Added coccinelle patch in log message -cc to all driver-specific mailing lists drivers/gpu/drm/i915/i915_pci.c| 2 +- drivers/gpu/drm/i915/intel_display.c | 10 +- drivers/gpu/drm/i915/intel_fbdev.c | 4 ++-- drivers/gpu/drm/i915/selftests/i915_gem_dmabuf.c | 2 +- drivers/gpu/drm/i915/selftests/i915_gem_evict.c| 2 +- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +- drivers/gpu/drm/i915/selftests/i915_gem_object.c | 2 +- drivers/gpu/drm/i915/selftests/i915_gem_request.c | 2 +- drivers/gpu/drm/i915/selftests/i915_vma.c | 2 +- drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c | 2 +- 10 files changed, 15 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c index 09d97e0..2f106cc 100644 --- a/drivers/gpu/drm/i915/i915_pci.c +++ b/drivers/gpu/drm/i915/i915_pci.c @@ -510,7 +510,7 @@ static void i915_pci_remove(struct pci_dev *pdev) struct drm_device *dev = pci_get_drvdata(pdev); i915_driver_unload(dev); - drm_dev_unref(dev); + drm_dev_put(dev); } static int i915_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index f172755..92f8304 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -2856,7 +2856,7 @@ static int skl_format_to_fourcc(int format, bool rgb_order, bool alpha) if (intel_plane_ggtt_offset(state) == plane_config->base) { fb = c->primary->fb; - drm_framebuffer_reference(fb); + drm_framebuffer_get(fb); goto valid_fb; } } @@ -2887,7 +2887,7 @@ static int skl_format_to_fourcc(int format, bool rgb_order, bool alpha) intel_crtc->pipe, PTR_ERR(intel_state->vma)); intel_state->vma = NULL; - drm_framebuffer_unreference(fb); + drm_framebuffer_put(fb); return; } @@ -2908,7 +2908,7 @@ static int skl_format_to_fourcc(int format, bool rgb_order, bool alpha) if (i915_gem_object_is_tiled(obj)) dev_priv->preserve_bios_swizzle = true; - drm_framebuffer_reference(fb); + drm_framebuffer_get(fb); primary->fb = primary->state->fb = fb; primary->crtc = primary->state->crtc = &intel_crtc->base; @@ -9847,7 +9847,7 @@ struct drm_framebuffer * if (obj->base.size < mode->vdisplay * fb->pitches[0]) return NULL; - drm_framebuffer_reference(fb); + drm_framebuffer_get(fb); return fb; #else return NULL; @@ -10028,7 +10028,7 @@ int intel_get_load_detect_pipe(struct drm_connector *connector, if (ret) goto fail; - drm_framebuffer_unreference(fb); + drm_framebuffer_put(fb); ret = drm_atomic_set_mode_for_crtc(&crtc_state->base, mode); if (ret) diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c index 262e75c..1ff7149 100644 --- a/drivers/gpu/drm/i915/intel_fbdev.c +++ b/drivers/gpu/drm/i915/intel_fbdev.c @@ -189,7 +189,7 @@ static int intelfb_create(struct drm_fb_helper *helper, " releasing it\n", intel_fb->base.width, intel_fb->base.height, sizes->fb_width, sizes->fb_height); - drm_framebuffer_unreference(&intel_fb->base); + drm_framebuffer_put(&intel_fb->base); intel_fb = ifbdev->fb = NULL; } if (!intel_fb || WARN_ON(!intel_fb->obj)) { @@ -624,7 +624,7 @@ static bool intel_fbdev_init_bios(struct drm_device *dev, ifbdev->preferred_bpp = fb->base.format->cpp[0] * 8; ifbdev->fb = fb; - drm_framebuffer_reference(&ifbdev->fb->base); + drm_framebuffer_put(&ifbdev->fb->base); /* Final pass to check if any active pipes don't have fbs */ for_each_crtc(dev, crtc) { diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/selftests/i915_gem_dmabuf.c index 89dc25a..a7055b1 100644 --- a/drivers/gpu/drm/i915/selftests/i915_gem_dmabuf.c +++ b/drivers/gpu/drm/i915/selftests/i915_gem_dmabuf.c @@ -389,7 +389,7 @@ int i915_gem_dmabuf_mock_selftests(void)
Re: [Intel-gfx] [RFC] [PATCH] mm, oom: Offload OOM notify callback to a kernel thread.
Michal Hocko wrote: > [Hmm, I do not see the original patch which this has been a reply to] urbl.hostedemail.com and b.barracudacentral.org blocked my IP address, and the rest are "Recipient address rejected: Greylisted" or "Deferred: 451-4.3.0 Multiple destination domains per transaction is unsupported.", and after all dropped at the servers. Sad... > > On Mon 02-10-17 06:59:12, Michael S. Tsirkin wrote: > > On Sun, Oct 01, 2017 at 02:44:34PM +0900, Tetsuo Handa wrote: > > > Tetsuo Handa wrote: > > > > Michael S. Tsirkin wrote: > > > > > On Mon, Sep 11, 2017 at 07:27:19PM +0900, Tetsuo Handa wrote: > > > > > > Hello. > > > > > > > > > > > > I noticed that virtio_balloon is using register_oom_notifier() and > > > > > > leak_balloon() from virtballoon_oom_notify() might depend on > > > > > > __GFP_DIRECT_RECLAIM memory allocation. > > > > > > > > > > > > In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order > > > > > > to > > > > > > serialize against fill_balloon(). But in fill_balloon(), > > > > > > alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | > > > > > > __GFP_NORETRY) is > > > > > > called with vb->balloon_lock mutex held. Since > > > > > > GFP_HIGHUSER[_MOVABLE] implies > > > > > > __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, this allocation attempt > > > > > > might > > > > > > depend on somebody else's __GFP_DIRECT_RECLAIM | !__GFP_NORETRY > > > > > > memory > > > > > > allocation. Such __GFP_DIRECT_RECLAIM | !__GFP_NORETRY allocation > > > > > > can reach > > > > > > __alloc_pages_may_oom() and hold oom_lock mutex and call > > > > > > out_of_memory(). > > > > > > And leak_balloon() is called by virtballoon_oom_notify() via > > > > > > blocking_notifier_call_chain() callback when vb->balloon_lock mutex > > > > > > is already > > > > > > held by fill_balloon(). As a result, despite __GFP_NORETRY is > > > > > > specified, > > > > > > fill_balloon() can indirectly get stuck waiting for > > > > > > vb->balloon_lock mutex > > > > > > at leak_balloon(). > > This is really nasty! And I would argue that this is an abuse of the oom > notifier interface from the virtio code. OOM notifiers are an ugly hack > on its own but all its users have to be really careful to not depend on > any allocation request because that is a straight deadlock situation. Please describe such warning at "int register_oom_notifier(struct notifier_block *nb)" definition. > > I do not think that making oom notifier API more complex is the way to > go. Can we simply change the lock to try_lock? Using mutex_trylock(&vb->balloon_lock) alone is not sufficient. Inside the mutex, __GFP_DIRECT_RECLAIM && !__GFP_NORETRY allocation attempt is used which will fail to make progress due to oom_lock already held. Therefore, virtballoon_oom_notify() needs to guarantee that all allocation attempts use GFP_NOWAIT when called from virtballoon_oom_notify(). virtballoon_oom_notify() can guarantee GFP_NOIO using memalloc_noio_{save,restore}() (which is currently missing because blocking_notifier_call_chain() might be called by GFP_NOIO allocation request (e.g. disk_events_workfn)). But there is no memalloc_nodirectreclaim_{save,restore}() for guaranteeing GFP_NOWAIT is used. virtballoon_oom_notify() will need to use some flag and switch GFP_NOWAIT and GFP_KERNEL based on that flag. I worry that such approach is prone to oversight. >If the lock is held we > would simply fall back to the normal OOM handling. As a follow up it > would be great if virtio could use some other form of aging e.g. > shrinker. > -- > 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] drm/i915: Fix DDI PHY init if it was already on
On Mon, Oct 02, 2017 at 01:53:07PM +, Imre Deak wrote: > The common lane power down flag of a DPIO PHY has a funky semantic: > after the initial enabling of the PHY (so from a disabled state) this > flag will be clear. It will be set only after the PHY will be used for > the first time (for instance due to enabling the corresponding pipe) and > then become unused (due to disabling the pipe). During the initial PHY > enablement we don't know which of the above phases we are in, so move > the check for the flag where this is known, the HW readout code. This is > where the rest of lane power down status checks are done anyway. This makes sense. I just wonder why at first place we were doing that extra check to see if that was disabled. I couldn't find anything on spec to justify the previous use of it and new one is consistent with bit 9 that is very similar, so: Reviewed-by: Rodrigo Vivi > > This fixes at least a problem on GLK where after module reloading, the > common lane power down flag of PHY1 is set, but the PHY is actually > powered-on and properly set up. The GRC readout code for other PHYs will > hence think that PHY1 is not powered initially and disable it after the > GRC readout. This will cause the AUX power well related to PHY1 to get > disabled in a stuck state, timing out when we try to enable it later. > > Cc: Ville Syrjala > Fixes: e93da0a0137b ("drm/i915/bxt: Sanitiy check the PHY lane power down > status") > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102777 > Signed-off-by: Imre Deak > --- > drivers/gpu/drm/i915/intel_ddi.c | 3 ++- > drivers/gpu/drm/i915/intel_dpio_phy.c | 20 > 2 files changed, 2 insertions(+), 21 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c > b/drivers/gpu/drm/i915/intel_ddi.c > index 93cbbcbbc193..65f4b6786791 100644 > --- a/drivers/gpu/drm/i915/intel_ddi.c > +++ b/drivers/gpu/drm/i915/intel_ddi.c > @@ -1713,7 +1713,8 @@ bool intel_ddi_get_hw_state(struct intel_encoder > *encoder, > out: > if (ret && IS_GEN9_LP(dev_priv)) { > tmp = I915_READ(BXT_PHY_CTL(port)); > - if ((tmp & (BXT_PHY_LANE_POWERDOWN_ACK | > + if ((tmp & (BXT_PHY_CMNLANE_POWERDOWN_ACK | > + BXT_PHY_LANE_POWERDOWN_ACK | > BXT_PHY_LANE_ENABLED)) != BXT_PHY_LANE_ENABLED) > DRM_ERROR("Port %c enabled but PHY powered down? " > "(PHY_CTL %08x)\n", port_name(port), tmp); > diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c > b/drivers/gpu/drm/i915/intel_dpio_phy.c > index 09b670929786..de38d014ed39 100644 > --- a/drivers/gpu/drm/i915/intel_dpio_phy.c > +++ b/drivers/gpu/drm/i915/intel_dpio_phy.c > @@ -208,12 +208,6 @@ static const struct bxt_ddi_phy_info glk_ddi_phy_info[] > = { > }, > }; > > -static u32 bxt_phy_port_mask(const struct bxt_ddi_phy_info *phy_info) > -{ > - return (phy_info->dual_channel * BIT(phy_info->channel[DPIO_CH1].port)) > | > - BIT(phy_info->channel[DPIO_CH0].port); > -} > - > static const struct bxt_ddi_phy_info * > bxt_get_phy_list(struct drm_i915_private *dev_priv, int *count) > { > @@ -313,7 +307,6 @@ bool bxt_ddi_phy_is_enabled(struct drm_i915_private > *dev_priv, > enum dpio_phy phy) > { > const struct bxt_ddi_phy_info *phy_info; > - enum port port; > > phy_info = bxt_get_phy_info(dev_priv, phy); > > @@ -335,19 +328,6 @@ bool bxt_ddi_phy_is_enabled(struct drm_i915_private > *dev_priv, > return false; > } > > - for_each_port_masked(port, bxt_phy_port_mask(phy_info)) { > - u32 tmp = I915_READ(BXT_PHY_CTL(port)); > - > - if (tmp & BXT_PHY_CMNLANE_POWERDOWN_ACK) { > - DRM_DEBUG_DRIVER("DDI PHY %d powered, but common lane " > - "for port %c powered down " > - "(PHY_CTL %08x)\n", > - phy, port_name(port), tmp); > - > - return false; > - } > - } > - > return true; > } > > -- > 2.13.2 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Replace *_reference/unreference() or *_ref/unref with _get/put()
== Series Details == Series: drm/i915: Replace *_reference/unreference() or *_ref/unref with _get/put() URL : https://patchwork.freedesktop.org/series/31283/ State : failure == Summary == Series 31283v1 drm/i915: Replace *_reference/unreference() or *_ref/unref with _get/put() https://patchwork.freedesktop.org/api/1.0/series/31283/revisions/1/mbox/ Test gem_exec_suspend: Subgroup basic-s3: pass -> INCOMPLETE (fi-ivb-3770) pass -> DMESG-WARN (fi-byt-j1900) pass -> INCOMPLETE (fi-hsw-4770) pass -> INCOMPLETE (fi-hsw-4770r) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: pass -> INCOMPLETE (fi-byt-j1900) fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:458s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:476s fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 time:396s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:576s fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:287s fi-bxt-dsi total:289 pass:259 dwarn:0 dfail:0 fail:0 skip:30 time:531s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:536s fi-byt-j1900 total:245 pass:214 dwarn:1 dfail:0 fail:0 skip:29 fi-cfl-s total:289 pass:256 dwarn:1 dfail:0 fail:0 skip:32 time:563s fi-cnl-y total:289 pass:261 dwarn:1 dfail:0 fail:0 skip:27 time:633s fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:431s fi-glk-1 total:289 pass:257 dwarn:3 dfail:0 fail:0 skip:29 time:588s fi-hsw-4770 total:118 pass:100 dwarn:0 dfail:0 fail:0 skip:17 fi-hsw-4770r total:118 pass:100 dwarn:0 dfail:0 fail:0 skip:17 fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:474s fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:507s fi-ivb-3770 total:118 pass:96 dwarn:0 dfail:0 fail:0 skip:21 fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:505s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:577s fi-kbl-7567u total:289 pass:265 dwarn:4 dfail:0 fail:0 skip:20 time:490s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:595s fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:659s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:478s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:534s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:578s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:470s fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38 time:591s fi-snb-2600 total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:434s fi-byt-n2820 failed to connect after reboot 2f14e319a2fd0125bcb06b00095afa6cab5134bd drm-tip: 2017y-10m-02d-09h-23m-23s UTC integration manifest 513daac4b852 drm/i915: Replace *_reference/unreference() or *_ref/unref with _get/put() == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5871/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add has_psr-flag to gen9lp
On Fri, Sep 29, 2017 at 12:32:10PM +, David Weinehall wrote: > On Thu, Sep 28, 2017 at 08:19:29PM -, Patchwork wrote: > > == Series Details == > > > > Series: drm/i915: Add has_psr-flag to gen9lp > > URL : https://patchwork.freedesktop.org/series/28488/ > > State : success > > > > == Summary == > > > > Series 28488v1 drm/i915: Add has_psr-flag to gen9lp > > https://patchwork.freedesktop.org/api/1.0/series/28488/revisions/1/mbox/ > > > > Test kms_psr_sink_crc: > > Subgroup psr_basic: > > skip -> PASS (fi-glk-1) > > This seems relevant, and promising. merged to dinq. Thanks for the patch. > > > Kind regards, David > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/cnl: Do not add an extra page for precaution in the Gen10 LRC size
BSpec indicates exactly 16750 DWORDs (17 pages), plus one page for PPHWSP. Suggested-by: Joonas Lahtinen Fixes: 7fd0b1a ("drm/i915/cnl: Add Gen10 LRC size") Signed-off-by: Oscar Mateo Cc: Rodrigo Vivi Cc: Daniele Ceraolo Spurio Cc: Ben Widawsky --- drivers/gpu/drm/i915/intel_engine_cs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c index a28e2a8..febbb91 100644 --- a/drivers/gpu/drm/i915/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/intel_engine_cs.c @@ -39,7 +39,7 @@ #define GEN8_LR_CONTEXT_RENDER_SIZE(20 * PAGE_SIZE) #define GEN9_LR_CONTEXT_RENDER_SIZE(22 * PAGE_SIZE) -#define GEN10_LR_CONTEXT_RENDER_SIZE (19 * PAGE_SIZE) +#define GEN10_LR_CONTEXT_RENDER_SIZE (18 * PAGE_SIZE) #define GEN8_LR_CONTEXT_OTHER_SIZE ( 2 * PAGE_SIZE) -- 1.9.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 drm/i915/cnl: Do not add an extra page for precaution in the Gen10 LRC size
== Series Details == Series: drm/i915/cnl: Do not add an extra page for precaution in the Gen10 LRC size URL : https://patchwork.freedesktop.org/series/31284/ State : success == Summary == Series 31284v1 drm/i915/cnl: Do not add an extra page for precaution in the Gen10 LRC size https://patchwork.freedesktop.org/api/1.0/series/31284/revisions/1/mbox/ Test gem_exec_suspend: Subgroup basic-s3: dmesg-warn -> PASS (fi-cfl-s) fdo#103026 fdo#103026 https://bugs.freedesktop.org/show_bug.cgi?id=103026 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:453s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:472s fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 time:398s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:570s fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:290s fi-bxt-dsi total:289 pass:259 dwarn:0 dfail:0 fail:0 skip:30 time:525s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:534s fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34 time:541s fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38 time:532s fi-cfl-s total:289 pass:257 dwarn:0 dfail:0 fail:0 skip:32 time:568s fi-cnl-y total:289 pass:261 dwarn:1 dfail:0 fail:0 skip:27 time:617s fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:441s fi-glk-1 total:289 pass:258 dwarn:3 dfail:0 fail:0 skip:28 time:595s fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:439s fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:418s fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:461s fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:505s fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:474s fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:505s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:575s fi-kbl-7567u total:289 pass:265 dwarn:4 dfail:0 fail:0 skip:20 time:490s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:585s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:471s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:536s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:512s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:470s fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38 time:583s fi-snb-2600 total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:435s fi-pnv-d510 failed to connect after reboot 14f3207683e165f826d0e5861944fc6f39e8e20f drm-tip: 2017y-10m-02d-20h-23m-38s UTC integration manifest 1f2eb31bd161 drm/i915/cnl: Do not add an extra page for precaution in the Gen10 LRC size == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5872/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 04/10] drm/i915: Expose a PMU interface for perf queries
Hi Peter, friendly reminder. Could you, please, respond? -Original Message- From: Rogozhkin, Dmitry V Sent: Wednesday, September 20, 2017 1:15 PM To: Rogozhkin, Dmitry V ; pet...@infradead.org Cc: Intel-gfx@lists.freedesktop.org Subject: RE: [Intel-gfx] [RFC 04/10] drm/i915: Expose a PMU interface for perf queries Hi Peter, could you, please, comment on below? -Original Message- From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Rogozhkin, Dmitry V Sent: Wednesday, September 13, 2017 4:06 PM To: pet...@infradead.org Cc: Intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [RFC 04/10] drm/i915: Expose a PMU interface for perf queries On Tue, 2017-08-29 at 21:21 +0200, Peter Zijlstra wrote: > On Tue, Aug 29, 2017 at 07:16:31PM +, Rogozhkin, Dmitry V wrote: > > > Pretty strict, people tend to get fairly upset every time we leak stuff. > > > In fact Debian and Android carry a perf_event_paranoid patch that > > > default disables _everything_ :-( > > > > Can you say more on that for Debian and Android? What exactly they do? > > What is the value of perf_event_paranoid there? They disable > > everything even for root and CAP_SYS_ADMIN? But still they don't > > remove this from kernel on compilation stage, right? So users can > > explicitly change perf_event_paranoid to the desired value? > > They introduce (and default to) perf_event_paranoid = 3. Which > disallows everything for unpriv user, root can still do things IIRC, > I'd have to dig out the patch. > > This way apps have no access to the syscall, but you can enable it > using ADB by lowering the setting. So developers still have access, > but regular apps do not. > Hi, Peter. How you would feel about the following idea (or close to it): 1. We introduce one more level for perf_event_paranoid=4 (or =3, I am not sure whether Debian/Android =3 is considered uAPI) which would mean: "disallow kernel profiling for unpriv, but let individual kernel modules to have their own settings". 2. We will have i915 PMU custom setting "/sys/module/i915/parameters/perf_event_paranoid" which will be in effect only if global perf_event_paranoid=4 (or =3) and prevail over a global setting Would anything like that be acceptable upstream? This would permit customers to configure i915 PMU support for unpriv users separately from the rest of PMU subsystem. Regards, Dmitry. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 17/21] drm/i915/selftests: huge page tests
Hi Matthew, [auto build test ERROR on drm-intel/for-linux-next] [cannot apply to v4.14-rc3] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Matthew-Auld/huge-gtt-pages/20171002-212557 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: i386-allmodconfig (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): >> ERROR: "__udivdi3" [drivers/gpu/drm/i915/i915.ko] undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/cnl: Do not add an extra page for precaution in the Gen10 LRC size
== Series Details == Series: drm/i915/cnl: Do not add an extra page for precaution in the Gen10 LRC size URL : https://patchwork.freedesktop.org/series/31284/ State : success == Summary == Test perf: Subgroup polling: pass -> FAIL (shard-hsw) fdo#102252 +1 Test kms_flip: Subgroup wf_vblank-vs-dpms-interruptible: dmesg-warn -> PASS (shard-hsw) Subgroup modeset-vs-vblank-race: pass -> DMESG-WARN (shard-hsw) fdo#102919 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#102919 https://bugs.freedesktop.org/show_bug.cgi?id=102919 shard-hswtotal:2429 pass:1330 dwarn:8 dfail:0 fail:8 skip:1083 time:10059s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5872/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Organize GLK_COLORS.
On Mon, Oct 02, 2017 at 01:02:28PM +, Jani Nikula wrote: > On Thu, 28 Sep 2017, Rodrigo Vivi wrote: > > Let's organize this in a way that it gets more obvious > > when looking to the platform colors and in a easier > > way to get inherited. > > > > Signed-off-by: Rodrigo Vivi > > --- > > drivers/gpu/drm/i915/i915_pci.c | 6 -- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_pci.c > > b/drivers/gpu/drm/i915/i915_pci.c > > index 9b54aafa2a0b..10537dcdd9c1 100644 > > --- a/drivers/gpu/drm/i915/i915_pci.c > > +++ b/drivers/gpu/drm/i915/i915_pci.c > > @@ -54,6 +54,8 @@ > > .color = { .degamma_lut_size = 512, .gamma_lut_size = 512 } > > #define CHV_COLORS \ > > .color = { .degamma_lut_size = 65, .gamma_lut_size = 257 } > > +#define GLK_COLORS \ > > + .color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 } > > > > /* Keep in gen based order, and chronological order within a gen */ > > #define GEN2_FEATURES \ > > @@ -495,7 +497,7 @@ static const struct intel_device_info > > intel_geminilake_info __initconst = { > > GEN9_LP_FEATURES, > > .platform = INTEL_GEMINILAKE, > > .ddb_size = 1024, > > - .color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 } > > + GLK_COLORS > > Please add he comma at the end. > > > }; > > > > #define KBL_PLATFORM \ > > @@ -543,7 +545,7 @@ static const struct intel_device_info > > intel_coffeelake_gt3_info __initconst = { > > #define GEN10_FEATURES \ > > GEN9_FEATURES, \ > > .ddb_size = 1024, \ > > - .color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 } > > + GLK_COLORS this one here doesn't compile. it is inside a define... So, I have a: "v2: Add comma at the end (Jani), when possible." here but I'm not sure about that since comma here is not really needed, also it wasn't there with the .color and it is not symmetric anymore... > > Ditto. > > BR, > Jani. > > > > > static const struct intel_device_info intel_cannonlake_gt2_info > > __initconst = { > > GEN10_FEATURES, > > -- > Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC i-g-t 0/6] Drop tests for object creation from stolen
The tests were merged before the feature, which never made it to the driver; the last update I could find ([1]) is more than a year old. The tests are using a wrong getparam number and planned extensions to the gem_create and get_aperture ioctl structures that don't match what's currently in i915. Due to this all stolen-related subtests are skipping. Given the fact that there has been no traction behind the feature for a long time it doesn't look like we'll need those tests anytime soon and thus it makes sense to remove them. The patches didn't revert cleanly and also contained some improvements that are worth keeping, so instead of a revert I've organized the removal in a single patch per test file to drop only the unneeded code. [1] https://patchwork.freedesktop.org/series/659/ Cc: Ankitprasad Sharma Cc: Petri Latvala Cc: Arkadiusz Hiler Cc: Tvrtko Ursulin Cc: Chris Wilson Daniele Ceraolo Spurio (6): tests/gem_pread: drop stolen memory related subtests tests/gem_pwrite: drop stolen memory related subtests tests/gem_create: drop stolen memory related subtest tests/gem_stolen: drop gem_stolen.c tests/gem_concurrent_all: drop stolen memory related subtests lib/ioctl_wrappers: drop stolen memory related wrappers lib/ioctl_wrappers.c | 119 lib/ioctl_wrappers.h | 16 -- tests/Makefile.sources | 1 - tests/gem_concurrent_all.c | 35 tests/gem_create.c | 37 +--- tests/gem_pread.c | 95 -- tests/gem_pwrite.c | 43 - tests/gem_stolen.c | 455 - 8 files changed, 2 insertions(+), 799 deletions(-) delete mode 100644 tests/gem_stolen.c -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC i-g-t 3/6] tests/gem_create: drop stolen memory related subtest
The feature was never merged and there has been no progress in the last year. The subtest is currently skipping on all platforms by checking a field in the get_aperture ioctl structure that doesn't exist in the kernel version of the struct. Signed-off-by: Daniele Ceraolo Spurio --- tests/gem_create.c | 37 ++--- 1 file changed, 2 insertions(+), 35 deletions(-) diff --git a/tests/gem_create.c b/tests/gem_create.c index de7b820..a451816 100644 --- a/tests/gem_create.c +++ b/tests/gem_create.c @@ -27,8 +27,7 @@ /** @file gem_create.c * - * This is a test for the extended and old gem_create ioctl, that - * includes allocation of object from stolen memory and shmem. + * This is a test for the gem_create ioctl. * * The goal is to simply ensure that basics work and invalid input * combinations are rejected. @@ -57,42 +56,13 @@ #include "drm.h" #include "i915_drm.h" -IGT_TEST_DESCRIPTION("This is a test for the extended & old gem_create ioctl," -" that includes allocation of object from stolen memory" -" and shmem."); +IGT_TEST_DESCRIPTION("This is a test for the gem_create ioctl"); #define CLEAR(s) memset(&s, 0, sizeof(s)) #define PAGE_SIZE 4096 -struct local_i915_gem_create_v2 { - uint64_t size; - uint32_t handle; - uint32_t pad; -#define I915_CREATE_PLACEMENT_STOLEN (1<<0) - uint32_t flags; -} create; - #define LOCAL_IOCTL_I915_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_CREATE, struct local_i915_gem_create_v2) -static void invalid_flag_test(int fd) -{ - int ret; - - gem_require_stolen_support(fd); - - create.handle = 0; - create.size = PAGE_SIZE; - create.flags = ~I915_CREATE_PLACEMENT_STOLEN; - ret = drmIoctl(fd, LOCAL_IOCTL_I915_GEM_CREATE, &create); - - igt_assert(ret <= 0); - - create.flags = ~0; - ret = drmIoctl(fd, LOCAL_IOCTL_I915_GEM_CREATE, &create); - - igt_assert(ret <= 0); -} - static void invalid_size_test(int fd) { int handle; @@ -152,9 +122,6 @@ igt_main fd = drm_open_driver(DRIVER_INTEL); } - igt_subtest("stolen-invalid-flag") - invalid_flag_test(fd); - igt_subtest("create-invalid-size") invalid_size_test(fd); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC i-g-t 2/6] tests/gem_pwrite: drop stolen memory related subtests
The feature was never merged and there has been no progress in the last year. The subtests are currently skipping on all platforms by checking a field in the get_aperture ioctl structure that doesn't exist in the kernel version of the struct. Signed-off-by: Daniele Ceraolo Spurio --- tests/gem_pwrite.c | 43 --- 1 file changed, 43 deletions(-) diff --git a/tests/gem_pwrite.c b/tests/gem_pwrite.c index b61b446..1c3d23d 100644 --- a/tests/gem_pwrite.c +++ b/tests/gem_pwrite.c @@ -206,7 +206,6 @@ static void test_big_gtt(int fd, int scale, unsigned flags) } uint32_t *src, dst; -uint32_t *src_user, dst_stolen; int fd; int main(int argc, char **argv) @@ -241,8 +240,6 @@ int main(int argc, char **argv) dst = gem_create(fd, object_size); src = malloc(object_size); - dst_stolen = gem_create_stolen(fd, object_size); - src_user = malloc(object_size); } igt_subtest("basic") { @@ -279,49 +276,9 @@ int main(int argc, char **argv) } } - igt_subtest("stolen-normal") { - gem_require_stolen_support(fd); - for (count = 1; count <= 1<<17; count <<= 1) { - struct timeval start, end; - - gettimeofday(&start, NULL); - do_gem_write(fd, dst_stolen, src_user, -object_size, count); - gettimeofday(&end, NULL); - usecs = elapsed(&start, &end, count); - bps = bytes_per_sec(buf, object_size/usecs*1e6); - igt_info("Time to pwrite %d bytes x %6d: %7.3fµs, %s\n", -object_size, count, usecs, bps); - fflush(stdout); - } - } - - for (c = cache; c->level != -1; c++) { - igt_subtest_f("stolen-%s", c->name) { - gem_require_stolen_support(fd); - gem_set_caching(fd, dst, c->level); - for (count = 1; count <= 1<<17; count <<= 1) { - struct timeval start, end; - - gettimeofday(&start, NULL); - do_gem_write(fd, dst_stolen, src_user, -object_size, count); - gettimeofday(&end, NULL); - bps = bytes_per_sec(buf, - object_size/usecs*1e6); - igt_info("Time to stolen-%s pwrite %d bytes x %6d: %7.3fµs, %s\n", -c->name, object_size, count, -usecs, bps); - fflush(stdout); - } - } - } - igt_fixture { free(src); gem_close(fd, dst); - free(src_user); - gem_close(fd, dst_stolen); } { -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC i-g-t 1/6] tests/gem_pread: drop stolen memory related subtests
The feature was never merged and there has been no progress in the last year. The subtests are currently skipping on all platforms by checking a field in the get_aperture ioctl structure that doesn't exist in the kernel version of the struct. Signed-off-by: Daniele Ceraolo Spurio --- tests/gem_pread.c | 95 --- 1 file changed, 95 deletions(-) diff --git a/tests/gem_pread.c b/tests/gem_pread.c index f4cf472..39a46ed 100644 --- a/tests/gem_pread.c +++ b/tests/gem_pread.c @@ -40,10 +40,6 @@ #include "drm.h" #define OBJECT_SIZE 16384 -#define LARGE_OBJECT_SIZE 1024 * 1024 -#define KGRN "\x1B[32m" -#define KRED "\x1B[31m" -#define KNRM "\x1B[0m" static void do_gem_read(int fd, uint32_t handle, void *buf, int len, int loops) { @@ -79,8 +75,6 @@ static const char *bytes_per_sec(char *buf, double v) uint32_t *src, dst; -uint32_t *dst_user, src_stolen, large_stolen; -uint32_t *stolen_pf_user, *stolen_nopf_user; int fd, count; int main(int argc, char **argv) @@ -113,8 +107,6 @@ int main(int argc, char **argv) dst = gem_create(fd, object_size); src = malloc(object_size); - src_stolen = gem_create_stolen(fd, object_size); - dst_user = malloc(object_size); } igt_subtest("basic") { @@ -151,96 +143,9 @@ int main(int argc, char **argv) } } - igt_subtest("stolen-normal") { - gem_require_stolen_support(fd); - for (count = 1; count <= 1<<17; count <<= 1) { - struct timeval start, end; - - gettimeofday(&start, NULL); - do_gem_read(fd, src_stolen, dst_user, object_size, count); - gettimeofday(&end, NULL); - usecs = elapsed(&start, &end, count); - bps = bytes_per_sec(buf, object_size/usecs*1e6); - igt_info("Time to pread %d bytes x %6d: %7.3fµs, %s\n", -object_size, count, usecs, bps); - fflush(stdout); - } - } - for (c = cache; c->level != -1; c++) { - igt_subtest_f("stolen-%s", c->name) { - gem_require_stolen_support(fd); - gem_set_caching(fd, src_stolen, c->level); - - for (count = 1; count <= 1<<17; count <<= 1) { - struct timeval start, end; - - gettimeofday(&start, NULL); - do_gem_read(fd, src_stolen, dst_user, - object_size, count); - gettimeofday(&end, NULL); - usecs = elapsed(&start, &end, count); - bps = bytes_per_sec(buf, object_size/usecs*1e6); - igt_info("Time to stolen-%s pread %d bytes x %6d: %7.3fµs, %s\n", -c->name, object_size, count, usecs, bps); - fflush(stdout); - } - } - } - - /* List the time taken in pread operation for stolen objects, with -* and without the overhead of page fault handling on accessing the -* user space buffer -*/ - igt_subtest("pagefault-pread") { - gem_require_stolen_support(fd); - large_stolen = gem_create_stolen(fd, LARGE_OBJECT_SIZE); - stolen_nopf_user = (uint32_t *) mmap(NULL, LARGE_OBJECT_SIZE, - PROT_WRITE, - MAP_ANONYMOUS|MAP_PRIVATE, - -1, 0); - igt_assert(stolen_nopf_user); - - for (count = 1; count <= 10; count ++) { - struct timeval start, end; - double t_elapsed = 0; - - gettimeofday(&start, NULL); - do_gem_read(fd, large_stolen, stolen_nopf_user, - LARGE_OBJECT_SIZE, 1); - gettimeofday(&end, NULL); - t_elapsed = elapsed(&start, &end, count); - bps = bytes_per_sec(buf, object_size/t_elapsed*1e6); - igt_info("Pagefault-N - Time to pread %d bytes: %7.3fµs, %s\n", -LARGE_OBJECT_SIZE, t_elapsed, bps); - - stolen_pf_user = (uint32_t *) mmap(NULL, LARGE_OBJECT_SIZE, - PROT_WRITE, - MAP_ANONYMOUS|MAP_PRIVATE, - -1, 0); - igt_assert(stolen_pf_user); - - gettimeofday(&start, NULL); -
[Intel-gfx] [RFC i-g-t 4/6] tests/gem_stolen: drop gem_stolen.c
The feature was never merged and there has been no progress in the last year. The subtests are currently skipping on all platforms by checking a field in the get_aperture ioctl structure that doesn't exist in the kernel version of the struct. Signed-off-by: Daniele Ceraolo Spurio --- tests/Makefile.sources | 1 - tests/gem_stolen.c | 455 - 2 files changed, 456 deletions(-) delete mode 100644 tests/gem_stolen.c diff --git a/tests/Makefile.sources b/tests/Makefile.sources index c4d320e..b2a9cfe 100644 --- a/tests/Makefile.sources +++ b/tests/Makefile.sources @@ -141,7 +141,6 @@ TESTS_progs = \ gem_shrink \ gem_softpin \ gem_spin_batch \ - gem_stolen \ gem_storedw_batches_loop \ gem_storedw_loop \ gem_streaming_writes \ diff --git a/tests/gem_stolen.c b/tests/gem_stolen.c deleted file mode 100644 index 1d48997..000 --- a/tests/gem_stolen.c +++ /dev/null @@ -1,455 +0,0 @@ -/* - * Copyright © 2015 Intel Corporation - * - * Permission is hereby granted, free of charge, to any person obtaining a - * copy of this software and associated documentation files (the "Software"), - * to deal in the Software without restriction, including without limitation - * the rights to use, copy, modify, merge, publish, distribute, sublicense, - * and/or sell copies of the Software, and to permit persons to whom the - * Software is furnished to do so, subject to the following conditions: - * - * The above copyright notice and this permission notice (including the next - * paragraph) shall be included in all copies or substantial portions of the - * Software. - * - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL - * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER - * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING - * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS - * IN THE SOFTWARE. - * - * Authors: - *Ankitprasad Sharma - * - */ - -/** @file gem_create_stolen.c - * - * This is a test for the extended gem_create ioctl, that includes allocation - * of object from stolen memory. - * - * The goal is to simply ensure the basics work, and invalid input combinations - * are rejected. - */ - -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -#include - -#include "ioctl_wrappers.h" -#include "intel_bufmgr.h" -#include "intel_batchbuffer.h" -#include "intel_io.h" -#include "intel_chipset.h" -#include "igt_aux.h" -#include "drmtest.h" -#include "drm.h" -#include "i915_drm.h" - -IGT_TEST_DESCRIPTION("This test verifies the exetended gem_create ioctl," -" that includes allocation of obj from stolen region"); -#define CLEAR(s) memset(&s, 0, sizeof(s)) -#define SIZE 1024*1024 -#define DWORD_SIZE 4 -#define DATA 0xdead -#define LARGE_SIZE 0x -#define MAX_OBJECTS 100 - -static drm_intel_bufmgr *bufmgr; -static struct intel_batchbuffer *batch; - -static void verify_copy_op(drm_intel_bo *src, drm_intel_bo *dest) -{ - uint32_t *virt, i, ret; - /* Fill the src BO with dwords */ - ret = drm_intel_gem_bo_map_gtt(src); - igt_assert(!ret); - - virt = src->virtual; - for (i = 0; i < SIZE/DWORD_SIZE; i++) - virt[i] = i; - - intel_copy_bo(batch, dest, src, SIZE); - - ret = drm_intel_gem_bo_map_gtt(dest); - igt_assert(!ret); - - virt = dest->virtual; - /* verify */ - for (i = 0; i < SIZE/DWORD_SIZE; i++) - igt_assert_eq(virt[i], i); - - drm_intel_bo_unmap(src); - drm_intel_bo_unmap(dest); -} - -static void stolen_pwrite(int fd) -{ - drm_intel_bo *bo; - uint32_t buf[SIZE/DWORD_SIZE]; - uint32_t handle = 0; - uint32_t *virt; - int i, ret = 0; - - for (i = 0; i < SIZE/DWORD_SIZE; i++) - buf[i] = DATA; - - gem_require_stolen_support(fd); - - handle = gem_create_stolen(fd, SIZE); - - gem_write(fd, handle, 0, buf, SIZE); - bo = gem_handle_to_libdrm_bo(bufmgr, fd, "bo", handle); - - ret = drm_intel_gem_bo_map_gtt(bo); - igt_assert(!ret); - - virt = bo->virtual; - - for (i = 0; i < SIZE/DWORD_SIZE; i++) - igt_assert_eq(virt[i], DATA); - - drm_intel_bo_unmap(bo); - drm_intel_bo_unreference(bo); - gem_close(fd, handle); -} - -static void stolen_pread(int fd) -{ - drm_intel_bo *bo; - uint32_t buf[SIZE/DWORD_SIZE]; - uint32_t handle = 0; - uint32_t *virt; - int i, ret = 0; - - CLEAR(buf); - - gem_require_stolen_support(fd); - - handle = gem_create_stolen(fd, SIZE); - - bo = gem_handle_to_libdrm_bo(bufmgr, fd, "
[Intel-gfx] [RFC i-g-t 6/6] lib/ioctl_wrappers: drop stolen memory related wrappers
The feature was never merged and there has been no progress in the last year. The wrappers are using a wrong ioctl number (38 is HAS_POOLED_EU and not CREATE_VERSION) and extensions of the gem_create and get_aperture ioctl structures that never made it into the kernel. Tests that were using the wrappers have already been removed by previous patches so it is now safe to remove the wrappers themselves. Signed-off-by: Daniele Ceraolo Spurio --- lib/ioctl_wrappers.c | 119 --- lib/ioctl_wrappers.h | 16 --- 2 files changed, 135 deletions(-) diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c index 51b6b7b..fdf6cc5 100644 --- a/lib/ioctl_wrappers.c +++ b/lib/ioctl_wrappers.c @@ -479,79 +479,6 @@ void gem_sync(int fd, uint32_t handle) errno = 0; } - -bool gem_create__has_stolen_support(int fd) -{ - static int has_stolen_support = -1; - struct drm_i915_getparam gp; - int val = -1; - - if (has_stolen_support < 0) { - memset(&gp, 0, sizeof(gp)); - gp.param = 38; /* CREATE_VERSION */ - gp.value = &val; - - /* Do we have the extended gem_create_ioctl? */ - ioctl(fd, DRM_IOCTL_I915_GETPARAM, &gp); - has_stolen_support = val >= 2; - } - - return has_stolen_support; -} - -struct local_i915_gem_create_v2 { - uint64_t size; - uint32_t handle; - uint32_t pad; -#define I915_CREATE_PLACEMENT_STOLEN (1<<0) - uint32_t flags; -}; - -#define LOCAL_IOCTL_I915_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_CREATE, struct local_i915_gem_create_v2) -uint32_t __gem_create_stolen(int fd, uint64_t size) -{ - struct local_i915_gem_create_v2 create; - int ret; - - memset(&create, 0, sizeof(create)); - create.handle = 0; - create.size = size; - create.flags = I915_CREATE_PLACEMENT_STOLEN; - ret = igt_ioctl(fd, LOCAL_IOCTL_I915_GEM_CREATE, &create); - - if (ret < 0) - return 0; - - errno = 0; - return create.handle; -} - -/** - * gem_create_stolen: - * @fd: open i915 drm file descriptor - * @size: desired size of the buffer - * - * This wraps the new GEM_CREATE ioctl, which allocates a new gem buffer - * object of @size and placement in stolen memory region. - * - * Returns: The file-private handle of the created buffer object - */ - -uint32_t gem_create_stolen(int fd, uint64_t size) -{ - struct local_i915_gem_create_v2 create; - - memset(&create, 0, sizeof(create)); - create.handle = 0; - create.size = size; - create.flags = I915_CREATE_PLACEMENT_STOLEN; - do_ioctl(fd, LOCAL_IOCTL_I915_GEM_CREATE, &create); - igt_assert(create.handle); - - return create.handle; -} - - uint32_t __gem_create(int fd, int size) { struct drm_i915_gem_create create; @@ -1378,52 +1305,6 @@ bool gem_has_bsd2(int fd) has_bsd2 = has_param(fd, LOCAL_I915_PARAM_HAS_BSD2); return has_bsd2; } - -struct local_i915_gem_get_aperture { - __u64 aper_size; - __u64 aper_available_size; - __u64 version; - __u64 map_total_size; - __u64 stolen_total_size; -}; -#define DRM_I915_GEM_GET_APERTURE 0x23 -#define LOCAL_IOCTL_I915_GEM_GET_APERTURE DRM_IOR (DRM_COMMAND_BASE + DRM_I915_GEM_GET_APERTURE, struct local_i915_gem_get_aperture) -/** - * gem_total_mappable_size: - * @fd: open i915 drm file descriptor - * - * Feature test macro to query the kernel for the total mappable size. - * - * Returns: Total mappable address space size. - */ -uint64_t gem_total_mappable_size(int fd) -{ - struct local_i915_gem_get_aperture aperture; - - memset(&aperture, 0, sizeof(aperture)); - do_ioctl(fd, LOCAL_IOCTL_I915_GEM_GET_APERTURE, &aperture); - - return aperture.map_total_size; -} - -/** - * gem_total_stolen_size: - * @fd: open i915 drm file descriptor - * - * Feature test macro to query the kernel for the total stolen size. - * - * Returns: Total stolen memory. - */ -uint64_t gem_total_stolen_size(int fd) -{ - struct local_i915_gem_get_aperture aperture; - - memset(&aperture, 0, sizeof(aperture)); - do_ioctl(fd, LOCAL_IOCTL_I915_GEM_GET_APERTURE, &aperture); - - return aperture.stolen_total_size; -} - /** * gem_available_aperture_size: * @fd: open i915 drm file descriptor diff --git a/lib/ioctl_wrappers.h b/lib/ioctl_wrappers.h index 090c125..008747a 100644 --- a/lib/ioctl_wrappers.h +++ b/lib/ioctl_wrappers.h @@ -70,9 +70,6 @@ int __gem_set_domain(int fd, uint32_t handle, uint32_t read, uint32_t write); void gem_set_domain(int fd, uint32_t handle, uint32_t read, uint32_t write); int gem_wait(int fd, uint32_t handle, int64_t *timeout_ns); void gem_sync(int fd, uint32_t handle); -bool gem_create__has_stolen_support(int fd); -uint32_t __gem_create_stolen(int fd, uint64_t size); -uint32_t gem_create_stolen(int fd, uint64_t siz
[Intel-gfx] [RFC i-g-t 5/6] tests/gem_concurrent_all: drop stolen memory related subtests
The feature was never merged and there has been no progress in the last year. The tests are currently excluded from compilation with and ifdef. Cc: Chris Wilson Signed-off-by: Daniele Ceraolo Spurio --- tests/gem_concurrent_all.c | 35 --- 1 file changed, 35 deletions(-) diff --git a/tests/gem_concurrent_all.c b/tests/gem_concurrent_all.c index 201b491..87f2129 100644 --- a/tests/gem_concurrent_all.c +++ b/tests/gem_concurrent_all.c @@ -170,36 +170,6 @@ static void can_create_private(const struct create *create, unsigned count) } #endif -#if HAVE_CREATE_STOLEN -static drm_intel_bo * -create_stolen_bo(drm_intel_bufmgr *bufmgr, uint64_t size) -{ - drm_intel_bo *bo; - uint32_t handle; - - /* XXX gem_create_with_flags(fd, size, I915_CREATE_STOLEN); */ - - handle = gem_create(fd, size); - bo = gem_handle_to_libdrm_bo(bufmgr, fd, "stolen", handle); - gem_close(fd, handle); - - return bo; -} - -static void can_create_stolen(const struct create *create, unsigned count) -{ - /* XXX check num_buffers against available stolen */ - igt_require(0); -} -#endif - -static void create_cpu_require(const struct create *create, unsigned count) -{ -#if HAVE_CREATE_STOLEN - igt_require(create->create != create_stolen_bo); -#endif -} - static drm_intel_bo * unmapped_create_bo(const struct buffers *b) { @@ -208,7 +178,6 @@ unmapped_create_bo(const struct buffers *b) static void create_snoop_require(const struct create *create, unsigned count) { - create_cpu_require(create, count); igt_require(!gem_has_llc(fd)); } @@ -1727,7 +1696,6 @@ igt_main { .name = "cpu", .create_bo = unmapped_create_bo, - .require = create_cpu_require, .set_bo = cpu_set_bo, .cmp_bo = cpu_cmp_bo, .release_bo = nop_release_bo, @@ -1807,9 +1775,6 @@ igt_main #if HAVE_CREATE_PRIVATE { "private-", can_create_private, create_private_bo}, #endif -#if HAVE_CREATE_STOLEN - { "stolen-", can_create_stolen, create_stolen_bo}, -#endif { NULL, NULL } }; const struct size sizes[] = { -- 1.9.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 2-in-1: Organize feature inheritance and disable IPC.
== Series Details == Series: 2-in-1: Organize feature inheritance and disable IPC. URL : https://patchwork.freedesktop.org/series/31090/ State : success == Summary == Series 31090v1 2-in-1: Organize feature inheritance and disable IPC. https://patchwork.freedesktop.org/api/1.0/series/31090/revisions/1/mbox/ fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:459s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:476s fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 time:395s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:570s fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:288s fi-bxt-dsi total:289 pass:259 dwarn:0 dfail:0 fail:0 skip:30 time:534s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:541s fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34 time:548s fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38 time:521s fi-cfl-s total:289 pass:256 dwarn:1 dfail:0 fail:0 skip:32 time:560s fi-cnl-y total:289 pass:261 dwarn:1 dfail:0 fail:0 skip:27 time:614s fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:433s fi-glk-1 total:289 pass:258 dwarn:3 dfail:0 fail:0 skip:28 time:597s fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:438s fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:424s fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:466s fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:499s fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:472s fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:503s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:581s fi-kbl-7567u total:289 pass:265 dwarn:4 dfail:0 fail:0 skip:20 time:498s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:594s fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:659s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:473s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:533s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:519s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:477s fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38 time:591s fi-snb-2600 total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:434s 14f3207683e165f826d0e5861944fc6f39e8e20f drm-tip: 2017y-10m-02d-20h-23m-38s UTC integration manifest 8da14f06fd4a drm/i915: Extend WaDisableIPC to all platforms. 37a80792833f drm/i915: Organize GLK_COLORS. dcd1fd8d44c9 drm/i915: Organize GEN features inheritance. 9d19c7ea1a15 drm/i915/skl: Fix has_ipc on skl and document WaDisableIPC. == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5873/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Drop tests for object creation from stolen
== Series Details == Series: Drop tests for object creation from stolen URL : https://patchwork.freedesktop.org/series/31290/ State : success == Summary == IGT patchset tested on top of latest successful build b5404f8435f828ca039a2e46be629b3d4c92465b meson: Follow suit with the renaming of kms_pipe_color with latest DRM-Tip kernel build CI_DRM_3163 14f3207683e1 drm-tip: 2017y-10m-02d-20h-23m-38s UTC integration manifest Testlist changes: -igt@gem_create@stolen-invalid-flag -igt@gem_pread@pagefault-pread -igt@gem_pread@stolen-display -igt@gem_pread@stolen-normal -igt@gem_pread@stolen-snoop -igt@gem_pread@stolen-uncached -igt@gem_pwrite@stolen-display -igt@gem_pwrite@stolen-normal -igt@gem_pwrite@stolen-snoop -igt@gem_pwrite@stolen-uncached -igt@gem_stolen@large-object-alloc -igt@gem_stolen@stolen-clear -igt@gem_stolen@stolen-copy -igt@gem_stolen@stolen-fill-purge -igt@gem_stolen@stolen-hibernate -igt@gem_stolen@stolen-no-mmap -igt@gem_stolen@stolen-pread -igt@gem_stolen@stolen-pwrite fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:458s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:472s fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 time:391s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:585s fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:291s fi-bxt-dsi total:289 pass:259 dwarn:0 dfail:0 fail:0 skip:30 time:532s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:533s fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34 time:555s fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38 time:546s fi-cfl-s total:289 pass:256 dwarn:1 dfail:0 fail:0 skip:32 time:567s fi-cnl-y total:289 pass:261 dwarn:1 dfail:0 fail:0 skip:27 time:639s fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:441s fi-glk-1 total:289 pass:258 dwarn:3 dfail:0 fail:0 skip:28 time:597s fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:442s fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:423s fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:462s fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:505s fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:480s fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:509s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:582s fi-kbl-7567u total:289 pass:265 dwarn:4 dfail:0 fail:0 skip:20 time:491s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:595s fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:661s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:499s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:537s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:522s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:479s fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38 time:593s fi-snb-2600 total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:446s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_283/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] tests/gem_bad_length: drop gem_bad_length.c
Most of the gem_bad_length code is compiled out because creating a zero-length object is not allowed anymore by i915 and thus it is not possible to execute it. The remaining part checks that creation of a zero-length object does indeed fail, which is also checked by gem_create/create-invalid-size. The only difference between the 2 tests is that gem_bad_length checks specifically for EINVAL while create-invalid-size only looks for failure, so after adding the EINVAL check to create-invalid-size it is safe to drop gem_bad_length. Signed-off-by: Daniele Ceraolo Spurio --- tests/Makefile.sources | 1 - tests/gem_bad_length.c | 133 - tests/gem_create.c | 2 +- 3 files changed, 1 insertion(+), 135 deletions(-) delete mode 100644 tests/gem_bad_length.c diff --git a/tests/Makefile.sources b/tests/Makefile.sources index c4d320e..142ff2b 100644 --- a/tests/Makefile.sources +++ b/tests/Makefile.sources @@ -40,7 +40,6 @@ TESTS_progs = \ drv_module_reload \ drv_selftest \ drv_suspend \ - gem_bad_length \ gem_bad_reloc \ gem_basic \ gem_busy \ diff --git a/tests/gem_bad_length.c b/tests/gem_bad_length.c deleted file mode 100644 index cca0145..000 --- a/tests/gem_bad_length.c +++ /dev/null @@ -1,133 +0,0 @@ -/* - * Copyright © 2011 Intel Corporation - * - * Permission is hereby granted, free of charge, to any person obtaining a - * copy of this software and associated documentation files (the "Software"), - * to deal in the Software without restriction, including without limitation - * the rights to use, copy, modify, merge, publish, distribute, sublicense, - * and/or sell copies of the Software, and to permit persons to whom the - * Software is furnished to do so, subject to the following conditions: - * - * The above copyright notice and this permission notice (including the next - * paragraph) shall be included in all copies or substantial portions of the - * Software. - * - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL - * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER - * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING - * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS - * IN THE SOFTWARE. - * - * Authors: - *Chris Wilson - * - */ - -#include "igt.h" -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include "drm.h" - -IGT_TEST_DESCRIPTION("Test minimal bo_create and batchbuffer exec."); - -/* - * Testcase: Minimal bo_create and batchbuffer exec - * - * Originally this caught an kernel oops due to the unchecked assumption that - * objects have size > 0. - */ - -static uint32_t do_gem_create(int fd, int size, int *retval) -{ - struct drm_i915_gem_create create; - int ret; - - create.handle = 0; - create.size = (size + 4095) & -4096; - ret = drmIoctl(fd, DRM_IOCTL_I915_GEM_CREATE, &create); - igt_assert(retval || ret == 0); - if (retval) - *retval = errno; - - return create.handle; -} - -#if 0 -static int gem_exec(int fd, struct drm_i915_gem_execbuffer2 *execbuf) -{ - return drmIoctl(fd, DRM_IOCTL_I915_GEM_EXECBUFFER2, execbuf); -} -#endif - -static void create0(int fd) -{ - int retval = 0; - igt_info("trying to create a zero-length gem object\n"); - do_gem_create(fd, 0, &retval); - igt_assert(retval == EINVAL); -} - -#if 0 -static void exec0(int fd) -{ - struct drm_i915_gem_execbuffer2 execbuf; - struct drm_i915_gem_exec_object2 exec[1]; - uint32_t buf[2] = { MI_BATCH_BUFFER_END, 0 }; - - /* Just try executing with a zero-length bo. -* We expect the kernel to either accept the nop batch, or reject it -* for the zero-length buffer, but never crash. -*/ - - exec[0].handle = gem_create(fd, 4096); - gem_write(fd, exec[0].handle, 0, buf, sizeof(buf)); - exec[0].relocation_count = 0; - exec[0].relocs_ptr = 0; - exec[0].alignment = 0; - exec[0].offset = 0; - exec[0].flags = 0; - exec[0].rsvd1 = 0; - exec[0].rsvd2 = 0; - - execbuf.buffers_ptr = (uintptr_t)exec; - execbuf.buffer_count = 1; - execbuf.batch_start_offset = 0; - execbuf.batch_len = sizeof(buf); - execbuf.cliprects_ptr = 0; - execbuf.num_cliprects = 0; - execbuf.DR1 = 0; - execbuf.DR4 = 0; - execbuf.flags = 0; - i915_execbuffer2_set_context_id(execbuf, 0); - execbuf.rsvd2 = 0; - - igt_info("trying to run an empty batchbuffer\n"); - gem_exec(fd, &execbuf); - - gem_close(fd, exec[0].handle); -} -#endif - -igt_simple_main -{ - int fd; - - igt_skip_o
[Intel-gfx] ✓ Fi.CI.BAT: success for tests/gem_bad_length: drop gem_bad_length.c
== Series Details == Series: tests/gem_bad_length: drop gem_bad_length.c URL : https://patchwork.freedesktop.org/series/31292/ State : success == Summary == IGT patchset tested on top of latest successful build b5404f8435f828ca039a2e46be629b3d4c92465b meson: Follow suit with the renaming of kms_pipe_color with latest DRM-Tip kernel build CI_DRM_3163 14f3207683e1 drm-tip: 2017y-10m-02d-20h-23m-38s UTC integration manifest Testlist changes: -igt@gem_bad_length Test drv_module_reload: Subgroup basic-reload-inject: pass -> INCOMPLETE (fi-cfl-s) k.org#196765 k.org#196765 https://bugzilla.kernel.org/show_bug.cgi?id=196765 fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:462s fi-bdw-gvtdvmtotal:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:470s fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 time:395s fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:573s fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:289s fi-bxt-dsi total:289 pass:259 dwarn:0 dfail:0 fail:0 skip:30 time:535s fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:537s fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34 time:549s fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38 time:549s fi-cfl-s total:288 pass:255 dwarn:1 dfail:0 fail:0 skip:31 fi-cnl-y total:289 pass:261 dwarn:1 dfail:0 fail:0 skip:27 time:636s fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:439s fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:440s fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:422s fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:467s fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:505s fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:482s fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:499s fi-kbl-7560u total:289 pass:270 dwarn:0 dfail:0 fail:0 skip:19 time:583s fi-kbl-7567u total:289 pass:265 dwarn:4 dfail:0 fail:0 skip:20 time:497s fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:588s fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:658s fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:476s fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:541s fi-skl-6770hqtotal:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:524s fi-skl-gvtdvmtotal:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:482s fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38 time:590s fi-snb-2600 total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:441s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_284/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Drop tests for object creation from stolen
== Series Details == Series: Drop tests for object creation from stolen URL : https://patchwork.freedesktop.org/series/31290/ State : success == Summary == Test perf: Subgroup blocking: fail -> PASS (shard-hsw) fdo#102252 Test kms_flip: Subgroup flip-vs-absolute-wf_vblank: pass -> FAIL (shard-hsw) fdo#100368 Subgroup wf_vblank-vs-dpms-interruptible: dmesg-warn -> PASS (shard-hsw) fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 shard-hswtotal:2412 pass:1331 dwarn:7 dfail:0 fail:8 skip:1066 time:10058s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_283/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for tests/gem_bad_length: drop gem_bad_length.c
== Series Details == Series: tests/gem_bad_length: drop gem_bad_length.c URL : https://patchwork.freedesktop.org/series/31292/ State : success == Summary == Test perf: Subgroup blocking: fail -> PASS (shard-hsw) fdo#102252 Test kms_setmode: Subgroup basic: pass -> FAIL (shard-hsw) fdo#99912 Test kms_flip: Subgroup wf_vblank-vs-dpms-interruptible: dmesg-warn -> PASS (shard-hsw) Test gem_eio: Subgroup throttle: dmesg-warn -> PASS (shard-hsw) fdo#102886 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 fdo#102886 https://bugs.freedesktop.org/show_bug.cgi?id=102886 shard-hswtotal:2428 pass:1331 dwarn:6 dfail:0 fail:8 skip:1083 time:10104s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_284/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx