Re: [Intel-gfx] [PATCH 0/3] LPSS PWM support for devices that support it
Hello Hi, This is an untested attempt to enable LPSS PWM in the driver. As part of this did some restructuring for encapsulating the pwm_info inside the panel->backlight itself. This makes enabling LPSS PWM clean and simple. I did try it on my Asus T100 TAF without success. The error in dmesg: [1.204866] [drm:pwm_setup_backlight [i915]] *ERROR* Failed to own the pwm chip: pwm_lpss how can i further debug it for you? Thanks ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ success: Fi.CI.BAT
== Summary == Built on 058740f8fced6851aeda34f366f5330322cd585f drm-intel-nightly: 2016y-01m-13d-17h-07m-44s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: dmesg-warn -> PASS (bdw-nuci7) Test kms_flip: Subgroup basic-flip-vs-dpms: dmesg-warn -> PASS (ilk-hp8440p) bdw-nuci7total:138 pass:129 dwarn:0 dfail:0 fail:0 skip:9 bdw-ultratotal:138 pass:132 dwarn:0 dfail:0 fail:0 skip:6 bsw-nuc-2total:141 pass:115 dwarn:2 dfail:0 fail:0 skip:24 hsw-brixbox total:141 pass:134 dwarn:0 dfail:0 fail:0 skip:7 ilk-hp8440p total:141 pass:101 dwarn:3 dfail:0 fail:0 skip:37 ivb-t430stotal:135 pass:122 dwarn:3 dfail:4 fail:0 skip:6 skl-i5k-2total:141 pass:131 dwarn:2 dfail:0 fail:0 skip:8 skl-i7k-2total:141 pass:131 dwarn:2 dfail:0 fail:0 skip:8 snb-dellxps total:141 pass:122 dwarn:5 dfail:0 fail:0 skip:14 snb-x220ttotal:141 pass:122 dwarn:5 dfail:0 fail:1 skip:13 Results at /archive/results/CI_IGT_test/Patchwork_1176/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: disable non-sequential pfits on ivb/hsw
On Wed, 13 Jan 2016, Chris Bainbridge wrote:
> The existing code assumes a sequential mapping of panel fitters to pipes
> (pfit0-pipeA, pfit1-pipeB, pfit2-pipeC), but boot firmware can
> arbitrarily assign any pipe to a pfit on IVB hardware e.g. Macbook UEFI
> uses pfit 0 and pipe C for eDP1 when the firmware boots in a non-16:10
> resolution (the last-used resolution is stored in NVRAM by OS X so the
> firmware can immediately restore it at boot). When this happens, the
> display will appear letterboxed due to incorrect aspect ratio and
> attempting to switch to alternative resolutions will fail. Fix this by
> disabling any panel fitters which have been non-sequentially assigned at
> boot time.
>
> Link: https://bugs.freedesktop.org/show_bug.cgi?id=93523
s/Link/Bugzilla/
> Signed-off-by: Chris Bainbridge
> ---
> drivers/gpu/drm/i915/intel_display.c | 26 ++
> 1 file changed, 18 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 32cf97346978..9e588139a2dd 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9170,6 +9170,24 @@ static void ironlake_get_pfit_config(struct intel_crtc
> *crtc,
> struct drm_device *dev = crtc->base.dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> uint32_t tmp;
> + int pipe;
> +
> + /*
> + * PF_CTL assumes panel fitter 0 is on pipe A, panel fitter 1 is on
> + * pipe B, and panel fitter 2 is on pipe C, but firmware can init IVB
> + * panel fitters to any arbitrary pipe (Macbook UEFI uses pfit 0 for
> + * pipe C), so find and disable any other mappings.
> + */
> + for (pipe = 0; pipe < INTEL_INFO(dev)->num_pipes; pipe++) {
> + tmp = I915_READ(PF_CTL(pipe));
> + if (IS_GEN7(dev) && (tmp & PF_ENABLE) &&
> + PF_PIPE_SEL_IVB(pipe) != (tmp & PF_PIPE_SEL_MASK_IVB)) {
> + DRM_DEBUG_KMS("disabling initial panel fitter\n");
> + I915_WRITE(PF_CTL(pipe), 0);
> + I915_WRITE(PF_WIN_POS(pipe), 0);
> + I915_WRITE(PF_WIN_SZ(pipe), 0);
> + }
> + }
>
> tmp = I915_READ(PF_CTL(crtc->pipe));
>
> @@ -9177,14 +9195,6 @@ static void ironlake_get_pfit_config(struct intel_crtc
> *crtc,
> pipe_config->pch_pfit.enabled = true;
> pipe_config->pch_pfit.pos = I915_READ(PF_WIN_POS(crtc->pipe));
> pipe_config->pch_pfit.size = I915_READ(PF_WIN_SZ(crtc->pipe));
> -
> - /* We currently do not free assignements of panel fitters on
> - * ivb/hsw (since we don't use the higher upscaling modes which
> - * differentiates them) so just WARN about this case for now. */
> - if (IS_GEN7(dev)) {
> - WARN_ON((tmp & PF_PIPE_SEL_MASK_IVB) !=
> - PF_PIPE_SEL_IVB(crtc->pipe));
> - }
> }
> }
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ failure: Fi.CI.BAT
== Summary == HEAD is now at 058740f drm-intel-nightly: 2016y-01m-13d-17h-07m-44s UTC integration manifest Applying: drm/i915: Make i915_gem_reset_ring_status() public Applying: drm/i915: Generalise common GPU engine reset request/unrequest code Applying: drm/i915: TDR / per-engine hang recovery support for gen8. Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_dma.c M drivers/gpu/drm/i915/i915_irq.c M drivers/gpu/drm/i915/intel_lrc.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/intel_lrc.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_lrc.c Auto-merging drivers/gpu/drm/i915/i915_irq.c Auto-merging drivers/gpu/drm/i915/i915_dma.c Patch failed at 0003 drm/i915: TDR / per-engine hang recovery support for gen8. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Make sure DC writes are coherent on flush.
On Wed, Jan 13, 2016 at 06:59:39PM -0800, Francisco Jerez wrote:
> We need to set the DC FLUSH PIPE_CONTROL bit on Gen7+ to guarantee
> that writes performed via the HDC are visible in memory. Fixes an
> intermittent failure in a Piglit test that writes to a BO from a
> shader using GL atomic counters (implemented as HDC untyped atomics)
> and then expects the memory to read back the same value after mapping
> it on the CPU.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91298
> Tested-by: Mark Janes
> Cc: Rodrigo Vivi
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_lrc.c| 1 +
> drivers/gpu/drm/i915/intel_ringbuffer.c | 2 ++
> 2 files changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index ab344e0..02213c6 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1735,6 +1735,7 @@ static int gen8_emit_flush_render(struct
> drm_i915_gem_request *request,
> if (flush_domains) {
> flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
> flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
> + flags |= PIPE_CONTROL_DC_FLUSH_ENABLE;
> flags |= PIPE_CONTROL_FLUSH_ENABLE;
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 4060acf..8cd8aab 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -331,6 +331,7 @@ gen7_render_ring_flush(struct drm_i915_gem_request *req,
> if (flush_domains) {
> flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
> flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
> + flags |= PIPE_CONTROL_DC_FLUSH_ENABLE;
> flags |= PIPE_CONTROL_FLUSH_ENABLE;
> }
> if (invalidate_domains) {
> @@ -403,6 +404,7 @@ gen8_render_ring_flush(struct drm_i915_gem_request *req,
> if (flush_domains) {
> flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
> flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
> + flags |= PIPE_CONTROL_DC_FLUSH_ENABLE;
> flags |= PIPE_CONTROL_FLUSH_ENABLE;
> }
> if (invalidate_domains) {
> --
> 2.7.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ success: Fi.CI.BAT
== Summary == Built on 058740f8fced6851aeda34f366f5330322cd585f drm-intel-nightly: 2016y-01m-13d-17h-07m-44s UTC integration manifest Test kms_flip: Subgroup basic-flip-vs-dpms: dmesg-warn -> PASS (ilk-hp8440p) bdw-nuci7total:138 pass:128 dwarn:1 dfail:0 fail:0 skip:9 bdw-ultratotal:138 pass:132 dwarn:0 dfail:0 fail:0 skip:6 bsw-nuc-2total:141 pass:115 dwarn:2 dfail:0 fail:0 skip:24 hsw-brixbox total:141 pass:134 dwarn:0 dfail:0 fail:0 skip:7 ilk-hp8440p total:141 pass:101 dwarn:3 dfail:0 fail:0 skip:37 ivb-t430stotal:135 pass:122 dwarn:3 dfail:4 fail:0 skip:6 skl-i5k-2total:141 pass:131 dwarn:2 dfail:0 fail:0 skip:8 skl-i7k-2total:141 pass:131 dwarn:2 dfail:0 fail:0 skip:8 snb-dellxps total:141 pass:122 dwarn:5 dfail:0 fail:0 skip:14 snb-x220ttotal:141 pass:122 dwarn:5 dfail:0 fail:1 skip:13 Results at /archive/results/CI_IGT_test/Patchwork_1178/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] PROBLEM: displayport MST external monitors don't return from sleep mode
On Thu, 14 Jan 2016, Derek Yerger wrote: > Kind Regards, > Derek Yerger > Computer Engineering > 10171358 / djy24 > [1.] displayport MST external monitors don't return from sleep mode > > [2.] When displays go to sleep, upon return from sleep the two monitors > attached to a belkin mini displayport to 2x HDMI, do not return from > sleep. This results in part of the desktop being inaccessible, until the > external displays are unplugged, and then plugged back in. > > Sometimes, Xorg will also back down to one monitor. The data > accompanying this report is for an instance where the power save mode > caused Xorg to drop to the primary monitor only. > > This is on a Dell XPS 13 (9333) using intel i915. There are two external > monitors connected by HDMI to a DP-MST adapter which connects to the > single mini-displayport. A single-HDMI-to-mini-displayport adapter works > as expected (coming out of power save). > > The bug can be reproduced by either letting the screen power save > timeout elapse, or by running "xset dpms force off" Please report i915 bugs at the freedesktop.org bugzilla: https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel But before doing so, please check if your issue might be one of these existing DP MST bugs: https://goo.gl/VERzzh BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/11] drm/i915: Use insert_page for pwrite_fast
On Thu, Jan 14, 2016 at 11:46:39AM +0530, ankitprasad.r.sha...@intel.com wrote:
> out_unpin:
> - i915_gem_object_ggtt_unpin(obj);
> + if (node.allocated) {
> + wmb();
> + i915->gtt.base.clear_range(&i915->gtt.base,
> +node.start, node.size,
> +true);
> + remove_mappable_node(&node);
> + i915_gem_object_unpin_pages(obj);
> + i915_gem_object_put_pages(obj);
Oops, just unpin the pages don't free (put) them. The API is asymmetic
and greedy, we grab the pages and don't give them back until the system
asks for them back.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ warning: Fi.CI.BAT
== Summary == Built on 058740f8fced6851aeda34f366f5330322cd585f drm-intel-nightly: 2016y-01m-13d-17h-07m-44s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: dmesg-warn -> PASS (bdw-nuci7) Test kms_force_connector_basic: Subgroup force-connector-state: pass -> SKIP (ivb-t430s) Test pm_rpm: Subgroup basic-pci-d3-state: pass -> DMESG-WARN (skl-i7k-2) bdw-nuci7total:138 pass:129 dwarn:0 dfail:0 fail:0 skip:9 bdw-ultratotal:138 pass:132 dwarn:0 dfail:0 fail:0 skip:6 bsw-nuc-2total:141 pass:115 dwarn:2 dfail:0 fail:0 skip:24 hsw-brixbox total:141 pass:134 dwarn:0 dfail:0 fail:0 skip:7 ilk-hp8440p total:141 pass:100 dwarn:4 dfail:0 fail:0 skip:37 ivb-t430stotal:135 pass:121 dwarn:3 dfail:4 fail:0 skip:7 skl-i5k-2total:141 pass:131 dwarn:2 dfail:0 fail:0 skip:8 skl-i7k-2total:141 pass:130 dwarn:3 dfail:0 fail:0 skip:8 snb-dellxps total:141 pass:122 dwarn:5 dfail:0 fail:0 skip:14 snb-x220ttotal:141 pass:122 dwarn:5 dfail:0 fail:1 skip:13 Results at /archive/results/CI_IGT_test/Patchwork_1179/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Make sure DC writes are coherent on flush.
On Thu, Jan 14, 2016 at 09:58:00AM +0200, Jani Nikula wrote:
> On Thu, 14 Jan 2016, Francisco Jerez wrote:
> > We need to set the DC FLUSH PIPE_CONTROL bit on Gen7+ to guarantee
> > that writes performed via the HDC are visible in memory. Fixes an
> > intermittent failure in a Piglit test that writes to a BO from a
> > shader using GL atomic counters (implemented as HDC untyped atomics)
> > and then expects the memory to read back the same value after mapping
> > it on the CPU.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91298
> > Tested-by: Mark Janes
> > Cc: Rodrigo Vivi
>
> Should this be backported to stable kernels? Is this a regression, or
> has it always been broken?
It was always missing, but since Mesa wasn't dirtying the DC it didn't
matter.
I'd say put cc:stable on it. I can't see much risk of regressions from
this, and it would allow using a modern Mesa with stable kernels without
hitting these problems.
>
> BR,
> Jani.
>
>
> > ---
> > drivers/gpu/drm/i915/intel_lrc.c| 1 +
> > drivers/gpu/drm/i915/intel_ringbuffer.c | 2 ++
> > 2 files changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index ab344e0..02213c6 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -1735,6 +1735,7 @@ static int gen8_emit_flush_render(struct
> > drm_i915_gem_request *request,
> > if (flush_domains) {
> > flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
> > flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
> > + flags |= PIPE_CONTROL_DC_FLUSH_ENABLE;
> > flags |= PIPE_CONTROL_FLUSH_ENABLE;
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > index 4060acf..8cd8aab 100644
> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > @@ -331,6 +331,7 @@ gen7_render_ring_flush(struct drm_i915_gem_request *req,
> > if (flush_domains) {
> > flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
> > flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
> > + flags |= PIPE_CONTROL_DC_FLUSH_ENABLE;
> > flags |= PIPE_CONTROL_FLUSH_ENABLE;
> > }
> > if (invalidate_domains) {
> > @@ -403,6 +404,7 @@ gen8_render_ring_flush(struct drm_i915_gem_request *req,
> > if (flush_domains) {
> > flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
> > flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
> > + flags |= PIPE_CONTROL_DC_FLUSH_ENABLE;
> > flags |= PIPE_CONTROL_FLUSH_ENABLE;
> > }
> > if (invalidate_domains) {
>
> --
> Jani Nikula, Intel Open Source Technology Center
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/11] drm/i915: Clearing buffer objects via CPU/GTT
On Thu, Jan 14, 2016 at 11:46:40AM +0530, ankitprasad.r.sha...@intel.com wrote:
> From: Ankitprasad Sharma
>
> This patch adds support for clearing buffer objects via CPU/GTT. This
> is particularly useful for clearing out the non shmem backed objects.
> Currently intend to use this only for buffers allocated from stolen
> region.
>
> v2: Added kernel doc for i915_gem_clear_object(), corrected/removed
> variable assignments (Tvrtko)
>
> v3: Map object page by page to the gtt if the pinning of the whole object
> to the ggtt fails, Corrected function name (Chris)
>
> v4: Clear the buffer page by page, and not map the whole object in the gtt
> aperture. Use i915 wrapper function in place of drm_mm_insert_node_in_range.
>
> v5: Use renamed wrapper function for drm_mm_insert_node_in_range,
> updated barrier positioning (Chris)
>
> v6: Use PAGE_SIZE instead of 4096, use get_pages call before pinning pages
> (Tvrtko)
>
> Testcase: igt/gem_stolen
>
> Signed-off-by: Ankitprasad Sharma
> Reviewed-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/i915_gem.c | 49
> +
> 2 files changed, 50 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 7dc122f..1153150 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2893,6 +2893,7 @@ int i915_gem_obj_prepare_shmem_read(struct
> drm_i915_gem_object *obj,
> int *needs_clflush);
>
> int __must_check i915_gem_object_get_pages(struct drm_i915_gem_object *obj);
> +int i915_gem_object_clear(struct drm_i915_gem_object *obj);
>
> static inline int __sg_page_count(struct scatterlist *sg)
> {
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 4ef74cf..a2138c0 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -5359,3 +5359,52 @@ fail:
> drm_gem_object_unreference(&obj->base);
> return ERR_PTR(ret);
> }
> +
> +/**
> + * i915_gem_object_clear() - Clear buffer object via CPU/GTT
> + * @obj: Buffer object to be cleared
> + *
> + * Return: 0 - success, non-zero - failure
> + */
> +int i915_gem_object_clear(struct drm_i915_gem_object *obj)
> +{
> + int ret, i;
> + char __iomem *base;
> + size_t size = obj->base.size;
> + struct drm_i915_private *i915 = to_i915(obj->base.dev);
> + struct drm_mm_node node;
> +
> + lockdep_assert_held(&obj->base.dev->struct_mutex);
> + memset(&node, 0, sizeof(node));
We are repeating this? I think every caller has to clear the node before
inserting it (part of the requirement of the drm_mm_insert_node), so we
can move it to insert_mappable_node().
> + ret = insert_mappable_node(i915, &node, PAGE_SIZE);
> + if (ret)
return ret;
> +
> + ret = i915_gem_object_get_pages(obj);
> + if (ret) {
goto err_remove_node;
> + }
> +
> + i915_gem_object_pin_pages(obj);
> + base = io_mapping_map_wc(i915->gtt.mappable, node.start);
> + for (i = 0; i < size/PAGE_SIZE; i++) {
> + i915->gtt.base.insert_page(&i915->gtt.base,
> +i915_gem_object_get_dma_address(obj,
> i),
> +node.start,
> +I915_CACHE_NONE, 0);
> + wmb();
> + memset_io(base, 0, PAGE_SIZE);
> + wmb();
> + }
> +
> + io_mapping_unmap(base);
> + i915->gtt.base.clear_range(&i915->gtt.base,
> + node.start, node.size,
> + true);
> + remove_mappable_node(&node);
> + i915_gem_object_unpin_pages(obj);
> + i915_gem_object_put_pages(obj);
Again don't put pages...
> +out:
Fix the onion.
i.e. undo the operation in reverse order;
put_pages(obj);
err_remove_node:
remove_mappable_node(&node);
> + return ret;
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests/gem_guc_loading: Adding simple GuC loading test
Hi Daniel,
Some teams, in the past, experienced issues with GuC loading. In order to
prevent such issues they need a simple loading tests that can be included in
automation environment. As the time progress and GuC will become more widely
used and this test could be extended but for now it is needed in its simple form
Thanks,
Lukasz
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Friday, January 8, 2016 8:55 AM
To: Fiedorowicz, Lukasz
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/gem_guc_loading: Adding simple GuC
loading test
On Tue, Jan 05, 2016 at 05:17:07PM +0100, Lukasz Fiedorowicz wrote:
> Test check GuC debugfs file for successful loading confirmation
>
> Signed-off-by: Lukasz Fiedorowicz
What's the value of this testcase? What happens on a system without guc?
Seems more like a "is your system configured correctly" testcase, and thus far
we haven't done those as separate tests, but just as a pile of igt_require (or
maybe igt_fail) in a relevant functional testcase.
-Daniel
> ---
> tests/Makefile.sources | 1 +
> tests/gem_guc_loading.c | 89
> +
> 2 files changed, 90 insertions(+)
> create mode 100644 tests/gem_guc_loading.c
>
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources index
> d594038..331234f 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -36,6 +36,7 @@ TESTS_progs_M = \
> gem_flink_basic \
> gem_flink_race \
> gem_linear_blits \
> + gem_guc_loading \
> gem_madvise \
> gem_mmap \
> gem_mmap_gtt \
> diff --git a/tests/gem_guc_loading.c b/tests/gem_guc_loading.c new
> file mode 100644 index 000..fd53a46
> --- /dev/null
> +++ b/tests/gem_guc_loading.c
> @@ -0,0 +1,89 @@
> +/*
> + * Copyright (c) 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:
> + *Lukasz Fiedorowicz
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include "igt.h"
> +
> +IGT_TEST_DESCRIPTION("GuC firmware loading test.");
> +
> +#define LOAD_STATUS_BUF_SIZE 96
> +
> +enum guc_status { GUC_ENABLED, GUC_DISABLED };
> +
> +int guc_status_fd;
> +
> +static void open_guc_status(void)
> +{
> + guc_status_fd = igt_debugfs_open("i915_guc_load_status", O_RDONLY);
> + igt_assert_f(guc_status_fd >= 0, "Can't open
> +i915_guc_load_status\n"); }
> +
> +static enum guc_status get_guc_status(void) {
> + char buf[LOAD_STATUS_BUF_SIZE];
> +
> + FILE *fp = fdopen(guc_status_fd, "r");
> + igt_assert_f(fp != NULL, "Can't open i915_guc_load_status file\n");
> +
> + while (fgets(buf, LOAD_STATUS_BUF_SIZE, fp))
> + if ((strstr(buf, "\tload: SUCCESS\n")))
> + return GUC_ENABLED;
> +
> + return GUC_DISABLED;
> +}
> +
> +static void close_guc_status(void)
> +{
> + close(guc_status_fd);
> +}
> +
> +static void test_guc_loaded()
> +{
> + igt_assert_f(get_guc_status() == GUC_ENABLED, "GuC is disabled\n");
> +}
> +
> +igt_main
> +{
> + int gfx_fd = 0;
> + int gen = 0;
> +
> + igt_fixture
> + {
> + gfx_fd = drm_open_driver(DRIVER_INTEL);
> + gen = intel_gen(intel_get_drm_devid(gfx_fd));
> + igt_require(gen >= 9);
> + open_guc_status();
> + }
> +
> + igt_subtest("guc_loaded") test_guc_loaded();
> +
> + igt_fixture close_guc_status();
> +}
> --
> 2.4.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Inte
[Intel-gfx] ✗ warning: Fi.CI.BAT
== Summary == Built on 058740f8fced6851aeda34f366f5330322cd585f drm-intel-nightly: 2016y-01m-13d-17h-07m-44s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: dmesg-warn -> PASS (bdw-nuci7) pass -> DMESG-WARN (bdw-ultra) Test kms_flip: Subgroup basic-flip-vs-modeset: pass -> DMESG-WARN (skl-i5k-2) Test kms_pipe_crc_basic: Subgroup read-crc-pipe-b: pass -> DMESG-WARN (ilk-hp8440p) bdw-nuci7total:138 pass:129 dwarn:0 dfail:0 fail:0 skip:9 bdw-ultratotal:138 pass:131 dwarn:1 dfail:0 fail:0 skip:6 bsw-nuc-2total:141 pass:115 dwarn:2 dfail:0 fail:0 skip:24 hsw-brixbox total:141 pass:134 dwarn:0 dfail:0 fail:0 skip:7 ilk-hp8440p total:141 pass:99 dwarn:5 dfail:0 fail:0 skip:37 ivb-t430stotal:135 pass:122 dwarn:3 dfail:4 fail:0 skip:6 skl-i5k-2total:141 pass:130 dwarn:3 dfail:0 fail:0 skip:8 skl-i7k-2total:141 pass:131 dwarn:2 dfail:0 fail:0 skip:8 snb-dellxps total:141 pass:122 dwarn:5 dfail:0 fail:0 skip:14 snb-x220ttotal:141 pass:122 dwarn:5 dfail:0 fail:1 skip:13 Results at /archive/results/CI_IGT_test/Patchwork_1180/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/11] drm/i915: Support for creating Stolen memory backed objects
On Thu, Jan 14, 2016 at 11:46:41AM +0530, ankitprasad.r.sha...@intel.com wrote: > From: Ankitprasad Sharma > > Extend the drm_i915_gem_create structure to add support for > creating Stolen memory backed objects. Added a new flag through > which user can specify the preference to allocate the object from > stolen memory, which if set, an attempt will be made to allocate > the object from stolen memory subject to the availability of > free space in the stolen region. > > v2: Rebased to the latest drm-intel-nightly (Ankit) > > v3: Changed versioning of GEM_CREATE param, added new comments (Tvrtko) > > v4: Changed size from 32b to 64b to prevent userspace overflow (Tvrtko) > Corrected function arguments ordering (Chris) > > v5: Corrected function name (Chris) > > v6: Updated datatype for flags to keep sizeof(drm_i915_gem_create) u64 > aligned (Chris) > > v7: Use first 8 bits of gem_create flags for placement (Chris), Add helper > function for object allocation from stolen region (Ankit) > > Testcase: igt/gem_stolen > > Signed-off-by: Ankitprasad Sharma Reviewed-by: Chris Wilson > + /** > + * Requested flags (currently used for placement > + * (which memory domain)) > + * > + * You can request that the object be created from special memory > + * rather than regular system pages using this parameter. Such > + * irregular objects may have certain restrictions (such as CPU > + * access to a stolen object is verboten). > + * > + * This can be used in the future for other purposes too > + * e.g. specifying tiling/caching/madvise > + */ > + __u64 flags; > +#define I915_CREATE_PLACEMENT_NORMAL 0 /* standard swappable bo */ > +#define I915_CREATE_PLACEMENT_STOLEN 1 /* Cannot use CPU mmaps */ /* Allocate the object from memory reserved for the igfx (stolen). * * Objects allocated from stolen are restricted in the API they can use, * as direct CPU access to stolen memory is prohibited by the system. * This means that you cannot use a regular CPU mmap (either using WB * or with the WC extension). You can still use a GTT mmap, pwrite, * pread and pass it around for use by execbuffer and between processes * like normal. * * Stolen memory is a very limited resource and certain functions of the * hardware can only work from within stolen memory. Userspace's * allocations may be evicted from stolen and moved to normal memory as * required. If the allocation is marked as purgeable (using madvise), * the allocation will be dropped and further access to the object's * backing storage will result in -EFAULT. Stolen objects will also be * migrated to normal memory across suspend and resume, as the stolen * memory is not preserved. * * Stolen memory is regarded as a resource placement hint, most suitable * for medium-sized buffers that are only accessed by the GPU and can be * discarded. */ -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/11] drm/i915: Propagating correct error codes to the userspace
On Thu, Jan 14, 2016 at 11:46:42AM +0530, ankitprasad.r.sha...@intel.com wrote:
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 6a429c0..b7dcd21 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -396,19 +396,18 @@ i915_gem_alloc_object_stolen(struct drm_device *dev,
> size_t size)
>
> mutex_lock(&dev->struct_mutex);
> obj = i915_gem_object_create_stolen(dev, size);
> - if (!obj) {
> - mutex_unlock(&dev->struct_mutex);
> - return NULL;
> - }
> + if (IS_ERR(obj))
> + goto out;
>
> /* Always clear fresh buffers before handing to userspace */
> ret = i915_gem_object_clear(obj);
> if (ret) {
> drm_gem_object_unreference(&obj->base);
> mutex_unlock(&dev->struct_mutex);
> - return NULL;
> + return ERR_PTR(ret);
ret = i915_gem_object_clear(obj);
if (ret) {
drm_gem_object_unreference(&obj->base);
obj = ERR_PTR(ret);
goto out;
}
> }
>
> +out:
> mutex_unlock(&dev->struct_mutex);
> return obj;
> }
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/dsi: lose the loose 666 format name in favor of packed
The enum mipi_dsi_pixel_format defines MIPI_DSI_FMT_RGB666 for the
"loose" 24 bpp format and MIPI_DSI_FMT_RGB666_PACKED for the 18 bpp
format. We have this the other way round, defining a loose version for
24 bpp.
Follow suit with what's in enum mipi_dsi_pixel_format to avoid future
confusion. Rename
VID_MODE_FORMAT_RGB666 -> VID_MODE_FORMAT_RGB666_PACKED
VID_MODE_FORMAT_RGB666_LOOSE -> VID_MODE_FORMAT_RGB666
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_reg.h| 4 ++--
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 2 +-
drivers/gpu/drm/i915/intel_dsi_pll.c | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0a988895165f..379c61677334 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7849,8 +7849,8 @@ enum skl_disp_power_wells {
#define VID_MODE_FORMAT_MASK (0xf << 7)
#define VID_MODE_NOT_SUPPORTED(0 << 7)
#define VID_MODE_FORMAT_RGB565(1 << 7)
-#define VID_MODE_FORMAT_RGB666(2 << 7)
-#define VID_MODE_FORMAT_RGB666_LOOSE (3 << 7)
+#define VID_MODE_FORMAT_RGB666_PACKED (2 << 7)
+#define VID_MODE_FORMAT_RGB666(3 << 7)
#define VID_MODE_FORMAT_RGB888(4 << 7)
#define CMD_MODE_CHANNEL_NUMBER_SHIFT 5
#define CMD_MODE_CHANNEL_NUMBER_MASK (3 << 5)
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 1d43e6f37fc1..3f4b9712bffd 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -420,7 +420,7 @@ struct drm_panel *vbt_panel_init(struct intel_dsi
*intel_dsi, u16 panel_id)
intel_dsi->dual_link = mipi_config->dual_link;
intel_dsi->pixel_overlap = mipi_config->pixel_overlap;
- if (intel_dsi->pixel_format == VID_MODE_FORMAT_RGB666)
+ if (intel_dsi->pixel_format == VID_MODE_FORMAT_RGB666_PACKED)
bits_per_pixel = 18;
else if (intel_dsi->pixel_format == VID_MODE_FORMAT_RGB565)
bits_per_pixel = 16;
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index bb5e95a1a453..f70df2b42b23 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -37,10 +37,10 @@ static int dsi_pixel_format_bpp(int pixel_format)
switch (pixel_format) {
default:
case VID_MODE_FORMAT_RGB888:
- case VID_MODE_FORMAT_RGB666_LOOSE:
+ case VID_MODE_FORMAT_RGB666:
bpp = 24;
break;
- case VID_MODE_FORMAT_RGB666:
+ case VID_MODE_FORMAT_RGB666_PACKED:
bpp = 18;
break;
case VID_MODE_FORMAT_RGB565:
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/dsi: start using enum mipi_dsi_pixel_format
A small step moving us closer to DRM MIPI DSI code. Use enum
mipi_dsi_pixel_format instead of our own. The first benefit is being
able to use common mipi_dsi_pixel_format_to_bpp().
There's a little back and forth conversion with the VBT -> enum ->
register, since we have just shoved the VBT value into the register
directly. Longer term, all the VBT parsing and deciphering should be
done in intel_bios.c, and abstracted there.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi.c | 19 +++-
drivers/gpu/drm/i915/intel_dsi.h | 8 +--
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 36 +-
drivers/gpu/drm/i915/intel_dsi_pll.c | 30 +
4 files changed, 54 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 91cef3525c93..83f18791c009 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -840,6 +840,23 @@ static void set_dsi_timings(struct drm_encoder *encoder,
}
}
+static u32 pixel_format_to_reg(enum mipi_dsi_pixel_format fmt)
+{
+ switch (fmt) {
+ case MIPI_DSI_FMT_RGB888:
+ return VID_MODE_FORMAT_RGB888;
+ case MIPI_DSI_FMT_RGB666:
+ return VID_MODE_FORMAT_RGB666;
+ case MIPI_DSI_FMT_RGB666_PACKED:
+ return VID_MODE_FORMAT_RGB666_PACKED;
+ case MIPI_DSI_FMT_RGB565:
+ return VID_MODE_FORMAT_RGB565;
+ default:
+ MISSING_CASE(fmt);
+ return VID_MODE_FORMAT_RGB666;
+ }
+}
+
static void intel_dsi_prepare(struct intel_encoder *intel_encoder)
{
struct drm_encoder *encoder = &intel_encoder->base;
@@ -910,7 +927,7 @@ static void intel_dsi_prepare(struct intel_encoder
*intel_encoder)
val |= intel_dsi->channel << VID_MODE_CHANNEL_NUMBER_SHIFT;
/* XXX: cross-check bpp vs. pixel format? */
- val |= intel_dsi->pixel_format;
+ val |= pixel_format_to_reg(intel_dsi->pixel_format);
}
tmp = 0;
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index de7be7f3fb42..54f072cd78f1 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -62,8 +62,12 @@ struct intel_dsi {
/* number of DSI lanes */
unsigned int lane_count;
- /* video mode pixel format for MIPI_DSI_FUNC_PRG register */
- u32 pixel_format;
+ /*
+* video mode pixel format
+*
+* XXX: consolidate on .format in struct mipi_dsi_device.
+*/
+ enum mipi_dsi_pixel_format pixel_format;
/* video mode format for MIPI_VIDEO_MODE_FORMAT register */
u32 video_mode_format;
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 3f4b9712bffd..9a963fa3491c 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -392,6 +392,25 @@ static const struct drm_panel_funcs vbt_panel_funcs = {
.get_modes = vbt_panel_get_modes,
};
+/* XXX: This should be done when parsing the VBT in intel_bios.c */
+static enum mipi_dsi_pixel_format pixel_format_from_vbt(u32 fmt)
+{
+ /* It just so happens the VBT matches register contents. */
+ switch (fmt) {
+ case VID_MODE_FORMAT_RGB888:
+ return MIPI_DSI_FMT_RGB888;
+ case VID_MODE_FORMAT_RGB666:
+ return MIPI_DSI_FMT_RGB666;
+ case VID_MODE_FORMAT_RGB666_PACKED:
+ return MIPI_DSI_FMT_RGB666_PACKED;
+ case VID_MODE_FORMAT_RGB565:
+ return MIPI_DSI_FMT_RGB565;
+ default:
+ MISSING_CASE(fmt);
+ return MIPI_DSI_FMT_RGB666;
+ }
+}
+
struct drm_panel *vbt_panel_init(struct intel_dsi *intel_dsi, u16 panel_id)
{
struct drm_device *dev = intel_dsi->base.base.dev;
@@ -400,7 +419,7 @@ struct drm_panel *vbt_panel_init(struct intel_dsi
*intel_dsi, u16 panel_id)
struct mipi_pps_data *pps = dev_priv->vbt.dsi.pps;
struct drm_display_mode *mode = dev_priv->vbt.lfp_lvds_vbt_mode;
struct vbt_panel *vbt_panel;
- u32 bits_per_pixel = 24;
+ u32 bpp;
u32 tlpx_ns, extra_byte_count, bitrate, tlpx_ui;
u32 ui_num, ui_den;
u32 prepare_cnt, exit_zero_cnt, clk_zero_cnt, trail_cnt;
@@ -416,15 +435,11 @@ struct drm_panel *vbt_panel_init(struct intel_dsi
*intel_dsi, u16 panel_id)
intel_dsi->eotp_pkt = mipi_config->eot_pkt_disabled ? 0 : 1;
intel_dsi->clock_stop = mipi_config->enable_clk_stop ? 1 : 0;
intel_dsi->lane_count = mipi_config->lane_cnt + 1;
- intel_dsi->pixel_format = mipi_config->videomode_color_format << 7;
+ intel_dsi->pixel_format =
pixel_format_from_vbt(mipi_config->videomode_color_format << 7);
+ bpp = mipi_dsi_pixel_format_to_bpp(intel_dsi->pixel_
Re: [Intel-gfx] [PATCH 01/11] drm/i915: Add support for mapping an object page by page
On 14/01/16 06:16, ankitprasad.r.sha...@intel.com wrote:
From: Chris Wilson
Introduced a new vm specfic callback insert_page() to program a single pte in
ggtt or ppgtt. This allows us to map a single page in to the mappable aperture
space. This can be iterated over to access the whole object by using space as
meagre as page size.
Signed-off-by: Chris Wilson
Signed-off-by: Ankitprasad Sharma
---
drivers/char/agp/intel-gtt.c| 9 +++
drivers/gpu/drm/i915/i915_gem_gtt.c | 49 +
drivers/gpu/drm/i915/i915_gem_gtt.h | 5
include/drm/intel-gtt.h | 3 +++
4 files changed, 66 insertions(+)
diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 1341a94..7c68576 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -838,6 +838,15 @@ static bool i830_check_flags(unsigned int flags)
return false;
}
+void intel_gtt_insert_page(dma_addr_t addr,
+ unsigned int pg,
+ unsigned int flags)
+{
+ intel_private.driver->write_entry(addr, pg, flags);
+ wmb();
+}
+EXPORT_SYMBOL(intel_gtt_insert_page);
+
void intel_gtt_insert_sg_entries(struct sg_table *st,
unsigned int pg_start,
unsigned int flags)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 56f4f2e..48bd6a4 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2339,6 +2339,23 @@ static void gen8_set_pte(void __iomem *addr, gen8_pte_t
pte)
#endif
}
+static void gen8_ggtt_insert_page(struct i915_address_space *vm,
+ dma_addr_t addr,
+ uint64_t offset,
+ enum i915_cache_level level,
+ u32 unused)
+{
+ struct drm_i915_private *dev_priv = to_i915(vm->dev);
+ gen8_pte_t __iomem *pte =
+ (gen8_pte_t __iomem *)dev_priv->gtt.gsm +
+ (offset >> PAGE_SHIFT);
+
+ gen8_set_pte(pte, gen8_pte_encode(addr, level, true));
+ wmb();
+
+ I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
+}
+
static void gen8_ggtt_insert_entries(struct i915_address_space *vm,
struct sg_table *st,
uint64_t start,
@@ -2410,6 +2427,23 @@ static void gen8_ggtt_insert_entries__BKL(struct
i915_address_space *vm,
stop_machine(gen8_ggtt_insert_entries__cb, &arg, NULL);
}
+static void gen6_ggtt_insert_page(struct i915_address_space *vm,
+ dma_addr_t addr,
+ uint64_t offset,
+ enum i915_cache_level level,
+ u32 flags)
+{
+ struct drm_i915_private *dev_priv = to_i915(vm->dev);
+ gen6_pte_t __iomem *pte =
+ (gen6_pte_t __iomem *)dev_priv->gtt.gsm +
+ (offset >> PAGE_SHIFT);
+
+ iowrite32(vm->pte_encode(addr, level, true, flags), pte);
+ wmb();
+
+ I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
+}
+
/*
* Binds an object into the global gtt with the specified cache level. The
object
* will be accessible to the GPU via commands whose operands reference offsets
@@ -2521,6 +2555,18 @@ static void gen6_ggtt_clear_range(struct
i915_address_space *vm,
assert_rpm_atomic_end(dev_priv, rpm_atomic_seq);
}
+static void i915_ggtt_insert_page(struct i915_address_space *vm,
+ dma_addr_t addr,
+ uint64_t offset,
+ enum i915_cache_level cache_level,
+ u32 unused)
+{
+ unsigned int flags = (cache_level == I915_CACHE_NONE) ?
+ AGP_USER_MEMORY : AGP_USER_CACHED_MEMORY;
+
+ intel_gtt_insert_page(addr, offset >> PAGE_SHIFT, flags);
+}
+
static void i915_ggtt_insert_entries(struct i915_address_space *vm,
struct sg_table *pages,
uint64_t start,
@@ -3050,6 +3096,7 @@ static int gen8_gmch_probe(struct drm_device *dev,
ret = ggtt_probe_common(dev, gtt_size);
dev_priv->gtt.base.clear_range = gen8_ggtt_clear_range;
+ dev_priv->gtt.base.insert_page = gen8_ggtt_insert_page;
dev_priv->gtt.base.insert_entries = gen8_ggtt_insert_entries;
dev_priv->gtt.base.bind_vma = ggtt_bind_vma;
dev_priv->gtt.base.unbind_vma = ggtt_unbind_vma;
@@ -3095,6 +3142,7 @@ static int gen6_gmch_probe(struct drm_device *dev,
ret = ggtt_probe_common(dev, gtt_size);
dev_priv->gtt.base.clear_range = gen6_ggtt_clear_range;
+ dev_priv->gtt.base.insert_page = gen6_ggtt_insert_page;
dev_priv->gtt.base.insert_entries = gen6_ggtt_insert_entries;
dev
Re: [Intel-gfx] [PATCH] drm/i915: Make sure DC writes are coherent on flush.
On Thu, 14 Jan 2016, Francisco Jerez wrote:
> We need to set the DC FLUSH PIPE_CONTROL bit on Gen7+ to guarantee
> that writes performed via the HDC are visible in memory. Fixes an
> intermittent failure in a Piglit test that writes to a BO from a
> shader using GL atomic counters (implemented as HDC untyped atomics)
> and then expects the memory to read back the same value after mapping
> it on the CPU.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91298
> Tested-by: Mark Janes
> Cc: Rodrigo Vivi
Francisco, this is missing your Signed-off-by i.e. developer certificate
of origin http://developercertificate.org/ - can't push without. Please
reply with that.
BR,
Jani.
> ---
> drivers/gpu/drm/i915/intel_lrc.c| 1 +
> drivers/gpu/drm/i915/intel_ringbuffer.c | 2 ++
> 2 files changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index ab344e0..02213c6 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1735,6 +1735,7 @@ static int gen8_emit_flush_render(struct
> drm_i915_gem_request *request,
> if (flush_domains) {
> flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
> flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
> + flags |= PIPE_CONTROL_DC_FLUSH_ENABLE;
> flags |= PIPE_CONTROL_FLUSH_ENABLE;
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 4060acf..8cd8aab 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -331,6 +331,7 @@ gen7_render_ring_flush(struct drm_i915_gem_request *req,
> if (flush_domains) {
> flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
> flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
> + flags |= PIPE_CONTROL_DC_FLUSH_ENABLE;
> flags |= PIPE_CONTROL_FLUSH_ENABLE;
> }
> if (invalidate_domains) {
> @@ -403,6 +404,7 @@ gen8_render_ring_flush(struct drm_i915_gem_request *req,
> if (flush_domains) {
> flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
> flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
> + flags |= PIPE_CONTROL_DC_FLUSH_ENABLE;
> flags |= PIPE_CONTROL_FLUSH_ENABLE;
> }
> if (invalidate_domains) {
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/11] drm/i915: Support for creating Stolen memory backed objects
On 14/01/16 10:24, Chris Wilson wrote: On Thu, Jan 14, 2016 at 11:46:41AM +0530, ankitprasad.r.sha...@intel.com wrote: From: Ankitprasad Sharma Extend the drm_i915_gem_create structure to add support for creating Stolen memory backed objects. Added a new flag through which user can specify the preference to allocate the object from stolen memory, which if set, an attempt will be made to allocate the object from stolen memory subject to the availability of free space in the stolen region. v2: Rebased to the latest drm-intel-nightly (Ankit) v3: Changed versioning of GEM_CREATE param, added new comments (Tvrtko) v4: Changed size from 32b to 64b to prevent userspace overflow (Tvrtko) Corrected function arguments ordering (Chris) v5: Corrected function name (Chris) v6: Updated datatype for flags to keep sizeof(drm_i915_gem_create) u64 aligned (Chris) v7: Use first 8 bits of gem_create flags for placement (Chris), Add helper function for object allocation from stolen region (Ankit) Testcase: igt/gem_stolen Signed-off-by: Ankitprasad Sharma Reviewed-by: Chris Wilson + /** +* Requested flags (currently used for placement +* (which memory domain)) +* +* You can request that the object be created from special memory +* rather than regular system pages using this parameter. Such +* irregular objects may have certain restrictions (such as CPU +* access to a stolen object is verboten). +* +* This can be used in the future for other purposes too +* e.g. specifying tiling/caching/madvise +*/ + __u64 flags; +#define I915_CREATE_PLACEMENT_NORMAL 0 /* standard swappable bo */ +#define I915_CREATE_PLACEMENT_STOLEN 1 /* Cannot use CPU mmaps */ /* Allocate the object from memory reserved for the igfx (stolen). * * Objects allocated from stolen are restricted in the API they can use, * as direct CPU access to stolen memory is prohibited by the system. * This means that you cannot use a regular CPU mmap (either using WB * or with the WC extension). You can still use a GTT mmap, pwrite, * pread and pass it around for use by execbuffer and between processes * like normal. What happens when a stolen batch buffer gets to relocate_entry_cpu ? * * Stolen memory is a very limited resource and certain functions of the * hardware can only work from within stolen memory. Userspace's * allocations may be evicted from stolen and moved to normal memory as * required. If the allocation is marked as purgeable (using madvise), * the allocation will be dropped and further access to the object's * backing storage will result in -EFAULT. Stolen objects will also be * migrated to normal memory across suspend and resume, as the stolen * memory is not preserved. * * Stolen memory is regarded as a resource placement hint, most suitable * for medium-sized buffers that are only accessed by the GPU and can be * discarded. */ Would it be better if the placement hint did not specifically mention stolen memory but specific limitations? Like, create.flags = NOT_A_BATCHBUFFER | DONT_NEED_MMAP_CPU ? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ success: Fi.CI.BAT
== Summary == Built on 058740f8fced6851aeda34f366f5330322cd585f drm-intel-nightly: 2016y-01m-13d-17h-07m-44s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: dmesg-warn -> PASS (skl-i7k-2) UNSTABLE Test kms_flip: Subgroup basic-flip-vs-dpms: dmesg-warn -> PASS (ilk-hp8440p) bdw-nuci7total:138 pass:128 dwarn:1 dfail:0 fail:0 skip:9 bdw-ultratotal:138 pass:132 dwarn:0 dfail:0 fail:0 skip:6 bsw-nuc-2total:141 pass:115 dwarn:2 dfail:0 fail:0 skip:24 hsw-brixbox total:141 pass:134 dwarn:0 dfail:0 fail:0 skip:7 ilk-hp8440p total:141 pass:101 dwarn:3 dfail:0 fail:0 skip:37 ivb-t430stotal:135 pass:122 dwarn:3 dfail:4 fail:0 skip:6 skl-i5k-2total:141 pass:131 dwarn:2 dfail:0 fail:0 skip:8 skl-i7k-2total:141 pass:132 dwarn:1 dfail:0 fail:0 skip:8 snb-dellxps total:141 pass:122 dwarn:5 dfail:0 fail:0 skip:14 snb-x220ttotal:141 pass:122 dwarn:5 dfail:0 fail:1 skip:13 Results at /archive/results/CI_IGT_test/Patchwork_1181/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Clear pending reset requests during suspend
Pending reset requests are cleared before suspending, they should be picked up after resume when new work is submitted. This is originally added as part of TDR patches for Gen8 from Tomas Elf which are under review, as suggested by Chris this is extracted as a separate patch as it can be useful now. Cc: Mika Kuoppala Cc: Chris Wilson Signed-off-by: Arun Siluvery --- drivers/gpu/drm/i915/i915_drv.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index f17a2b0..09ed83e 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -594,6 +594,13 @@ static int i915_drm_suspend(struct drm_device *dev) goto out; } + /* +* Clear any pending reset requests. They should be picked up +* after resume when new work is submitted +*/ + atomic_clear_mask(I915_RESET_IN_PROGRESS_FLAG, + &dev_priv->gpu_error.reset_counter); + intel_guc_suspend(dev); intel_suspend_gt_powersave(dev); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/11] drm/i915: Support for pread/pwrite from/to non shmem backed objects
On Thu, Jan 14, 2016 at 11:46:44AM +0530, ankitprasad.r.sha...@intel.com wrote:
> From: Ankitprasad Sharma
>
> This patch adds support for extending the pread/pwrite functionality
> for objects not backed by shmem. The access will be made through
> gtt interface. This will cover objects backed by stolen memory as well
> as other non-shmem backed objects.
>
> v2: Drop locks around slow_user_access, prefault the pages before
> access (Chris)
>
> v3: Rebased to the latest drm-intel-nightly (Ankit)
>
> v4: Moved page base & offset calculations outside the copy loop,
> corrected data types for size and offset variables, corrected if-else
> braces format (Tvrtko/kerneldocs)
>
> v5: Enabled pread/pwrite for all non-shmem backed objects including
> without tiling restrictions (Ankit)
>
> v6: Using pwrite_fast for non-shmem backed objects as well (Chris)
>
> v7: Updated commit message, Renamed i915_gem_gtt_read to i915_gem_gtt_copy,
> added pwrite slow path for non-shmem backed objects (Chris/Tvrtko)
>
> v8: Updated v7 commit message, mutex unlock around pwrite slow path for
> non-shmem backed objects (Tvrtko)
>
> v9: Corrected check during pread_ioctl, to avoid shmem_pread being
> called for non-shmem backed objects (Tvrtko)
>
> v10: Moved the write_domain check to needs_clflush and tiling mode check
> to pwrite_fast (Chris)
>
> v11: Use pwrite_fast fallback for all objects (shmem and non-shmem backed),
> call fast_user_write regardless of pagefault in previous iteration
>
> Testcase: igt/gem_stolen
Presumably igt/gem_pread and igt/gem_pwrite didn't break?
We could with the help of say vgem create a few 1+GiB objects that have
no obj->base.filp and so stress the pinning code better. (Or even just
stolen on some machines would be enough to create an unmappable object.)
> Signed-off-by: Ankitprasad Sharma
> ---
> drivers/gpu/drm/i915/i915_gem.c | 155
> +---
> 1 file changed, 129 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 7642b1b..ab1d043 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -55,6 +55,9 @@ static bool cpu_cache_is_coherent(struct drm_device *dev,
>
> static bool cpu_write_needs_clflush(struct drm_i915_gem_object *obj)
> {
> + if (obj->base.write_domain == I915_GEM_DOMAIN_CPU)
> + return false;
> +
> if (!cpu_cache_is_coherent(obj->base.dev, obj->cache_level))
> return true;
>
> @@ -646,6 +649,99 @@ shmem_pread_slow(struct page *page, int
> shmem_page_offset, int page_length,
> return ret ? - EFAULT : 0;
> }
>
> +static inline uint64_t
> +slow_user_access(struct io_mapping *mapping,
> + uint64_t page_base, int page_offset,
> + char __user *user_data,
> + int length, bool pwrite)
static inline bool
> +{
> + void __iomem *vaddr_inatomic;
inatomic? We are not!
void __iomem *ioaddr;
void *vaddr;
> + void *vaddr;
> + uint64_t unwritten;
> +
> + vaddr_inatomic = io_mapping_map_wc(mapping, page_base);
> + /* We can use the cpu mem copy function because this is X86. */
> + vaddr = (void __force *)vaddr_inatomic + page_offset;
> + if (pwrite)
> + unwritten = __copy_from_user(vaddr, user_data, length);
> + else
> + unwritten = __copy_to_user(user_data, vaddr, length);
> +
> + io_mapping_unmap(vaddr_inatomic);
> + return unwritten;
> +}
> +
> +static int
> +i915_gem_gtt_copy(struct drm_device *dev,
> +struct drm_i915_gem_object *obj, uint64_t size,
> +uint64_t data_offset, uint64_t data_ptr)
> +{
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + char __user *user_data;
> + uint64_t remain;
> + uint64_t offset, page_base;
> + int page_offset, page_length, ret = 0;
> +
> + ret = i915_gem_obj_ggtt_pin(obj, 0, PIN_MAPPABLE);
> + if (ret)
> + goto out;
> +
> + ret = i915_gem_object_set_to_gtt_domain(obj, false);
> + if (ret)
> + goto out_unpin;
> +
> + ret = i915_gem_object_put_fence(obj);
> + if (ret)
> + goto out_unpin;
> +
> + user_data = to_user_ptr(data_ptr);
> + remain = size;
> + offset = i915_gem_obj_ggtt_offset(obj) + data_offset;
> +
> + mutex_unlock(&dev->struct_mutex);
> + if (likely(!i915.prefault_disable))
> + ret = fault_in_multipages_writeable(user_data, remain);
> +
> + /*
> + * page_offset = offset within page
> + * page_base = page offset within aperture
> + */
> + page_offset = offset_in_page(offset);
> + page_base = offset & PAGE_MASK;
Where's the page-by-page copy? (Think about objects larger than the
aperture, or trying to operate in parallel with many - pinning aperture
space is bad practice.)
> + while (remain > 0) {
> + /* page_length = bytes to copy for this page */
Re: [Intel-gfx] [PATCH 09/11] drm/i915: Migrate stolen objects before hibernation
On Thu, Jan 14, 2016 at 11:46:45AM +0530, ankitprasad.r.sha...@intel.com wrote: > From: Chris Wilson > > Ville reminded us that stolen memory is not preserved across > hibernation, and a result of this was that context objects now being > allocated from stolen were being corrupted on S4 and promptly hanging > the GPU on resume. > > We want to utilise stolen for as much as possible (nothing else will use > that wasted memory otherwise), so we need a strategy for handling > general objects allocated from stolen and hibernation. A simple solution > is to do a CPU copy through the GTT of the stolen object into a fresh > shmemfs backing store and thenceforth treat it as a normal objects. This > can be refined in future to either use a GPU copy to avoid the slow > uncached reads (though it's hibernation!) and recreate stolen objects > upon resume/first-use. For now, a simple approach should suffice for > testing the object migration. > > v2: > Swap PTE for pinned bindings over to the shmemfs. This adds a > complicated dance, but is required as many stolen objects are likely to > be pinned for use by the hardware. Swapping the PTEs should not result > in externally visible behaviour, as each PTE update should be atomic and > the two pages identical. (danvet) > > safe-by-default, or the principle of least surprise. We need a new flag > to mark objects that we can wilfully discard and recreate across > hibernation. (danvet) > > Just use the global_list rather than invent a new stolen_list. This is > the slowpath hibernate and so adding a new list and the associated > complexity isn't worth it. > > v3: Rebased on drm-intel-nightly (Ankit) > > v4: Use insert_page to map stolen memory backed pages for migration to > shmem (Chris) > > v5: Acquire mutex lock while copying stolen buffer objects to shmem (Chris) > > v6: Handled file leak, Splitted object migration function, added kerneldoc > for migrate_stolen_to_shmemfs() function (Tvrtko) > Use i915 wrapper function for drm_mm_insert_node_in_range() > > v7: Keep the object in cpu domain after get_pages, remove the object from > the unbound list only when marked PURGED, Corrected split of object migration > function (Chris) > > v8: Split i915_gem_freeze(), removed redundant use of barrier, corrected > use of set_to_cpu_domain() (Chris) > > v9: Replaced WARN_ON by BUG_ON and added a comment explaining it (Tvrtko) I read Daniel's comment as this should be BUG_ON. It is machine death. A way for userspace to engineer writes to unowned pages. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: add onoff utility function
Add a common function to return "on" or "off" string based on the
argument, and drop the local versions of it.
This is the onoff version of
commit 42a8ca4cb4a48ddbf40e8edb291425e76bcdc230
Author: Jani Nikula
Date: Thu Aug 27 16:23:30 2015 +0300
drm/i915: add yesno utility function
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.c | 6 +++---
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers/gpu/drm/i915/intel_display.c | 30 --
drivers/gpu/drm/i915/intel_dp.c | 9 ++---
drivers/gpu/drm/i915/intel_pm.c | 11 +--
5 files changed, 27 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index f17a2b0c2493..975af3568521 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1335,8 +1335,8 @@ static int vlv_wait_for_gt_wells(struct drm_i915_private
*dev_priv,
return 0;
DRM_DEBUG_KMS("waiting for GT wells to go %s (%08x)\n",
- wait_for_on ? "on" : "off",
- I915_READ(VLV_GTLC_PW_STATUS));
+ onoff(wait_for_on),
+ I915_READ(VLV_GTLC_PW_STATUS));
/*
* RC6 transitioning can be delayed up to 2 msec (see
@@ -1345,7 +1345,7 @@ static int vlv_wait_for_gt_wells(struct drm_i915_private
*dev_priv,
err = wait_for(COND, 3);
if (err)
DRM_ERROR("timeout waiting for GT wells to go %s\n",
- wait_for_on ? "on" : "off");
+ onoff(wait_for_on));
return err;
#undef COND
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 104bd1809936..eb7bb97f7316 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -102,6 +102,11 @@ static inline const char *yesno(bool v)
return v ? "yes" : "no";
}
+static inline const char *onoff(bool v)
+{
+ return v ? "on" : "off";
+}
+
enum pipe {
INVALID_PIPE = -1,
PIPE_A = 0,
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a087892dd797..0f52f71402a0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1150,11 +1150,6 @@ static void intel_wait_for_pipe_off(struct intel_crtc
*crtc)
}
}
-static const char *state_string(bool enabled)
-{
- return enabled ? "on" : "off";
-}
-
/* Only for pre-ILK configs */
void assert_pll(struct drm_i915_private *dev_priv,
enum pipe pipe, bool state)
@@ -1166,7 +1161,7 @@ void assert_pll(struct drm_i915_private *dev_priv,
cur_state = !!(val & DPLL_VCO_ENABLE);
I915_STATE_WARN(cur_state != state,
"PLL state assertion failure (expected %s, current %s)\n",
-state_string(state), state_string(cur_state));
+ onoff(state), onoff(cur_state));
}
/* XXX: the dsi pll is shared between MIPI DSI ports */
@@ -1182,7 +1177,7 @@ static void assert_dsi_pll(struct drm_i915_private
*dev_priv, bool state)
cur_state = val & DSI_PLL_VCO_EN;
I915_STATE_WARN(cur_state != state,
"DSI PLL state assertion failure (expected %s, current %s)\n",
-state_string(state), state_string(cur_state));
+ onoff(state), onoff(cur_state));
}
#define assert_dsi_pll_enabled(d) assert_dsi_pll(d, true)
#define assert_dsi_pll_disabled(d) assert_dsi_pll(d, false)
@@ -1206,14 +1201,13 @@ void assert_shared_dpll(struct drm_i915_private
*dev_priv,
bool cur_state;
struct intel_dpll_hw_state hw_state;
- if (WARN (!pll,
- "asserting DPLL %s with no DPLL\n", state_string(state)))
+ if (WARN(!pll, "asserting DPLL %s with no DPLL\n", onoff(state)))
return;
cur_state = pll->get_hw_state(dev_priv, pll, &hw_state);
I915_STATE_WARN(cur_state != state,
"%s assertion failure (expected %s, current %s)\n",
-pll->name, state_string(state), state_string(cur_state));
+ pll->name, onoff(state), onoff(cur_state));
}
static void assert_fdi_tx(struct drm_i915_private *dev_priv,
@@ -1233,7 +1227,7 @@ static void assert_fdi_tx(struct drm_i915_private
*dev_priv,
}
I915_STATE_WARN(cur_state != state,
"FDI TX state assertion failure (expected %s, current %s)\n",
-state_string(state), state_string(cur_state));
+ onoff(state), onoff(cur_state));
}
#define assert_fdi_tx_enabled(d, p) assert_fdi_tx(d, p, true)
#define assert_fdi_tx_disabled(d, p) assert_fdi_tx(d, p, false)
@@ -1248,7 +1242,7 @@ static void assert_fdi_rx(struct drm_i915_private
*dev_priv,
cur_state = !!(val & FDI_RX_ENABLE);
I915_STATE_WARN(cur_state != state,
"FDI RX state assertion failure (expected %s, current %s)\n",
-
[Intel-gfx] [PATCH igt] igt/gem_softpin: Remove false dependencies on esoteric features
For softpinning, we do not require either userptr or extended ppgtt, so
remove those requirements and make the tests work universally. (Certain
ABI tests require large GTT, or per-process GTT.)
In the process, make the tests more extensive - validate overlapping
handling more careful, explicitly test no-relocation support, validate
more ABI handling. And for fun, cause a kernel GPF.
Signed-off-by: Chris Wilson
---
tests/gem_softpin.c | 1313 +--
1 file changed, 324 insertions(+), 989 deletions(-)
diff --git a/tests/gem_softpin.c b/tests/gem_softpin.c
index 1cbde4e..f188559 100644
--- a/tests/gem_softpin.c
+++ b/tests/gem_softpin.c
@@ -26,80 +26,10 @@
*
*/
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include "drm.h"
-#include "ioctl_wrappers.h"
-#include "drmtest.h"
-#include "intel_chipset.h"
-#include "intel_io.h"
-#include "i915_drm.h"
-#include
-#include
-#include
-#include
-#include "igt_kms.h"
-#include
-#include
-#include
-
-#define BO_SIZE 4096
-#define MULTIPAGE_BO_SIZE 2 * BO_SIZE
-#define STORE_BATCH_BUFFER_SIZE 4
+#include "igt.h"
+
#define EXEC_OBJECT_PINNED (1<<4)
#define EXEC_OBJECT_SUPPORTS_48B_ADDRESS (1<<3)
-#define SHARED_BUFFER_SIZE 4096
-
-typedef struct drm_i915_gem_userptr i915_gem_userptr;
-
-static uint32_t init_userptr(int fd, i915_gem_userptr *, void *ptr, uint64_t
size);
-static void *create_mem_buffer(uint64_t size);
-static int gem_call_userptr_ioctl(int fd, i915_gem_userptr *userptr);
-static void gem_pin_userptr_test(void);
-static void gem_pin_bo_test(void);
-static void gem_pin_invalid_vma_test(bool test_decouple_flags, bool
test_canonical_offset);
-static void gem_pin_overlap_test(void);
-static void gem_pin_high_address_test(void);
-
-#define NO_PPGTT 0
-#define ALIASING_PPGTT 1
-#define FULL_32_BIT_PPGTT 2
-#define FULL_48_BIT_PPGTT 3
-/* uses_full_ppgtt
- * Finds supported PPGTT details.
- * @fd DRM fd
- * @min can be
- * 0 - No PPGTT
- * 1 - Aliasing PPGTT
- * 2 - Full PPGTT (32b)
- * 3 - Full PPGTT (48b)
- * RETURNS true/false if min support is present
-*/
-static bool uses_full_ppgtt(int fd, int min)
-{
- struct drm_i915_getparam gp;
- int val = 0;
-
- memset(&gp, 0, sizeof(gp));
- gp.param = 18; /* HAS_ALIASING_PPGTT */
- gp.value = &val;
-
- if (drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, &gp))
- return 0;
-
- errno = 0;
- return val >= min;
-}
/* has_softpin_support
* Finds if softpin feature is supported
@@ -121,83 +51,6 @@ static bool has_softpin_support(int fd)
return (val == 1);
}
-/* gem_call_userptr_ioctl
- * Helper to call ioctl - TODO: move to lib
- * @fd - drm fd
- * @userptr - pointer to initialised userptr
- * RETURNS status of ioctl call
-*/
-static int gem_call_userptr_ioctl(int fd, i915_gem_userptr *userptr)
-{
- int ret;
-
- ret = drmIoctl(fd, DRM_IOCTL_I915_GEM_USERPTR, userptr);
-
- if (ret)
- ret = errno;
-
- return ret;
-}
-
-/* init_userptr
- * Helper that inits userptr an returns handle
- * @fd - drm fd
- * @userptr - pointer to empty userptr
- * @ptr - buffer to be shared
- * @size - size of buffer
- * @ro - read only flag
- * RETURNS handle to shared buffer
-*/
-static uint32_t init_userptr(int fd, i915_gem_userptr *userptr, void *ptr,
-uint64_t size)
-{
- int ret;
-
- memset((void*)userptr, 0, sizeof(i915_gem_userptr));
-
- userptr->user_ptr = (unsigned long)ptr; /* Need the cast to overcome
compiler warning */
- userptr->user_size = size;
- userptr->flags = 0; /* use synchronized operation */
-
- ret = gem_call_userptr_ioctl(fd, userptr);
- igt_assert_eq(ret, 0);
-
- return userptr->handle;
-}
-
-/* create_mem_buffer
- * Creates a 4K aligned CPU buffer
- * @size - size of buffer
- * RETURNS pointer to buffer of @size
-*/
-static void *create_mem_buffer(uint64_t size)
-{
- void *addr;
- int ret;
-
- ret = posix_memalign(&addr, 4096, size);
- igt_assert(ret == 0);
-
- return addr;
-}
-
-/* setup_exec_obj
- * populate exec object
- * @exec - exec object
- * @handle - handle to gem buffer
- * @flags - any flags
- * @offset - requested VMA
-*/
-static void setup_exec_obj(struct drm_i915_gem_exec_object2 *exec,
- uint32_t handle, uint32_t flags,
- uint64_t offset)
-{
- memset(exec, 0, sizeof(struct drm_i915_gem_exec_object2));
- exec->handle = handle;
- exec->flags = flags;
- exec->offset = offset;
-}
-
/* gen8_canonical_addr
* Used to convert any address into canonical form, i.e. [63:48] == [47].
* Based on kernel's sign_extend64 implementation.
@@ -210,904 +63,386 @@ static uint64_t gen8_canonical_addr(uint64_t address)
return (__s64)(address << shift) >> shift;
}
-/* gem_store_data
Re: [Intel-gfx] [PATCH] drm/i915: Clear pending reset requests during suspend
Hi Arun,
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on v4.4 next-20160114]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Arun-Siluvery/drm-i915-Clear-pending-reset-requests-during-suspend/20160114-185121
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-x010-01140842 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
drivers/gpu/drm/i915/i915_drv.c: In function 'i915_drm_suspend':
>> drivers/gpu/drm/i915/i915_drv.c:601:2: warning: 'atomic_clear_mask' is
>> deprecated [-Wdeprecated-declarations]
atomic_clear_mask(I915_RESET_IN_PROGRESS_FLAG,
^
In file included from include/linux/debug_locks.h:5:0,
from include/linux/lockdep.h:23,
from include/linux/spinlock_types.h:18,
from include/linux/mutex.h:15,
from include/linux/kernfs.h:13,
from include/linux/sysfs.h:15,
from include/linux/kobject.h:21,
from include/linux/device.h:17,
from drivers/gpu/drm/i915/i915_drv.c:30:
include/linux/atomic.h:458:33: note: declared here
static inline __deprecated void atomic_clear_mask(unsigned int mask,
atomic_t *v)
^
vim +/atomic_clear_mask +601 drivers/gpu/drm/i915/i915_drv.c
585
586 drm_kms_helper_poll_disable(dev);
587
588 pci_save_state(dev->pdev);
589
590 error = i915_gem_suspend(dev);
591 if (error) {
592 dev_err(&dev->pdev->dev,
593 "GEM idle failed, resume might fail\n");
594 goto out;
595 }
596
597 /*
598 * Clear any pending reset requests. They should be picked up
599 * after resume when new work is submitted
600 */
> 601 atomic_clear_mask(I915_RESET_IN_PROGRESS_FLAG,
602&dev_priv->gpu_error.reset_counter);
603
604 intel_guc_suspend(dev);
605
606 intel_suspend_gt_powersave(dev);
607
608 /*
609 * Disable CRTCs directly since we want to preserve sw state
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/11] drm/i915: Support for creating Stolen memory backed objects
On Thu, Jan 14, 2016 at 10:46:39AM +, Tvrtko Ursulin wrote: > > On 14/01/16 10:24, Chris Wilson wrote: > >On Thu, Jan 14, 2016 at 11:46:41AM +0530, ankitprasad.r.sha...@intel.com > >wrote: > >>From: Ankitprasad Sharma > >> > >>Extend the drm_i915_gem_create structure to add support for > >>creating Stolen memory backed objects. Added a new flag through > >>which user can specify the preference to allocate the object from > >>stolen memory, which if set, an attempt will be made to allocate > >>the object from stolen memory subject to the availability of > >>free space in the stolen region. > >> > >>v2: Rebased to the latest drm-intel-nightly (Ankit) > >> > >>v3: Changed versioning of GEM_CREATE param, added new comments (Tvrtko) > >> > >>v4: Changed size from 32b to 64b to prevent userspace overflow (Tvrtko) > >>Corrected function arguments ordering (Chris) > >> > >>v5: Corrected function name (Chris) > >> > >>v6: Updated datatype for flags to keep sizeof(drm_i915_gem_create) u64 > >>aligned (Chris) > >> > >>v7: Use first 8 bits of gem_create flags for placement (Chris), Add helper > >>function for object allocation from stolen region (Ankit) > >> > >>Testcase: igt/gem_stolen > >> > >>Signed-off-by: Ankitprasad Sharma > > > >Reviewed-by: Chris Wilson > > > >>+ /** > >>+* Requested flags (currently used for placement > >>+* (which memory domain)) > >>+* > >>+* You can request that the object be created from special memory > >>+* rather than regular system pages using this parameter. Such > >>+* irregular objects may have certain restrictions (such as CPU > >>+* access to a stolen object is verboten). > >>+* > >>+* This can be used in the future for other purposes too > >>+* e.g. specifying tiling/caching/madvise > >>+*/ > >>+ __u64 flags; > >>+#define I915_CREATE_PLACEMENT_NORMAL 0 /* standard swappable bo */ > >>+#define I915_CREATE_PLACEMENT_STOLEN 1 /* Cannot use CPU mmaps */ > > > >/* Allocate the object from memory reserved for the igfx (stolen). > > * > > * Objects allocated from stolen are restricted in the API they can use, > > * as direct CPU access to stolen memory is prohibited by the system. > > * This means that you cannot use a regular CPU mmap (either using WB > > * or with the WC extension). You can still use a GTT mmap, pwrite, > > * pread and pass it around for use by execbuffer and between processes > > * like normal. > > What happens when a stolen batch buffer gets to relocate_entry_cpu ? The kernel goes bang. It is easy to fix. To cover all corner cases, such as the stolen object being larger than the mappable aperture, requires the insert-page routines though. > > * Stolen memory is a very limited resource and certain functions of the > > * hardware can only work from within stolen memory. Userspace's > > * allocations may be evicted from stolen and moved to normal memory as > > * required. If the allocation is marked as purgeable (using madvise), > > * the allocation will be dropped and further access to the object's > > * backing storage will result in -EFAULT. Stolen objects will also be > > * migrated to normal memory across suspend and resume, as the stolen > > * memory is not preserved. > > * > > * Stolen memory is regarded as a resource placement hint, most suitable > > * for medium-sized buffers that are only accessed by the GPU and can be > > * discarded. > > */ > > Would it be better if the placement hint did not specifically > mention stolen memory but specific limitations? Like, It is a nice idea, but it doesn't really fit with the other placement domains I have sketched out (they are all fully featured, or nearly so, but exist in different pools of memory with different characteristics and reasons for choice). -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Clear pending reset requests during suspend
On Thu, Jan 14, 2016 at 10:49:45AM +, Arun Siluvery wrote: > Pending reset requests are cleared before suspending, they should be picked up > after resume when new work is submitted. > > This is originally added as part of TDR patches for Gen8 from Tomas Elf which > are under review, as suggested by Chris this is extracted as a separate patch > as it can be useful now. > > Cc: Mika Kuoppala > Cc: Chris Wilson > Signed-off-by: Arun Siluvery > --- > drivers/gpu/drm/i915/i915_drv.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > index f17a2b0..09ed83e 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -594,6 +594,13 @@ static int i915_drm_suspend(struct drm_device *dev) > goto out; > } > > + /* > + * Clear any pending reset requests. They should be picked up > + * after resume when new work is submitted > + */ > + atomic_clear_mask(I915_RESET_IN_PROGRESS_FLAG, > + &dev_priv->gpu_error.reset_counter); > + The comment is slightly wrong. When the error tasklet in progress sees that the flag is unset, it return (i.e. doesn't perform the reset). This is ok, because we are putting the device to PCI_D3, we are powering it down which should be our ultimate reset. So no need for the reset on resume. Except We do need to clean up the bookkeeping. Hmm. so what we need to do is actually flush the reset task, and pretend it succeeded. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ failure: Fi.CI.BAT
== Summary == Built on 058740f8fced6851aeda34f366f5330322cd585f drm-intel-nightly: 2016y-01m-13d-17h-07m-44s UTC integration manifest Test gem_pread: Subgroup basic: pass -> FAIL (snb-dellxps) Test gem_pwrite: Subgroup basic: pass -> FAIL (snb-dellxps) Test kms_flip: Subgroup basic-flip-vs-dpms: dmesg-warn -> PASS (ilk-hp8440p) bdw-ultratotal:138 pass:132 dwarn:0 dfail:0 fail:0 skip:6 bsw-nuc-2total:141 pass:115 dwarn:2 dfail:0 fail:0 skip:24 hsw-brixbox total:141 pass:134 dwarn:0 dfail:0 fail:0 skip:7 ilk-hp8440p total:141 pass:101 dwarn:3 dfail:0 fail:0 skip:37 ivb-t430stotal:135 pass:122 dwarn:3 dfail:4 fail:0 skip:6 skl-i5k-2total:141 pass:131 dwarn:2 dfail:0 fail:0 skip:8 skl-i7k-2total:141 pass:131 dwarn:2 dfail:0 fail:0 skip:8 snb-dellxps total:141 pass:120 dwarn:5 dfail:0 fail:2 skip:14 snb-x220ttotal:141 pass:122 dwarn:5 dfail:0 fail:1 skip:13 Results at /archive/results/CI_IGT_test/Patchwork_1182/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/11] drm/i915: Support for creating Stolen memory backed objects
On 14/01/16 11:14, Chris Wilson wrote: On Thu, Jan 14, 2016 at 10:46:39AM +, Tvrtko Ursulin wrote: On 14/01/16 10:24, Chris Wilson wrote: On Thu, Jan 14, 2016 at 11:46:41AM +0530, ankitprasad.r.sha...@intel.com wrote: From: Ankitprasad Sharma Extend the drm_i915_gem_create structure to add support for creating Stolen memory backed objects. Added a new flag through which user can specify the preference to allocate the object from stolen memory, which if set, an attempt will be made to allocate the object from stolen memory subject to the availability of free space in the stolen region. v2: Rebased to the latest drm-intel-nightly (Ankit) v3: Changed versioning of GEM_CREATE param, added new comments (Tvrtko) v4: Changed size from 32b to 64b to prevent userspace overflow (Tvrtko) Corrected function arguments ordering (Chris) v5: Corrected function name (Chris) v6: Updated datatype for flags to keep sizeof(drm_i915_gem_create) u64 aligned (Chris) v7: Use first 8 bits of gem_create flags for placement (Chris), Add helper function for object allocation from stolen region (Ankit) Testcase: igt/gem_stolen Signed-off-by: Ankitprasad Sharma Reviewed-by: Chris Wilson + /** +* Requested flags (currently used for placement +* (which memory domain)) +* +* You can request that the object be created from special memory +* rather than regular system pages using this parameter. Such +* irregular objects may have certain restrictions (such as CPU +* access to a stolen object is verboten). +* +* This can be used in the future for other purposes too +* e.g. specifying tiling/caching/madvise +*/ + __u64 flags; +#define I915_CREATE_PLACEMENT_NORMAL 0 /* standard swappable bo */ +#define I915_CREATE_PLACEMENT_STOLEN 1 /* Cannot use CPU mmaps */ /* Allocate the object from memory reserved for the igfx (stolen). * * Objects allocated from stolen are restricted in the API they can use, * as direct CPU access to stolen memory is prohibited by the system. * This means that you cannot use a regular CPU mmap (either using WB * or with the WC extension). You can still use a GTT mmap, pwrite, * pread and pass it around for use by execbuffer and between processes * like normal. What happens when a stolen batch buffer gets to relocate_entry_cpu ? The kernel goes bang. It is easy to fix. To cover all corner cases, such as the stolen object being larger than the mappable aperture, requires the insert-page routines though. I know, I keep pointing it out. :/ * Stolen memory is a very limited resource and certain functions of the * hardware can only work from within stolen memory. Userspace's * allocations may be evicted from stolen and moved to normal memory as * required. If the allocation is marked as purgeable (using madvise), * the allocation will be dropped and further access to the object's * backing storage will result in -EFAULT. Stolen objects will also be * migrated to normal memory across suspend and resume, as the stolen * memory is not preserved. * * Stolen memory is regarded as a resource placement hint, most suitable * for medium-sized buffers that are only accessed by the GPU and can be * discarded. */ Would it be better if the placement hint did not specifically mention stolen memory but specific limitations? Like, It is a nice idea, but it doesn't really fit with the other placement domains I have sketched out (they are all fully featured, or nearly so, but exist in different pools of memory with different characteristics and reasons for choice). Perhaps these pools have some characteristics which could be described abstractly? I am of course coming back to why would userspace have to know about stolen, why would we fail object creation if there is no space, and then move objects out of stolen on hibernate and never put them back. Sounds like a bad and inflexible interface, and a lying kernel to me. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ failure: Fi.CI.BAT
On 14/01/2016 07:20, Patchwork wrote: == Summary == Built on 058740f8fced6851aeda34f366f5330322cd585f drm-intel-nightly: 2016y-01m-13d-17h-07m-44s UTC integration manifest Test gem_ctx_basic: pass -> FAIL (bdw-ultra) Test failed to load - not patch related Test gem_ctx_param_basic: Subgroup non-root-set: pass -> DMESG-WARN (bsw-nuc-2) gem driver allocated a poisoned slab - not patch related Test kms_flip: Subgroup basic-flip-vs-dpms: pass -> SKIP (bsw-nuc-2) test reqs not met - not patch related dmesg-warn -> PASS (ilk-hp8440p) warn to PASS bdw-nuci7total:138 pass:128 dwarn:1 dfail:0 fail:0 skip:9 bdw-ultratotal:138 pass:131 dwarn:0 dfail:0 fail:1 skip:6 bsw-nuc-2total:141 pass:113 dwarn:3 dfail:0 fail:0 skip:25 hsw-brixbox total:141 pass:134 dwarn:0 dfail:0 fail:0 skip:7 hsw-gt2 total:141 pass:137 dwarn:0 dfail:0 fail:0 skip:4 ilk-hp8440p total:141 pass:101 dwarn:3 dfail:0 fail:0 skip:37 ivb-t430stotal:135 pass:122 dwarn:3 dfail:4 fail:0 skip:6 skl-i5k-2total:141 pass:131 dwarn:2 dfail:0 fail:0 skip:8 skl-i7k-2total:141 pass:131 dwarn:2 dfail:0 fail:0 skip:8 snb-dellxps total:141 pass:122 dwarn:5 dfail:0 fail:0 skip:14 snb-x220ttotal:141 pass:122 dwarn:5 dfail:0 fail:1 skip:13 Results at /archive/results/CI_IGT_test/Patchwork_1174/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v3] Add a lib for power management helpers
This patch aims to create a separate lib for power management related helpers. Initially it only contains code that modify settings for external components (to handle components with default settings that prevents entering deeper sleep states), but moving i915-related power management helpers to this lib would probably make sense too. v2: Change name of library to igt_pm Namespace all exported functions with igt_pm_ v3: Various fixes based on feedback from Thomas Wood David Weinehall (1): lib/igt_pm: Lib for power management .../intel-gpu-tools/intel-gpu-tools-docs.xml | 1 + lib/Makefile.sources | 2 + lib/igt.h | 1 + lib/igt_aux.c | 15 +- lib/igt_pm.c | 233 + lib/igt_pm.h | 31 +++ tests/pm_lpsp.c| 25 +-- tests/pm_rpm.c | 40 +--- 8 files changed, 281 insertions(+), 67 deletions(-) create mode 100644 lib/igt_pm.c create mode 100644 lib/igt_pm.h -- 2.7.0.rc3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v3] lib/igt_pm: Lib for power management
Move power management related code to a separate library.
Initially this is done only for workarounds that apply to external
components. Modify the users of such workarounds accordingly.
This currently involves HD audio and SATA link power management.
For SATA link PM there's also code to save the previous settings,
to allow for resetting the values after we've finished testing.
Signed-off-by: David Weinehall
---
.../intel-gpu-tools/intel-gpu-tools-docs.xml | 1 +
lib/Makefile.sources | 2 +
lib/igt.h | 1 +
lib/igt_aux.c | 15 +-
lib/igt_pm.c | 233 +
lib/igt_pm.h | 31 +++
tests/pm_lpsp.c| 25 +--
tests/pm_rpm.c | 40 +---
8 files changed, 281 insertions(+), 67 deletions(-)
create mode 100644 lib/igt_pm.c
create mode 100644 lib/igt_pm.h
diff --git a/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml
b/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml
index 618dc5fd7076..3ea3563a029a 100644
--- a/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml
+++ b/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml
@@ -24,6 +24,7 @@
+
diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index 4999868052b1..2f0eb2075e14 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -60,6 +60,8 @@ libintel_tools_la_SOURCES = \
igt_core.h \
igt_draw.c \
igt_draw.h \
+ igt_pm.c\
+ igt_pm.h\
$(NULL)
.PHONY: version.h.tmp
diff --git a/lib/igt.h b/lib/igt.h
index 3be25511bb77..d751f2439de2 100644
--- a/lib/igt.h
+++ b/lib/igt.h
@@ -35,6 +35,7 @@
#include "igt_fb.h"
#include "igt_gt.h"
#include "igt_kms.h"
+#include "igt_pm.h"
#include "igt_stats.h"
#include "instdone.h"
#include "intel_batchbuffer.h"
diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index 4d08d68bb932..cd7f14649fe2 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -59,6 +59,7 @@
#include "intel_reg.h"
#include "ioctl_wrappers.h"
#include "igt_kms.h"
+#include "igt_pm.h"
/**
* SECTION:igt_aux
@@ -531,19 +532,7 @@ bool igt_setup_runtime_pm(void)
if (pm_status_fd >= 0)
return true;
- /* The Audio driver can get runtime PM references, so we need to make
-* sure its runtime PM is enabled, so it can release the refs and
-* actually enable us to runtime suspend. */
- fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_WRONLY);
- if (fd >= 0) {
- igt_assert(write(fd, "1\n", 2) == 2);
- close(fd);
- }
- fd = open("/sys/bus/pci/devices/:00:03.0/power/control", O_WRONLY);
- if (fd >= 0) {
- igt_assert(write(fd, "auto\n", 5) == 5);
- close(fd);
- }
+ igt_pm_enable_audio_runtime_pm();
/* Our implementation uses autosuspend. Try to set it to 0ms so the test
* suite goes faster and we have a higher probability of triggering race
diff --git a/lib/igt_pm.c b/lib/igt_pm.c
new file mode 100644
index ..2f574961d179
--- /dev/null
+++ b/lib/igt_pm.c
@@ -0,0 +1,233 @@
+/*
+ * Copyright © 2013, 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:
+ *Paulo Zanoni
+ *David Weinehall
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "drmtest.h"
+#include "igt_pm.h"
+
+enum {
+ POLICY_UNKNOWN = -1,
+ POLICY_MAX_PERFORMANCE = 0,
+ POLICY_MEDIUM_POWER = 1,
+ POLICY_MIN_POWER = 2
+};
+
+#define MAX_PERFORMANCE_STR"max_performance\n"
+#define M
Re: [Intel-gfx] [RFC 3/9] staging/android/sync: Move sync framework out of staging
On 13/01/2016 19:00, Gustavo Padovan wrote: Hi John, 2016-01-13 john.c.harri...@intel.com : From: John Harrison The sync framework is now used by the i915 driver. Therefore it can be moved out of staging and into the regular tree. Also, the public interfaces can actually be made public and exported. I also have been working on de-staging the sync framework, but I've taken the approach of cleaning up the sync framework first. e.g., I got rid of sync_pt and use struct fence directly, also sync_timeline is now fence_timeline and its ops are gone in favor of fence_ops. My current work is here: https://git.kernel.org/cgit/linux/kernel/git/padovan/linux.git/log/?h=sync My current plan is clean up patches, add commits messages and document the changes I've made and then it should be ready for a RFC. Gustavo Hello, Sounds good. I did note in my cover letter that these patches were only being posted to let people review the i915 side of the changes on a complete and working tree. Once we found out you were working on the de-stage the decision was to let you get on with it and not duplicate the effort here :). Note that patches four and five of this series are enhancements to the sync code rather than just de-staging it. Would they still be applicable to your new and improved version? Do you have an expected time scale for when your patches will land? Also, do you have any sort of overview document explaining what externally visible changes you are making and what the implications are for other drivers that are using the API? Re the SW_SYNC_USER bits, we were just using that for a user land test program. The idea was to create an timeline external to the i915 driver and pass sync points in to i915 to be waited on and check that the i915 work itself only happens after the test signals the timeline appropriately. If this interface is going away, is there a plan to replace it with any other mechanism for doing similar? Or do we have to create some kind of dummy kernel module in order to get a testing timeline? Thanks, John. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v10] drm/i915: Extend LRC pinning to cover GPU context writeback
On Wed, Jan 13, 2016 at 04:19:45PM +, Nick Hoath wrote:
> + if (ctx->engine[ring->id].dirty) {
> + struct drm_i915_gem_request *req = NULL;
> +
> + /**
> + * If there is already a request pending on
> + * this ring, wait for that to complete,
> + * otherwise create a switch to idle request
> + */
> + if (list_empty(&ring->request_list)) {
> + int ret;
> +
> + ret = i915_gem_request_alloc(
> + ring,
> + ring->default_context,
> + &req);
> + if (!ret)
> + i915_add_request(req);
> + else
> + DRM_DEBUG("Failed to ensure context saved");
> + } else {
> + req = list_first_entry(
> + &ring->request_list,
> + typeof(*req), list);
> + }
> + if (req) {
> + ret = i915_wait_request(req);
> + if (ret != 0) {
> + /**
> + * If we get here, there's probably been a ring
> + * reset, so we just clean up the dirty flag.&
> + * pin count.
> + */
> + ctx->engine[ring->id].dirty = false;
> + __intel_lr_context_unpin(
> + ring,
> + ctx);
> + }
> + }
If you were to take a lr_context_pin on the last_context, and only
release that pin when you change to a new context, you do not need to
introduce a blocking context-close, nor do you need to introduce the
usage of default_context.
(lr_context_pin should take a reference on the ctx to prevent early
freeeing ofc).
The code at that point starts to look v.v.similar to legacy, right down
to the need to use a GPU reset during shutdown to prevent writing back
the context image. (Which you still currently need to get rid of the
default context now.)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 6/9] drm/i915: Add sync framework support to execbuff IOCTL
On 13/01/2016 18:43, Chris Wilson wrote:
On Wed, Jan 13, 2016 at 05:57:32PM +, john.c.harri...@intel.com wrote:
static int
i915_gem_do_execbuffer(struct drm_device *dev, void *data,
struct drm_file *file,
@@ -1428,6 +1465,17 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
*data,
u32 dispatch_flags;
int ret, i;
bool need_relocs;
+ int fd_fence_complete = -1;
+ int fd_fence_wait = lower_32_bits(args->rsvd2);
+ struct sync_fence *sync_fence;
+
+ /*
+* Make sure an broken fence handle is not returned no matter
+* how early an error might be hit. Note that rsvd2 has been
+* saved away above because it is also an input parameter!
+*/
+ if (args->flags & I915_EXEC_CREATE_FENCE)
+ args->rsvd2 = (__u64) -1;
But you are not restoring the user input parameter upon an error path.
Very simple example is the user trying to do a wait on a fence but is
woken up by a signal and then tries to restart the syscall, the standard
do {
ret = ioctl(fd, request, arg);
} while (ret == -1 && (errno == EINTR || errno == EAGAIN));
loop errors out with EINVAL on the second pass.
if (!i915_gem_check_execbuffer(args))
return -EINVAL;
@@ -1511,6 +1559,17 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
*data,
dispatch_flags |= I915_DISPATCH_RS;
}
+ /*
+* Without a GPU scheduler, any fence waits must be done up front.
+*/
+ if (args->flags & I915_EXEC_WAIT_FENCE) {
+ ret = i915_early_fence_wait(ring, fd_fence_wait);
+ if (ret < 0)
+ return ret;
+
+ args->flags &= ~I915_EXEC_WAIT_FENCE;
+ }
+
ret = i915_mutex_lock_interruptible(dev);
if (ret)
goto pre_mutex_err;
@@ -1695,13 +1754,41 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
*data,
i915_gem_context_reference(ctx);
params->ctx = ctx;
+ if (args->flags & I915_EXEC_CREATE_FENCE) {
+ /*
+* Caller has requested a sync fence.
+* User interrupts will be enabled to make sure that
+* the timeline is signalled on completion.
+*/
+ ret = i915_create_sync_fence(params->request, &sync_fence,
+&fd_fence_complete);
+ if (ret) {
+ DRM_ERROR("Fence creation failed for ring %d, ctx %p\n",
+ ring->id, ctx);
+ goto err_batch_unpin;
+ }
+ }
+
ret = dev_priv->gt.execbuf_submit(params, args, &eb->vmas);
if (ret)
- goto err_batch_unpin;
+ goto err_fence;
/* the request owns the ref now */
i915_gem_context_unreference(ctx);
+ if (fd_fence_complete != -1) {
+ /*
+* Install the fence into the pre-allocated file
+* descriptor to the fence object so that user land
+* can wait on it...
+*/
+ i915_install_sync_fence_fd(params->request,
+ sync_fence, fd_fence_complete);
+
+ /* Return the fence through the rsvd2 field */
+ args->rsvd2 = (__u64) fd_fence_complete;
Use the upper s32 for the output, so again you are not overwriting user
state without good reason.
-Chris
Makes sense. Will do.
Thanks,
John.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ warning: Fi.CI.BAT
== Summary == Built on 058740f8fced6851aeda34f366f5330322cd585f drm-intel-nightly: 2016y-01m-13d-17h-07m-44s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: pass -> DMESG-WARN (bdw-ultra) bdw-ultratotal:138 pass:131 dwarn:1 dfail:0 fail:0 skip:6 bsw-nuc-2total:141 pass:115 dwarn:2 dfail:0 fail:0 skip:24 hsw-brixbox total:141 pass:134 dwarn:0 dfail:0 fail:0 skip:7 hsw-gt2 total:141 pass:137 dwarn:0 dfail:0 fail:0 skip:4 ilk-hp8440p total:141 pass:100 dwarn:4 dfail:0 fail:0 skip:37 ivb-t430stotal:135 pass:122 dwarn:3 dfail:4 fail:0 skip:6 skl-i7k-2total:141 pass:131 dwarn:2 dfail:0 fail:0 skip:8 snb-dellxps total:141 pass:122 dwarn:5 dfail:0 fail:0 skip:14 snb-x220ttotal:141 pass:122 dwarn:5 dfail:0 fail:1 skip:13 Results at /archive/results/CI_IGT_test/Patchwork_1183/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v10] drm/i915: Extend LRC pinning to cover GPU context writeback
On 14/01/2016 11:36, Chris Wilson wrote:
On Wed, Jan 13, 2016 at 04:19:45PM +, Nick Hoath wrote:
+ if (ctx->engine[ring->id].dirty) {
+ struct drm_i915_gem_request *req = NULL;
+
+ /**
+* If there is already a request pending on
+* this ring, wait for that to complete,
+* otherwise create a switch to idle request
+*/
+ if (list_empty(&ring->request_list)) {
+ int ret;
+
+ ret = i915_gem_request_alloc(
+ ring,
+ ring->default_context,
+ &req);
+ if (!ret)
+ i915_add_request(req);
+ else
+ DRM_DEBUG("Failed to ensure context saved");
+ } else {
+ req = list_first_entry(
+ &ring->request_list,
+ typeof(*req), list);
+ }
+ if (req) {
+ ret = i915_wait_request(req);
+ if (ret != 0) {
+ /**
+* If we get here, there's probably been a ring
+* reset, so we just clean up the dirty flag.&
+* pin count.
+*/
+ ctx->engine[ring->id].dirty = false;
+ __intel_lr_context_unpin(
+ ring,
+ ctx);
+ }
+ }
If you were to take a lr_context_pin on the last_context, and only
release that pin when you change to a new context, you do not need to
That what this patch does.
introduce a blocking context-close, nor do you need to introduce the
usage of default_context.
The use of default_context here is to stop a context hanging around
after it is no longer needed.
(lr_context_pin should take a reference on the ctx to prevent early
freeeing ofc).
You can't clear the reference on the ctx in an interrupt context.
The code at that point starts to look v.v.similar to legacy, right down
to the need to use a GPU reset during shutdown to prevent writing back
the context image. (Which you still currently need to get rid of the
default context now.)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/11] drm/i915: Support for creating Stolen memory backed objects
On Thu, Jan 14, 2016 at 11:27:42AM +, Tvrtko Ursulin wrote: > > On 14/01/16 11:14, Chris Wilson wrote: > >On Thu, Jan 14, 2016 at 10:46:39AM +, Tvrtko Ursulin wrote: > >> > >>On 14/01/16 10:24, Chris Wilson wrote: > >>> * Stolen memory is a very limited resource and certain functions of the > >>> * hardware can only work from within stolen memory. Userspace's > >>> * allocations may be evicted from stolen and moved to normal memory as > >>> * required. If the allocation is marked as purgeable (using madvise), > >>> * the allocation will be dropped and further access to the object's > >>> * backing storage will result in -EFAULT. Stolen objects will also be > >>> * migrated to normal memory across suspend and resume, as the stolen > >>> * memory is not preserved. > >>> * > >>> * Stolen memory is regarded as a resource placement hint, most suitable > >>> * for medium-sized buffers that are only accessed by the GPU and can be > >>> * discarded. > >>> */ > >> > >>Would it be better if the placement hint did not specifically > >>mention stolen memory but specific limitations? Like, > > > >It is a nice idea, but it doesn't really fit with the other placement > >domains I have sketched out (they are all fully featured, or nearly so, > >but exist in different pools of memory with different characteristics > >and reasons for choice). > > Perhaps these pools have some characteristics which could be > described abstractly? I am of course coming back to why would > userspace have to know about stolen, why would we fail object > creation if there is no space, and then move objects out of stolen > on hibernate and never put them back. Sounds like a bad and > inflexible interface, and a lying kernel to me. I agree that migrating and failing because of not enough space is nasty. I was tempted to suggest we allow stolen to fallback to normal during creation. (But ABI is tricky, and I think we've got way past the point where this series is ready, we're down to stray lines and choosing a colour for the kettle.) The choice is whether we disable powersaving because userspace allocated a ton of vertex buffers in stolen, or if we just tell them to get lost and take back our memory. It's a two-level priority eviction pass at the moment, kernel vs userspace. We could extend that to several classes/priorites (anything that maps to an unsigned long), but then we need to define a policy of whether some levels are privileged etc. (Overengineering until someone discovers that the kernel kicking their objects out to enable FBC actually causes regression.) Some of the abstraction is nice, but I feel that it makes for sloppy uAPI, and a hindrance to letting userspace decide what it wants. With complex questions of "where should I allocate this buffer", the answer has always been to push that as close to the real decision maker as possible. Making the choice in the kernel, smacks of policy. The mechanism would be to let userspace know the details and make a choice. (All the kernel should have to do is make sure userspace doesn't stomp on each other.) The question is whether the important API detail is the placement, or the first/second class nature of the object interface. I favour selecting placement. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/7] Misc WM fixes and Arbitrated Display Bandwidth WA for SKL
Hi, This series add a set of updates to the WM calculation and also enables arbitrated display bandwidth based WA. Some of these patches do overlap with Matts work but we wanted to send them out as we have them in our internal testing for early review. Most likley some of them can be superceded by patches from Matt, or can be re-used if deemed necessary. Especially "drm/i915/skl+: Use fb size for relative data rate calculation" this already addresses some of Ville's comment on similar patch from Matt. Regards Shobhit Kumar, Mahesh (6): drm/i915/skl+: Use proper bytes_per_pixel during WM calculation drm/i915/skl+: Use fb size for relative data rate calculation drm/i915/skl+: calculate ddb minimum allocation drm/i915/skl+: calculate plane pixel rate. drm/i915/skl+: Use scaling amount for plane data rate calculation drm/i915/skl: WA for watermark calculation based on Arbitrated Display BW Shobhit Kumar (1): drm/i915: Add support to parse DMI table and get platform memory info drivers/gpu/drm/i915/i915_dma.c | 19 +++ drivers/gpu/drm/i915/i915_drv.h | 15 ++ drivers/gpu/drm/i915/intel_drv.h | 2 + drivers/gpu/drm/i915/intel_pm.c | 294 +-- 4 files changed, 316 insertions(+), 14 deletions(-) -- 2.4.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/7] drm/i915/skl+: Use fb size for relative data rate calculation
From: "Kumar, Mahesh"
Use FB size for relative data rate calculation. don't always use
pipe source width & height.
adjust height & width according to rotation.
Signed-off-by: Kumar, Mahesh
---
drivers/gpu/drm/i915/intel_pm.c | 42 -
1 file changed, 33 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 68f21b9..d33c4ff 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2928,24 +2928,33 @@ skl_plane_relative_data_rate(const struct
intel_crtc_state *cstate,
int y)
{
struct intel_crtc *intel_crtc = to_intel_crtc(cstate->base.crtc);
+ struct intel_plane_state *intel_pstate = to_intel_plane_state(pstate);
struct drm_framebuffer *fb = pstate->fb;
+ uint32_t width = 0, height = 0;
+
+ if (drm_rect_width(&intel_pstate->src)) {
+ width = drm_rect_width(&intel_pstate->src) >> 16;
+ height = drm_rect_height(&intel_pstate->src) >> 16;
+ } else {
+ width = intel_crtc->config->pipe_src_w;
+ height = intel_crtc->config->pipe_src_h;
+ }
+
+ if (intel_rotation_90_or_270(pstate->rotation))
+ swap(width, height);
/* for planar format */
if (fb->pixel_format == DRM_FORMAT_NV12) {
if (y) /* y-plane data rate */
- return intel_crtc->config->pipe_src_w *
- intel_crtc->config->pipe_src_h *
+ return width * height *
drm_format_plane_cpp(fb->pixel_format, 0);
else/* uv-plane data rate */
- return (intel_crtc->config->pipe_src_w/2) *
- (intel_crtc->config->pipe_src_h/2) *
+ return (width / 2) * (height / 2) *
drm_format_plane_cpp(fb->pixel_format, 1);
}
/* for packed formats */
- return intel_crtc->config->pipe_src_w *
- intel_crtc->config->pipe_src_h *
- drm_format_plane_cpp(fb->pixel_format, 0);
+ return width * height * drm_format_plane_cpp(fb->pixel_format, 0);
}
/*
@@ -3181,10 +3190,25 @@ static bool skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
uint32_t res_blocks, res_lines;
uint32_t selected_result;
uint8_t bytes_per_pixel;
+ struct intel_crtc *intel_crtc = to_intel_crtc(cstate->base.crtc);
+ struct intel_plane_state *intel_pstate =
to_intel_plane_state(plane->state);
+ uint32_t width = 0, height = 0;
if (latency == 0 || !cstate->base.active || !fb)
return false;
+ if (drm_rect_width(&intel_pstate->src)) {
+ width = drm_rect_width(&intel_pstate->src) >> 16;
+ height = drm_rect_height(&intel_pstate->src) >> 16;
+ } else {
+ width = intel_crtc->config->pipe_src_w;
+ height = intel_crtc->config->pipe_src_h;
+ }
+
+ if (intel_rotation_90_or_270(plane->state->rotation))
+ swap(width, height);
+
+ /* for planar format */
bytes_per_pixel = (fb->pixel_format == DRM_FORMAT_NV12) ?
drm_format_plane_cpp(fb->pixel_format, 1) :
drm_format_plane_cpp(fb->pixel_format, 0);
@@ -3193,12 +3217,12 @@ static bool skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
latency);
method2 = skl_wm_method2(skl_pipe_pixel_rate(cstate),
cstate->base.adjusted_mode.crtc_htotal,
-cstate->pipe_src_w,
+width,
bytes_per_pixel,
fb->modifier[0],
latency);
- plane_bytes_per_line = cstate->pipe_src_w * bytes_per_pixel;
+ plane_bytes_per_line = width * bytes_per_pixel;
plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
--
2.4.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/7] drm/i915/skl+: calculate ddb minimum allocation
From: "Kumar, Mahesh"
don't always use 8 ddb as minimum, instead calculate using proper
algorithm.
Signed-off-by: Kumar, Mahesh
---
drivers/gpu/drm/i915/intel_pm.c | 57 +++--
1 file changed, 55 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d33c4ff..64b39ec 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2994,6 +2994,59 @@ skl_get_total_relative_data_rate(const struct
intel_crtc_state *cstate)
return total_data_rate;
}
+static uint16_t
+skl_ddb_min_alloc(const struct intel_crtc *crtc,
+ const struct drm_plane *plane, int y)
+{
+ struct drm_framebuffer *fb = plane->state->fb;
+ struct intel_plane_state *pstate = to_intel_plane_state(plane->state);
+ uint16_t min_alloc;
+ uint32_t src_w, src_h;
+
+ /* For packed formats, no y-plane, return 0 */
+ if (y && !(fb->pixel_format == DRM_FORMAT_NV12))
+ return 0;
+
+ if (drm_rect_width(&pstate->src)) {
+ src_w = drm_rect_width(&pstate->src) >> 16;
+ src_h = drm_rect_height(&pstate->src) >> 16;
+ } else {
+ src_w = crtc->config->pipe_src_w;
+ src_h = crtc->config->pipe_src_h;
+ }
+
+ if (intel_rotation_90_or_270(plane->state->rotation))
+ swap(src_w, src_h);
+
+ if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
+ fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
+ uint32_t min_scanlines = 8;
+ uint8_t bytes_per_pixel =
+ y ? drm_format_plane_cpp(fb->pixel_format, 1) :
+ drm_format_plane_cpp(fb->pixel_format, 0);
+
+ if (intel_rotation_90_or_270(plane->state->rotation)) {
+ switch (bytes_per_pixel) {
+ case 1:
+ min_scanlines = 32;
+ break;
+ case 2:
+ min_scanlines = 16;
+ break;
+ case 8:
+ WARN(1, "Unsupported pixel depth for rotation");
+ }
+ }
+ min_alloc = DIV_ROUND_UP((4 * src_w / (y ? 1 : 2) *
+ bytes_per_pixel), 512) * min_scanlines/4 + 3;
+ } else {
+ min_alloc = 8;
+ }
+
+ return min_alloc;
+}
+
+
static void
skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
struct skl_ddb_allocation *ddb /* out */)
@@ -3038,9 +3091,9 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
if (plane->type == DRM_PLANE_TYPE_CURSOR)
continue;
- minimum[id] = 8;
+ minimum[id] = skl_ddb_min_alloc(intel_crtc, plane, 0);
alloc_size -= minimum[id];
- y_minimum[id] = (fb->pixel_format == DRM_FORMAT_NV12) ? 8 : 0;
+ y_minimum[id] = skl_ddb_min_alloc(intel_crtc, plane, 1);
alloc_size -= y_minimum[id];
}
--
2.4.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/7] drm/i915/skl: WA for watermark calculation based on Arbitrated Display BW
From: "Kumar, Mahesh"
If the arbitary display bandwidth is > 60% of memory bandwith, for
x-tile we should increase latency at all levels by 15us.
If the arbitary dsplay bandwidth is greater than 20% of memory bandwith
in case of y-tile being enabled, double the scan lines
v2: Update the commit message to explain the WA (shobhit)
Signed-off-by: Shobhit Kumar
Signed-off-by: Kumar, Mahesh
---
drivers/gpu/drm/i915/i915_drv.h | 9 +
drivers/gpu/drm/i915/intel_pm.c | 86 +
2 files changed, 95 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f588993..3c914a6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1620,6 +1620,12 @@ enum intel_pipe_crc_source {
INTEL_PIPE_CRC_SOURCE_MAX,
};
+enum watermark_memory_wa {
+ WATERMARK_WA_NONE,
+ WATERMARK_WA_X_TILED,
+ WATERMARK_WA_Y_TILED,
+};
+
struct intel_pipe_crc_entry {
uint32_t frame;
uint32_t crc[5];
@@ -1915,6 +1921,9 @@ struct drm_i915_private {
/* Committed wm config */
struct intel_wm_config config;
+ /* This stores if WaterMark memory workaround is needed */
+ enum watermark_memory_wa mem_wa;
+
/*
* The skl_wm_values structure is a bit too big for stack
* allocation, so we keep the staging struct where we store
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index dc08494..fb59f4e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3304,6 +3304,11 @@ static bool skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
if (latency == 0 || !cstate->base.active || !fb)
return false;
+ if (dev_priv->wm.mem_wa != WATERMARK_WA_NONE) {
+ if (fb->modifier[0] == I915_FORMAT_MOD_X_TILED)
+ latency += 15;
+ }
+
if (drm_rect_width(&intel_pstate->src)) {
width = drm_rect_width(&intel_pstate->src) >> 16;
height = drm_rect_height(&intel_pstate->src) >> 16;
@@ -3352,6 +3357,9 @@ static bool skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
WARN(1, "Unsupported pixel depth for rotation");
}
}
+ if (dev_priv->wm.mem_wa == WATERMARK_WA_Y_TILED)
+ min_scanlines *= 2;
+
y_tile_minimum = plane_blocks_per_line * min_scanlines;
selected_result = max(method2, y_tile_minimum);
} else {
@@ -3803,6 +3811,83 @@ static void skl_set_plane_pixel_rate(struct drm_crtc
*crtc)
}
+static void
+skl_set_display_memory_wa(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct intel_crtc *intel_crtc = NULL;
+ struct intel_plane *intel_plane = NULL;
+ uint32_t num_active_crtc = 0;
+ uint64_t max_pixel_rate_pipe = 0;
+ uint64_t display_bw = 0, available_bw = 0;
+ bool y_tile_enabled = false;
+ int memory_portion = 0;
+
+ for_each_intel_crtc(dev, intel_crtc) {
+ uint64_t max_pixel_rate_plane = 0;
+ uint64_t pipe_bw;
+ uint32_t num_active_plane = 0;
+ const struct intel_crtc_state *cstate = NULL;
+
+ if (!intel_crtc->active)
+ continue;
+ cstate = to_intel_crtc_state(intel_crtc->base.state);
+ num_active_crtc++;
+
+ for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) {
+ struct drm_plane *plane = &intel_plane->base;
+ struct drm_framebuffer *fb = plane->state->fb;
+ uint64_t plane_bw, interm_bw = 1000;
+
+ if (fb == NULL)
+ continue;
+ if (plane->type == DRM_PLANE_TYPE_CURSOR)
+ continue;
+ num_active_plane++;
+
+ if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED)
+ y_tile_enabled = true;
+
+ /*
+* planeBW = pixel_rate(MHz) * BPP * plane downscale
+* amount * pipe downscale amount;
+*
+* skl_pipe_pixel_rate return adjusted value according
+* to downscaling amount
+* pixel rate is in KHz & downscale factor is multiplied
+* by 1000, so devide by 1000*1000
+*/
+ interm_bw = skl_pipe_pixel_rate(cstate) *
+ drm_format_plane_cpp(fb->pixel_format, 0) *
+ skl_plane_downscale_amount(intel_plane);
+
[Intel-gfx] [PATCH 1/7] drm/i915/skl+: Use proper bytes_per_pixel during WM calculation
From: "Kumar, Mahesh" Don't always use bytes_per_pixel using y_plane=0, instead use it according to pixel format. If NV12 use y_plane eqal to 1 Signed-off-by: Kumar, Mahesh --- drivers/gpu/drm/i915/intel_pm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 9df9e9a..68f21b9 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -3185,7 +3185,9 @@ static bool skl_compute_plane_wm(const struct drm_i915_private *dev_priv, if (latency == 0 || !cstate->base.active || !fb) return false; - bytes_per_pixel = drm_format_plane_cpp(fb->pixel_format, 0); + bytes_per_pixel = (fb->pixel_format == DRM_FORMAT_NV12) ? + drm_format_plane_cpp(fb->pixel_format, 1) : + drm_format_plane_cpp(fb->pixel_format, 0); method1 = skl_wm_method1(skl_pipe_pixel_rate(cstate), bytes_per_pixel, latency); -- 2.4.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/7] drm/i915: Add support to parse DMI table and get platform memory info
This is needed for WM computation workaround for arbitrated display
bandwidth.
Signed-off-by: Shobhit Kumar
---
drivers/gpu/drm/i915/i915_dma.c | 19 +++
drivers/gpu/drm/i915/i915_drv.h | 6 ++
2 files changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index a0f5659..03c3131 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -49,6 +49,7 @@
#include
#include
#include
+#include
static int i915_getparam(struct drm_device *dev, void *data,
@@ -855,6 +856,21 @@ static void intel_init_dpio(struct drm_i915_private
*dev_priv)
}
}
+static void dmi_decode_memory_info(const struct dmi_header *hdr, void *priv)
+{
+ struct drm_i915_private *dev_priv = (struct drm_i915_private *) priv;
+ const u8 *data = (const u8 *) hdr;
+
+ if (hdr->type == 17 && hdr->length > 0x17) {
+
+ /* Found a memory channel */
+ dev_priv->dmi.mem_channel++;
+
+ /* Get the speed */
+ dev_priv->dmi.mem_speed = (uint16_t) (*((uint16_t *)(data +
0x15)));
+ }
+}
+
/**
* i915_driver_load - setup chip and create an initial config
* @dev: DRM device
@@ -882,6 +898,9 @@ int i915_driver_load(struct drm_device *dev, unsigned long
flags)
dev->dev_private = dev_priv;
dev_priv->dev = dev;
+ /* walk the dmi device table for getting platform memory information */
+ dmi_walk(dmi_decode_memory_info, (void *) dev_priv);
+
/* Setup the write-once "constant" device info */
device_info = (struct intel_device_info *)&dev_priv->info;
memcpy(device_info, info, sizeof(dev_priv->info));
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 104bd18..f588993 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1962,6 +1962,12 @@ struct drm_i915_private {
* NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
* will be rejected. Instead look for a better place.
*/
+
+ /* DMI data for memory bandwidth calculation */
+ struct {
+ uint16_t mem_channel;
+ uint16_t mem_speed;
+ } dmi;
};
static inline struct drm_i915_private *to_i915(const struct drm_device *dev)
--
2.4.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/7] drm/i915/skl+: calculate plane pixel rate.
From: "Kumar, Mahesh"
Don't use pipe pixel rate for plane pixel rate.
Calculate plane pixel according to formula
adjusted plane_pixel_rate = adjusted pipe_pixel_rate * downscale ammount
downscale amount = max[1, src_h/dst_h] * max[1, src_w/dst_w]
if 90/270 rotation use rotated width & height
Signed-off-by: Kumar, Mahesh
---
drivers/gpu/drm/i915/intel_drv.h | 2 +
drivers/gpu/drm/i915/intel_pm.c | 95 +++-
2 files changed, 95 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 059b46e..49f237e 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -661,6 +661,8 @@ struct intel_plane_wm_parameters {
u64 tiling;
unsigned int rotation;
uint16_t fifo_size;
+/* Stores the adjusted plane pixel rate for WM calculation */
+ uint32_t plane_pixel_rate;
};
struct intel_plane {
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 64b39ec..ffcc56a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2841,6 +2841,54 @@ skl_wm_plane_id(const struct intel_plane *plane)
}
}
+/*
+ * This function takes drm_plane_state as input
+ * and decides the downscale amount according to the formula
+ *
+ * downscale amount = Max[1, Horizontal source size / Horizontal dest size]
+ *
+ * Return value is multiplied by 1000 to retain fractional part
+ * Caller should take care of dividing & Rounding off the value
+ */
+static uint32_t
+skl_plane_downscale_amount(const struct intel_plane *intel_plane)
+{
+ struct drm_plane_state *pstate = intel_plane->base.state;
+ struct intel_crtc *crtc = to_intel_crtc(pstate->crtc);
+ struct intel_plane_state *intel_pstate = to_intel_plane_state(pstate);
+ uint32_t downscale_h, downscale_w;
+ uint32_t src_w, src_h, dst_w, dst_h, tmp;
+
+ if (drm_rect_width(&intel_pstate->src)) {
+ src_w = drm_rect_width(&intel_pstate->src) >> 16;
+ src_h = drm_rect_height(&intel_pstate->src) >> 16;
+ } else {
+ src_w = crtc->config->pipe_src_w;
+ src_h = crtc->config->pipe_src_h;
+ }
+
+ dst_w = drm_rect_width(&intel_pstate->dst);
+ dst_h = drm_rect_height(&intel_pstate->dst);
+
+ if (intel_rotation_90_or_270(pstate->rotation))
+ swap(dst_w, dst_h);
+
+ /* If destination height & wight are zero return amount as unity */
+ if (dst_w == 0 || dst_h == 0)
+ return 1000;
+
+ /* Multiply by 1000 for precision */
+ tmp = (1000 * src_h) / dst_h;
+ downscale_h = max_t(uint32_t, 1000, tmp);
+
+ tmp = (1000 * src_w) / dst_w;
+ downscale_w = max_t(uint32_t, 1000, tmp);
+
+ /* Reducing precision to 3 decimal places */
+ return DIV_ROUND_UP(downscale_h * downscale_w, 1000);
+}
+
+
static void
skl_ddb_get_pipe_allocation_limits(struct drm_device *dev,
const struct intel_crtc_state *cstate,
@@ -3265,10 +3313,10 @@ static bool skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
bytes_per_pixel = (fb->pixel_format == DRM_FORMAT_NV12) ?
drm_format_plane_cpp(fb->pixel_format, 1) :
drm_format_plane_cpp(fb->pixel_format, 0);
- method1 = skl_wm_method1(skl_pipe_pixel_rate(cstate),
+ method1 = skl_wm_method1(intel_plane->wm.plane_pixel_rate,
bytes_per_pixel,
latency);
- method2 = skl_wm_method2(skl_pipe_pixel_rate(cstate),
+ method2 = skl_wm_method2(intel_plane->wm.plane_pixel_rate,
cstate->base.adjusted_mode.crtc_htotal,
width,
bytes_per_pixel,
@@ -3709,6 +3757,46 @@ static void skl_update_other_pipe_wm(struct drm_device
*dev,
}
}
+static uint32_t
+skl_plane_pixel_rate(struct intel_crtc_state *cstate, struct intel_plane
*plane)
+{
+ uint32_t adjusted_pixel_rate;
+ uint32_t downscale_amount;
+
+ /*
+* adjusted plane pixel rate = adjusted pipe pixel rate
+* Plane pixel rate = adjusted plane pixel rate * plane down scale
+* amount
+*/
+ adjusted_pixel_rate = skl_pipe_pixel_rate(cstate);
+ downscale_amount = skl_plane_downscale_amount(plane);
+
+ return DIV_ROUND_UP(adjusted_pixel_rate * downscale_amount,
+ 1000);
+}
+
+static void skl_set_plane_pixel_rate(struct drm_crtc *crtc)
+{
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct intel_crtc_state *cstate = to_intel_crtc_state(crtc->state);
+ struct intel_plane *intel_plane = NULL;
+ struct drm_device *dev = crtc->dev;
+
+ if (!intel_crtc->active)
+ return;
+ for_each_inte
[Intel-gfx] [PATCH 5/7] drm/i915/skl+: Use scaling amount for plane data rate calculation
From: "Kumar, Mahesh"
Signed-off-by: Kumar, Mahesh
---
drivers/gpu/drm/i915/intel_pm.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ffcc56a..dc08494 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2978,6 +2978,8 @@ skl_plane_relative_data_rate(const struct
intel_crtc_state *cstate,
struct intel_crtc *intel_crtc = to_intel_crtc(cstate->base.crtc);
struct intel_plane_state *intel_pstate = to_intel_plane_state(pstate);
struct drm_framebuffer *fb = pstate->fb;
+ struct intel_plane *intel_plane = to_intel_plane(pstate->plane);
+ uint32_t down_scale_amount, data_rate;
uint32_t width = 0, height = 0;
if (drm_rect_width(&intel_pstate->src)) {
@@ -2994,15 +2996,19 @@ skl_plane_relative_data_rate(const struct
intel_crtc_state *cstate,
/* for planar format */
if (fb->pixel_format == DRM_FORMAT_NV12) {
if (y) /* y-plane data rate */
- return width * height *
+ data_rate = width * height *
drm_format_plane_cpp(fb->pixel_format, 0);
else/* uv-plane data rate */
- return (width / 2) * (height / 2) *
+ data_rate = (width / 2) * (height / 2) *
drm_format_plane_cpp(fb->pixel_format, 1);
}
/* for packed formats */
- return width * height * drm_format_plane_cpp(fb->pixel_format, 0);
+ data_rate = width * height * drm_format_plane_cpp(fb->pixel_format, 0);
+ down_scale_amount = skl_plane_downscale_amount(intel_plane);
+
+ return DIV_ROUND_UP((data_rate * down_scale_amount), 1000);
+
}
/*
--
2.4.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 6/9] drm/i915: Add sync framework support to execbuff IOCTL
On Thu, Jan 14, 2016 at 11:47:17AM +, John Harrison wrote: > On 13/01/2016 18:43, Chris Wilson wrote: > >Use the upper s32 for the output, so again you are not overwriting user > >state without good reason. > > > Makes sense. Will do. It would also be useful (for nefarious reasons) to only copy back the rsvd2 field, i.e. keep it as DRM_IOW(EXECBUFFER2) and do the small fixed-sized copy_to_user of rsvd2 as required. That means we can avoid the copy mostly, and treat args as a private copy of the user parameters, i.e. space we can scribble over with impunity. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ failure: Fi.CI.BAT
== Summary == Built on 058740f8fced6851aeda34f366f5330322cd585f drm-intel-nightly: 2016y-01m-13d-17h-07m-44s UTC integration manifest Test gem_ctx_basic: pass -> FAIL (bdw-ultra) bdw-nuci7total:138 pass:128 dwarn:1 dfail:0 fail:0 skip:9 bdw-ultratotal:138 pass:131 dwarn:0 dfail:0 fail:1 skip:6 bsw-nuc-2total:141 pass:115 dwarn:2 dfail:0 fail:0 skip:24 hsw-brixbox total:141 pass:134 dwarn:0 dfail:0 fail:0 skip:7 hsw-gt2 total:141 pass:137 dwarn:0 dfail:0 fail:0 skip:4 ilk-hp8440p total:141 pass:100 dwarn:4 dfail:0 fail:0 skip:37 ivb-t430stotal:135 pass:122 dwarn:3 dfail:4 fail:0 skip:6 skl-i7k-2total:141 pass:131 dwarn:2 dfail:0 fail:0 skip:8 snb-dellxps total:141 pass:122 dwarn:5 dfail:0 fail:0 skip:14 snb-x220ttotal:141 pass:122 dwarn:5 dfail:0 fail:1 skip:13 Results at /archive/results/CI_IGT_test/Patchwork_1184/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v10] drm/i915: Extend LRC pinning to cover GPU context writeback
On Thu, Jan 14, 2016 at 11:56:07AM +, Nick Hoath wrote:
> On 14/01/2016 11:36, Chris Wilson wrote:
> >On Wed, Jan 13, 2016 at 04:19:45PM +, Nick Hoath wrote:
> >>+ if (ctx->engine[ring->id].dirty) {
> >>+ struct drm_i915_gem_request *req = NULL;
> >>+
> >>+ /**
> >>+* If there is already a request pending on
> >>+* this ring, wait for that to complete,
> >>+* otherwise create a switch to idle request
> >>+*/
> >>+ if (list_empty(&ring->request_list)) {
> >>+ int ret;
> >>+
> >>+ ret = i915_gem_request_alloc(
> >>+ ring,
> >>+ ring->default_context,
> >>+ &req);
> >>+ if (!ret)
> >>+ i915_add_request(req);
> >>+ else
> >>+ DRM_DEBUG("Failed to ensure context saved");
> >>+ } else {
> >>+ req = list_first_entry(
> >>+ &ring->request_list,
> >>+ typeof(*req), list);
> >>+ }
> >>+ if (req) {
> >>+ ret = i915_wait_request(req);
> >>+ if (ret != 0) {
> >>+ /**
> >>+* If we get here, there's probably been a ring
> >>+* reset, so we just clean up the dirty flag.&
> >>+* pin count.
> >>+*/
> >>+ ctx->engine[ring->id].dirty = false;
> >>+ __intel_lr_context_unpin(
> >>+ ring,
> >>+ ctx);
> >>+ }
> >>+ }
> >
> >If you were to take a lr_context_pin on the last_context, and only
> >release that pin when you change to a new context, you do not need to
>
> That what this patch does.
>
> >introduce a blocking context-close, nor do you need to introduce the
> >usage of default_context.
>
> The use of default_context here is to stop a context hanging around
> after it is no longer needed.
By blocking, which is not acceptable. Also we can eliminate the
default_context and so pinning that opposed to the last_context serves
no purpose other than by chance having a more preferrable position when
it comes to defragmentation. But you don't enable that anyway and we
have alternative strategies now that avoid the issue with fragmentation
of the mappable aperture.
> >(lr_context_pin should take a reference on the ctx to prevent early
> >freeeing ofc).
>
> You can't clear the reference on the ctx in an interrupt context.
The execlists submission should moved out of the interrupt context, for
the very simple reason that it is causing machine panics. userspace
submits a workload, machine lockups
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v10] drm/i915: Extend LRC pinning to cover GPU context writeback
On 14/01/2016 12:31, Chris Wilson wrote:
On Thu, Jan 14, 2016 at 11:56:07AM +, Nick Hoath wrote:
On 14/01/2016 11:36, Chris Wilson wrote:
On Wed, Jan 13, 2016 at 04:19:45PM +, Nick Hoath wrote:
+ if (ctx->engine[ring->id].dirty) {
+ struct drm_i915_gem_request *req = NULL;
+
+ /**
+* If there is already a request pending on
+* this ring, wait for that to complete,
+* otherwise create a switch to idle request
+*/
+ if (list_empty(&ring->request_list)) {
+ int ret;
+
+ ret = i915_gem_request_alloc(
+ ring,
+ ring->default_context,
+ &req);
+ if (!ret)
+ i915_add_request(req);
+ else
+ DRM_DEBUG("Failed to ensure context saved");
+ } else {
+ req = list_first_entry(
+ &ring->request_list,
+ typeof(*req), list);
+ }
+ if (req) {
+ ret = i915_wait_request(req);
+ if (ret != 0) {
+ /**
+* If we get here, there's probably been a ring
+* reset, so we just clean up the dirty flag.&
+* pin count.
+*/
+ ctx->engine[ring->id].dirty = false;
+ __intel_lr_context_unpin(
+ ring,
+ ctx);
+ }
+ }
If you were to take a lr_context_pin on the last_context, and only
release that pin when you change to a new context, you do not need to
That what this patch does.
introduce a blocking context-close, nor do you need to introduce the
usage of default_context.
The use of default_context here is to stop a context hanging around
after it is no longer needed.
By blocking, which is not acceptable. Also we can eliminate the
default_context and so pinning that opposed to the last_context serves
no purpose other than by chance having a more preferrable position when
it comes to defragmentation. But you don't enable that anyway and we
Enabling the shrinker on execlists is something I'm working on which is
predicated on this patch. Also why is blocking on closing a context not
acceptable?
have alternative strategies now that avoid the issue with fragmentation
of the mappable aperture.
(lr_context_pin should take a reference on the ctx to prevent early
freeeing ofc).
You can't clear the reference on the ctx in an interrupt context.
The execlists submission should moved out of the interrupt context, for
the very simple reason that it is causing machine panics. userspace
submits a workload, machine lockups
Create a jira, and I'm sure we'll look at making that change.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ success: Fi.CI.BAT
== Summary == Built on 058740f8fced6851aeda34f366f5330322cd585f drm-intel-nightly: 2016y-01m-13d-17h-07m-44s UTC integration manifest bdw-nuci7total:138 pass:128 dwarn:1 dfail:0 fail:0 skip:9 bdw-ultratotal:138 pass:132 dwarn:0 dfail:0 fail:0 skip:6 hsw-brixbox total:141 pass:134 dwarn:0 dfail:0 fail:0 skip:7 hsw-gt2 total:141 pass:137 dwarn:0 dfail:0 fail:0 skip:4 ilk-hp8440p total:141 pass:100 dwarn:4 dfail:0 fail:0 skip:37 ivb-t430stotal:135 pass:122 dwarn:3 dfail:4 fail:0 skip:6 skl-i7k-2total:141 pass:131 dwarn:2 dfail:0 fail:0 skip:8 snb-dellxps total:141 pass:122 dwarn:5 dfail:0 fail:0 skip:14 Results at /archive/results/CI_IGT_test/Patchwork_1185/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/6] drm/i915: move VBT based TV presence check to intel_bios.c
On Mon, 2016-01-11 at 21:54 +0200, Jani Nikula wrote:
> Hide knowledge about VBT child devices in intel_bios.c.
>
Tested-by: Mika Kahola
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_bios.c | 38 ++
> drivers/gpu/drm/i915/intel_tv.c | 43
> +--
> 3 files changed, 40 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 104bd1809936..3822c465d3dc 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3347,6 +3347,7 @@ extern void intel_i2c_reset(struct drm_device *dev);
> /* intel_bios.c */
> int intel_bios_init(struct drm_i915_private *dev_priv);
> bool intel_bios_is_valid_vbt(const void *buf, size_t size);
> +bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv);
>
> /* intel_opregion.c */
> #ifdef CONFIG_ACPI
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 15ba52bd2538..bb9e8b086b63 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1415,3 +1415,41 @@ intel_bios_init(struct drm_i915_private *dev_priv)
>
> return 0;
> }
> +
> +/**
> + * intel_bios_is_tv_present - is integrated TV present in VBT
> + * @dev_priv:i915 device instance
> + *
> + * Return true if TV is present. If no child devices were parsed from VBT,
> + * assume TV is present.
> + */
> +bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv)
> +{
> + union child_device_config *p_child;
> + int i;
> +
> + if (!dev_priv->vbt.child_dev_num)
> + return true;
> +
> + for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> + p_child = dev_priv->vbt.child_dev + i;
> + /*
> + * If the device type is not TV, continue.
> + */
> + switch (p_child->old.device_type) {
> + case DEVICE_TYPE_INT_TV:
> + case DEVICE_TYPE_TV:
> + case DEVICE_TYPE_TV_SVIDEO_COMPOSITE:
> + break;
> + default:
> + continue;
> + }
> + /* Only when the addin_offset is non-zero, it is regarded
> + * as present.
> + */
> + if (p_child->old.addin_offset)
> + return true;
> + }
> +
> + return false;
> +}
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 948cbff6c62e..29e68859b9b7 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -1529,47 +1529,6 @@ static const struct drm_encoder_funcs
> intel_tv_enc_funcs = {
> .destroy = intel_encoder_destroy,
> };
>
> -/*
> - * Enumerate the child dev array parsed from VBT to check whether
> - * the integrated TV is present.
> - * If it is present, return 1.
> - * If it is not present, return false.
> - * If no child dev is parsed from VBT, it assumes that the TV is present.
> - */
> -static int tv_is_present_in_vbt(struct drm_device *dev)
> -{
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - union child_device_config *p_child;
> - int i, ret;
> -
> - if (!dev_priv->vbt.child_dev_num)
> - return 1;
> -
> - ret = 0;
> - for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> - p_child = dev_priv->vbt.child_dev + i;
> - /*
> - * If the device type is not TV, continue.
> - */
> - switch (p_child->old.device_type) {
> - case DEVICE_TYPE_INT_TV:
> - case DEVICE_TYPE_TV:
> - case DEVICE_TYPE_TV_SVIDEO_COMPOSITE:
> - break;
> - default:
> - continue;
> - }
> - /* Only when the addin_offset is non-zero, it is regarded
> - * as present.
> - */
> - if (p_child->old.addin_offset) {
> - ret = 1;
> - break;
> - }
> - }
> - return ret;
> -}
> -
> void
> intel_tv_init(struct drm_device *dev)
> {
> @@ -1585,7 +1544,7 @@ intel_tv_init(struct drm_device *dev)
> if ((I915_READ(TV_CTL) & TV_FUSE_STATE_MASK) == TV_FUSE_STATE_DISABLED)
> return;
>
> - if (!tv_is_present_in_vbt(dev)) {
> + if (!intel_bios_is_tv_present(dev_priv)) {
> DRM_DEBUG_KMS("Integrated TV is not present.\n");
> return;
> }
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/6] drm/i915: move VBT based LVDS presence check to intel_bios.c
On Mon, 2016-01-11 at 21:54 +0200, Jani Nikula wrote:
> Hide knowledge about VBT child devices in intel_bios.c.
>
Tested-by: Mika Kahola
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_bios.c | 50
> drivers/gpu/drm/i915/intel_lvds.c | 53
> +--
> 3 files changed, 52 insertions(+), 52 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 3822c465d3dc..5f0d44b380aa 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3348,6 +3348,7 @@ extern void intel_i2c_reset(struct drm_device *dev);
> int intel_bios_init(struct drm_i915_private *dev_priv);
> bool intel_bios_is_valid_vbt(const void *buf, size_t size);
> bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv);
> +bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8
> *i2c_pin);
>
> /* intel_opregion.c */
> #ifdef CONFIG_ACPI
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index bb9e8b086b63..099f3f0002a2 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1453,3 +1453,53 @@ bool intel_bios_is_tv_present(struct drm_i915_private
> *dev_priv)
>
> return false;
> }
> +
> +/**
> + * intel_bios_is_lvds_present - is LVDS present in VBT
> + * @dev_priv:i915 device instance
> + * @i2c_pin: i2c pin for LVDS if present
> + *
> + * Return true if LVDS is present. If no child devices were parsed from VBT,
> + * assume LVDS is present.
> + */
> +bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8
> *i2c_pin)
> +{
> + int i;
> +
> + if (!dev_priv->vbt.child_dev_num)
> + return true;
> +
> + for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> + union child_device_config *uchild = dev_priv->vbt.child_dev + i;
> + struct old_child_dev_config *child = &uchild->old;
> +
> + /* If the device type is not LFP, continue.
> + * We have to check both the new identifiers as well as the
> + * old for compatibility with some BIOSes.
> + */
> + if (child->device_type != DEVICE_TYPE_INT_LFP &&
> + child->device_type != DEVICE_TYPE_LFP)
> + continue;
> +
> + if (intel_gmbus_is_valid_pin(dev_priv, child->i2c_pin))
> + *i2c_pin = child->i2c_pin;
> +
> + /* However, we cannot trust the BIOS writers to populate
> + * the VBT correctly. Since LVDS requires additional
> + * information from AIM blocks, a non-zero addin offset is
> + * a good indicator that the LVDS is actually present.
> + */
> + if (child->addin_offset)
> + return true;
> +
> + /* But even then some BIOS writers perform some black magic
> + * and instantiate the device without reference to any
> + * additional data. Trust that if the VBT was written into
> + * the OpRegion then they have validated the LVDS's existence.
> + */
> + if (dev_priv->opregion.vbt)
> + return true;
> + }
> +
> + return false;
> +}
> diff --git a/drivers/gpu/drm/i915/intel_lvds.c
> b/drivers/gpu/drm/i915/intel_lvds.c
> index 0da0240caf81..80f8684e5137 100644
> --- a/drivers/gpu/drm/i915/intel_lvds.c
> +++ b/drivers/gpu/drm/i915/intel_lvds.c
> @@ -772,57 +772,6 @@ static const struct dmi_system_id intel_no_lvds[] = {
> { } /* terminating entry */
> };
>
> -/*
> - * Enumerate the child dev array parsed from VBT to check whether
> - * the LVDS is present.
> - * If it is present, return 1.
> - * If it is not present, return false.
> - * If no child dev is parsed from VBT, it assumes that the LVDS is present.
> - */
> -static bool lvds_is_present_in_vbt(struct drm_device *dev,
> -u8 *i2c_pin)
> -{
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - int i;
> -
> - if (!dev_priv->vbt.child_dev_num)
> - return true;
> -
> - for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> - union child_device_config *uchild = dev_priv->vbt.child_dev + i;
> - struct old_child_dev_config *child = &uchild->old;
> -
> - /* If the device type is not LFP, continue.
> - * We have to check both the new identifiers as well as the
> - * old for compatibility with some BIOSes.
> - */
> - if (child->device_type != DEVICE_TYPE_INT_LFP &&
> - child->device_type != DEVICE_TYPE_LFP)
> - continue;
> -
> - if (intel_gmbus_is_valid_pin(dev_priv, child->i2c_pin))
> - *i2c_pin = child->i2c_pin;
> -
>
Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: hide away VBT private data in a separate header
On Mon, 2016-01-11 at 21:54 +0200, Jani Nikula wrote:
> We've been accumulating code across the driver that depends on the VBT
> specific structures and defines. The VBT is an uncontrollable
> beast. Encourage encapsulation of the VBT data by hiding the structures
> and defines in a private header only to be included from intel_bios.c.
>
Tested-by: Mika Kahola
> Signed-off-by: Jani Nikula
> ---
> Documentation/DocBook/gpu.tmpl| 2 +-
> drivers/gpu/drm/i915/intel_bios.c | 2 +-
> drivers/gpu/drm/i915/intel_bios.h | 860
> ++
> drivers/gpu/drm/i915/intel_bios_private.h | 823
> 4 files changed, 859 insertions(+), 828 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/intel_bios_private.h
>
> diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
> index 351e801cead9..4ba7c6f8e8b1 100644
> --- a/Documentation/DocBook/gpu.tmpl
> +++ b/Documentation/DocBook/gpu.tmpl
> @@ -3323,7 +3323,7 @@ int num_ioctls;
> Video BIOS Table (VBT)
> !Pdrivers/gpu/drm/i915/intel_bios.c Video BIOS Table (VBT)
> !Idrivers/gpu/drm/i915/intel_bios.c
> -!Idrivers/gpu/drm/i915/intel_bios.h
> +!Idrivers/gpu/drm/i915/intel_bios_private.h
>
>
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 94c2baa50db7..83b78e0df306 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -29,7 +29,7 @@
> #include
> #include
> #include "i915_drv.h"
> -#include "intel_bios.h"
> +#include "intel_bios_private.h"
>
> /**
> * DOC: Video BIOS Table (VBT)
> diff --git a/drivers/gpu/drm/i915/intel_bios.h
> b/drivers/gpu/drm/i915/intel_bios.h
> index 350d4e0f75a4..536d90f0c3eb 100644
> --- a/drivers/gpu/drm/i915/intel_bios.h
> +++ b/drivers/gpu/drm/i915/intel_bios.h
> @@ -1,5 +1,5 @@
> /*
> - * Copyright © 2006 Intel Corporation
> + * Copyright © 2016 Intel Corporation
> *
> * Permission is hereby granted, free of charge, to any person obtaining a
> * copy of this software and associated documentation files (the "Software"),
> @@ -19,543 +19,15 @@
> * 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:
> - *Eric Anholt
> - *
> - */
> -
> -#ifndef _INTEL_BIOS_H_
> -#define _INTEL_BIOS_H_
> -
> -/**
> - * struct vbt_header - VBT Header structure
> - * @signature: VBT signature, always starts with "$VBT"
> - * @version: Version of this structure
> - * @header_size: Size of this structure
> - * @vbt_size:Size of VBT (VBT Header, BDB Header and data
> blocks)
> - * @vbt_checksum:Checksum
> - * @reserved0: Reserved
> - * @bdb_offset: Offset of &struct bdb_header from beginning of
> VBT
> - * @aim_offset: Offsets of add-in data blocks from beginning of
> VBT
> - */
> -struct vbt_header {
> - u8 signature[20];
> - u16 version;
> - u16 header_size;
> - u16 vbt_size;
> - u8 vbt_checksum;
> - u8 reserved0;
> - u32 bdb_offset;
> - u32 aim_offset[4];
> -} __packed;
> -
> -/**
> - * struct bdb_header - BDB Header structure
> - * @signature: BDB signature "BIOS_DATA_BLOCK"
> - * @version: Version of the data block definitions
> - * @header_size: Size of this structure
> - * @bdb_size:Size of BDB (BDB Header and data blocks)
> - */
> -struct bdb_header {
> - u8 signature[16];
> - u16 version;
> - u16 header_size;
> - u16 bdb_size;
> -} __packed;
> -
> -/* strictly speaking, this is a "skip" block, but it has interesting info */
> -struct vbios_data {
> - u8 type; /* 0 == desktop, 1 == mobile */
> - u8 relstage;
> - u8 chipset;
> - u8 lvds_present:1;
> - u8 tv_present:1;
> - u8 rsvd2:6; /* finish byte */
> - u8 rsvd3[4];
> - u8 signon[155];
> - u8 copyright[61];
> - u16 code_segment;
> - u8 dos_boot_mode;
> - u8 bandwidth_percent;
> - u8 rsvd4; /* popup memory size */
> - u8 resize_pci_bios;
> - u8 rsvd5; /* is crt already on ddc2 */
> -} __packed;
> -
> -/*
> - * There are several types of BIOS data blocks (BDBs), each block has
> - * an ID and size in the first 3 bytes (ID in first, size in next 2).
> - * Known types are listed below.
> */
> -#define BDB_GENERAL_FEATURES 1
> -#define BDB_GENERAL_DEFINITIONS2
> -#define BDB_OLD_TOGGLE_LIST3
> -#define BDB_MODE_SUPPORT_LIST 4
> -#define BDB_GENERIC_MODE_TABLE 5
> -#define BDB_EXT_MMIO_REGS 6
> -#define BDB_SWF_IO 7
> -#define BDB_SWF_MMIO 8
> -#define BDB_PSR9
> -#define BDB_MODE_REMOVAL_TABLE10
> -#define BDB_CHILD_DEVICE_TABLE11
> -#define BDB_DRIVER_FEATURES 12
> -#define BDB_DRIVER_PERSI
Re: [Intel-gfx] [PATCH v2 3/6] drm/i915: move VBT based eDP port check to intel_bios.c
On Mon, 2016-01-11 at 21:54 +0200, Jani Nikula wrote:
> Hide knowledge about VBT child devices in intel_bios.c.
>
Tested-by: Mika Kahola
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_bios.c | 33 +
> drivers/gpu/drm/i915/intel_dp.c | 21 +
> 3 files changed, 35 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 5f0d44b380aa..6ae828f984de 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3349,6 +3349,7 @@ int intel_bios_init(struct drm_i915_private *dev_priv);
> bool intel_bios_is_valid_vbt(const void *buf, size_t size);
> bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv);
> bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8
> *i2c_pin);
> +bool intel_bios_is_port_edp(struct drm_i915_private *dev_priv, enum port
> port);
>
> /* intel_opregion.c */
> #ifdef CONFIG_ACPI
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 099f3f0002a2..a7491a450cc8 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1503,3 +1503,36 @@ bool intel_bios_is_lvds_present(struct
> drm_i915_private *dev_priv, u8 *i2c_pin)
>
> return false;
> }
> +
> +/**
> + * intel_bios_is_port_edp - is the device in given port eDP
> + * @dev_priv:i915 device instance
> + * @port:port to check
> + *
> + * Return true if the device in %port is eDP.
> + */
> +bool intel_bios_is_port_edp(struct drm_i915_private *dev_priv, enum port
> port)
> +{
> + union child_device_config *p_child;
> + static const short port_mapping[] = {
> + [PORT_B] = DVO_PORT_DPB,
> + [PORT_C] = DVO_PORT_DPC,
> + [PORT_D] = DVO_PORT_DPD,
> + [PORT_E] = DVO_PORT_DPE,
> + };
> + int i;
> +
> + if (!dev_priv->vbt.child_dev_num)
> + return false;
> +
> + for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> + p_child = dev_priv->vbt.child_dev + i;
> +
> + if (p_child->common.dvo_port == port_mapping[port] &&
> + (p_child->common.device_type & DEVICE_TYPE_eDP_BITS) ==
> + (DEVICE_TYPE_eDP & DEVICE_TYPE_eDP_BITS))
> + return true;
> + }
> +
> + return false;
> +}
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 796e3d313cb9..02cb4e9bf5ea 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5068,14 +5068,6 @@ put_power:
> bool intel_dp_is_edp(struct drm_device *dev, enum port port)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> - union child_device_config *p_child;
> - int i;
> - static const short port_mapping[] = {
> - [PORT_B] = DVO_PORT_DPB,
> - [PORT_C] = DVO_PORT_DPC,
> - [PORT_D] = DVO_PORT_DPD,
> - [PORT_E] = DVO_PORT_DPE,
> - };
>
> /*
>* eDP not supported on g4x. so bail out early just
> @@ -5087,18 +5079,7 @@ bool intel_dp_is_edp(struct drm_device *dev, enum port
> port)
> if (port == PORT_A)
> return true;
>
> - if (!dev_priv->vbt.child_dev_num)
> - return false;
> -
> - for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> - p_child = dev_priv->vbt.child_dev + i;
> -
> - if (p_child->common.dvo_port == port_mapping[port] &&
> - (p_child->common.device_type & DEVICE_TYPE_eDP_BITS) ==
> - (DEVICE_TYPE_eDP & DEVICE_TYPE_eDP_BITS))
> - return true;
> - }
> - return false;
> + return intel_bios_is_port_edp(dev_priv, port);
> }
>
> void
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/6] drm/i915: move VBT based DSI presence check to intel_bios.c
On Mon, 2016-01-11 at 21:54 +0200, Jani Nikula wrote:
> Hide knowledge about VBT child devices in intel_bios.c.
>
Tested-by: Mika Kahola
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> drivers/gpu/drm/i915/intel_bios.c | 33 -
> drivers/gpu/drm/i915/intel_dsi.c | 23 ++-
> 3 files changed, 47 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 6ae828f984de..f8516f564d0a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1474,7 +1474,6 @@ struct intel_vbt_data {
>
> /* MIPI DSI */
> struct {
> - u16 port;
> u16 panel_id;
> struct mipi_config *config;
> struct mipi_pps_data *pps;
> @@ -3350,6 +3349,7 @@ bool intel_bios_is_valid_vbt(const void *buf, size_t
> size);
> bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv);
> bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8
> *i2c_pin);
> bool intel_bios_is_port_edp(struct drm_i915_private *dev_priv, enum port
> port);
> +bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv, enum port
> *port);
>
> /* intel_opregion.c */
> #ifdef CONFIG_ACPI
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index a7491a450cc8..94c2baa50db7 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1221,7 +1221,6 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
> &&p_child->common.device_type & DEVICE_TYPE_MIPI_OUTPUT) {
> DRM_DEBUG_KMS("Found MIPI as LFP\n");
> dev_priv->vbt.has_mipi = 1;
> - dev_priv->vbt.dsi.port = p_child->common.dvo_port;
> }
>
> child_dev_ptr = dev_priv->vbt.child_dev + count;
> @@ -1536,3 +1535,35 @@ bool intel_bios_is_port_edp(struct drm_i915_private
> *dev_priv, enum port port)
>
> return false;
> }
> +
> +/**
> + * intel_bios_is_dsi_present - is DSI present in VBT
> + * @dev_priv:i915 device instance
> + * @port:port for DSI if present
> + *
> + * Return true if DSI is present, and return the port in %port.
> + */
> +bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv,
> +enum port *port)
> +{
> + union child_device_config *p_child;
> + int i;
> +
> + for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> + p_child = dev_priv->vbt.child_dev + i;
> +
> + if (!(p_child->common.device_type & DEVICE_TYPE_MIPI_OUTPUT))
> + continue;
> +
> + switch (p_child->common.dvo_port) {
> + case DVO_PORT_MIPIA:
> + case DVO_PORT_MIPIB:
> + case DVO_PORT_MIPIC:
> + case DVO_PORT_MIPID:
> + *port = p_child->common.dvo_port - DVO_PORT_MIPIA;
> + return true;
> + }
> + }
> +
> + return false;
> +}
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 91cef3525c93..33f219cfba43 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -1112,9 +1112,15 @@ void intel_dsi_init(struct drm_device *dev)
> DRM_DEBUG_KMS("\n");
>
> /* There is no detection method for MIPI so rely on VBT */
> - if (!dev_priv->vbt.has_mipi)
> + if (!intel_bios_is_dsi_present(dev_priv, &port))
> return;
>
> + if (port != PORT_A && port != PORT_C) {
> + DRM_DEBUG_KMS("VBT has unsupported DSI port %c\n",
> + port_name(port));
> + return;
> + }
> +
> if (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev)) {
> dev_priv->mipi_mmio_base = VLV_MIPI_BASE;
> } else {
> @@ -1153,16 +1159,15 @@ void intel_dsi_init(struct drm_device *dev)
> intel_connector->unregister = intel_connector_unregister;
>
> /* Pipe A maps to MIPI DSI port A, pipe B maps to MIPI DSI port C */
> - if (dev_priv->vbt.dsi.port == DVO_PORT_MIPIA) {
> - intel_encoder->crtc_mask = (1 << PIPE_A);
> - intel_dsi->ports = (1 << PORT_A);
> - } else if (dev_priv->vbt.dsi.port == DVO_PORT_MIPIC) {
> - intel_encoder->crtc_mask = (1 << PIPE_B);
> - intel_dsi->ports = (1 << PORT_C);
> - }
> + if (port == PORT_A)
> + intel_encoder->crtc_mask = 1 << PIPE_A;
> + else
> + intel_encoder->crtc_mask = 1 << PIPE_B;
>
> if (dev_priv->vbt.dsi.config->dual_link)
> - intel_dsi->ports = ((1 << PORT_A) | (1 << PORT_C));
> + intel_dsi->ports = (1 << PORT_A) | (1 << PORT_C);
> + else
> + intel_dsi->ports = 1 << port;
>
> /* Create a DSI host (and a device) for each port. */
>
[Intel-gfx] [PATCH 1/2] drm/i915: Start WM computation from scratch on ILK-BDW
From: Ville Syrjälä
ilk_compute_pipe_wm() assumes as zeroed pipe_wm structure when it
starts. We used to pass such a zeroed struct in, but this got broken
when the pipe_wm structure got embedded in the crtc state.
To fix it without too much fuzz, we need to resort to a memset().
Fixes: 4e0963c7663b ("drm/i915: Calculate pipe watermarks into CRTC state (v3)")
Cc: Matt Roper
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 9df9e9a22f3c..e9f4e6e7b736 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2317,6 +2317,7 @@ static int ilk_compute_pipe_wm(struct intel_crtc
*intel_crtc,
return PTR_ERR(cstate);
pipe_wm = &cstate->wm.optimal.ilk;
+ memset(pipe_wm, 0, sizeof(*pipe_wm));
for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) {
ps = drm_atomic_get_plane_state(state,
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Use the active wm config for merging on ILK-BDW
From: Ville Syrjälä
ilk_program_watermarks() is supposed to merge the active watermarks from
all pipes. Thus we need to use the active config too instead of some
precomputed stuff.
Fixes: aa363136866c ("drm/i915: Calculate watermark configuration during atomic
check (v2)")
Cc: Matt Roper
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 32 ++--
1 file changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e9f4e6e7b736..f44a961183d7 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3680,23 +3680,43 @@ static void skl_update_wm(struct drm_crtc *crtc)
dev_priv->wm.skl_hw = *results;
}
+static void ilk_compute_wm_config(struct drm_device *dev,
+ struct intel_wm_config *config)
+{
+ struct intel_crtc *crtc;
+
+ /* Compute the currently _active_ config */
+ for_each_intel_crtc(dev, crtc) {
+ const struct intel_pipe_wm *wm = &crtc->wm.active.ilk;
+
+ if (!wm->pipe_enabled)
+ continue;
+
+ config->sprites_enabled |= wm->sprites_enabled;
+ config->sprites_scaled |= wm->sprites_scaled;
+ config->num_pipes_active++;
+ }
+}
+
static void ilk_program_watermarks(struct drm_i915_private *dev_priv)
{
struct drm_device *dev = dev_priv->dev;
struct intel_pipe_wm lp_wm_1_2 = {}, lp_wm_5_6 = {}, *best_lp_wm;
struct ilk_wm_maximums max;
- struct intel_wm_config *config = &dev_priv->wm.config;
+ struct intel_wm_config config = {};
struct ilk_wm_values results = {};
enum intel_ddb_partitioning partitioning;
- ilk_compute_wm_maximums(dev, 1, config, INTEL_DDB_PART_1_2, &max);
- ilk_wm_merge(dev, config, &max, &lp_wm_1_2);
+ ilk_compute_wm_config(dev, &config);
+
+ ilk_compute_wm_maximums(dev, 1, &config, INTEL_DDB_PART_1_2, &max);
+ ilk_wm_merge(dev, &config, &max, &lp_wm_1_2);
/* 5/6 split only in single pipe config on IVB+ */
if (INTEL_INFO(dev)->gen >= 7 &&
- config->num_pipes_active == 1 && config->sprites_enabled) {
- ilk_compute_wm_maximums(dev, 1, config, INTEL_DDB_PART_5_6,
&max);
- ilk_wm_merge(dev, config, &max, &lp_wm_5_6);
+ config.num_pipes_active == 1 && config.sprites_enabled) {
+ ilk_compute_wm_maximums(dev, 1, &config, INTEL_DDB_PART_5_6,
&max);
+ ilk_wm_merge(dev, &config, &max, &lp_wm_5_6);
best_lp_wm = ilk_find_best_result(dev, &lp_wm_1_2, &lp_wm_5_6);
} else {
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: add onoff utility function
On Thu, Jan 14, 2016 at 12:53:34PM +0200, Jani Nikula wrote:
> Add a common function to return "on" or "off" string based on the
> argument, and drop the local versions of it.
>
> This is the onoff version of
>
> commit 42a8ca4cb4a48ddbf40e8edb291425e76bcdc230
> Author: Jani Nikula
> Date: Thu Aug 27 16:23:30 2015 +0300
>
> drm/i915: add yesno utility function
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_drv.c | 6 +++---
> drivers/gpu/drm/i915/i915_drv.h | 5 +
> drivers/gpu/drm/i915/intel_display.c | 30 --
> drivers/gpu/drm/i915/intel_dp.c | 9 ++---
> drivers/gpu/drm/i915/intel_pm.c | 11 +--
> 5 files changed, 27 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index f17a2b0c2493..975af3568521 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1335,8 +1335,8 @@ static int vlv_wait_for_gt_wells(struct
> drm_i915_private *dev_priv,
> return 0;
>
> DRM_DEBUG_KMS("waiting for GT wells to go %s (%08x)\n",
> - wait_for_on ? "on" : "off",
> - I915_READ(VLV_GTLC_PW_STATUS));
> + onoff(wait_for_on),
> + I915_READ(VLV_GTLC_PW_STATUS));
>
> /*
>* RC6 transitioning can be delayed up to 2 msec (see
> @@ -1345,7 +1345,7 @@ static int vlv_wait_for_gt_wells(struct
> drm_i915_private *dev_priv,
> err = wait_for(COND, 3);
> if (err)
> DRM_ERROR("timeout waiting for GT wells to go %s\n",
> - wait_for_on ? "on" : "off");
> + onoff(wait_for_on));
>
> return err;
> #undef COND
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 104bd1809936..eb7bb97f7316 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -102,6 +102,11 @@ static inline const char *yesno(bool v)
> return v ? "yes" : "no";
> }
>
> +static inline const char *onoff(bool v)
> +{
> + return v ? "on" : "off";
> +}
> +
> enum pipe {
> INVALID_PIPE = -1,
> PIPE_A = 0,
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index a087892dd797..0f52f71402a0 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1150,11 +1150,6 @@ static void intel_wait_for_pipe_off(struct intel_crtc
> *crtc)
> }
> }
>
> -static const char *state_string(bool enabled)
> -{
> - return enabled ? "on" : "off";
> -}
> -
> /* Only for pre-ILK configs */
> void assert_pll(struct drm_i915_private *dev_priv,
> enum pipe pipe, bool state)
> @@ -1166,7 +1161,7 @@ void assert_pll(struct drm_i915_private *dev_priv,
> cur_state = !!(val & DPLL_VCO_ENABLE);
> I915_STATE_WARN(cur_state != state,
>"PLL state assertion failure (expected %s, current %s)\n",
> - state_string(state), state_string(cur_state));
> + onoff(state), onoff(cur_state));
> }
>
> /* XXX: the dsi pll is shared between MIPI DSI ports */
> @@ -1182,7 +1177,7 @@ static void assert_dsi_pll(struct drm_i915_private
> *dev_priv, bool state)
> cur_state = val & DSI_PLL_VCO_EN;
> I915_STATE_WARN(cur_state != state,
>"DSI PLL state assertion failure (expected %s, current %s)\n",
> - state_string(state), state_string(cur_state));
> + onoff(state), onoff(cur_state));
> }
> #define assert_dsi_pll_enabled(d) assert_dsi_pll(d, true)
> #define assert_dsi_pll_disabled(d) assert_dsi_pll(d, false)
> @@ -1206,14 +1201,13 @@ void assert_shared_dpll(struct drm_i915_private
> *dev_priv,
> bool cur_state;
> struct intel_dpll_hw_state hw_state;
>
> - if (WARN (!pll,
> - "asserting DPLL %s with no DPLL\n", state_string(state)))
> + if (WARN(!pll, "asserting DPLL %s with no DPLL\n", onoff(state)))
> return;
>
> cur_state = pll->get_hw_state(dev_priv, pll, &hw_state);
> I915_STATE_WARN(cur_state != state,
>"%s assertion failure (expected %s, current %s)\n",
> - pll->name, state_string(state), state_string(cur_state));
> + pll->name, onoff(state), onoff(cur_state));
> }
>
> static void assert_fdi_tx(struct drm_i915_private *dev_priv,
> @@ -1233,7 +1227,7 @@ static void assert_fdi_tx(struct drm_i915_private
> *dev_priv,
> }
> I915_STATE_WARN(cur_state != state,
>"FDI TX state assertion failure (expected %s, current %s)\n",
> - state_string(state), state_string(cur_state));
> + onoff(state), onoff(cur_state));
> }
> #define assert_fdi_tx_enabled(d, p) assert_fdi_tx(d, p, true)
> #define assert_fdi_tx_disabled(d, p) assert_fdi_tx(d, p, false)
>
Re: [Intel-gfx] [PATCH 4/6] drm/i915: Save sink_count for tracking changes to it
On Tue, 2016-01-05 at 18:20 +0530, Shubhangi Shrivastava wrote:
> Sink count can change between short pulse hpd hence this patch
> adds a member variable to intel_dp so we can track any changes
> between short pulse interrupts.
>
> Tested-by: Nathan D Ciobanu
> Signed-off-by: Sivakumar Thulasimani
> Signed-off-by: Shubhangi Shrivastava
> ---
> drivers/gpu/drm/i915/intel_dp.c | 7 +++
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 842790e..c2e8516 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4385,14 +4385,13 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
> /* If we're HPD-aware, SINK_COUNT changes dynamically */
> if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
> intel_dp->downstream_ports[0] & DP_DS_PORT_HPD) {
> - uint8_t reg;
>
> if (intel_dp_dpcd_read_wake(&intel_dp->aux, DP_SINK_COUNT,
> - ®, 1) < 0)
> + &intel_dp->sink_count, 1) < 0)
> return connector_status_unknown;
>
> - return DP_GET_SINK_COUNT(reg) ? connector_status_connected
> - :
> connector_status_disconnected;
> + return DP_GET_SINK_COUNT(intel_dp->sink_count) ?
> + connector_status_connected : connector_status_disconnected;
I think it would be better to have the value of intel_dp->sink_count ready for
consumption, i.e., store the result of DP_GET_SINK_COUNT().
Ander
> }
>
> /* If no HPD, poke DDC gently */
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 0438b57..88b05ba 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -757,6 +757,7 @@ struct intel_dp {
> uint32_t DP;
> int link_rate;
> uint8_t lane_count;
> + uint8_t sink_count;
> bool has_audio;
> enum hdmi_force_audio force_audio;
> bool limited_color_range;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] drm/i915: read sink_count dpcd always
On Tue, 2016-01-05 at 18:20 +0530, Shubhangi Shrivastava wrote:
> This patch reads sink_count dpcd always and removes its
> read operation based on values in downstream port dpcd.
>
> SINK_COUNT dpcd is not dependent on DOWNSTREAM_PORT_PRESENT dpcd.
> SINK_COUNT denotes if a display is attached, while
> DOWNSTREAM_PORT_PRESET indicates how many ports are available
> in the dongle where display can be attached. so it is possible
> for sink count to change irrespective of value in downstream
> port dpcd.
>
> Here is a table of possible values and scenarios
>
> sink_count downstream_port
> present
> 0 0 no display is attached
> 0 1 dongle is connected without display
> 1 0 display connected directly
> 1 1 display connected through dongle
>
> Tested-by: Nathan D Ciobanu
> Signed-off-by: Sivakumar Thulasimani
> Signed-off-by: Shubhangi Shrivastava
> ---
> drivers/gpu/drm/i915/intel_dp.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index c2e8516..0d58bfd 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3865,6 +3865,13 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> if (intel_dp->dpcd[DP_DPCD_REV] == 0)
> return false; /* DPCD not present */
>
> + if (intel_dp_dpcd_read_wake(&intel_dp->aux, DP_SINK_COUNT,
> + &intel_dp->sink_count, 1) < 0)
> + return false;
> +
> + if (!DP_GET_SINK_COUNT(intel_dp->sink_count))
> + return false;
> +
My understanding is that this function should only read the DPCD data while
detection based on that data is done in intel_dp_detect_dpcd(). With the return
on sink_count == 0 here, we skip the end of the function, which updates the
cached downstream port information. Is there a reason why we need this early
return here?
Also, I think this could be squashed with the previous patch.
Ander
> /* Check if the panel supports PSR */
> memset(intel_dp->psr_dpcd, 0, sizeof(intel_dp->psr_dpcd));
> if (is_edp(intel_dp)) {
> @@ -4386,10 +4393,6 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
> if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
> intel_dp->downstream_ports[0] & DP_DS_PORT_HPD) {
>
> - if (intel_dp_dpcd_read_wake(&intel_dp->aux, DP_SINK_COUNT,
> - &intel_dp->sink_count, 1) < 0)
> - return connector_status_unknown;
> -
> return DP_GET_SINK_COUNT(intel_dp->sink_count) ?
> connector_status_connected : connector_status_disconnected;
> }
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: add onoff utility function
On Thu, 14 Jan 2016, Ville Syrjälä wrote:
> On Thu, Jan 14, 2016 at 12:53:34PM +0200, Jani Nikula wrote:
>> Add a common function to return "on" or "off" string based on the
>> argument, and drop the local versions of it.
>>
>> This is the onoff version of
>>
>> commit 42a8ca4cb4a48ddbf40e8edb291425e76bcdc230
>> Author: Jani Nikula
>> Date: Thu Aug 27 16:23:30 2015 +0300
>>
>> drm/i915: add yesno utility function
>>
>> Signed-off-by: Jani Nikula
>
> Reviewed-by: Ville Syrjälä
Pushed to drm-intel-next-queued, thanks for the review.
BR,
Jani.
>
>> ---
>> drivers/gpu/drm/i915/i915_drv.c | 6 +++---
>> drivers/gpu/drm/i915/i915_drv.h | 5 +
>> drivers/gpu/drm/i915/intel_display.c | 30 --
>> drivers/gpu/drm/i915/intel_dp.c | 9 ++---
>> drivers/gpu/drm/i915/intel_pm.c | 11 +--
>> 5 files changed, 27 insertions(+), 34 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.c
>> b/drivers/gpu/drm/i915/i915_drv.c
>> index f17a2b0c2493..975af3568521 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.c
>> +++ b/drivers/gpu/drm/i915/i915_drv.c
>> @@ -1335,8 +1335,8 @@ static int vlv_wait_for_gt_wells(struct
>> drm_i915_private *dev_priv,
>> return 0;
>>
>> DRM_DEBUG_KMS("waiting for GT wells to go %s (%08x)\n",
>> -wait_for_on ? "on" : "off",
>> -I915_READ(VLV_GTLC_PW_STATUS));
>> + onoff(wait_for_on),
>> + I915_READ(VLV_GTLC_PW_STATUS));
>>
>> /*
>> * RC6 transitioning can be delayed up to 2 msec (see
>> @@ -1345,7 +1345,7 @@ static int vlv_wait_for_gt_wells(struct
>> drm_i915_private *dev_priv,
>> err = wait_for(COND, 3);
>> if (err)
>> DRM_ERROR("timeout waiting for GT wells to go %s\n",
>> - wait_for_on ? "on" : "off");
>> + onoff(wait_for_on));
>>
>> return err;
>> #undef COND
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 104bd1809936..eb7bb97f7316 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -102,6 +102,11 @@ static inline const char *yesno(bool v)
>> return v ? "yes" : "no";
>> }
>>
>> +static inline const char *onoff(bool v)
>> +{
>> +return v ? "on" : "off";
>> +}
>> +
>> enum pipe {
>> INVALID_PIPE = -1,
>> PIPE_A = 0,
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index a087892dd797..0f52f71402a0 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -1150,11 +1150,6 @@ static void intel_wait_for_pipe_off(struct intel_crtc
>> *crtc)
>> }
>> }
>>
>> -static const char *state_string(bool enabled)
>> -{
>> -return enabled ? "on" : "off";
>> -}
>> -
>> /* Only for pre-ILK configs */
>> void assert_pll(struct drm_i915_private *dev_priv,
>> enum pipe pipe, bool state)
>> @@ -1166,7 +1161,7 @@ void assert_pll(struct drm_i915_private *dev_priv,
>> cur_state = !!(val & DPLL_VCO_ENABLE);
>> I915_STATE_WARN(cur_state != state,
>> "PLL state assertion failure (expected %s, current %s)\n",
>> - state_string(state), state_string(cur_state));
>> +onoff(state), onoff(cur_state));
>> }
>>
>> /* XXX: the dsi pll is shared between MIPI DSI ports */
>> @@ -1182,7 +1177,7 @@ static void assert_dsi_pll(struct drm_i915_private
>> *dev_priv, bool state)
>> cur_state = val & DSI_PLL_VCO_EN;
>> I915_STATE_WARN(cur_state != state,
>> "DSI PLL state assertion failure (expected %s, current %s)\n",
>> - state_string(state), state_string(cur_state));
>> +onoff(state), onoff(cur_state));
>> }
>> #define assert_dsi_pll_enabled(d) assert_dsi_pll(d, true)
>> #define assert_dsi_pll_disabled(d) assert_dsi_pll(d, false)
>> @@ -1206,14 +1201,13 @@ void assert_shared_dpll(struct drm_i915_private
>> *dev_priv,
>> bool cur_state;
>> struct intel_dpll_hw_state hw_state;
>>
>> -if (WARN (!pll,
>> - "asserting DPLL %s with no DPLL\n", state_string(state)))
>> +if (WARN(!pll, "asserting DPLL %s with no DPLL\n", onoff(state)))
>> return;
>>
>> cur_state = pll->get_hw_state(dev_priv, pll, &hw_state);
>> I915_STATE_WARN(cur_state != state,
>> "%s assertion failure (expected %s, current %s)\n",
>> - pll->name, state_string(state), state_string(cur_state));
>> +pll->name, onoff(state), onoff(cur_state));
>> }
>>
>> static void assert_fdi_tx(struct drm_i915_private *dev_priv,
>> @@ -1233,7 +1227,7 @@ static void assert_fdi_tx(struct drm_i915_private
>> *dev_priv,
>> }
>> I915_STATE_WARN(cur_state != state,
>> "FDI TX state assertion failure (expected %s, current %s)\n",
>> - state_string(state), state_string(cur_
[Intel-gfx] ✗ warning: Fi.CI.BAT
== Summary == Built on 058740f8fced6851aeda34f366f5330322cd585f drm-intel-nightly: 2016y-01m-13d-17h-07m-44s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: dmesg-warn -> PASS (bdw-nuci7) pass -> DMESG-WARN (bdw-ultra) bdw-nuci7total:138 pass:129 dwarn:0 dfail:0 fail:0 skip:9 bdw-ultratotal:138 pass:131 dwarn:1 dfail:0 fail:0 skip:6 bsw-nuc-2total:141 pass:115 dwarn:2 dfail:0 fail:0 skip:24 hsw-brixbox total:141 pass:134 dwarn:0 dfail:0 fail:0 skip:7 hsw-gt2 total:141 pass:137 dwarn:0 dfail:0 fail:0 skip:4 ilk-hp8440p total:141 pass:100 dwarn:4 dfail:0 fail:0 skip:37 ivb-t430stotal:135 pass:122 dwarn:3 dfail:4 fail:0 skip:6 skl-i5k-2total:141 pass:131 dwarn:2 dfail:0 fail:0 skip:8 skl-i7k-2total:141 pass:131 dwarn:2 dfail:0 fail:0 skip:8 snb-dellxps total:141 pass:122 dwarn:5 dfail:0 fail:0 skip:14 snb-x220ttotal:141 pass:122 dwarn:5 dfail:0 fail:1 skip:13 Results at /archive/results/CI_IGT_test/Patchwork_1186/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/8] drm/i915: Some more fb offsets[] prep stuff
From: Ville Syrjälä Yanked a few more prep patches from my earlier fb offsets[] work [1]. First few have r-bs, the rest don't. The last two patches are new. Things just tickled my OCD a bit too much so had to deal with them. [1] http://lists.freedesktop.org/archives/intel-gfx/2015-October/078050.html Ville Syrjälä (8): drm/i915: Don't leak framebuffer_references if drm_framebuffer_init() fails drm/i915: Set i915_ggtt_view_normal type explicitly drm/i915: Pass the dma_addr_t array as const to rotate_pages() drm/i915: Rename the rotated gtt view member to 'rotated' drm/i915: Pass stride to rotate_pages() drm/i915: Pass rotation_info to intel_rotate_fb_obj_pages() drm/i915: Make display gtt offsets u32 drm/i915: Standardize on 'cpp' for bytes per pixel drivers/gpu/drm/i915/i915_gem_gtt.c | 22 +++--- drivers/gpu/drm/i915/i915_gem_gtt.h | 2 +- drivers/gpu/drm/i915/intel_display.c | 49 +++--- drivers/gpu/drm/i915/intel_drv.h | 12 ++-- drivers/gpu/drm/i915/intel_pm.c | 128 +-- drivers/gpu/drm/i915/intel_sprite.c | 40 +-- 6 files changed, 123 insertions(+), 130 deletions(-) -- 2.4.10 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/8] drm/i915: Pass the dma_addr_t array as const to rotate_pages()
From: Ville Syrjälä
rotate_pages() doesn't modify the passed in dma addresses, so make
them const.
Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index d7f9ddd52840..7377b6725c33 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3331,7 +3331,7 @@ i915_gem_obj_lookup_or_create_ggtt_vma(struct
drm_i915_gem_object *obj,
}
static struct scatterlist *
-rotate_pages(dma_addr_t *in, unsigned int offset,
+rotate_pages(const dma_addr_t *in, unsigned int offset,
unsigned int width, unsigned int height,
struct sg_table *st, struct scatterlist *sg)
{
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/8] drm/i915: Don't leak framebuffer_references if drm_framebuffer_init() fails
From: Ville Syrjälä
Don't increment obj->framebuffer_references until we know we actually
managed to create the framebuffer.
Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a087892dd797..2bf2e76849b0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14899,7 +14899,6 @@ static int intel_framebuffer_init(struct drm_device
*dev,
drm_helper_mode_fill_fb_struct(&intel_fb->base, mode_cmd);
intel_fb->obj = obj;
- intel_fb->obj->framebuffer_references++;
ret = drm_framebuffer_init(dev, &intel_fb->base, &intel_fb_funcs);
if (ret) {
@@ -14907,6 +14906,8 @@ static int intel_framebuffer_init(struct drm_device
*dev,
return ret;
}
+ intel_fb->obj->framebuffer_references++;
+
return 0;
}
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/8] drm/i915: Set i915_ggtt_view_normal type explicitly
From: Ville Syrjälä
Just for clarity set the type for i915_ggtt_view_normal explicitly.
While at it fix the indentation fail for i915_ggtt_view_rotated.
Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 56f4f2e58d53..d7f9ddd52840 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -96,9 +96,11 @@
static int
i915_get_ggtt_vma_pages(struct i915_vma *vma);
-const struct i915_ggtt_view i915_ggtt_view_normal;
+const struct i915_ggtt_view i915_ggtt_view_normal = {
+ .type = I915_GGTT_VIEW_NORMAL,
+};
const struct i915_ggtt_view i915_ggtt_view_rotated = {
-.type = I915_GGTT_VIEW_ROTATED
+ .type = I915_GGTT_VIEW_ROTATED,
};
static int sanitize_enable_ppgtt(struct drm_device *dev, int enable_ppgtt)
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/8] drm/i915: Make display gtt offsets u32
From: Ville Syrjälä
Using 'unsigned long' for ggtt offsets doesn't make much sense. Use
'u32' instead since we've not yet seen a >4GiB ggtt.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 22 ++
drivers/gpu/drm/i915/intel_drv.h | 12 ++--
drivers/gpu/drm/i915/intel_sprite.c | 6 +++---
3 files changed, 19 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e68b2904e68f..686de845176e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2454,11 +2454,11 @@ static void intel_unpin_fb_obj(struct drm_framebuffer
*fb,
/* Computes the linear offset to the base tile and adjusts x, y. bytes per
pixel
* is assumed to be a power-of-two. */
-unsigned long intel_compute_tile_offset(struct drm_i915_private *dev_priv,
- int *x, int *y,
- uint64_t fb_modifier,
- unsigned int cpp,
- unsigned int pitch)
+u32 intel_compute_tile_offset(struct drm_i915_private *dev_priv,
+ int *x, int *y,
+ uint64_t fb_modifier,
+ unsigned int cpp,
+ unsigned int pitch)
{
if (fb_modifier != DRM_FORMAT_MOD_NONE) {
unsigned int tile_size, tile_width, tile_height;
@@ -2712,14 +2712,12 @@ static void i9xx_update_primary_plane(struct drm_plane
*primary,
struct drm_framebuffer *fb = plane_state->base.fb;
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
int plane = intel_crtc->plane;
- unsigned long linear_offset;
- int x = plane_state->src.x1 >> 16;
- int y = plane_state->src.y1 >> 16;
+ u32 linear_offset;
u32 dspcntr;
i915_reg_t reg = DSPCNTR(plane);
- int pixel_size;
-
- pixel_size = drm_format_plane_cpp(fb->pixel_format, 0);
+ int pixel_size = drm_format_plane_cpp(fb->pixel_format, 0);
+ int x = plane_state->src.x1 >> 16;
+ int y = plane_state->src.y1 >> 16;
dspcntr = DISPPLANE_GAMMA_ENABLE;
@@ -2845,7 +2843,7 @@ static void ironlake_update_primary_plane(struct
drm_plane *primary,
struct drm_framebuffer *fb = plane_state->base.fb;
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
int plane = intel_crtc->plane;
- unsigned long linear_offset;
+ u32 linear_offset;
u32 dspcntr;
i915_reg_t reg = DSPCNTR(plane);
int pixel_size = drm_format_plane_cpp(fb->pixel_format, 0);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 059b46e22c31..d955084ecda1 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -597,7 +597,7 @@ struct intel_crtc {
/* Display surface base address adjustement for pageflips. Note that on
* gen4+ this only adjusts up to a tile, offsets within a tile are
* handled in the hw itself (with the TILEOFF register). */
- unsigned long dspaddr_offset;
+ u32 dspaddr_offset;
int adjusted_x;
int adjusted_y;
@@ -1195,11 +1195,11 @@ void assert_fdi_rx_pll(struct drm_i915_private
*dev_priv,
void assert_pipe(struct drm_i915_private *dev_priv, enum pipe pipe, bool
state);
#define assert_pipe_enabled(d, p) assert_pipe(d, p, true)
#define assert_pipe_disabled(d, p) assert_pipe(d, p, false)
-unsigned long intel_compute_tile_offset(struct drm_i915_private *dev_priv,
- int *x, int *y,
- uint64_t fb_modifier,
- unsigned int cpp,
- unsigned int pitch);
+u32 intel_compute_tile_offset(struct drm_i915_private *dev_priv,
+ int *x, int *y,
+ uint64_t fb_modifier,
+ unsigned int cpp,
+ unsigned int pitch);
void intel_prepare_reset(struct drm_device *dev);
void intel_finish_reset(struct drm_device *dev);
void hsw_enable_pc8(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 0875c8e0ec0a..f1ee7db0811a 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -350,7 +350,7 @@ vlv_update_plane(struct drm_plane *dplane,
int pipe = intel_plane->pipe;
int plane = intel_plane->plane;
u32 sprctl;
- unsigned long sprsurf_offset, linear_offset;
+ u32 sprsurf_offset, linear_offset;
int pixel_size = drm_format_plane_cpp(fb->pixel_format, 0);
const struct drm_intel_sprite_colorkey *key = &plane_state->ckey;
int crtc_x = plane_state->dst.x1;
@@ -493,7 +493,7 @@ ivb_update_pla
[Intel-gfx] [PATCH 8/8] drm/i915: Standardize on 'cpp' for bytes per pixel
From: Ville Syrjälä
We more or less randomly call the "bytes per pixel" value
'cpp', 'bytes_per_pixel', 'pixel_size', or even 'bpp'. Let's just pick
one and stick to it. I've chosen 'cpp'.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 22 +++---
drivers/gpu/drm/i915/intel_pm.c | 128 +--
drivers/gpu/drm/i915/intel_sprite.c | 34 --
3 files changed, 87 insertions(+), 97 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 686de845176e..33a2b3e18754 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2715,7 +2715,7 @@ static void i9xx_update_primary_plane(struct drm_plane
*primary,
u32 linear_offset;
u32 dspcntr;
i915_reg_t reg = DSPCNTR(plane);
- int pixel_size = drm_format_plane_cpp(fb->pixel_format, 0);
+ int cpp = drm_format_plane_cpp(fb->pixel_format, 0);
int x = plane_state->src.x1 >> 16;
int y = plane_state->src.y1 >> 16;
@@ -2775,13 +2775,12 @@ static void i9xx_update_primary_plane(struct drm_plane
*primary,
if (IS_G4X(dev))
dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
- linear_offset = y * fb->pitches[0] + x * pixel_size;
+ linear_offset = y * fb->pitches[0] + x * cpp;
if (INTEL_INFO(dev)->gen >= 4) {
intel_crtc->dspaddr_offset =
intel_compute_tile_offset(dev_priv, &x, &y,
- fb->modifier[0],
- pixel_size,
+ fb->modifier[0], cpp,
fb->pitches[0]);
linear_offset -= intel_crtc->dspaddr_offset;
} else {
@@ -2798,7 +2797,7 @@ static void i9xx_update_primary_plane(struct drm_plane
*primary,
data and adding to linear_offset*/
linear_offset +=
(crtc_state->pipe_src_h - 1) * fb->pitches[0] +
- (crtc_state->pipe_src_w - 1) * pixel_size;
+ (crtc_state->pipe_src_w - 1) * cpp;
}
intel_crtc->adjusted_x = x;
@@ -2846,7 +2845,7 @@ static void ironlake_update_primary_plane(struct
drm_plane *primary,
u32 linear_offset;
u32 dspcntr;
i915_reg_t reg = DSPCNTR(plane);
- int pixel_size = drm_format_plane_cpp(fb->pixel_format, 0);
+ int cpp = drm_format_plane_cpp(fb->pixel_format, 0);
int x = plane_state->src.x1 >> 16;
int y = plane_state->src.y1 >> 16;
@@ -2885,11 +2884,10 @@ static void ironlake_update_primary_plane(struct
drm_plane *primary,
if (!IS_HASWELL(dev) && !IS_BROADWELL(dev))
dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
- linear_offset = y * fb->pitches[0] + x * pixel_size;
+ linear_offset = y * fb->pitches[0] + x * cpp;
intel_crtc->dspaddr_offset =
intel_compute_tile_offset(dev_priv, &x, &y,
- fb->modifier[0],
- pixel_size,
+ fb->modifier[0], cpp,
fb->pitches[0]);
linear_offset -= intel_crtc->dspaddr_offset;
if (plane_state->base.rotation == BIT(DRM_ROTATE_180)) {
@@ -2903,7 +2901,7 @@ static void ironlake_update_primary_plane(struct
drm_plane *primary,
data and adding to linear_offset*/
linear_offset +=
(crtc_state->pipe_src_h - 1) * fb->pitches[0] +
- (crtc_state->pipe_src_w - 1) * pixel_size;
+ (crtc_state->pipe_src_w - 1) * cpp;
}
}
@@ -14735,10 +14733,12 @@ u32 intel_fb_pitch_limit(struct drm_device *dev,
uint64_t fb_modifier,
u32 gen = INTEL_INFO(dev)->gen;
if (gen >= 9) {
+ int cpp = drm_format_plane_cpp(pixel_format, 0);
+
/* "The stride in bytes must not exceed the of the size of 8K
* pixels and 32K bytes."
*/
-return min(8192*drm_format_plane_cpp(pixel_format, 0), 32768);
+ return min(8192 * cpp, 32768);
} else if (gen >= 5 && !IS_VALLEYVIEW(dev) && !IS_CHERRYVIEW(dev)) {
return 32*1024;
} else if (gen >= 4) {
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 9df9e9a22f3c..fda14852f843 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -546,7 +546,7 @@ static const struct intel_watermark_params i845_wm_info = {
* intel_calculate_wm - calculate watermark level
* @clock_in_khz: pixel clock
* @wm: chip FIFO params
- * @pixel_size: display pixel size
+ * @cpp: bytes per pixel
* @latency
[Intel-gfx] [PATCH 4/8] drm/i915: Rename the rotated gtt view member to 'rotated'
From: Ville Syrjälä
Also rename 'rotation_info' to 'rotated' to match the view type exactly,
this should avoid confusion which union members is valid for each view
type.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 4 ++--
drivers/gpu/drm/i915/i915_gem_gtt.h | 2 +-
drivers/gpu/drm/i915/intel_display.c | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 7377b6725c33..a3ea6b15c762 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3366,7 +3366,7 @@ static struct sg_table *
intel_rotate_fb_obj_pages(struct i915_ggtt_view *ggtt_view,
struct drm_i915_gem_object *obj)
{
- struct intel_rotation_info *rot_info = &ggtt_view->params.rotation_info;
+ struct intel_rotation_info *rot_info = &ggtt_view->params.rotated;
unsigned int size_pages = rot_info->size >> PAGE_SHIFT;
unsigned int size_pages_uv;
struct sg_page_iter sg_iter;
@@ -3598,7 +3598,7 @@ i915_ggtt_view_size(struct drm_i915_gem_object *obj,
if (view->type == I915_GGTT_VIEW_NORMAL) {
return obj->base.size;
} else if (view->type == I915_GGTT_VIEW_ROTATED) {
- return view->params.rotation_info.size;
+ return view->params.rotated.size;
} else if (view->type == I915_GGTT_VIEW_PARTIAL) {
return view->params.partial.size << PAGE_SHIFT;
} else {
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index b448ad832dcf..75a84e116e93 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -156,7 +156,7 @@ struct i915_ggtt_view {
u64 offset;
unsigned int size;
} partial;
- struct intel_rotation_info rotation_info;
+ struct intel_rotation_info rotated;
} params;
struct sg_table *pages;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 2bf2e76849b0..e68b2904e68f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2290,7 +2290,7 @@ intel_fill_fb_ggtt_view(struct i915_ggtt_view *view,
struct drm_framebuffer *fb,
const struct drm_plane_state *plane_state)
{
struct drm_i915_private *dev_priv = to_i915(fb->dev);
- struct intel_rotation_info *info = &view->params.rotation_info;
+ struct intel_rotation_info *info = &view->params.rotated;
unsigned int tile_size, tile_width, tile_height, cpp;
*view = i915_ggtt_view_normal;
@@ -2957,7 +2957,7 @@ u32 intel_plane_obj_offset(struct intel_plane
*intel_plane,
offset = vma->node.start;
if (plane == 1) {
- offset += vma->ggtt_view.params.rotation_info.uv_start_page *
+ offset += vma->ggtt_view.params.rotated.uv_start_page *
PAGE_SIZE;
}
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/8] drm/i915: Pass stride to rotate_pages()
From: Ville Syrjälä
Pass stride in addition to width and height to rotate_pages(). For now
width and stride are the same, but once framebuffer offsets enter the
scene that may no longer be the case.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index a3ea6b15c762..d547eecac242 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -,6 +,7 @@ i915_gem_obj_lookup_or_create_ggtt_vma(struct
drm_i915_gem_object *obj,
static struct scatterlist *
rotate_pages(const dma_addr_t *in, unsigned int offset,
unsigned int width, unsigned int height,
+unsigned int stride,
struct sg_table *st, struct scatterlist *sg)
{
unsigned int column, row;
@@ -3344,7 +3345,7 @@ rotate_pages(const dma_addr_t *in, unsigned int offset,
}
for (column = 0; column < width; column++) {
- src_idx = width * (height - 1) + column;
+ src_idx = stride * (height - 1) + column;
for (row = 0; row < height; row++) {
st->nents++;
/* We don't need the pages, but need to initialize
@@ -3355,7 +3356,7 @@ rotate_pages(const dma_addr_t *in, unsigned int offset,
sg_dma_address(sg) = in[offset + src_idx];
sg_dma_len(sg) = PAGE_SIZE;
sg = sg_next(sg);
- src_idx -= width;
+ src_idx -= stride;
}
}
@@ -3408,6 +3409,7 @@ intel_rotate_fb_obj_pages(struct i915_ggtt_view
*ggtt_view,
/* Rotate the pages. */
sg = rotate_pages(page_addr_list, 0,
rot_info->width_pages, rot_info->height_pages,
+rot_info->width_pages,
st, NULL);
/* Append the UV plane if NV12. */
@@ -3423,6 +3425,7 @@ intel_rotate_fb_obj_pages(struct i915_ggtt_view
*ggtt_view,
rotate_pages(page_addr_list, uv_start_page,
rot_info->width_pages_uv,
rot_info->height_pages_uv,
+rot_info->width_pages_uv,
st, sg);
}
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/8] drm/i915: Pass rotation_info to intel_rotate_fb_obj_pages()
From: Ville Syrjälä
intel_rotate_fb_obj_pages() doens't need the entire gtt view, just the
rotation info suffices.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index d547eecac242..b3d8e2b0948c 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3364,10 +3364,9 @@ rotate_pages(const dma_addr_t *in, unsigned int offset,
}
static struct sg_table *
-intel_rotate_fb_obj_pages(struct i915_ggtt_view *ggtt_view,
+intel_rotate_fb_obj_pages(struct intel_rotation_info *rot_info,
struct drm_i915_gem_object *obj)
{
- struct intel_rotation_info *rot_info = &ggtt_view->params.rotated;
unsigned int size_pages = rot_info->size >> PAGE_SHIFT;
unsigned int size_pages_uv;
struct sg_page_iter sg_iter;
@@ -3507,7 +3506,7 @@ i915_get_ggtt_vma_pages(struct i915_vma *vma)
vma->ggtt_view.pages = vma->obj->pages;
else if (vma->ggtt_view.type == I915_GGTT_VIEW_ROTATED)
vma->ggtt_view.pages =
- intel_rotate_fb_obj_pages(&vma->ggtt_view, vma->obj);
+
intel_rotate_fb_obj_pages(&vma->ggtt_view.params.rotated, vma->obj);
else if (vma->ggtt_view.type == I915_GGTT_VIEW_PARTIAL)
vma->ggtt_view.pages =
intel_partial_pages(&vma->ggtt_view, vma->obj);
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/11] drm/i915: Add support for mapping an object page by page
On Thu, Jan 14, 2016 at 10:32:11AM +, Tvrtko Ursulin wrote:
> >diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
> >b/drivers/gpu/drm/i915/i915_gem_gtt.h
> >index b448ad8..5f86596 100644
> >--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> >+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> >@@ -317,6 +317,11 @@ struct i915_address_space {
> > uint64_t start,
> > uint64_t length,
> > bool use_scratch);
> >+void (*insert_page)(struct i915_address_space *vm,
> >+dma_addr_t addr,
> >+uint64_t offset,
> >+enum i915_cache_level cache_level,
> >+u32 flags);
> > void (*insert_entries)(struct i915_address_space *vm,
> >struct sg_table *st,
> >uint64_t start,
>
> Why not extend the current API to support start page offset and
> number of pages? Could default to full object like today if zero.
> Eg:
>
> void (*insert_entries)(struct i915_address_space *vm,
> struct sg_table *st,
> + unsigned page_offset,
> + unsigned num_pages,
Ouch. That would be quite slow for the insert_page() use case of
page-by-page looping.
> uint64_t start,
> enum i915_cache_level cache_level,
> u32 flags);
>
> That way we would not have two functions for effectively the same
> thing operating on different type of input parameters.
>
> If extending insert_entries is not preferable, then still we could
> add another compatible one, like insert_entries_range or something,
> and then both could share the same underlying implementation for
> less code.
>
> Like this, this patch already does not match current codebase - see
> assert_rpm_atomic_begin in insert_entries.
>
> Also if API between the two was compatible there would be no need
> for i915_gem_object_get_dma_address() and i915_gem_object_get_page()
> could be used instead.
The point was to write a lowlevel analog to provide a complementary API
to insert_entries that could be used for everywhere the we wanted to peek
through the GTT without even touching an object, i.e. for cases where we
might allocate a scratch page and temporarily put it into the GTT.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 3/9] staging/android/sync: Move sync framework out of staging
Hi John, 2016-01-14 John Harrison : > On 13/01/2016 19:00, Gustavo Padovan wrote: > >Hi John, > > > >2016-01-13 john.c.harri...@intel.com : > > > >>From: John Harrison > >> > >>The sync framework is now used by the i915 driver. Therefore it can be > >>moved out of staging and into the regular tree. Also, the public > >>interfaces can actually be made public and exported. > >I also have been working on de-staging the sync framework, but I've > >taken the approach of cleaning up the sync framework first. e.g., I got > >rid of sync_pt and use struct fence directly, also sync_timeline is now > >fence_timeline and its ops are gone in favor of fence_ops. My current > >work is here: > > > >https://git.kernel.org/cgit/linux/kernel/git/padovan/linux.git/log/?h=sync > > > >My current plan is clean up patches, add commits messages and document > >the changes I've made and then it should be ready for a RFC. > > > > Gustavo > Hello, > > Sounds good. I did note in my cover letter that these patches were only > being posted to let people review the i915 side of the changes on a complete > and working tree. Once we found out you were working on the de-stage the > decision was to let you get on with it and not duplicate the effort here :). > Note that patches four and five of this series are enhancements to the sync > code rather than just de-staging it. Would they still be applicable to your > new and improved version? Yes, with a small rework we can surely apply them on top of my changes. > Do you have an expected time scale for when your patches will land? I hope to send a RFC sometime next week, after that it will depend on how many comments and iterations I get from upstream. > Also, do you have any sort of overview document explaining what externally > visible changes you are making and what the implications are for other > drivers that are using the API? Not yet. But I'll write one. In short: SW_SYNC didn't change from API point of view. And I replaced sync_timeline with fence_timeline and sync_pt with fence changing the respective functions name, e.g., sync_timeline_create is now fence_timeline_create. > > Re the SW_SYNC_USER bits, we were just using that for a user land test > program. The idea was to create an timeline external to the i915 driver and > pass sync points in to i915 to be waited on and check that the i915 work > itself only happens after the test signals the timeline appropriately. If > this interface is going away, is there a plan to replace it with any other > mechanism for doing similar? Or do we have to create some kind of dummy > kernel module in order to get a testing timeline? I've moved it to debugfs. You just need to point your test program to /sync/sw_sync and everything will continue to work. Gustavo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm/i915: Splitting intel_dp_detect
On Wednesday 13 January 2016 07:03 PM, Ander Conselvan De Oliveira wrote:
On Wed, 2016-01-13 at 13:20 +0200, Ander Conselvan De Oliveira wrote:
On Tue, 2016-01-05 at 18:20 +0530, Shubhangi Shrivastava wrote:
intel_dp_detect() is called for not just detection but
during modes enumeration as well. Repeating the whole
sequence during each of these calls is wasteful and
time consuming.
This patch moves probing for panel, DPCD read etc done in
intel_dp_detect() to a new function intel_dp_long_pulse().
Note that the behavior of intel_dp_detect() is changed to
report connected or disconnected depending on whether the
EDID is available or not.
This change will be required by further patches in the series
to avoid performing duplicated DPCD operations on hotplug.
v2: Moved a hunk to next patch of the series.
Moved intel_dp_unset_edid to out. (Ander)
v3: Rephrased commit message and intel_dp_unset_dp() is called
within intel_dp_set_dp() to free the previous EDID. (Ander)
Tested-by: Nathan D Ciobanu
Signed-off-by: Sivakumar Thulasimani
Signed-off-by: Shubhangi Shrivastava
---
drivers/gpu/drm/i915/intel_dp.c | 56 +-
--
-
1 file changed, 35 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index 796e3d3..e3b4208 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -129,6 +129,7 @@ static void edp_panel_vdd_off(struct intel_dp *intel_dp,
bool sync);
static void vlv_init_panel_power_sequencer(struct intel_dp *intel_dp);
static void vlv_steal_power_sequencer(struct drm_device *dev,
enum pipe pipe);
+static void intel_dp_unset_edid(struct intel_dp *intel_dp);
static unsigned int intel_dp_unused_lane_mask(int lane_count)
{
@@ -4587,6 +4588,7 @@ intel_dp_set_edid(struct intel_dp *intel_dp)
struct intel_connector *intel_connector = intel_dp
->attached_connector;
struct edid *edid;
+ intel_dp_unset_edid(intel_dp);
edid = intel_dp_get_edid(intel_dp);
intel_connector->detect_edid = edid;
@@ -4607,9 +4609,10 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
intel_dp->has_audio = false;
}
-static enum drm_connector_status
-intel_dp_detect(struct drm_connector *connector, bool force)
+static void
+intel_dp_long_pulse(struct intel_connector *intel_connector)
{
+ struct drm_connector *connector = &intel_connector->base;
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct intel_digital_port *intel_dig_port =
dp_to_dig_port(intel_dp);
struct intel_encoder *intel_encoder = &intel_dig_port->base;
@@ -4619,17 +4622,6 @@ intel_dp_detect(struct drm_connector *connector, bool
force)
bool ret;
u8 sink_irq_vector;
- DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
- connector->base.id, connector->name);
- intel_dp_unset_edid(intel_dp);
-
- if (intel_dp->is_mst) {
- /* MST devices are disconnected from a monitor POV */
- if (intel_encoder->type != INTEL_OUTPUT_EDP)
- intel_encoder->type = INTEL_OUTPUT_DISPLAYPORT;
- return connector_status_disconnected;
- }
-
power_domain = intel_display_port_aux_power_domain(intel_encoder);
intel_display_power_get(to_i915(dev), power_domain);
@@ -4653,14 +4645,8 @@ intel_dp_detect(struct drm_connector *connector, bool
force)
intel_dp_probe_oui(intel_dp);
ret = intel_dp_probe_mst(intel_dp);
- if (ret) {
- /* if we are in MST mode then this connector
- won't appear connected or have anything with EDID on it
*/
- if (intel_encoder->type != INTEL_OUTPUT_EDP)
- intel_encoder->type = INTEL_OUTPUT_DISPLAYPORT;
This deletion is new in this version of the patch. I think we still need the
hunk above, otherwise we might not properly update the encoder type when we
switch from an HDMI sink connected through a level shifter to an MST sink.
Ander
Encoder type setting for MST is being done in intel_dp_detect(). So,
don't find a need to add it here.
- status = connector_status_disconnected;
+ if (ret)
goto out;
Also, there is no call to intel_dp_unset_edid() for this case, since the code
will reach the label 'out' with status being connected. So in this case the
return value of intel_dp_detect() will depend on the stale value of
intel_dp->detect_edid.
Ander
Yes.. Thats right.. Will add a call to intel_dp_unset_edid() in is_mst()
check of intel_dp_detect().
- }
/*
* Clearing NACK and defer counts to get their exact values
@@ -4691,8 +4677,36 @@ intel_dp_detect(struct drm_connector *connector, bool
force)
}
out:
+ if (status != connector_status_connected)
+ intel_dp_unset_edid(intel_dp);
intel_display_power
Re: [Intel-gfx] [PATCH 6/6] drm/i915: force full detect on sink count change
On Tue, 2016-01-05 at 18:20 +0530, Shubhangi Shrivastava wrote:
> This patch checks for changes in sink count between short pulse
> hpds and forces full detect when there is a change.
>
> This will allow both detection of hotplug and unplug of panels
> through dongles that give only short pulse for such events.
>
> v2: changed variable type from u8 to bool (Jani)
> return immediately if perform_full_detect is set(Siva)
>
> v3: changed method of determining full detection from using
> pointer to return code (Siva)
>
> Tested-by: Nathan D Ciobanu
> Signed-off-by: Sivakumar Thulasimani
> Signed-off-by: Shubhangi Shrivastava
> ---
> drivers/gpu/drm/i915/intel_dp.c | 30 +++---
> 1 file changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 0d58bfd..8a659ee 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4331,12 +4331,14 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
> * 3. Use Link Training from 2.5.3.3 and 3.5.1.3
> * 4. Check link status on receipt of hot-plug interrupt
> */
> -static void
> +static bool
Please expand the comment above to indicate what the return value of this
function is supposed to mean.
> intel_dp_short_pulse(struct intel_dp *intel_dp)
> {
> struct drm_device *dev = intel_dp_to_dev(intel_dp);
> u8 sink_irq_vector;
> u8 link_status[DP_LINK_STATUS_SIZE];
> + u8 old_sink_count = intel_dp->sink_count;
> + bool ret;
>
> /*
>* Clearing compliance test variables to allow capturing
> @@ -4348,12 +4350,20 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
>
> /* Try to read receiver status if the link appears to be up */
> if (!intel_dp_get_link_status(intel_dp, link_status)) {
> - return;
> + return false;
> }
>
> - /* Now read the DPCD to see if it's actually running */
> - if (!intel_dp_get_dpcd(intel_dp)) {
> - return;
> + /*
> + * Now read the DPCD to see if it's actually running
> + * Don't return immediately if dpcd read failed,
> + * if sink count was 1 and dpcd read failed we need
> + * to do full detection
> + */
> + ret = intel_dp_get_dpcd(intel_dp);
> +
> + if ((old_sink_count != intel_dp->sink_count) || !ret) {
I don't see the connection of the comment above with this. If the dpcd read
fails, the 'return false' will be reached regardless of the previous value of
intel_dp->sink_count. Did you intend to do something different or did I miss
something?
> + /* No need to proceed if we are going to do full detect */
> + return false;
> }
>
> /* Try to read the source of the interrupt */
> @@ -4373,6 +4383,8 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
> drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
> intel_dp_check_link_status(intel_dp);
> drm_modeset_unlock(&dev->mode_config.connection_mutex);
> +
> + return true;
> }
>
> /* XXX this is probably wrong for multiple downstream ports */
> @@ -5095,8 +5107,12 @@ intel_dp_hpd_pulse(struct intel_digital_port
> *intel_dig_port, bool long_hpd)
> }
> }
>
> - if (!intel_dp->is_mst)
> - intel_dp_short_pulse(intel_dp);
> + if (!intel_dp->is_mst) {
> + if (!intel_dp_short_pulse(intel_dp)) {
> + intel_dp_long_pulse(intel_dp
> ->attached_connector);
> + goto put_power;
It could be in a follow up patch, but I think its a good moment to get rid of
the goto put_power. The only thing they do is skip the 'ret = IRQ_HANDLED'
assignment now.
Ander
> + }
> + }
> }
>
> ret = IRQ_HANDLED;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/dsi: lose the loose 666 format name in favor of packed
On Thu, 2016-01-14 at 12:28 +0200, Jani Nikula wrote:
> The enum mipi_dsi_pixel_format defines MIPI_DSI_FMT_RGB666 for the
> "loose" 24 bpp format and MIPI_DSI_FMT_RGB666_PACKED for the 18 bpp
> format. We have this the other way round, defining a loose version for
> 24 bpp.
>
> Follow suit with what's in enum mipi_dsi_pixel_format to avoid future
> confusion. Rename
>
> VID_MODE_FORMAT_RGB666 -> VID_MODE_FORMAT_RGB666_PACKED
> VID_MODE_FORMAT_RGB666_LOOSE -> VID_MODE_FORMAT_RGB666
>
Tested-by: Mika Kahola
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_reg.h| 4 ++--
> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 2 +-
> drivers/gpu/drm/i915/intel_dsi_pll.c | 4 ++--
> 3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 0a988895165f..379c61677334 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7849,8 +7849,8 @@ enum skl_disp_power_wells {
> #define VID_MODE_FORMAT_MASK(0xf << 7)
> #define VID_MODE_NOT_SUPPORTED (0 << 7)
> #define VID_MODE_FORMAT_RGB565 (1 << 7)
> -#define VID_MODE_FORMAT_RGB666 (2 << 7)
> -#define VID_MODE_FORMAT_RGB666_LOOSE(3 << 7)
> +#define VID_MODE_FORMAT_RGB666_PACKED (2 << 7)
> +#define VID_MODE_FORMAT_RGB666 (3 << 7)
> #define VID_MODE_FORMAT_RGB888 (4 << 7)
> #define CMD_MODE_CHANNEL_NUMBER_SHIFT 5
> #define CMD_MODE_CHANNEL_NUMBER_MASK(3 << 5)
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index 1d43e6f37fc1..3f4b9712bffd 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -420,7 +420,7 @@ struct drm_panel *vbt_panel_init(struct intel_dsi
> *intel_dsi, u16 panel_id)
> intel_dsi->dual_link = mipi_config->dual_link;
> intel_dsi->pixel_overlap = mipi_config->pixel_overlap;
>
> - if (intel_dsi->pixel_format == VID_MODE_FORMAT_RGB666)
> + if (intel_dsi->pixel_format == VID_MODE_FORMAT_RGB666_PACKED)
> bits_per_pixel = 18;
> else if (intel_dsi->pixel_format == VID_MODE_FORMAT_RGB565)
> bits_per_pixel = 16;
> diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
> b/drivers/gpu/drm/i915/intel_dsi_pll.c
> index bb5e95a1a453..f70df2b42b23 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_pll.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
> @@ -37,10 +37,10 @@ static int dsi_pixel_format_bpp(int pixel_format)
> switch (pixel_format) {
> default:
> case VID_MODE_FORMAT_RGB888:
> - case VID_MODE_FORMAT_RGB666_LOOSE:
> + case VID_MODE_FORMAT_RGB666:
> bpp = 24;
> break;
> - case VID_MODE_FORMAT_RGB666:
> + case VID_MODE_FORMAT_RGB666_PACKED:
> bpp = 18;
> break;
> case VID_MODE_FORMAT_RGB565:
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/dsi: start using enum mipi_dsi_pixel_format
On Thu, 2016-01-14 at 12:28 +0200, Jani Nikula wrote:
> A small step moving us closer to DRM MIPI DSI code. Use enum
> mipi_dsi_pixel_format instead of our own. The first benefit is being
> able to use common mipi_dsi_pixel_format_to_bpp().
>
> There's a little back and forth conversion with the VBT -> enum ->
> register, since we have just shoved the VBT value into the register
> directly. Longer term, all the VBT parsing and deciphering should be
> done in intel_bios.c, and abstracted there.
>
Tested-by: Mika Kahola
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_dsi.c | 19 +++-
> drivers/gpu/drm/i915/intel_dsi.h | 8 +--
> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 36
> +-
> drivers/gpu/drm/i915/intel_dsi_pll.c | 30 +
> 4 files changed, 54 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 91cef3525c93..83f18791c009 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -840,6 +840,23 @@ static void set_dsi_timings(struct drm_encoder *encoder,
> }
> }
>
> +static u32 pixel_format_to_reg(enum mipi_dsi_pixel_format fmt)
> +{
> + switch (fmt) {
> + case MIPI_DSI_FMT_RGB888:
> + return VID_MODE_FORMAT_RGB888;
> + case MIPI_DSI_FMT_RGB666:
> + return VID_MODE_FORMAT_RGB666;
> + case MIPI_DSI_FMT_RGB666_PACKED:
> + return VID_MODE_FORMAT_RGB666_PACKED;
> + case MIPI_DSI_FMT_RGB565:
> + return VID_MODE_FORMAT_RGB565;
> + default:
> + MISSING_CASE(fmt);
> + return VID_MODE_FORMAT_RGB666;
> + }
> +}
> +
> static void intel_dsi_prepare(struct intel_encoder *intel_encoder)
> {
> struct drm_encoder *encoder = &intel_encoder->base;
> @@ -910,7 +927,7 @@ static void intel_dsi_prepare(struct intel_encoder
> *intel_encoder)
> val |= intel_dsi->channel << VID_MODE_CHANNEL_NUMBER_SHIFT;
>
> /* XXX: cross-check bpp vs. pixel format? */
> - val |= intel_dsi->pixel_format;
> + val |= pixel_format_to_reg(intel_dsi->pixel_format);
> }
>
> tmp = 0;
> diff --git a/drivers/gpu/drm/i915/intel_dsi.h
> b/drivers/gpu/drm/i915/intel_dsi.h
> index de7be7f3fb42..54f072cd78f1 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.h
> +++ b/drivers/gpu/drm/i915/intel_dsi.h
> @@ -62,8 +62,12 @@ struct intel_dsi {
> /* number of DSI lanes */
> unsigned int lane_count;
>
> - /* video mode pixel format for MIPI_DSI_FUNC_PRG register */
> - u32 pixel_format;
> + /*
> + * video mode pixel format
> + *
> + * XXX: consolidate on .format in struct mipi_dsi_device.
> + */
> + enum mipi_dsi_pixel_format pixel_format;
>
> /* video mode format for MIPI_VIDEO_MODE_FORMAT register */
> u32 video_mode_format;
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index 3f4b9712bffd..9a963fa3491c 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -392,6 +392,25 @@ static const struct drm_panel_funcs vbt_panel_funcs = {
> .get_modes = vbt_panel_get_modes,
> };
>
> +/* XXX: This should be done when parsing the VBT in intel_bios.c */
> +static enum mipi_dsi_pixel_format pixel_format_from_vbt(u32 fmt)
> +{
> + /* It just so happens the VBT matches register contents. */
> + switch (fmt) {
> + case VID_MODE_FORMAT_RGB888:
> + return MIPI_DSI_FMT_RGB888;
> + case VID_MODE_FORMAT_RGB666:
> + return MIPI_DSI_FMT_RGB666;
> + case VID_MODE_FORMAT_RGB666_PACKED:
> + return MIPI_DSI_FMT_RGB666_PACKED;
> + case VID_MODE_FORMAT_RGB565:
> + return MIPI_DSI_FMT_RGB565;
> + default:
> + MISSING_CASE(fmt);
> + return MIPI_DSI_FMT_RGB666;
> + }
> +}
> +
> struct drm_panel *vbt_panel_init(struct intel_dsi *intel_dsi, u16 panel_id)
> {
> struct drm_device *dev = intel_dsi->base.base.dev;
> @@ -400,7 +419,7 @@ struct drm_panel *vbt_panel_init(struct intel_dsi
> *intel_dsi, u16 panel_id)
> struct mipi_pps_data *pps = dev_priv->vbt.dsi.pps;
> struct drm_display_mode *mode = dev_priv->vbt.lfp_lvds_vbt_mode;
> struct vbt_panel *vbt_panel;
> - u32 bits_per_pixel = 24;
> + u32 bpp;
> u32 tlpx_ns, extra_byte_count, bitrate, tlpx_ui;
> u32 ui_num, ui_den;
> u32 prepare_cnt, exit_zero_cnt, clk_zero_cnt, trail_cnt;
> @@ -416,15 +435,11 @@ struct drm_panel *vbt_panel_init(struct intel_dsi
> *intel_dsi, u16 panel_id)
> intel_dsi->eotp_pkt = mipi_config->eot_pkt_disabled ? 0 : 1;
> intel_dsi->clock_stop = mipi_config->enable_clk_stop ? 1 : 0;
> intel_dsi->lane_count = mipi_config->lane_cnt + 1;
> - intel_dsi->pixel_form
[Intel-gfx] ✗ failure: Fi.CI.BAT
== Summary == Built on 8fb2feecca499d11e104264071ac55e273e23af5 drm-intel-nightly: 2016y-01m-14d-13h-06m-44s UTC integration manifest Test gem_basic: Subgroup create-close: pass -> DMESG-WARN (skl-i7k-2) Test gem_cpu_reloc: Subgroup basic: pass -> DMESG-FAIL (skl-i7k-2) Test gem_ctx_param_basic: Subgroup basic: pass -> DMESG-WARN (skl-i7k-2) Subgroup invalid-param-set: pass -> DMESG-WARN (skl-i7k-2) Subgroup non-root-set-no-zeromap: pass -> DMESG-WARN (skl-i7k-2) Subgroup root-set-no-zeromap-disabled: pass -> DMESG-WARN (skl-i7k-2) Test gem_mmap: Subgroup basic: pass -> DMESG-WARN (skl-i7k-2) Test gem_mmap_gtt: Subgroup basic-read: pass -> DMESG-WARN (skl-i7k-2) Subgroup basic-write: pass -> DMESG-WARN (skl-i7k-2) Test gem_storedw_loop: Subgroup basic-render: dmesg-warn -> PASS (skl-i5k-2) UNSTABLE dmesg-warn -> PASS (bdw-nuci7) dmesg-warn -> PASS (skl-i7k-2) UNSTABLE Test kms_addfb_basic: Subgroup addfb25-modifier-no-flag: pass -> DMESG-WARN (skl-i7k-2) Subgroup addfb25-x-tiled-mismatch: pass -> DMESG-WARN (skl-i7k-2) Subgroup addfb25-yf-tiled: pass -> DMESG-WARN (skl-i7k-2) Subgroup bad-pitch-1024: pass -> DMESG-WARN (skl-i7k-2) Subgroup bad-pitch-63: pass -> DMESG-WARN (skl-i7k-2) Subgroup bad-pitch-999: pass -> DMESG-WARN (skl-i7k-2) Subgroup clobberred-modifier: pass -> DMESG-WARN (skl-i7k-2) Subgroup too-high: pass -> DMESG-WARN (skl-i7k-2) Subgroup too-wide: pass -> DMESG-WARN (skl-i7k-2) Subgroup unused-offsets: pass -> DMESG-WARN (skl-i7k-2) Test kms_flip: Subgroup basic-plain-flip: pass -> DMESG-FAIL (skl-i7k-2) Test kms_pipe_crc_basic: Subgroup nonblocking-crc-pipe-a-frame-sequence: pass -> DMESG-FAIL (skl-i7k-2) Subgroup read-crc-pipe-b-frame-sequence: pass -> DMESG-FAIL (skl-i7k-2) Test prime_self_import: Subgroup basic-with_two_bos: pass -> DMESG-WARN (skl-i7k-2) bdw-nuci7total:138 pass:129 dwarn:0 dfail:0 fail:0 skip:9 bdw-ultratotal:138 pass:131 dwarn:1 dfail:0 fail:0 skip:6 bsw-nuc-2total:141 pass:115 dwarn:2 dfail:0 fail:0 skip:24 hsw-brixbox total:141 pass:134 dwarn:0 dfail:0 fail:0 skip:7 hsw-gt2 total:141 pass:137 dwarn:0 dfail:0 fail:0 skip:4 ilk-hp8440p total:141 pass:101 dwarn:3 dfail:0 fail:0 skip:37 ivb-t430stotal:135 pass:122 dwarn:3 dfail:4 fail:0 skip:6 skl-i5k-2total:141 pass:132 dwarn:1 dfail:0 fail:0 skip:8 skl-i7k-2total:141 pass:108 dwarn:20 dfail:4 fail:0 skip:8 snb-dellxps total:141 pass:122 dwarn:5 dfail:0 fail:0 skip:14 snb-x220ttotal:141 pass:122 dwarn:5 dfail:0 fail:1 skip:13 Results at /archive/results/CI_IGT_test/Patchwork_1187/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 3/9] staging/android/sync: Move sync framework out of staging
On 14/01/2016 13:42, Gustavo Padovan wrote: Hi John, 2016-01-14 John Harrison : On 13/01/2016 19:00, Gustavo Padovan wrote: Hi John, 2016-01-13 john.c.harri...@intel.com : From: John Harrison The sync framework is now used by the i915 driver. Therefore it can be moved out of staging and into the regular tree. Also, the public interfaces can actually be made public and exported. I also have been working on de-staging the sync framework, but I've taken the approach of cleaning up the sync framework first. e.g., I got rid of sync_pt and use struct fence directly, also sync_timeline is now fence_timeline and its ops are gone in favor of fence_ops. My current work is here: https://git.kernel.org/cgit/linux/kernel/git/padovan/linux.git/log/?h=sync My current plan is clean up patches, add commits messages and document the changes I've made and then it should be ready for a RFC. Gustavo Hello, Sounds good. I did note in my cover letter that these patches were only being posted to let people review the i915 side of the changes on a complete and working tree. Once we found out you were working on the de-stage the decision was to let you get on with it and not duplicate the effort here :). Note that patches four and five of this series are enhancements to the sync code rather than just de-staging it. Would they still be applicable to your new and improved version? Yes, with a small rework we can surely apply them on top of my changes. Do you have an expected time scale for when your patches will land? I hope to send a RFC sometime next week, after that it will depend on how many comments and iterations I get from upstream. Make sure to CC myself and hopefully I should be able to do some testing/reviewing for you. Also, do you have any sort of overview document explaining what externally visible changes you are making and what the implications are for other drivers that are using the API? Not yet. But I'll write one. In short: SW_SYNC didn't change from API point of view. And I replaced sync_timeline with fence_timeline and sync_pt with fence changing the respective functions name, e.g., sync_timeline_create is now fence_timeline_create. Re the SW_SYNC_USER bits, we were just using that for a user land test program. The idea was to create an timeline external to the i915 driver and pass sync points in to i915 to be waited on and check that the i915 work itself only happens after the test signals the timeline appropriately. If this interface is going away, is there a plan to replace it with any other mechanism for doing similar? Or do we have to create some kind of dummy kernel module in order to get a testing timeline? I've moved it to debugfs. You just need to point your test program to /sync/sw_sync and everything will continue to work. Okay, that sounds easy enough :). Daniel Vetter, do you see any issues with using this in an IGT test? Gustavo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ failure: Fi.CI.BAT
On Thu, Jan 14, 2016 at 02:20:40PM -, Patchwork wrote: > == Summary == > > Built on 8fb2feecca499d11e104264071ac55e273e23af5 drm-intel-nightly: > 2016y-01m-14d-13h-06m-44s UTC integration manifest > > Test gem_basic: > Subgroup create-close: > pass -> DMESG-WARN (skl-i7k-2) > Test gem_cpu_reloc: > Subgroup basic: > pass -> DMESG-FAIL (skl-i7k-2) > Test gem_ctx_param_basic: > Subgroup basic: > pass -> DMESG-WARN (skl-i7k-2) > Subgroup invalid-param-set: > pass -> DMESG-WARN (skl-i7k-2) > Subgroup non-root-set-no-zeromap: > pass -> DMESG-WARN (skl-i7k-2) > Subgroup root-set-no-zeromap-disabled: > pass -> DMESG-WARN (skl-i7k-2) > Test gem_mmap: > Subgroup basic: > pass -> DMESG-WARN (skl-i7k-2) > Test gem_mmap_gtt: > Subgroup basic-read: > pass -> DMESG-WARN (skl-i7k-2) > Subgroup basic-write: > pass -> DMESG-WARN (skl-i7k-2) > Test gem_storedw_loop: > Subgroup basic-render: > dmesg-warn -> PASS (skl-i5k-2) UNSTABLE > dmesg-warn -> PASS (bdw-nuci7) > dmesg-warn -> PASS (skl-i7k-2) UNSTABLE > Test kms_addfb_basic: > Subgroup addfb25-modifier-no-flag: > pass -> DMESG-WARN (skl-i7k-2) > Subgroup addfb25-x-tiled-mismatch: > pass -> DMESG-WARN (skl-i7k-2) > Subgroup addfb25-yf-tiled: > pass -> DMESG-WARN (skl-i7k-2) > Subgroup bad-pitch-1024: > pass -> DMESG-WARN (skl-i7k-2) > Subgroup bad-pitch-63: > pass -> DMESG-WARN (skl-i7k-2) > Subgroup bad-pitch-999: > pass -> DMESG-WARN (skl-i7k-2) > Subgroup clobberred-modifier: > pass -> DMESG-WARN (skl-i7k-2) > Subgroup too-high: > pass -> DMESG-WARN (skl-i7k-2) > Subgroup too-wide: > pass -> DMESG-WARN (skl-i7k-2) > Subgroup unused-offsets: > pass -> DMESG-WARN (skl-i7k-2) > Test kms_flip: > Subgroup basic-plain-flip: > pass -> DMESG-FAIL (skl-i7k-2) > Test kms_pipe_crc_basic: > Subgroup nonblocking-crc-pipe-a-frame-sequence: > pass -> DMESG-FAIL (skl-i7k-2) > Subgroup read-crc-pipe-b-frame-sequence: > pass -> DMESG-FAIL (skl-i7k-2) > Test prime_self_import: > Subgroup basic-with_two_bos: > pass -> DMESG-WARN (skl-i7k-2) Looks like the GPU died or something on that skl. Can't imagine it being related to watermark patches. Unfortunately these didn't cure the recent underrun regressions from the ilk-ivb machines. So seems like there's something more busted somewhere. > > bdw-nuci7total:138 pass:129 dwarn:0 dfail:0 fail:0 skip:9 > bdw-ultratotal:138 pass:131 dwarn:1 dfail:0 fail:0 skip:6 > bsw-nuc-2total:141 pass:115 dwarn:2 dfail:0 fail:0 skip:24 > hsw-brixbox total:141 pass:134 dwarn:0 dfail:0 fail:0 skip:7 > hsw-gt2 total:141 pass:137 dwarn:0 dfail:0 fail:0 skip:4 > ilk-hp8440p total:141 pass:101 dwarn:3 dfail:0 fail:0 skip:37 > ivb-t430stotal:135 pass:122 dwarn:3 dfail:4 fail:0 skip:6 > skl-i5k-2total:141 pass:132 dwarn:1 dfail:0 fail:0 skip:8 > skl-i7k-2total:141 pass:108 dwarn:20 dfail:4 fail:0 skip:8 > snb-dellxps total:141 pass:122 dwarn:5 dfail:0 fail:0 skip:14 > snb-x220ttotal:141 pass:122 dwarn:5 dfail:0 fail:1 skip:13 > > Results at /archive/results/CI_IGT_test/Patchwork_1187/ -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ failure: Fi.CI.BAT
== Summary == Built on 8fb2feecca499d11e104264071ac55e273e23af5 drm-intel-nightly: 2016y-01m-14d-13h-06m-44s UTC integration manifest Test gem_ctx_basic: pass -> FAIL (bdw-ultra) Test gem_storedw_loop: Subgroup basic-render: dmesg-warn -> PASS (bdw-nuci7) dmesg-warn -> PASS (bdw-ultra) bdw-nuci7total:138 pass:129 dwarn:0 dfail:0 fail:0 skip:9 bdw-ultratotal:138 pass:131 dwarn:0 dfail:0 fail:1 skip:6 bsw-nuc-2total:141 pass:115 dwarn:2 dfail:0 fail:0 skip:24 hsw-brixbox total:141 pass:134 dwarn:0 dfail:0 fail:0 skip:7 hsw-gt2 total:141 pass:137 dwarn:0 dfail:0 fail:0 skip:4 ilk-hp8440p total:141 pass:101 dwarn:3 dfail:0 fail:0 skip:37 ivb-t430stotal:135 pass:122 dwarn:3 dfail:4 fail:0 skip:6 skl-i5k-2total:141 pass:131 dwarn:2 dfail:0 fail:0 skip:8 snb-dellxps total:141 pass:122 dwarn:5 dfail:0 fail:0 skip:14 snb-x220ttotal:141 pass:122 dwarn:5 dfail:0 fail:1 skip:13 Results at /archive/results/CI_IGT_test/Patchwork_1188/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ failure: Fi.CI.BAT
On Thu, Jan 14, 2016 at 02:49:45PM -, Patchwork wrote: > == Summary == > > Built on 8fb2feecca499d11e104264071ac55e273e23af5 drm-intel-nightly: > 2016y-01m-14d-13h-06m-44s UTC integration manifest > > Test gem_ctx_basic: > pass -> FAIL (bdw-ultra) "Returncode -15" and nothing more. Weird. > Test gem_storedw_loop: > Subgroup basic-render: > dmesg-warn -> PASS (bdw-nuci7) > dmesg-warn -> PASS (bdw-ultra) > > bdw-nuci7total:138 pass:129 dwarn:0 dfail:0 fail:0 skip:9 > bdw-ultratotal:138 pass:131 dwarn:0 dfail:0 fail:1 skip:6 > bsw-nuc-2total:141 pass:115 dwarn:2 dfail:0 fail:0 skip:24 > hsw-brixbox total:141 pass:134 dwarn:0 dfail:0 fail:0 skip:7 > hsw-gt2 total:141 pass:137 dwarn:0 dfail:0 fail:0 skip:4 > ilk-hp8440p total:141 pass:101 dwarn:3 dfail:0 fail:0 skip:37 > ivb-t430stotal:135 pass:122 dwarn:3 dfail:4 fail:0 skip:6 > skl-i5k-2total:141 pass:131 dwarn:2 dfail:0 fail:0 skip:8 > snb-dellxps total:141 pass:122 dwarn:5 dfail:0 fail:0 skip:14 > snb-x220ttotal:141 pass:122 dwarn:5 dfail:0 fail:1 skip:13 > > Results at /archive/results/CI_IGT_test/Patchwork_1188/ -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Decouple execbuf uAPI from internal implementation
From: Tvrtko Ursulin
At the moment execbuf ring selection is fully coupled to
internal ring ids which is not a good thing on its own.
This dependency is also spread between two source files and
not spelled out at either side which makes it hidden and
fragile.
This patch decouples this dependency by introducing an explicit
translation table of execbuf uAPI to ring id close to the only
call site (i915_gem_do_execbuffer).
This way we are free to change driver internal implementation
details without breaking userspace. All state relating to the
uAPI is now contained in, or next to, i915_gem_do_execbuffer.
As a side benefit, this patch decreases the compiled size
of i915_gem_do_execbuffer.
Signed-off-by: Tvrtko Ursulin
Cc: Daniel Vetter
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h| 4 +-
drivers/gpu/drm/i915/i915_gem.c| 2 +
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 103 +
drivers/gpu/drm/i915/intel_ringbuffer.h| 10 +--
4 files changed, 56 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index eb7bb97f7316..35d5d6099a44 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -334,7 +334,7 @@ struct drm_i915_file_private {
unsigned boosts;
} rps;
- struct intel_engine_cs *bsd_ring;
+ unsigned int bsd_ring;
};
enum intel_dpll_id {
@@ -1300,7 +1300,7 @@ struct i915_gem_mm {
bool busy;
/* the indicator for dispatch video commands on two BSD rings */
- int bsd_ring_dispatch_index;
+ unsigned int bsd_ring_dispatch_index;
/** Bit 6 swizzling required for X tiling */
uint32_t bit_6_swizzle_x;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ddc21d4b388d..26e6842f2df3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5112,6 +5112,8 @@ int i915_gem_open(struct drm_device *dev, struct drm_file
*file)
spin_lock_init(&file_priv->mm.lock);
INIT_LIST_HEAD(&file_priv->mm.request_list);
+ file_priv->bsd_ring = -1;
+
ret = i915_gem_context_open(dev, file);
if (ret)
kfree(file_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index d469c4779ff5..cd8646a23780 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1328,33 +1328,23 @@ i915_gem_ringbuffer_submission(struct
i915_execbuffer_params *params,
/**
* Find one BSD ring to dispatch the corresponding BSD command.
- * The Ring ID is returned.
+ * The ring index is returned.
*/
-static int gen8_dispatch_bsd_ring(struct drm_device *dev,
- struct drm_file *file)
+static unsigned int
+gen8_dispatch_bsd_ring(struct drm_i915_private *dev_priv, struct drm_file
*file)
{
- struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_i915_file_private *file_priv = file->driver_priv;
- /* Check whether the file_priv is using one ring */
- if (file_priv->bsd_ring)
- return file_priv->bsd_ring->id;
- else {
- /* If no, use the ping-pong mechanism to select one ring */
- int ring_id;
-
- mutex_lock(&dev->struct_mutex);
- if (dev_priv->mm.bsd_ring_dispatch_index == 0) {
- ring_id = VCS;
- dev_priv->mm.bsd_ring_dispatch_index = 1;
- } else {
- ring_id = VCS2;
- dev_priv->mm.bsd_ring_dispatch_index = 0;
- }
- file_priv->bsd_ring = &dev_priv->ring[ring_id];
- mutex_unlock(&dev->struct_mutex);
- return ring_id;
+ /* Check whether the file_priv has already selected one ring. */
+ if ((int)file_priv->bsd_ring < 0) {
+ /* If not, use the ping-pong mechanism to select one. */
+ mutex_lock(&dev_priv->dev->struct_mutex);
+ file_priv->bsd_ring = dev_priv->mm.bsd_ring_dispatch_index;
+ dev_priv->mm.bsd_ring_dispatch_index ^= 1;
+ mutex_unlock(&dev_priv->dev->struct_mutex);
}
+
+ return file_priv->bsd_ring;
}
static struct drm_i915_gem_object *
@@ -1377,6 +1367,16 @@ eb_get_batch(struct eb_vmas *eb)
return vma->obj;
}
+#define I915_USER_RINGS (4)
+
+static const enum intel_ring_id user_ring_map[I915_USER_RINGS + 1] = {
+ [I915_EXEC_DEFAULT] = RCS,
+ [I915_EXEC_RENDER] = RCS,
+ [I915_EXEC_BLT] = BCS,
+ [I915_EXEC_BSD] = VCS,
+ [I915_EXEC_VEBOX] = VECS
+};
+
static int
i915_gem_do_execbuffer(struct drm_device *dev, void *data,
struct drm_file *file,
@@ -1393,6 +1393,7 @@ i915_gem_do_execbuffer(struct drm_device *
[Intel-gfx] [PATCH] drm/i915/bios: Fix the sequence size calculations for MIPI seq v3
Two errors in a single line. The size was read from the wrong offset,
and the end index didn't take the five bytes for sequence byte and size
of sequence into account. Fix it all, and break up the calculations a
bit to make it clearer.
Cc: Ville Syrjälä
Reported-by: Mika Kahola
Fixes: 2a33d93486f2 ("drm/i915/bios: add support for MIPI sequence block v3")
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 12e2f8b8bf9c..bf62a19c8f69 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -842,6 +842,7 @@ static int goto_next_sequence_v3(const u8 *data, int index,
int total)
{
int seq_end;
u16 len;
+ u32 size_of_sequence;
/*
* Could skip sequence based on Size of Sequence alone, but also do some
@@ -852,14 +853,24 @@ static int goto_next_sequence_v3(const u8 *data, int
index, int total)
return 0;
}
- seq_end = index + *((const u32 *)(data + 1));
+ /* Skip Sequence Byte. */
+ index++;
+
+ /*
+* Size of Sequence. Excludes the Sequence Byte and the size itself,
+* includes MIPI_SEQ_ELEM_END byte, excludes the final MIPI_SEQ_END
+* byte.
+*/
+ size_of_sequence = *((const uint32_t *)(data + index));
+ index += 4;
+
+ seq_end = index + size_of_sequence;
if (seq_end > total) {
DRM_ERROR("Invalid sequence size\n");
return 0;
}
- /* Skip Sequence Byte and Size of Sequence. */
- for (index = index + 5; index < total; index += len) {
+ for (; index < total; index += len) {
u8 operation_byte = *(data + index);
index++;
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915/skl: WA for watermark calculation based on Arbitrated Display BW
Hi Mahesh, [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on next-20160114] [cannot apply to v4.4] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Shobhit-Kumar/Misc-WM-fixes-and-Arbitrated-Display-Bandwidth-WA-for-SKL/20160114-200444 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: i386-defconfig (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): drivers/built-in.o: In function `skl_update_wm': >> intel_pm.c:(.text+0xdcbfb): undefined reference to `__udivdi3' intel_pm.c:(.text+0xdccb7): undefined reference to `__udivdi3' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 1/8] drm/i915/gen9: Add framework to whitelist specific GPU registers
Some of the HW registers are privileged and cannot be written to from
non-privileged batch buffers coming from userspace unless they are added to
the HW whitelist. This whitelist is maintained by HW and it is different from
SW whitelist. Userspace need write access to them to implement preemption
related WA.
The reason for using this approach is, the register bits that control
preemption granularity at the HW level are not context save/restored; so even
if we set these bits always in kernel they are going to change once the
context is switched out. We can consider making them non-privileged by
default but these registers also contain other chicken bits which should not
be allowed to be modified.
In the later revisions controlling bits are save/restored at context level but
in the existing revisions these are exported via other debug registers and
should be on the whitelist. This patch adds changes to provide HW with a list
of registers to be whitelisted. HW checks this list during execution and
provides access accordingly.
HW imposes a limit on the number of registers on whitelist and it is
per-engine. At this point we are only enabling whitelist for RCS and we don't
foresee any requirement for other engines.
The registers to be whitelisted are added using generic workaround list
mechanism, even these are only enablers for userspace workarounds. But by
sharing this mechanism we get some test assets without additional cost (Mika).
v2: rebase
v3: parameterize RING_FORCE_TO_NONPRIV() as _MMIO() should be limited to
i915_reg.h (Ville), drop inline for wa_ring_whitelist_reg (Mika).
v4: improvements suggested by Chris Wilson.
Clarify that this is HW whitelist and different from the one maintained in
driver. This list is engine specific but it gets initialized along with other
WA which is RCS specific thing, so make it clear that we are not doing any
cross engine setup during initialization.
Make HW whitelist count of each engine available in debugfs.
Reviewed-by: Chris Wilson
Reviewed-by: Mika Kuoppala
Cc: Mika Kuoppala
Cc: Chris Wilson
Signed-off-by: Arun Siluvery
---
drivers/gpu/drm/i915/i915_debugfs.c | 15 ++-
drivers/gpu/drm/i915/i915_drv.h | 9 -
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_ringbuffer.c | 17 +
4 files changed, 38 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index e3377ab..7eb002c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3229,9 +3229,11 @@ static int i915_wa_registers(struct seq_file *m, void
*unused)
{
int i;
int ret;
+ struct intel_engine_cs *ring;
struct drm_info_node *node = (struct drm_info_node *) m->private;
struct drm_device *dev = node->minor->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
+ struct i915_workarounds *workarounds = &dev_priv->workarounds;
ret = mutex_lock_interruptible(&dev->struct_mutex);
if (ret)
@@ -3239,15 +3241,18 @@ static int i915_wa_registers(struct seq_file *m, void
*unused)
intel_runtime_pm_get(dev_priv);
- seq_printf(m, "Workarounds applied: %d\n", dev_priv->workarounds.count);
- for (i = 0; i < dev_priv->workarounds.count; ++i) {
+ seq_printf(m, "Workarounds applied: %d\n", workarounds->count);
+ for_each_ring(ring, dev_priv, i)
+ seq_printf(m, "HW whitelist count for %s: %d\n",
+ ring->name, workarounds->hw_whitelist_count[i]);
+ for (i = 0; i < workarounds->count; ++i) {
i915_reg_t addr;
u32 mask, value, read;
bool ok;
- addr = dev_priv->workarounds.reg[i].addr;
- mask = dev_priv->workarounds.reg[i].mask;
- value = dev_priv->workarounds.reg[i].value;
+ addr = workarounds->reg[i].addr;
+ mask = workarounds->reg[i].mask;
+ value = workarounds->reg[i].value;
read = I915_READ(addr);
ok = (value & mask) == (read & mask);
seq_printf(m, "0x%X: 0x%08X, mask: 0x%08X, read: 0x%08x,
status: %s\n",
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 104bd18..83fccc0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1653,11 +1653,18 @@ struct i915_wa_reg {
u32 mask;
};
-#define I915_MAX_WA_REGS 16
+/*
+ * RING_MAX_NONPRIV_SLOTS is per-engine but at this point we are only
+ * allowing it for RCS as we don't foresee any requirement of having
+ * a whitelist for other engines. When it is really required for
+ * other engines then the limit need to be increased.
+ */
+#define I915_MAX_WA_REGS (16 + RING_MAX_NONPRIV_SLOTS)
struct i915_workarounds {
struct i915_wa_reg reg[I915_MAX_WA_REGS];
u32 count;
+
[Intel-gfx] ✗ failure: Fi.CI.BAT
== Summary == Built on 8fb2feecca499d11e104264071ac55e273e23af5 drm-intel-nightly: 2016y-01m-14d-13h-06m-44s UTC integration manifest Test gem_ctx_basic: pass -> FAIL (bdw-ultra) Test gem_storedw_loop: Subgroup basic-render: dmesg-warn -> PASS (skl-i5k-2) UNSTABLE dmesg-warn -> PASS (bdw-nuci7) dmesg-warn -> PASS (bdw-ultra) Test kms_flip: Subgroup basic-flip-vs-dpms: pass -> DMESG-WARN (ilk-hp8440p) bdw-nuci7total:138 pass:129 dwarn:0 dfail:0 fail:0 skip:9 bdw-ultratotal:138 pass:131 dwarn:0 dfail:0 fail:1 skip:6 bsw-nuc-2total:141 pass:115 dwarn:2 dfail:0 fail:0 skip:24 hsw-brixbox total:141 pass:134 dwarn:0 dfail:0 fail:0 skip:7 hsw-gt2 total:141 pass:137 dwarn:0 dfail:0 fail:0 skip:4 ilk-hp8440p total:141 pass:100 dwarn:4 dfail:0 fail:0 skip:37 ivb-t430stotal:135 pass:122 dwarn:3 dfail:4 fail:0 skip:6 skl-i5k-2total:141 pass:132 dwarn:1 dfail:0 fail:0 skip:8 skl-i7k-2total:141 pass:131 dwarn:2 dfail:0 fail:0 skip:8 snb-dellxps total:141 pass:122 dwarn:5 dfail:0 fail:0 skip:14 snb-x220ttotal:141 pass:122 dwarn:5 dfail:0 fail:1 skip:13 Results at /archive/results/CI_IGT_test/Patchwork_1189/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [i-g-t PATCH 1/6] intel_bios_reader: pass bdb pointer around instead of having as global
Signed-off-by: Jani Nikula
---
tools/intel_bios_reader.c | 88 ---
1 file changed, 52 insertions(+), 36 deletions(-)
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index b31f648f0607..7b525f220f16 100644
--- a/tools/intel_bios_reader.c
+++ b/tools/intel_bios_reader.c
@@ -71,13 +71,13 @@ struct bdb_block {
void *data;
};
-struct bdb_header *bdb;
struct bdb_lvds_lfp_data_ptrs *lvds_lfp_data_ptrs;
static int tv_present;
static int lvds_present;
static int panel_type;
-static struct bdb_block *find_section(int section_id, int length)
+static struct bdb_block *find_section(const struct bdb_header *bdb,
+ int section_id, int length)
{
struct bdb_block *block;
unsigned char *base = (unsigned char *)bdb;
@@ -118,7 +118,8 @@ static struct bdb_block *find_section(int section_id, int
length)
return NULL;
}
-static void dump_general_features(const struct bdb_block *block)
+static void dump_general_features(const struct bdb_header *bdb,
+ const struct bdb_block *block)
{
struct bdb_general_features *features = block->data;
@@ -170,7 +171,8 @@ static void dump_general_features(const struct bdb_block
*block)
lvds_present = 1; /* should be based on IS_MOBILE() */
}
-static void dump_backlight_info(const struct bdb_block *block)
+static void dump_backlight_info(const struct bdb_header *bdb,
+ const struct bdb_block *block)
{
struct bdb_lvds_backlight *backlight = block->data;
struct blc_struct *blc;
@@ -352,7 +354,8 @@ static const char *efp_conn(uint8_t type)
-static void dump_child_device(struct child_device_config *child)
+static void dump_child_device(const struct bdb_header *bdb,
+ struct child_device_config *child)
{
char child_id[11];
@@ -390,7 +393,8 @@ static void dump_child_device(struct child_device_config
*child)
}
}
-static void dump_general_definitions(const struct bdb_block *block)
+static void dump_general_definitions(const struct bdb_header *bdb,
+const struct bdb_block *block)
{
struct bdb_general_definitions *defs = block->data;
int i;
@@ -409,10 +413,11 @@ static void dump_general_definitions(const struct
bdb_block *block)
child_device_num = (block->size - sizeof(*defs)) /
defs->child_dev_size;
for (i = 0; i < child_device_num; i++)
- dump_child_device((void*)&defs->devices[i *
defs->child_dev_size]);
+ dump_child_device(bdb,(void*)&defs->devices[i *
defs->child_dev_size]);
}
-static void dump_child_devices(const struct bdb_block *block)
+static void dump_child_devices(const struct bdb_header *bdb,
+ const struct bdb_block *block)
{
struct bdb_child_devices *child_devs = block->data;
struct child_device_config *child;
@@ -435,7 +440,8 @@ static void dump_child_devices(const struct bdb_block
*block)
}
}
-static void dump_lvds_options(const struct bdb_block *block)
+static void dump_lvds_options(const struct bdb_header *bdb,
+ const struct bdb_block *block)
{
struct bdb_lvds_options *options = block->data;
@@ -451,7 +457,8 @@ static void dump_lvds_options(const struct bdb_block *block)
printf("\tPFIT mode: %d\n", options->pfit_mode);
}
-static void dump_lvds_ptr_data(const struct bdb_block *block)
+static void dump_lvds_ptr_data(const struct bdb_header *bdb,
+ const struct bdb_block *block)
{
struct bdb_lvds_lfp_data_ptrs *ptrs = block->data;
@@ -461,7 +468,8 @@ static void dump_lvds_ptr_data(const struct bdb_block
*block)
lvds_lfp_data_ptrs = ptrs;
}
-static void dump_lvds_data(const struct bdb_block *block)
+static void dump_lvds_data(const struct bdb_header *bdb,
+ const struct bdb_block *block)
{
struct bdb_lvds_lfp_data *lvds_data = block->data;
struct bdb_lvds_lfp_data_ptrs *ptrs = lvds_lfp_data_ptrs;
@@ -533,7 +541,8 @@ static void dump_lvds_data(const struct bdb_block *block)
}
}
-static void dump_driver_feature(const struct bdb_block *block)
+static void dump_driver_feature(const struct bdb_header *bdb,
+ const struct bdb_block *block)
{
struct bdb_driver_feature *feature = block->data;
@@ -599,7 +608,8 @@ static void dump_driver_feature(const struct bdb_block
*block)
feature->legacy_crt_max_refresh);
}
-static void dump_edp(const struct bdb_block *block)
+static void dump_edp(const struct bdb_header *bdb,
+const struct bdb_block *block)
{
struct bdb_edp *edp = block->data;
int bpp, msa;
@@ -728,7 +738,8 @@ print_detail_timing_data(struct lvds_dvo_timing2
*dvo_timing
[Intel-gfx] [i-g-t PATCH 3/6] intel_bios_reader: make the VBT pointers more const
In const we trust.
Signed-off-by: Jani Nikula
---
tools/intel_bios_reader.c | 56 +++
1 file changed, 28 insertions(+), 28 deletions(-)
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index 496f2b4f8d1e..7dbda3eac77c 100644
--- a/tools/intel_bios_reader.c
+++ b/tools/intel_bios_reader.c
@@ -69,10 +69,10 @@ uint8_t *VBIOS;
struct bdb_block {
uint8_t id;
uint32_t size;
- void *data;
+ const void *data;
};
-struct bdb_lvds_lfp_data_ptrs *lvds_lfp_data_ptrs;
+const struct bdb_lvds_lfp_data_ptrs *lvds_lfp_data_ptrs;
static int tv_present;
static int lvds_present;
static int panel_type;
@@ -91,7 +91,7 @@ static struct bdb_block *find_section(const struct bdb_header
*bdb,
int section_id, int length)
{
struct bdb_block *block;
- unsigned char *base = (unsigned char *)bdb;
+ const uint8_t *base = (const uint8_t *)bdb;
int index = 0;
uint32_t total, current_size;
unsigned char current_id;
@@ -134,7 +134,7 @@ static struct bdb_block *find_section(const struct
bdb_header *bdb,
static void dump_general_features(const struct bdb_header *bdb,
const struct bdb_block *block)
{
- struct bdb_general_features *features = block->data;
+ const struct bdb_general_features *features = block->data;
printf("\tPanel fitting: ");
switch (features->panel_fitting) {
@@ -187,8 +187,8 @@ static void dump_general_features(const struct bdb_header
*bdb,
static void dump_backlight_info(const struct bdb_header *bdb,
const struct bdb_block *block)
{
- struct bdb_lvds_backlight *backlight = block->data;
- struct blc_struct *blc;
+ const struct bdb_lvds_backlight *backlight = block->data;
+ const struct blc_struct *blc;
if (sizeof(struct blc_struct) != backlight->blcstruct_size) {
printf("\tBacklight struct sizes don't match (expected %zu, got
%u), skipping\n",
@@ -409,7 +409,7 @@ static void dump_child_device(const struct bdb_header *bdb,
static void dump_general_definitions(const struct bdb_header *bdb,
const struct bdb_block *block)
{
- struct bdb_general_definitions *defs = block->data;
+ const struct bdb_general_definitions *defs = block->data;
int i;
int child_device_num;
@@ -432,8 +432,8 @@ static void dump_general_definitions(const struct
bdb_header *bdb,
static void dump_child_devices(const struct bdb_header *bdb,
const struct bdb_block *block)
{
- struct bdb_child_devices *child_devs = block->data;
- struct child_device_config *child;
+ const struct bdb_child_devices *child_devs = block->data;
+ const struct child_device_config *child;
int i;
for (i = 0; i < DEVICE_CHILD_SIZE; i++) {
@@ -456,7 +456,7 @@ static void dump_child_devices(const struct bdb_header *bdb,
static void dump_lvds_options(const struct bdb_header *bdb,
const struct bdb_block *block)
{
- struct bdb_lvds_options *options = block->data;
+ const struct bdb_lvds_options *options = block->data;
panel_type = options->panel_type;
printf("\tPanel type: %d\n", panel_type);
@@ -473,7 +473,7 @@ static void dump_lvds_options(const struct bdb_header *bdb,
static void dump_lvds_ptr_data(const struct bdb_header *bdb,
const struct bdb_block *block)
{
- struct bdb_lvds_lfp_data_ptrs *ptrs = block->data;
+ const struct bdb_lvds_lfp_data_ptrs *ptrs = block->data;
printf("\tNumber of entries: %d\n", ptrs->lvds_entries);
@@ -484,8 +484,8 @@ static void dump_lvds_ptr_data(const struct bdb_header *bdb,
static void dump_lvds_data(const struct bdb_header *bdb,
const struct bdb_block *block)
{
- struct bdb_lvds_lfp_data *lvds_data = block->data;
- struct bdb_lvds_lfp_data_ptrs *ptrs = lvds_lfp_data_ptrs;
+ const struct bdb_lvds_lfp_data *lvds_data = block->data;
+ const struct bdb_lvds_lfp_data_ptrs *ptrs = lvds_lfp_data_ptrs;
int num_entries;
int i;
int hdisplay, hsyncstart, hsyncend, htotal;
@@ -509,11 +509,11 @@ static void dump_lvds_data(const struct bdb_header *bdb,
num_entries);
for (i = 0; i < num_entries; i++) {
- uint8_t *lfp_data_ptr =
- (uint8_t *) lvds_data->data + lfp_data_size * i;
- uint8_t *timing_data = lfp_data_ptr + dvo_offset;
- struct bdb_lvds_lfp_data_entry *lfp_data =
- (struct bdb_lvds_lfp_data_entry *)lfp_data_ptr;
+ const uint8_t *lfp_data_ptr =
+ (const uint8_t *) lvds_data->data + lfp_data_size * i;
+ const uint8_t *timing_data = lfp_data_ptr + dvo_off
[Intel-gfx] [i-g-t PATCH 6/6] intel_bios_reader: dump MIPI sequence block v3
Similar to what's done in kernel. It's a bit artificial that the parsing
and dumping are two separate steps in the userspace tool, but it's
easier to follow and debug the code when both the kernel and userspace
are similar.
Signed-off-by: Jani Nikula
---
tools/intel_bios_reader.c | 46 ++
1 file changed, 22 insertions(+), 24 deletions(-)
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index 944ad5315f3a..d73ff5b32e35 100644
--- a/tools/intel_bios_reader.c
+++ b/tools/intel_bios_reader.c
@@ -973,7 +973,7 @@ static const char *sequence_name(enum mipi_seq seq_id)
return "(unknown)";
}
-static const uint8_t *dump_sequence(const uint8_t *data)
+static const uint8_t *dump_sequence(const uint8_t *data, uint8_t seq_version)
{
fn_mipi_elem_dump mipi_elem_dump;
@@ -982,21 +982,33 @@ static const uint8_t *dump_sequence(const uint8_t *data)
/* Skip Sequence Byte. */
data++;
+ /* Skip Size of Sequence. */
+ if (seq_version >= 3)
+ data += 4;
+
while (1) {
uint8_t operation_byte = *data++;
+ uint8_t operation_size = 0;
if (operation_byte == MIPI_SEQ_ELEM_END)
break;
- if (operation_byte < ARRAY_SIZE(dump_elem) &&
- dump_elem[operation_byte])
+ if (operation_byte < ARRAY_SIZE(dump_elem))
mipi_elem_dump = dump_elem[operation_byte];
else
mipi_elem_dump = NULL;
+ /* Size of Operation. */
+ if (seq_version >= 3)
+ operation_size = *data++;
+
if (mipi_elem_dump) {
data = mipi_elem_dump(data);
+ } else if (operation_size) {
+ /* We have size, skip. */
+ data += operation_size;
} else {
+ /* No size, can't skip without parsing. */
printf("Error: Unsupported MIPI element %u\n",
operation_byte);
return NULL;
@@ -1167,7 +1179,8 @@ static void dump_mipi_sequence(const struct bdb_header
*bdb,
const struct bdb_mipi_sequence *sequence = block->data;
const uint8_t *data;
uint32_t seq_size;
- int index = 0;
+ int index = 0, i;
+ const uint8_t *sequence_ptrs[MIPI_SEQ_MAX] = {};
/* Check if we have sequence block as well */
if (!sequence) {
@@ -1200,6 +1213,8 @@ static void dump_mipi_sequence(const struct bdb_header
*bdb,
return;
}
+ sequence_ptrs[seq_id] = data + index;
+
if (sequence->version >= 3)
index = goto_next_sequence_v3(data, index, seq_size);
else
@@ -1210,26 +1225,9 @@ static void dump_mipi_sequence(const struct bdb_header
*bdb,
}
}
- if (sequence->version >= 3) {
- fprintf(stderr, "Unable to dump MIPI Sequence Block v%u\n",
- sequence->version);
- return;
- }
-
- /*
-* loop into the sequence data and split into multiple sequneces
-* There are only 5 types of sequences as of now
-*/
-
-while (1) {
- int seq_id = *data;
- if (seq_id == MIPI_SEQ_END)
- break;
-
- data = dump_sequence(data);
- if (!data)
- break;
- }
+ /* Dump the sequences. Corresponds to sequence execution in kernel. */
+ for (i = 0; i < ARRAY_SIZE(sequence_ptrs); i++)
+ dump_sequence(sequence_ptrs[i], sequence->version);
}
static int
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [i-g-t PATCH 0/6] intel_bios_reader: support MIPI sequence block v3
Support MIPI sequence block v3 in the intel_bios_reader tool. This is mostly copied from the kernel. It makes some of the parts a bit artifical for an userspace tool, but hey, this pattern has been followed all around in IGT and it makes debugging kernel issues much easier that the code is similar. BR, Jani. Jani Nikula (6): intel_bios_reader: pass bdb pointer around instead of having as global intel_bios_reader: fix size handling for 32-bit block size intel_bios_reader: make the VBT pointers more const intel_bios_reader: port find_panel_sequence_block from kernel intel_bios_reader: port the sequence block parsing from kernel intel_bios_reader: dump MIPI sequence block v3 tools/intel_bios_reader.c | 412 +- 1 file changed, 296 insertions(+), 116 deletions(-) -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [i-g-t PATCH 2/6] intel_bios_reader: fix size handling for 32-bit block size
The MIPI DSI sequence block v3+ has a separate block size field.
Signed-off-by: Jani Nikula
---
tools/intel_bios_reader.c | 46 +-
1 file changed, 25 insertions(+), 21 deletions(-)
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index 7b525f220f16..496f2b4f8d1e 100644
--- a/tools/intel_bios_reader.c
+++ b/tools/intel_bios_reader.c
@@ -65,9 +65,10 @@ uint8_t *VBIOS;
#define YESNO(val) ((val) ? "yes" : "no")
+/* This is not for mapping to memory layout. */
struct bdb_block {
uint8_t id;
- uint16_t size;
+ uint32_t size;
void *data;
};
@@ -76,17 +77,27 @@ static int tv_present;
static int lvds_present;
static int panel_type;
+/* Get BDB block size given a pointer to Block ID. */
+static uint32_t _get_blocksize(const uint8_t *block_base)
+{
+ /* The MIPI Sequence Block v3+ has a separate size field. */
+ if (*block_base == BDB_MIPI_SEQUENCE && *(block_base + 3) >= 3)
+ return *((const uint32_t *)(block_base + 4));
+ else
+ return *((const uint16_t *)(block_base + 1));
+}
+
static struct bdb_block *find_section(const struct bdb_header *bdb,
int section_id, int length)
{
struct bdb_block *block;
unsigned char *base = (unsigned char *)bdb;
- int idx = 0;
- uint16_t total, current_size;
+ int index = 0;
+ uint32_t total, current_size;
unsigned char current_id;
/* skip to first section */
- idx += bdb->header_size;
+ index += bdb->header_size;
total = bdb->bdb_size;
if (total > length)
total = length;
@@ -98,20 +109,22 @@ static struct bdb_block *find_section(const struct
bdb_header *bdb,
}
/* walk the sections looking for section_id */
- while (idx + 3 < total) {
- current_id = *(base + idx);
- current_size = *(uint16_t *)(base + idx + 1);
- if (idx + current_size > total)
+ while (index + 3 < total) {
+ current_id = *(base + index);
+ current_size = _get_blocksize(base + index);
+ index += 3;
+
+ if (index + current_size > total)
return NULL;
if (current_id == section_id) {
block->id = current_id;
block->size = current_size;
- block->data = base + idx + 3;
+ block->data = base + index;
return block;
}
- idx += current_size + 3;
+ index += current_size;
}
free(block);
@@ -993,22 +1006,13 @@ static const uint8_t *dump_sequence(const uint8_t *data)
return data;
}
-static uint16_t get_blocksize(void *p)
-{
- uint16_t *block_ptr, block_size;
-
- block_ptr = (uint16_t *)((char *)p - 2);
- block_size = *block_ptr;
- return block_size;
-}
-
static void dump_mipi_sequence(const struct bdb_header *bdb,
const struct bdb_block *block)
{
struct bdb_mipi_sequence *sequence = block->data;
const uint8_t *data;
int i, panel_id, seq_size;
- uint16_t block_size;
+ uint32_t block_size;
/* Check if we have sequence block as well */
if (!sequence) {
@@ -1021,7 +1025,7 @@ static void dump_mipi_sequence(const struct bdb_header
*bdb,
if (sequence->version >= 3)
return;
- block_size = get_blocksize(sequence);
+ block_size = block->size;
data = &sequence->data[0];
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [i-g-t PATCH 5/6] intel_bios_reader: port the sequence block parsing from kernel
Reuse the same code as kernel. Also parses v3, although does not
actually dump that stuff yet.
Signed-off-by: Jani Nikula
---
tools/intel_bios_reader.c | 141 +-
1 file changed, 140 insertions(+), 1 deletion(-)
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index eb550817c44e..944ad5315f3a 100644
--- a/tools/intel_bios_reader.c
+++ b/tools/intel_bios_reader.c
@@ -1054,12 +1054,120 @@ find_panel_sequence_block(const struct
bdb_mipi_sequence *sequence,
return NULL;
}
+static int goto_next_sequence(const uint8_t *data, int index, int total)
+{
+ uint16_t len;
+
+ /* Skip Sequence Byte. */
+ for (index = index + 1; index < total; index += len) {
+ uint8_t operation_byte = *(data + index);
+ index++;
+
+ switch (operation_byte) {
+ case MIPI_SEQ_ELEM_END:
+ return index;
+ case MIPI_SEQ_ELEM_SEND_PKT:
+ if (index + 4 > total)
+ return 0;
+
+ len = *((const uint16_t *)(data + index + 2)) + 4;
+ break;
+ case MIPI_SEQ_ELEM_DELAY:
+ len = 4;
+ break;
+ case MIPI_SEQ_ELEM_GPIO:
+ len = 2;
+ break;
+ case MIPI_SEQ_ELEM_I2C:
+ if (index + 7 > total)
+ return 0;
+ len = *(data + index + 6) + 7;
+ break;
+ default:
+ fprintf(stderr, "Unknown operation byte\n");
+ return 0;
+ }
+ }
+
+ return 0;
+}
+
+static int goto_next_sequence_v3(const uint8_t *data, int index, int total)
+{
+ int seq_end;
+ uint16_t len;
+ uint32_t size_of_sequence;
+
+ /*
+* Could skip sequence based on Size of Sequence alone, but also do some
+* checking on the structure.
+*/
+ if (total < 5) {
+ fprintf(stderr, "Too small sequence size\n");
+ return 0;
+ }
+
+ /* Skip Sequence Byte. */
+ index++;
+
+ /*
+* Size of Sequence. Excludes the Sequence Byte and the size itself,
+* includes MIPI_SEQ_ELEM_END byte, excludes the final MIPI_SEQ_END
+* byte.
+*/
+ size_of_sequence = *((const uint32_t *)(data + index));
+ index += 4;
+
+ seq_end = index + size_of_sequence;
+ if (seq_end > total) {
+ fprintf(stderr, "Invalid sequence size\n");
+ return 0;
+ }
+
+ for (; index < total; index += len) {
+ uint8_t operation_byte = *(data + index);
+ index++;
+
+ if (operation_byte == MIPI_SEQ_ELEM_END) {
+ if (index != seq_end) {
+ fprintf(stderr, "Invalid element structure\n");
+ return 0;
+ }
+ return index;
+ }
+
+ len = *(data + index);
+ index++;
+
+ /*
+* FIXME: Would be nice to check elements like for v1/v2 in
+* goto_next_sequence() above.
+*/
+ switch (operation_byte) {
+ case MIPI_SEQ_ELEM_SEND_PKT:
+ case MIPI_SEQ_ELEM_DELAY:
+ case MIPI_SEQ_ELEM_GPIO:
+ case MIPI_SEQ_ELEM_I2C:
+ case MIPI_SEQ_ELEM_SPI:
+ case MIPI_SEQ_ELEM_PMIC:
+ break;
+ default:
+ fprintf(stderr, "Unknown operation byte %u\n",
+ operation_byte);
+ break;
+ }
+ }
+
+ return 0;
+}
+
static void dump_mipi_sequence(const struct bdb_header *bdb,
const struct bdb_block *block)
{
const struct bdb_mipi_sequence *sequence = block->data;
const uint8_t *data;
uint32_t seq_size;
+ int index = 0;
/* Check if we have sequence block as well */
if (!sequence) {
@@ -1069,14 +1177,45 @@ static void dump_mipi_sequence(const struct bdb_header
*bdb,
printf("\tSequence block version v%u\n", sequence->version);
- if (sequence->version >= 3)
+ /* Fail gracefully for forward incompatible sequence block. */
+ if (sequence->version >= 4) {
+ fprintf(stderr, "Unable to parse MIPI Sequence Block v%u\n",
+ sequence->version);
return;
+ }
data = find_panel_sequence_block(sequence, panel_type,
block->size, &seq_size);
if (!data)
return;
+ /* Parse the sequences. Corresponds to VBT parsi
[Intel-gfx] [i-g-t PATCH 4/6] intel_bios_reader: port find_panel_sequence_block from kernel
No need to reinvent wheels, reuse the code from kernel.
Signed-off-by: Jani Nikula
---
tools/intel_bios_reader.c | 81 ++-
1 file changed, 52 insertions(+), 29 deletions(-)
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index 7dbda3eac77c..eb550817c44e 100644
--- a/tools/intel_bios_reader.c
+++ b/tools/intel_bios_reader.c
@@ -1006,13 +1006,60 @@ static const uint8_t *dump_sequence(const uint8_t *data)
return data;
}
+/* Find the sequence block and size for the given panel. */
+static const uint8_t *
+find_panel_sequence_block(const struct bdb_mipi_sequence *sequence,
+ uint16_t panel_id, uint32_t total, uint32_t *seq_size)
+{
+ const uint8_t *data = &sequence->data[0];
+ uint8_t current_id;
+ uint32_t current_size;
+ int header_size = sequence->version >= 3 ? 5 : 3;
+ int index = 0;
+ int i;
+
+ /* skip new block size */
+ if (sequence->version >= 3)
+ data += 4;
+
+ for (i = 0; i < MAX_MIPI_CONFIGURATIONS && index < total; i++) {
+ if (index + header_size > total) {
+ fprintf(stderr, "Invalid sequence block (header)\n");
+ return NULL;
+ }
+
+ current_id = *(data + index);
+ if (sequence->version >= 3)
+ current_size = *((const uint32_t *)(data + index + 1));
+ else
+ current_size = *((const uint16_t *)(data + index + 1));
+
+ index += header_size;
+
+ if (index + current_size > total) {
+ fprintf(stderr, "Invalid sequence block\n");
+ return NULL;
+ }
+
+ if (current_id == panel_id) {
+ *seq_size = current_size;
+ return data + index;
+ }
+
+ index += current_size;
+ }
+
+ fprintf(stderr, "Sequence block detected but no valid configuration\n");
+
+ return NULL;
+}
+
static void dump_mipi_sequence(const struct bdb_header *bdb,
const struct bdb_block *block)
{
const struct bdb_mipi_sequence *sequence = block->data;
const uint8_t *data;
- int i, panel_id, seq_size;
- uint32_t block_size;
+ uint32_t seq_size;
/* Check if we have sequence block as well */
if (!sequence) {
@@ -1025,34 +1072,10 @@ static void dump_mipi_sequence(const struct bdb_header
*bdb,
if (sequence->version >= 3)
return;
- block_size = block->size;
-
- data = &sequence->data[0];
-
- /*
-* sequence block is variable length and hence we need to parse and
-* get the sequence data for specific panel id
-*/
- for (i = 0; i < MAX_MIPI_CONFIGURATIONS; i++) {
- panel_id = *data;
- seq_size = *((uint16_t *) (data + 1));
- data += 3;
-
- if (data + seq_size > (const uint8_t *)sequence + block_size) {
- printf("Invalid sequence block\n");
- return;
- }
-
- if (panel_id == panel_type)
- break;
-
- data += seq_size;
- }
-
- if (i == MAX_MIPI_CONFIGURATIONS) {
- printf("Sequence block detected but no valid configuration\n");
+ data = find_panel_sequence_block(sequence, panel_type,
+block->size, &seq_size);
+ if (!data)
return;
- }
/*
* loop into the sequence data and split into multiple sequneces
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 1/1] drm/i915/bxt: Check BIOS RC6 setup before enabling RC6
RC6 setup is shared between BIOS and Driver. BIOS sets up subset of RC6
setup registers. If those are not setup Driver should not enable RC6.
For implementing this, driver can check RC_CTRL0 and RC_CTRL1 values
to know if BIOS has enabled HW/SW RC6.
This will also enable user to control RC6 using BIOS settings alone.
RC6 related instability can be avoided by disabling via BIOS settings
till driver fixes it.
v2: Had placed logic in gen8 function by mistake. Fixed it.
Ensuring RPM is not enabled in case BIOS disabled RC6.
v3: Need to disable RPM if RC6 is disabled due to BIOS settings. (Daniel)
Runtime PM enabling happens before gen9_enable_rc6.
Moved the updation of enable_rc6 parameter in intel_uncore_sanitize.
v4: Added elaborate check for BIOS RC6 setup. Prepared check_pctx for bxt.
(Imre)
v5: Caching reserved stolen base and size in the driver private data.
Reorganized RC6 setup check. Moved from gen9_enable_rc6 to
intel_uncore_sanitize. (Imre)
Cc: Imre Deak
Change-Id: If89518708e133be6b3c7c6f90869fb66224b7b87
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_drv.h| 1 +
drivers/gpu/drm/i915/i915_gem_gtt.h| 2 ++
drivers/gpu/drm/i915/i915_gem_stolen.c | 39 ++
drivers/gpu/drm/i915/i915_reg.h| 11 +++
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c| 59 --
drivers/gpu/drm/i915/intel_uncore.c| 4 +++
7 files changed, 109 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cf7e0fc..0c8e61c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3223,6 +3223,7 @@ int i915_gem_stolen_insert_node_in_range(struct
drm_i915_private *dev_priv,
u64 end);
void i915_gem_stolen_remove_node(struct drm_i915_private *dev_priv,
struct drm_mm_node *node);
+int i915_gem_init_stolen_reserved(struct drm_device *dev);
int i915_gem_init_stolen(struct drm_device *dev);
void i915_gem_cleanup_stolen(struct drm_device *dev);
struct drm_i915_gem_object *
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index b448ad8..20ff6ca 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -343,6 +343,8 @@ struct i915_gtt {
size_t stolen_size; /* Total size of stolen memory */
size_t stolen_usable_size; /* Total size minus BIOS reserved */
+ size_t stolen_reserved_base;
+ size_t stolen_reserved_size;
u64 mappable_end; /* End offset that we can CPU map */
struct io_mapping *mappable;/* Mapping to our CPU mappable region */
phys_addr_t mappable_base; /* PA of our GMADR */
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 3476877..d5a65d9 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -386,14 +386,12 @@ static void bdw_get_stolen_reserved(struct
drm_i915_private *dev_priv,
*size = stolen_top - *base;
}
-int i915_gem_init_stolen(struct drm_device *dev)
+int i915_gem_init_stolen_reserved(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- unsigned long reserved_total, reserved_base = 0, reserved_size;
+ unsigned long reserved_base = 0, reserved_size;
unsigned long stolen_top;
- mutex_init(&dev_priv->mm.stolen_lock);
-
#ifdef CONFIG_INTEL_IOMMU
if (intel_iommu_gfx_mapped && INTEL_INFO(dev)->gen < 8) {
DRM_INFO("DMAR active, disabling use of stolen memory\n");
@@ -458,9 +456,38 @@ int i915_gem_init_stolen(struct drm_device *dev)
return 0;
}
+ dev_priv->gtt.stolen_reserved_base = reserved_base;
+ dev_priv->gtt.stolen_reserved_size = reserved_size;
+
+ return 0;
+}
+
+int i915_gem_init_stolen(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ unsigned long reserved_total;
+ unsigned long stolen_top;
+
+ mutex_init(&dev_priv->mm.stolen_lock);
+
+#ifdef CONFIG_INTEL_IOMMU
+ if (intel_iommu_gfx_mapped && INTEL_INFO(dev)->gen < 8) {
+ DRM_INFO("DMAR active, disabling use of stolen memory\n");
+ return 0;
+ }
+#endif
+
+ if (dev_priv->gtt.stolen_size == 0)
+ return 0;
+
+ if (dev_priv->mm.stolen_base == 0)
+ return 0;
+
+ stolen_top = dev_priv->mm.stolen_base + dev_priv->gtt.stolen_size;
+
/* It is possible for the reserved area to end before the end of stolen
-* memory, so just consider the start. */
- reserved_total = stolen_top - reserved_base;
+ * memory, so just consider the start. */
+ reserved_total = stolen_top - dev_priv->gtt.stolen_rese
[Intel-gfx] [PATCH v2 6/6] intel_bios_reader: dump MIPI sequence block v3
Similar to what's done in kernel. It's a bit artificial that the parsing
and dumping are two separate steps in the userspace tool, but it's
easier to follow and debug the code when both the kernel and userspace
are similar.
v2: don't segfault so much on dumping null pointers
Signed-off-by: Jani Nikula
---
tools/intel_bios_reader.c | 47 +++
1 file changed, 23 insertions(+), 24 deletions(-)
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index 944ad5315f3a..4cfd30afbb46 100644
--- a/tools/intel_bios_reader.c
+++ b/tools/intel_bios_reader.c
@@ -973,7 +973,7 @@ static const char *sequence_name(enum mipi_seq seq_id)
return "(unknown)";
}
-static const uint8_t *dump_sequence(const uint8_t *data)
+static const uint8_t *dump_sequence(const uint8_t *data, uint8_t seq_version)
{
fn_mipi_elem_dump mipi_elem_dump;
@@ -982,21 +982,33 @@ static const uint8_t *dump_sequence(const uint8_t *data)
/* Skip Sequence Byte. */
data++;
+ /* Skip Size of Sequence. */
+ if (seq_version >= 3)
+ data += 4;
+
while (1) {
uint8_t operation_byte = *data++;
+ uint8_t operation_size = 0;
if (operation_byte == MIPI_SEQ_ELEM_END)
break;
- if (operation_byte < ARRAY_SIZE(dump_elem) &&
- dump_elem[operation_byte])
+ if (operation_byte < ARRAY_SIZE(dump_elem))
mipi_elem_dump = dump_elem[operation_byte];
else
mipi_elem_dump = NULL;
+ /* Size of Operation. */
+ if (seq_version >= 3)
+ operation_size = *data++;
+
if (mipi_elem_dump) {
data = mipi_elem_dump(data);
+ } else if (operation_size) {
+ /* We have size, skip. */
+ data += operation_size;
} else {
+ /* No size, can't skip without parsing. */
printf("Error: Unsupported MIPI element %u\n",
operation_byte);
return NULL;
@@ -1167,7 +1179,8 @@ static void dump_mipi_sequence(const struct bdb_header
*bdb,
const struct bdb_mipi_sequence *sequence = block->data;
const uint8_t *data;
uint32_t seq_size;
- int index = 0;
+ int index = 0, i;
+ const uint8_t *sequence_ptrs[MIPI_SEQ_MAX] = {};
/* Check if we have sequence block as well */
if (!sequence) {
@@ -1200,6 +1213,8 @@ static void dump_mipi_sequence(const struct bdb_header
*bdb,
return;
}
+ sequence_ptrs[seq_id] = data + index;
+
if (sequence->version >= 3)
index = goto_next_sequence_v3(data, index, seq_size);
else
@@ -1210,26 +1225,10 @@ static void dump_mipi_sequence(const struct bdb_header
*bdb,
}
}
- if (sequence->version >= 3) {
- fprintf(stderr, "Unable to dump MIPI Sequence Block v%u\n",
- sequence->version);
- return;
- }
-
- /*
-* loop into the sequence data and split into multiple sequneces
-* There are only 5 types of sequences as of now
-*/
-
-while (1) {
- int seq_id = *data;
- if (seq_id == MIPI_SEQ_END)
- break;
-
- data = dump_sequence(data);
- if (!data)
- break;
- }
+ /* Dump the sequences. Corresponds to sequence execution in kernel. */
+ for (i = 0; i < ARRAY_SIZE(sequence_ptrs); i++)
+ if (sequence_ptrs[i])
+ dump_sequence(sequence_ptrs[i], sequence->version);
}
static int
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bios: Fix the sequence size calculations for MIPI seq v3
On Thu, Jan 14, 2016 at 05:12:07PM +0200, Jani Nikula wrote:
> Two errors in a single line. The size was read from the wrong offset,
> and the end index didn't take the five bytes for sequence byte and size
> of sequence into account. Fix it all, and break up the calculations a
> bit to make it clearer.
>
> Cc: Ville Syrjälä
> Reported-by: Mika Kahola
> Fixes: 2a33d93486f2 ("drm/i915/bios: add support for MIPI sequence block v3")
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_bios.c | 17 ++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 12e2f8b8bf9c..bf62a19c8f69 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -842,6 +842,7 @@ static int goto_next_sequence_v3(const u8 *data, int
> index, int total)
> {
> int seq_end;
> u16 len;
> + u32 size_of_sequence;
>
> /*
>* Could skip sequence based on Size of Sequence alone, but also do some
> @@ -852,14 +853,24 @@ static int goto_next_sequence_v3(const u8 *data, int
> index, int total)
> return 0;
> }
>
> - seq_end = index + *((const u32 *)(data + 1));
> + /* Skip Sequence Byte. */
> + index++;
> +
> + /*
> + * Size of Sequence. Excludes the Sequence Byte and the size itself,
> + * includes MIPI_SEQ_ELEM_END byte, excludes the final MIPI_SEQ_END
> + * byte.
> + */
> + size_of_sequence = *((const uint32_t *)(data + index));
Hmm. So it was reading from 'data+1' and now it's basically 'data+index+1'.
So it was correct for the first sequence, and busted for later ones I
suppose.
> + index += 4;
> +
> + seq_end = index + size_of_sequence;
And now we count the size of the sequence starting from the operation
byte, before we counted it from the sequence byte. "Fortunately" the spec
doesn't even tell us which is correct. If it works, it works.
Reviewed-by: Ville Syrjälä
BTW I was thinking that we could maybe add some kind of
"read the thing at index, and and increment the index past it" helpers.
Eg.
int get_u8(const void *data, int index, int size, u8 *ret);
int get_u32(const void *data, int index, int size, u32 *ret);
they could also do the index vs. size check and just return an error if
we try to go too far.
> if (seq_end > total) {
> DRM_ERROR("Invalid sequence size\n");
> return 0;
> }
>
> - /* Skip Sequence Byte and Size of Sequence. */
> - for (index = index + 5; index < total; index += len) {
> + for (; index < total; index += len) {
> u8 operation_byte = *(data + index);
> index++;
>
> --
> 2.1.4
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
