Re: [Intel-gfx] [PATCH] drm/i915/vlv: use PIPE_START_VBLANK interrupts on VLV
On Tue, Nov 05, 2013 at 03:48:01PM -0800, Jesse Barnes wrote:
> This fixes a mismatch between our vblank enable code and our IRQ
> handler. Also, since vblank start events come in before page flips
> reliably, it also fixes the kms_flip plain-flip test on my BYT system.
>
> Spotted-by: Ville Syrjälä
> Signed-off-by: Jesse Barnes
So kms_flip isn't totally crap I hear?
One problem is that the iosf bug is blocking QA's ability to use kms_flip
as a regression tests. I wonder a bit whether we need to split out the
results as subtests so that each connector type can be tracked
individually. The problem with that is that we'd have unstable subtest
names, which is a bit ugly ... Good ideas highly welcome.
Picked up for -fixes, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_irq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 2a44816..32c9c8d 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1353,7 +1353,7 @@ static irqreturn_t valleyview_irq_handler(int irq, void
> *arg)
> spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
>
> for_each_pipe(pipe) {
> - if (pipe_stats[pipe] & PIPE_VBLANK_INTERRUPT_STATUS)
> + if (pipe_stats[pipe] &
> PIPE_START_VBLANK_INTERRUPT_STATUS)
> drm_handle_vblank(dev, pipe);
>
> if (pipe_stats[pipe] & PLANE_FLIPDONE_INT_STATUS_VLV) {
> --
> 1.8.4.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] testcases: Slice Shutdown testscases.
On Tue, Nov 05, 2013 at 08:45:09PM -0200, Rodrigo Vivi wrote:
> 1. sysfs half/full switch.
> 4. execbuf without I915_EXEC_USE_PREDICATE
> 5. execbuf with I915_EXEC_USE_PREDICATE
>
> v2: include more tests and s/GT_FULL/USE_PREDICATE
> v3: make it more reliable and fix few comments
> v4: use number of slices on (1,2) instead of half and full strings.
>
> Signed-off-by: Rodrigo Vivi
> ---
> tests/Makefile.am | 1 +
> tests/gt_slices.c | 268
> ++
> 2 files changed, 269 insertions(+)
> create mode 100644 tests/gt_slices.c
>
> diff --git a/tests/Makefile.am b/tests/Makefile.am
> index 0290ae0..e21230a 100644
> --- a/tests/Makefile.am
> +++ b/tests/Makefile.am
> @@ -50,6 +50,7 @@ TESTS_progs_M = \
> gem_tiled_blits \
> gem_tiled_partial_pwrite_pread \
> gem_write_read_ring_switch \
> + gt_slices \
With the new namimg conventions I'd give this a pm_ prefix.
-Daniel
> kms_flip \
> kms_render \
> kms_setmode \
> diff --git a/tests/gt_slices.c b/tests/gt_slices.c
> new file mode 100644
> index 000..8388aca
> --- /dev/null
> +++ b/tests/gt_slices.c
> @@ -0,0 +1,268 @@
> +/*
> + * Copyright © 2013 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:
> + *Rodrigo Vivi
> + *
> + */
> +
> +/*
> + * Testcase: Test GT slice shutdown feature
> + *
> + * Sub tests:
> + * 1. sysfs half/full switch.
> + * 4. on execbuf without I915_EXEC_USE_PREDICATE
> + * 5. on execbuf with I915_EXEC_USE_PREDICATE
> + */
> +
> +#define _GNU_SOURCE
> +#include
> +#include
> +#include
> +#include
> +#include "drmtest.h"
> +
> +static void exec(int fd, uint32_t handle, bool use_predicate)
> +{
> +struct drm_i915_gem_execbuffer2 execbuf;
> +struct drm_i915_gem_exec_object2 gem_exec[1];
> +uint32_t b[2] = {MI_BATCH_BUFFER_END};
> +int loops = 100;
> +int ret = 0;
> +
> +gem_write(fd, handle, 0, b, sizeof(b));
> +
> +gem_exec[0].handle = handle;
> +gem_exec[0].relocation_count = 0;
> +gem_exec[0].relocs_ptr = 0;
> +gem_exec[0].alignment = 0;
> +gem_exec[0].offset = 0;
> +gem_exec[0].flags = 0;
> +gem_exec[0].rsvd1 = 0;
> +gem_exec[0].rsvd2 = 0;
> +
> +execbuf.buffers_ptr = (uintptr_t)gem_exec;
> +execbuf.buffer_count = 1;
> +execbuf.batch_start_offset = 0;
> +execbuf.batch_len = 8;
> +execbuf.cliprects_ptr = 0;
> +execbuf.num_cliprects = 0;
> +execbuf.DR1 = 0;
> +execbuf.DR4 = 0;
> +execbuf.flags = I915_EXEC_RENDER;
> + if (use_predicate)
> + execbuf.flags |= I915_EXEC_USE_PREDICATE;
> +i915_execbuffer2_set_context_id(execbuf, 0);
> +execbuf.rsvd2 = 0;
> +
> +while (loops-- && ret == 0) {
> +ret = drmIoctl(fd,
> + DRM_IOCTL_I915_GEM_EXECBUFFER2,
> + &execbuf);
> +}
> + gem_sync(fd, handle);
> +}
> +
> +static int slices_on(const int device)
> +{
> + char *path;
> + FILE *file;
> + int ret;
> + int slices;
> +
> + ret = asprintf(&path, "/sys/class/drm/card%d/power/gt_slices",
> +device);
> + igt_assert(ret != -1);
> +
> + file = fopen(path, "r");
> + igt_require(file);
> +
> + ret = fscanf(file, "%d", &slices);
> + igt_assert(ret != 0);
> +
> + fclose(file);
> + return slices;
> +}
> +
> +static int set_status(const int device, int slices)
> +{
> + char *path;
> + FILE *file;
> + int ret;
> + int attempts = 10;
> +
> + ret = asprintf(&path, "/sys/class/drm/card%d/power/gt_slices",
> +device);
> + igt_assert(ret != -1);
> +
> + while (attempts-- && ret != 0) {
> + f
Re: [Intel-gfx] [PATCH] drm/i915: Sanitize prepare_pipes after valleyview_modeset_global_pipes()
On Tue, Nov 05, 2013 at 10:34:12PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> valleyview_modeset_global_pipes() may add pipes that are getting fully
> disabled to prepare_pipes bitmask. The rest of the code doesn't expect
> this, so clear out any such pipes from the prepare_pipes bitmask.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index f97e895..ddbef9c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9514,10 +9514,14 @@ static int __intel_set_mode(struct drm_crtc *crtc,
>* mode set on this crtc. For other crtcs we need to use the
>* adjusted_mode bits in the crtc directly.
>*/
> - if (IS_VALLEYVIEW(dev))
> + if (IS_VALLEYVIEW(dev)) {
> valleyview_modeset_global_pipes(dev, &prepare_pipes,
> modeset_pipes, pipe_config);
>
> + /* may have added more to prepare_pipes than we should */
> + prepare_pipes &= ~disable_pipes;
> + }
I'd have move the full "take disable_pipes out" block from affected_pipes.
Afacs there's no need to do it twice.
-Daniel
> +
> for_each_intel_crtc_masked(dev, disable_pipes, intel_crtc)
> intel_crtc_disable(&intel_crtc->base);
>
> --
> 1.8.1.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Demote drop_caches_set print
On Tue, Nov 05, 2013 at 05:01:38PM -0800, Ben Widawsky wrote:
> Many tests call this ad naseum now (in an infinite loop, very often).
> It clutters the logs. Actually, I'd rather drop it completely...
Dropping it completely seems like the right solutions due to those "drop
caches in an infinite loop" kind of tests.
-Daniel
>
> Cc: Daniel Vetter
> Cc: Chris Wilson
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 7008aac..d24e7d1 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2657,7 +2657,7 @@ i915_drop_caches_set(void *data, u64 val)
> struct i915_vma *vma, *x;
> int ret;
>
> - DRM_DEBUG_DRIVER("Dropping caches: 0x%08llx\n", val);
> + DRM_DEBUG("Dropping caches: 0x%08llx\n", val);
>
> /* No need to check and wait for gpu resets, only libdrm auto-restarts
>* on ioctls on -EAGAIN. */
> --
> 1.8.4.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/62] drm/i915/bdw: display stuff
On Sat, Nov 02, 2013 at 09:07:07PM -0700, Ben Widawsky wrote:
> Just enough to make the code not barf...
>
> Init BDW display to look like HSW. For the simulator this should be
> fine, but this will probably require more work.
>
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/intel_display.c | 3 ++-
> drivers/gpu/drm/i915/intel_sprite.c | 1 +
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 0c2e83c..436b750 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -10308,7 +10308,7 @@ static void intel_init_display(struct drm_device *dev)
> dev_priv->display.write_eld = ironlake_write_eld;
> dev_priv->display.modeset_global_resources =
> ivb_modeset_global_resources;
> - } else if (IS_HASWELL(dev)) {
> + } else if (IS_HASWELL(dev) || IS_GEN8(dev)) {
> dev_priv->display.fdi_link_train = hsw_fdi_link_train;
> dev_priv->display.write_eld = haswell_write_eld;
> dev_priv->display.modeset_global_resources =
> @@ -10339,6 +10339,7 @@ static void intel_init_display(struct drm_device *dev)
> dev_priv->display.queue_flip = intel_gen6_queue_flip;
> break;
> case 7:
> + case 8:
> dev_priv->display.queue_flip = intel_gen7_queue_flip;
Since this patch's inception we've enabled RCS flips on gen7. I've added a
FIMXE(BDW) comment that this needs to be tested.
-Daniel
> break;
> }
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 8afaad6..f8b265c 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -1092,6 +1092,7 @@ intel_plane_init(struct drm_device *dev, enum pipe
> pipe, int plane)
> break;
>
> case 7:
> + case 8:
> if (IS_IVYBRIDGE(dev)) {
> intel_plane->can_scale = true;
> intel_plane->max_downscale = 2;
> --
> 1.8.4.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 20/62] drm/i915/bdw: Add GTT functions
> -Original Message-
> From: intel-gfx-boun...@lists.freedesktop.org [mailto:intel-gfx-
> boun...@lists.freedesktop.org] On Behalf Of Ben Widawsky
> Sent: Sunday, November 03, 2013 4:07 AM
> To: Intel GFX
> Cc: Daniel Vetter; Ben Widawsky; Widawsky, Benjamin
> Subject: [Intel-gfx] [PATCH 20/62] drm/i915/bdw: Add GTT functions
>
> With the PTE clarifications, the bind and clear functions can now be added for
> gen8.
>
> v2: Use for_each_sg_pages in gen8_ggtt_insert_entries.
>
> v3: Drop dev argument to pte encode functions, upstream lost it. Also rebase
> on top of the scratch page movement.
>
> v4: Rebase on top of the new address space vfuncs.
>
> v5: Add the bool use_scratch argument to clear_range and the bool valid
> argument to the PTE encode function to follow upstream changes.
>
> Signed-off-by: Ben Widawsky (v1)
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 88
> +++--
> 1 file changed, 85 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 8bf2184..df992dc 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -58,6 +58,15 @@ typedef uint64_t gen8_gtt_pte_t;
> #define HSW_WB_ELLC_LLC_AGE0
> HSW_CACHEABILITY_CONTROL(0xb)
> #define HSW_WT_ELLC_LLC_AGE0
> HSW_CACHEABILITY_CONTROL(0x6)
>
> +static inline gen8_gtt_pte_t gen8_pte_encode(dma_addr_t addr,
> + enum i915_cache_level level,
> + bool valid)
> +{
> + gen8_gtt_pte_t pte = valid ? _PAGE_PRESENT | _PAGE_RW : 0;
> + pte |= addr;
> + return pte;
> +}
> +
> static gen6_gtt_pte_t snb_pte_encode(dma_addr_t addr,
>enum i915_cache_level level,
>bool valid)
> @@ -576,6 +585,56 @@ int i915_gem_gtt_prepare_object(struct
> drm_i915_gem_object *obj)
> return 0;
> }
>
> +static inline void gen8_set_pte(void __iomem *addr, gen8_gtt_pte_t pte)
> +{ #ifdef writeq
> + writeq(pte, addr);
> +#else
> + iowrite32((u32)pte, addr);
> + iowrite32(pte >> 32, addr + 4);
> +#endif
> +}
> +
> +static void gen8_ggtt_insert_entries(struct i915_address_space *vm,
> + struct sg_table *st,
> + unsigned int first_entry,
> + enum i915_cache_level level)
> +{
> + struct drm_i915_private *dev_priv = vm->dev->dev_private;
> + gen8_gtt_pte_t __iomem *gtt_entries =
> + (gen8_gtt_pte_t __iomem *)dev_priv->gtt.gsm +
> first_entry;
> + int i = 0;
> + struct sg_page_iter sg_iter;
> + dma_addr_t addr;
> +
> + for_each_sg_page(st->sgl, &sg_iter, st->nents, 0) {
> + addr = sg_dma_address(sg_iter.sg) +
> + (sg_iter.sg_pgoffset << PAGE_SHIFT);
> + gen8_set_pte(>t_entries[i],
> + gen8_pte_encode(addr, level, true));
> + i++;
> + }
> +
> + /* XXX: This serves as a posting read to make sure that the PTE has
> + * actually been updated. There is some concern that even though
> + * registers and PTEs are within the same BAR that they are
> potentially
> + * of NUMA access patterns. Therefore, even with the way we
> assume
> + * hardware should work, we must keep this posting read for
> paranoia.
> + */
> + if (i != 0)
> + WARN_ON(readl(>t_entries[i-1])
> + != gen8_pte_encode(addr, level, true));
Comparing a u32 with a 64-bit page-table entry ?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/62] drm/i915/bdw: Implement interrupt changes
On Sat, Nov 02, 2013 at 09:07:09PM -0700, Ben Widawsky wrote:
> The interrupt handling implementation remains the same as previous
> generations with the 4 types of registers, status, identity, mask, and
> enable. However the layout of where the bits go have changed entirely.
> To address these changes, all of the interrupt vfuncs needed special
> gen8 code.
>
> The way it works is there is a top level status register now which
> informs the interrupt service routine which unit caused the interrupt,
> and therefore which interrupt registers to read to process the
> interrupt. For display the division is quite logical, a set of interrupt
> registers for each pipe, and in addition to those, a set each for "misc"
> and port.
>
> For GT the things get a bit hairy, as seen by the code. Each of the GT
> units has it's own bits defined. They all look *very similar* and
> resides in 16 bits of a GT register. As an example, RCS and BCS share
> register 0. To compact the code a bit, at a slight expense to
> complexity, this is exactly how the code works as well. 2 structures are
> added to the ring buffer so that our ring buffer interrupt handling code
> knows which ring shares the interrupt registers, and a shift value (ie.
> the top or bottom 16 bits of the register).
>
> The above allows us to kept the interrupt register caching scheme, the
> per interrupt enables, and the code to mask and unmask interrupts
> relatively clean (again at the cost of some more complexity).
>
> Most of the GT units mentioned above are command streamers, and so the
> symmetry should work quite well for even the yet to be implemented rings
> which Broadwell adds.
>
> v2: Fixes up a couple of bugs, and is more verbose about errors in the
> Broadwell interrupt handler.
>
> v3: fix DE_MISC IER offset
>
> v4: Simplify interrupts:
> I totally misread the docs the first time I implemented interrupts, and
> so this should greatly simplify the mess. Unlike GEN6, we never touch
> the regular mask registers in irq_get/put.
>
> v5: Rebased on to of recent pch hotplug setup changes.
>
> v6: Fixup on top of moving num_pipes to intel_info.
>
> v7: Rebased on top of Egbert Eich's hpd irq handling rework. Also
> wired up ibx_hpd_irq_setup for gen8.
>
> v8: Rebase on top of Jani's asle handling rework.
>
> v9: Rebase on top of Ben's VECS enabling for Haswell, where he
> unfortunately went OCD on the gt irq #defines. Not that they're still
> not yet fully consistent:
> - Used the GT_RENDER_ #defines + bdw shifts.
> - Dropped the shift from the L3_PARITY stuff, seemed clearer.
> - s/irq_refcount/irq_refcount.gt/
>
> v10: Squash in VECS enabling patches and the gen8_gt_irq_handler
> refactoring from Zhao Yakui
>
> v11: Rebase on top of the interrupt cleanups in upstream.
>
> v12: Rebase on top of Ben's DPF changes in upstream.
>
> v13: Drop bdw from the HAS_L3_DPF feature flag for now, it's unclear what
> exactly needs to be done. Requested by Ben.
>
> Signed-off-by: Ben Widawsky (v4)
> Signed-off-by: Daniel Vetter
I've had to fix quite a few things here, and I've made myself a todo for
patches to write on top of this one here. See the v14 changelog entry.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_drv.h | 5 +-
> drivers/gpu/drm/i915/i915_irq.c | 327
>
> drivers/gpu/drm/i915/i915_reg.h | 63 ++
> drivers/gpu/drm/i915/intel_ringbuffer.c | 90 +++--
> 4 files changed, 473 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index c1b178a..83d016c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1315,7 +1315,10 @@ typedef struct drm_i915_private {
> struct mutex dpio_lock;
>
> /** Cached value of IMR to avoid reads in updating the bitfield */
> - u32 irq_mask;
> + union {
> + u32 irq_mask;
> + u32 de_irq_mask[I915_MAX_PIPES];
> + };
> u32 gt_irq_mask;
> u32 pm_irq_mask;
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index a9f0cb6..3f0c9e3 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1118,6 +1118,56 @@ static void snb_gt_irq_handler(struct drm_device *dev,
> ivybridge_parity_error_irq_handler(dev, gt_iir);
> }
>
> +static irqreturn_t gen8_gt_irq_handler(struct drm_device *dev,
> + struct drm_i915_private *dev_priv,
> + u32 master_ctl)
> +{
> + u32 rcs, bcs, vcs;
> + uint32_t tmp = 0;
> + irqreturn_t ret = IRQ_NONE;
> +
> + if (master_ctl & (GEN8_GT_RCS_IRQ | GEN8_GT_BCS_IRQ)) {
> + tmp = I915_READ(GEN8_GT_IIR(0));
> + if (tmp) {
> + ret = IRQ_HANDLED;
> + rcs = tmp >> GEN8_RCS_IRQ_SHIFT;
> + bcs = tmp >> GEN8_BCS_IRQ_SHIFT;
> +
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Store HPLL frequency in dev_priv on VLV
On Tue, Nov 05, 2013 at 01:02:58PM -0800, Jesse Barnes wrote:
> On Tue, 5 Nov 2013 22:42:30 +0200
> ville.syrj...@linux.intel.com wrote:
>
> > From: Ville Syrjälä
> >
> > Keep the HPLL frequencey in dev_priv on VLV instead of reading
> > it from CCK every time it's needed.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 2 +-
> > drivers/gpu/drm/i915/intel_display.c | 7 ++-
> > 2 files changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 4bae871..dd40925 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1360,7 +1360,7 @@ typedef struct drm_i915_private {
> > int fence_reg_start; /* 4 if userland hasn't ioctl'd us yet */
> > int num_fence_regs; /* 8 on pre-965, 16 otherwise */
> >
> > - unsigned int fsb_freq, mem_freq, is_ddr3;
> > + unsigned int fsb_freq, mem_freq, is_ddr3, hpll_vco;
> >
> > /**
> > * wq - Driver workqueue for GEM.
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 48f4990..f97e895 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -3898,13 +3898,18 @@ int valleyview_get_vco(struct drm_i915_private
> > *dev_priv)
> > {
> > int hpll_freq, vco_freq[] = { 800, 1600, 2000, 2400 };
> >
> > + if (dev_priv->hpll_vco)
> > + return dev_priv->hpll_vco;
> > +
> > /* Obtain SKU information */
> > mutex_lock(&dev_priv->dpio_lock);
> > hpll_freq = vlv_cck_read(dev_priv, CCK_FUSE_REG) &
> > CCK_FUSE_HPLL_FREQ_MASK;
> > mutex_unlock(&dev_priv->dpio_lock);
> >
> > - return vco_freq[hpll_freq];
> > + dev_priv->hpll_vco = vco_freq[hpll_freq];
> > +
> > + return dev_priv->hpll_vco;
> > }
> >
> > /* Adjust CDclk dividers to allow high res or save power if possible */
>
> I'd just move this to init_clock_gating or something, then use
> dev_priv->hpll_vco everywhere, rather than this conditional lazy
> initialization.
The problem was the we need it at gmbus init time, and we do that very
early. So I couldn't figure out a nice place to stick it, and so
I ended up doing the lazy thing.
I suspect the best thing to do would be to move gmbus init to happen
later, alongside other modeset setup. But I'm feeling a bit lazy and
don't want to tackle that task right now.
Anyways, since we don't want patch 4/4, I think for now we can just
drop this one as well. The places where we call it currently aren't
really that frequent or performance sensitive.
--
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] drm/i915: Demote drop_caches_set print
On Wed, Nov 06, 2013 at 08:35:46AM +0100, Daniel Vetter wrote: > On Tue, Nov 05, 2013 at 05:01:38PM -0800, Ben Widawsky wrote: > > Many tests call this ad naseum now (in an infinite loop, very often). > > It clutters the logs. Actually, I'd rather drop it completely... > > Dropping it completely seems like the right solutions due to those "drop > caches in an infinite loop" kind of tests. By that argument we should remove all log messages. Why are we doing this ad nausem? I thought the recent intention was to call it around tests, in which case the debug log would be busy enough to hide this noise. (Noise until it is vital to explain some behavioural artifact.) -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 22/62] drm/i915/bdw: Implement Full Force Miss disables
On Tue, Nov 05, 2013 at 05:17:26PM +0100, Daniel Vetter wrote: > On Tue, Nov 05, 2013 at 05:41:21PM +0200, Imre Deak wrote: > > On Sat, 2013-11-02 at 21:07 -0700, Ben Widawsky wrote: > > > Implements WaVSRefCountFullforceMissDisable > > > Implements WaDSRefCountFullforceMissDisable > > > > > > v2: Rebased on the HSW patch (which fixed the bug from v1) > > > commit 41c0b3a88c7bae96d8e2ee60c7ed91f57fd152d7 > > > Author: Ben Widawsky > > > Date: Sat Jan 26 11:52:00 2013 -0800 > > > > > > drm/i915: Implement WaVSRefCountFullforceMissDisable > > > > > > Cc: Ville Syrjälä > > > Reviewed-by: Ville Syrjälä > > > Signed-off-by: Ben Widawsky > > > --- > > > drivers/gpu/drm/i915/i915_reg.h | 1 + > > > drivers/gpu/drm/i915/intel_pm.c | 4 > > > 2 files changed, 5 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h > > > b/drivers/gpu/drm/i915/i915_reg.h > > > index 9929750..68b877d 100644 > > > --- a/drivers/gpu/drm/i915/i915_reg.h > > > +++ b/drivers/gpu/drm/i915/i915_reg.h > > > @@ -990,6 +990,7 @@ > > > > > > #define GEN7_FF_THREAD_MODE 0x20a0 > > > #define GEN7_FF_SCHED_MASK 0x0077070 > > > +#define GEN7_FF_DS_REF_CNT_FFME(1 << 19) > > > #define GEN7_FF_TS_SCHED_HS1 (0x5<<16) > > > #define GEN7_FF_TS_SCHED_HS0 (0x3<<16) > > > #define GEN7_FF_TS_SCHED_LOAD_BALANCE (0x1<<16) > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c > > > b/drivers/gpu/drm/i915/intel_pm.c > > > index abc51ea..81ec2c3 100644 > > > --- a/drivers/gpu/drm/i915/intel_pm.c > > > +++ b/drivers/gpu/drm/i915/intel_pm.c > > > @@ -5147,6 +5147,10 @@ static void gen7_setup_fixed_func_scheduler(struct > > > drm_i915_private *dev_priv) > > > if (IS_HASWELL(dev_priv->dev)) > > > reg &= ~GEN7_FF_VS_REF_CNT_FFME; > > > > > > + /* WaVSRefCountFullforceMissDisable|WaDSRefCountFullforceMissDisable */ > > > + if (IS_GEN8(dev_priv->dev)) > > > + reg &= ~(GEN7_FF_DS_REF_CNT_FFME | GEN7_FF_VS_REF_CNT_FFME); > > > + > > > I915_WRITE(GEN7_FF_THREAD_MODE, reg); > > > } > > > > gen7_setup_fixed_func_scheduler() isn't called for GEN8. > > I've just looked at the history of the quilt tree and it's been like that > ever since I've merged the patch apparently. Probably mis-wiggled while > applying ... Ben, should I just move this to the gen8 clock gating? I've dropped this one for now. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Store HPLL frequency in dev_priv on VLV
On Wed, Nov 06, 2013 at 10:41:22AM +0200, Ville Syrjälä wrote:
> On Tue, Nov 05, 2013 at 01:02:58PM -0800, Jesse Barnes wrote:
> > On Tue, 5 Nov 2013 22:42:30 +0200
> > ville.syrj...@linux.intel.com wrote:
> >
> > > From: Ville Syrjälä
> > >
> > > Keep the HPLL frequencey in dev_priv on VLV instead of reading
> > > it from CCK every time it's needed.
> > >
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/i915_drv.h | 2 +-
> > > drivers/gpu/drm/i915/intel_display.c | 7 ++-
> > > 2 files changed, 7 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 4bae871..dd40925 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -1360,7 +1360,7 @@ typedef struct drm_i915_private {
> > > int fence_reg_start; /* 4 if userland hasn't ioctl'd us yet */
> > > int num_fence_regs; /* 8 on pre-965, 16 otherwise */
> > >
> > > - unsigned int fsb_freq, mem_freq, is_ddr3;
> > > + unsigned int fsb_freq, mem_freq, is_ddr3, hpll_vco;
> > >
> > > /**
> > >* wq - Driver workqueue for GEM.
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 48f4990..f97e895 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -3898,13 +3898,18 @@ int valleyview_get_vco(struct drm_i915_private
> > > *dev_priv)
> > > {
> > > int hpll_freq, vco_freq[] = { 800, 1600, 2000, 2400 };
> > >
> > > + if (dev_priv->hpll_vco)
> > > + return dev_priv->hpll_vco;
> > > +
> > > /* Obtain SKU information */
> > > mutex_lock(&dev_priv->dpio_lock);
> > > hpll_freq = vlv_cck_read(dev_priv, CCK_FUSE_REG) &
> > > CCK_FUSE_HPLL_FREQ_MASK;
> > > mutex_unlock(&dev_priv->dpio_lock);
> > >
> > > - return vco_freq[hpll_freq];
> > > + dev_priv->hpll_vco = vco_freq[hpll_freq];
> > > +
> > > + return dev_priv->hpll_vco;
> > > }
> > >
> > > /* Adjust CDclk dividers to allow high res or save power if possible */
> >
> > I'd just move this to init_clock_gating or something, then use
> > dev_priv->hpll_vco everywhere, rather than this conditional lazy
> > initialization.
>
> The problem was the we need it at gmbus init time, and we do that very
> early. So I couldn't figure out a nice place to stick it, and so
> I ended up doing the lazy thing.
>
> I suspect the best thing to do would be to move gmbus init to happen
> later, alongside other modeset setup. But I'm feeling a bit lazy and
> don't want to tackle that task right now.
>
> Anyways, since we don't want patch 4/4, I think for now we can just
> drop this one as well. The places where we call it currently aren't
> really that frequent or performance sensitive.
init ordering hell strikes again. If we opt for a fixed order (the lazy
ordering seems to not be too evil though in this case) I'd like to have a
big WARN in there in case we get it wrong.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Demote drop_caches_set print
On Wed, Nov 06, 2013 at 09:19:42AM +, Chris Wilson wrote: > On Wed, Nov 06, 2013 at 08:35:46AM +0100, Daniel Vetter wrote: > > On Tue, Nov 05, 2013 at 05:01:38PM -0800, Ben Widawsky wrote: > > > Many tests call this ad naseum now (in an infinite loop, very often). > > > It clutters the logs. Actually, I'd rather drop it completely... > > > > Dropping it completely seems like the right solutions due to those "drop > > caches in an infinite loop" kind of tests. > > By that argument we should remove all log messages. Why are we doing > this ad nausem? I thought the recent intention was to call it around > tests, in which case the debug log would be busy enough to hide this > noise. (Noise until it is vital to explain some behavioural artifact.) Some tests fork a 2nd thread which calls this in a busy loop. Together with using gtt mmaps for ioctl data it's a very effective means to hit the slowpath maze in our execbuf code. Iirc without this at least some of the older bugs wouldn't be possible to hit (namely the slowpath of the writeout of the updated gtt offset in the slow relocation path that we've killed since it's too hard). Generally I agree with you, but since I abuse this facility rather badly in some tests I guess we should drop the debug output. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] More questions and patches for 835GM/ns2501 DVO
On Sun, Nov 03, 2013 at 10:18:14PM +0100, Daniel Vetter wrote: > > On Sun, Nov 3, 2013 at 8:00 PM, Thomas Richter wrote: > > On 03.11.2013 18:13, Daniel Vetter wrote: > >>> > >>> Have you tried my patch to reorder the dvo sequence a bit? That /should/ > >>> get all these things right: > >>> > >>> http://www.spinics.net/lists/intel-gfx/msg34349.html > >> > >> There's also a follow-up patch for you to test: > >> > >> > >> http://www.spinics.net/lists/intel-gfx/msg34350.html > >> > >> That would prove that the first patch does indeed work. Note that patch 1 > >> in this series is already merged. > > > > Thanks, I tried. Actually, this worked fairly (but not perfectly) well. I no > > longer get a "stuck DVO" as I did before, i.e. the "re-enable" logic is not > > triggered anymore. However, I do get (occasionally) a kernel-oops: > > That's just a warning, not an oops ... > > > > > [ cut here ] > > WARNING: CPU: 0 PID: 2311 at drivers/gpu/drm/i915/intel_display.c:1098 > > assert_cursor.constprop.68+0xba/0xc0 [i915]() > > cursor on pipe A assertion failure (expected off, current on) > > Modules linked in: cpufreq_stats binfmt_misc michael_mic arc4 ecb > > lib80211_crypt_tkip lib80211_crypt_ccmp fuse nfsd exportfs nfs_acl nfs lockd > > fscache sunrpc loop firewire_sbp2 hostap_cs hostap snd_intel8x0 > > snd_ac97_codec ac97_bus lib80211 snd_pcm i915 snd_page_alloc snd_seq > > snd_seq_device snd_timer psmouse snd pcmcia apanel input_polldev soundcore > > yenta_socket pcmcia_rsrc pcmcia_core lpc_ich i2c_i801 mfd_core pcspkr > > i2c_algo_bit rng_core serio_raw evdev drm_kms_helper drm fujitsu_laptop > > led_class intel_agp intel_gtt agpgart i2c_core video ac button hid_generic > > usbhid hid sg sr_mod cdrom firewire_ohci firewire_core crc_itu_t 8139too > > 8139cp mii uhci_hcd usbcore usb_common > > CPU: 0 PID: 2311 Comm: Xorg Tainted: GW3.12.0-rc7+ #13 > > Hardware name: FUJITSU SIEMENS LIFEBOOK S Series/FJNB159, BIOS Version 1.06 > > 07/02/2002 > > c12f8c44 c1033def f8ad3990 f6adfab0 0907 f8ad25d8 044a f8a81ffa > > f8a81ffa f5ca8000 0041 f5ca8000 c1033eb3 0009 f6adfa98 > > f8ad3990 f6adfab0 f8a81ffa f8ad25d8 044a f8ad3990 0041 f8adb9a0 > > Call Trace: > > [] ? dump_stack+0xa/0x13 > > [] ? warn_slowpath_common+0x7f/0xb0 > > [] ? assert_cursor.constprop.68+0xba/0xc0 [i915] > > [] ? assert_cursor.constprop.68+0xba/0xc0 [i915] > > [] ? warn_slowpath_fmt+0x33/0x40 > > [] ? assert_cursor.constprop.68+0xba/0xc0 [i915] > > [] ? intel_disable_pipe+0x30/0xb0 [i915] > > [] ? i9xx_crtc_disable+0xca/0x2f0 [i915] > > [] ? __intel_set_mode+0x7ae/0x13b0 [i915] > > [] ? intel_set_mode+0x23/0x40 [i915] > > [] ? intel_crtc_set_config+0x7ac/0x9d0 [i915] > > [] ? drm_mode_set_config_internal+0x43/0xb0 [drm] > > [] ? drm_fb_helper_set_par+0x45/0xac [drm_kms_helper] > > [] ? fb_set_var+0x1a6/0x420 > > [] ? __find_get_block+0x9e/0x160 > > [] ? fbcon_blank+0x290/0x2d0 > > [] ? do_unblank_screen+0x98/0x1b0 > > [] ? notify_update+0x1d/0x30 > > [] ? complete_change_console+0x52/0xe0 > > [] ? vt_ioctl+0x1104/0x1220 > > [] ? drm_setmaster_ioctl+0xe0/0xe0 [drm] > > [] ? complete_change_console+0xe0/0xe0 > > [] ? tty_ioctl+0x21a/0x9a0 > > [] ? do_wp_page.isra.92+0x2a2/0x650 > > [] ? handle_mm_fault+0x318/0x610 > > [] ? no_tty+0x20/0x20 > > [] ? do_vfs_ioctl+0x7c/0x550 > > [] ? __do_page_fault+0x1b1/0x490 > > [] ? vfs_write+0x137/0x1b0 > > [] ? SyS_ioctl+0x46/0x80 > > [] ? sysenter_do_call+0x12/0x26 > > ---[ end trace 85d231d1072e932a ]--- > > > > If this happens, I get a black screen with only a cursor on it. Switching to > > the console and back restores the screen. > > Hm, that would mean that the cursor is somehow stuck in the enabled state, > despite that we've tried to disabled it very hard. Can you please try out > the below patch? If this doesn't work please take not of the different > WARNINGs you're hitting and whether it's always the same one with the same > calltrace or something different. > > I think for now we should try to get the single monitor case working - I > have a few theories for the dual-screen issues, but there's not much point > working on them if the simple case doesn't work yet. > > Also I think I'll merge the two patches if they don't make things worse > for you, imo it's the right approach and at least conceptually should be > able to avoid all these retry loops. > > Thanks, Daniel > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index f34252d134b6..04d2699f51b4 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -7123,7 +7123,9 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, > u32 base) > intel_crtc->cursor_visible = visible; > } > /* and commit changes on next vblank */ > + POSTING_READ(CURCNTR(pipe)); > I915_WRITE(CURBASE(pipe), base); > + POSTING_READ(CURBASE(
[Intel-gfx] intel_drv.so segfault
I'm getting the following segfault intermittently when using sna. I've tried xf86-video-intel-2.99.905 and the latest from git a week or so ago. [ 12021.732] (EE) Backtrace: [ 12021.741] (EE) 0: /usr/bin/X (xorg_backtrace+0x36) [0x589746] [ 12021.741] (EE) 1: /usr/bin/X (0x40+0x18d3d9) [0x58d3d9] [ 12021.741] (EE) 2: /lib64/libpthread.so.0 (0x7f5c707c5000+0x10460) [0x7f5c707d5460] [ 12021.741] (EE) 3: /usr/lib64/xorg/modules/drivers/intel_drv.so (0x7f5c6e3ca000+0x2fe79) [0x7f5c6e3f9e79] [ 12021.741] (EE) 4: /usr/lib64/xorg/modules/drivers/intel_drv.so (0x7f5c6e3ca000+0x3037f) [0x7f5c6e3fa37f] [ 12021.741] (EE) 5: /usr/bin/X (0x40+0x3713b) [0x43713b] [ 12021.741] (EE) 6: /usr/bin/X (0x40+0x3b176) [0x43b176] [ 12021.741] (EE) 7: /usr/bin/X (0x40+0x29c4a) [0x429c4a] [ 12021.741] (EE) 8: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x7f5c6f44a4bd] [ 12021.741] (EE) 9: /usr/bin/X (0x40+0x29f91) [0x429f91] [ 12021.741] (EE) [ 12021.741] (EE) Segmentation fault at address 0x0 - Grant ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] intel_drv.so segfault
On Wed, Nov 06, 2013 at 02:33:49AM -0800, Grant wrote: > I'm getting the following segfault intermittently when using sna. > I've tried xf86-video-intel-2.99.905 and the latest from git a week or > so ago. Symbols, please. addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i 0x2fe790x3037f -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] intel_drv.so segfault
On Wed, Nov 06, 2013 at 10:37:33AM +, Chris Wilson wrote: > On Wed, Nov 06, 2013 at 02:33:49AM -0800, Grant wrote: > > I'm getting the following segfault intermittently when using sna. > > I've tried xf86-video-intel-2.99.905 and the latest from git a week or > > so ago. > > Symbols, please. > > addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i 0x2fe790x3037f addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i 0x2fe79 0x3037f -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: Sanitize prepare_pipes after valleyview_modeset_global_pipes()
On Wed, Nov 06, 2013 at 08:33:08AM +0100, Daniel Vetter wrote:
> On Tue, Nov 05, 2013 at 10:34:12PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > valleyview_modeset_global_pipes() may add pipes that are getting fully
> > disabled to prepare_pipes bitmask. The rest of the code doesn't expect
> > this, so clear out any such pipes from the prepare_pipes bitmask.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index f97e895..ddbef9c 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -9514,10 +9514,14 @@ static int __intel_set_mode(struct drm_crtc *crtc,
> > * mode set on this crtc. For other crtcs we need to use the
> > * adjusted_mode bits in the crtc directly.
> > */
> > - if (IS_VALLEYVIEW(dev))
> > + if (IS_VALLEYVIEW(dev)) {
> > valleyview_modeset_global_pipes(dev, &prepare_pipes,
> > modeset_pipes, pipe_config);
> >
> > + /* may have added more to prepare_pipes than we should */
> > + prepare_pipes &= ~disable_pipes;
> > + }
>
> I'd have move the full "take disable_pipes out" block from affected_pipes.
> Afacs there's no need to do it twice.
I think we'd need to keep the '*modeset_pipes &= ~(*disable_pipes)' part
in intel_modeset_affected_pipes(). Otherwise we might end up calling
intel_modeset_pipe_config() for a disabled pipe. For prepare_pipes, it
looks like we could move the masking to happen only once after
valleyview_modeset_global_pipes(). Not sure if spreading it around like
that makes sense.
> -Daniel
> > +
> > for_each_intel_crtc_masked(dev, disable_pipes, intel_crtc)
> > intel_crtc_disable(&intel_crtc->base);
> >
> > --
> > 1.8.1.5
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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 1/2] drm/i915/vlv: Make the vlv_dpio_read/vlv_dpio_write more PHY centric
On Wed, Nov 06, 2013 at 02:36:35PM +0800, Chon Ming Lee wrote:
> vlv_dpio_read/write should be describe more in PHY centric instead of
> display controller centric.
> Create a enum dpio_channel for channel index and enum dpio_phy for PHY
> index. This should better to gather for upcoming platform.
>
> v2: Rebase the code based on
> drm/i915/vlv: Fix typo in the DPIO register define.
>
> v3: Rename vlv_phy to dpio_phy_iosf_port and define additional macro
> DPIO_PHY, and remove unrelated change. (Ville)
>
> Suggested-by: Ville Syrjälä
> Signed-off-by: Chon Ming Lee
Reviewed-by: Ville Syrjälä
PS.
Please add v2,v3,etc. note to the subject. In this case it would be
"[PATCH v3 1/2] ...". Otherwise it's really easy to lose track which
mail has the latest version.
> ---
> drivers/gpu/drm/i915/i915_drv.h | 13 +
> drivers/gpu/drm/i915/i915_reg.h |3 +++
> drivers/gpu/drm/i915/intel_display.c | 16
> drivers/gpu/drm/i915/intel_dp.c |8
> drivers/gpu/drm/i915/intel_drv.h |7 ---
> drivers/gpu/drm/i915/intel_hdmi.c |8
> drivers/gpu/drm/i915/intel_sideband.c | 13 ++---
> 7 files changed, 42 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 2aa7053..9fafc38 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -88,6 +88,18 @@ enum port {
> };
> #define port_name(p) ((p) + 'A')
>
> +#define I915_NUM_PHYS_VLV 1
> +
> +enum dpio_channel {
> + DPIO_CH0,
> + DPIO_CH1
> +};
> +
> +enum dpio_phy {
> + DPIO_PHY0,
> + DPIO_PHY1
> +};
> +
> enum intel_display_power_domain {
> POWER_DOMAIN_PIPE_A,
> POWER_DOMAIN_PIPE_B,
> @@ -1403,6 +1415,7 @@ typedef struct drm_i915_private {
> int num_shared_dpll;
> struct intel_shared_dpll shared_dplls[I915_NUM_PLLS];
> struct intel_ddi_plls ddi_plls;
> + int dpio_phy_iosf_port[I915_NUM_PHYS_VLV];
>
> /* Reclocking support */
> bool render_reclock_avail;
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 4dbc8da..969ca2e 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -457,6 +457,9 @@
> #define DPIO_TX3_SWING_CTL4(pipe) _PIPE(pipe, _DPIO_TX3_SWING_CTL4_A, \
> _DPIO_TX3_SWING_CTL4_B)
>
> +#define DPIO_PHY(pipe) ((pipe) >> 1)
> +#define DPIO_PHY_IOSF_PORT(phy)
> (dev_priv->dpio_phy_iosf_port[phy])
> +
> /*
> * Per pipe/PLL DPIO regs
> */
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 48f4990..b1d20b6 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1361,6 +1361,7 @@ static void intel_init_dpio(struct drm_device *dev)
> if (!IS_VALLEYVIEW(dev))
> return;
>
> + DPIO_PHY_IOSF_PORT(DPIO_PHY0) = IOSF_PORT_DPIO;
> /*
>* From VLV2A0_DP_eDP_DPIO_driver_vbios_notes_10.docx -
>* 6. De-assert cmn_reset/side_reset. Same as VLV X0.
> @@ -1494,18 +1495,25 @@ static void vlv_disable_pll(struct drm_i915_private
> *dev_priv, enum pipe pipe)
> POSTING_READ(DPLL(pipe));
> }
>
> -void vlv_wait_port_ready(struct drm_i915_private *dev_priv, int port)
> +void vlv_wait_port_ready(struct drm_i915_private *dev_priv,
> + struct intel_digital_port *dport)
> {
> u32 port_mask;
>
> - if (!port)
> + switch (dport->port) {
> + case PORT_B:
> port_mask = DPLL_PORTB_READY_MASK;
> - else
> + break;
> + case PORT_C:
> port_mask = DPLL_PORTC_READY_MASK;
> + break;
> + default:
> + BUG();
> + }
>
> if (wait_for((I915_READ(DPLL(0)) & port_mask) == 0, 1000))
> WARN(1, "timed out waiting for port %c ready: 0x%08x\n",
> - 'B' + port, I915_READ(DPLL(0)));
> + 'B' + dport->port, I915_READ(DPLL(0)));
> }
>
> /**
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index bcbdc7a..aea9e28 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1839,7 +1839,7 @@ static void vlv_pre_enable_dp(struct intel_encoder
> *encoder)
> struct drm_device *dev = encoder->base.dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
> - int port = vlv_dport_to_channel(dport);
> + enum dpio_channel port = vlv_dport_to_channel(dport);
> int pipe = intel_crtc->pipe;
> struct edp_power_seq power_seq;
> u32 val;
> @@ -1866,7 +1866,7 @@ static void vlv_pre_enable_dp(struct intel_encoder
> *encoder)
>
> intel_enable_dp(encoder);
>
> - vlv_wait_port_ready(dev_priv, port);
>
Re: [Intel-gfx] [PATCH 2/2] drm/i915/vlv: Rename VLV DPIO register to be more structure to match configdb document.
On Wed, Nov 06, 2013 at 02:37:36PM +0800, Chon Ming Lee wrote: > Some VLV PHY/PLL DPIO registers have group/lane/channel access. Current > DPIO register definition doesn't have a structure way to break them > down. As a result it is not easy to match the PHY/PLL registers with the > configdb document. Rename those registers based on the configdb for easy > cross references, and without the need to check the offset in the header > file. > > New format is as following. > > __DW doc>_ > > For example, > > VLV_PCS_DW0 - Group access to PCS for lane 0 to 3 for PCS DWORD 0. > VLV_PCS01_DW0_CH0 - PCS access to lane 0/1, channel 0 for PCS DWORD 0. > > Another example is > > VLV_TX_DW0 - Group access to TX lane 0 to 3 for TX DWORD 0 > VLV_TX0_DW0 - Refer to TX Lane 0 access only for TX DWORD 0. > > There is no functional change on this patch. > > v2: Rebase based on previous patch change. > > Suggested-by: Ville Syrjälä > Signed-off-by: Chon Ming Lee > --- > drivers/gpu/drm/i915/i915_debugfs.c | 40 > drivers/gpu/drm/i915/i915_reg.h | 190 > -- > drivers/gpu/drm/i915/intel_display.c | 48 +- > drivers/gpu/drm/i915/intel_dp.c | 32 +++--- > drivers/gpu/drm/i915/intel_hdmi.c| 54 -- > 5 files changed, 171 insertions(+), 193 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c > b/drivers/gpu/drm/i915/i915_debugfs.c > index 7008aac..d756e23 100644 > --- a/drivers/gpu/drm/i915/i915_debugfs.c > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > @@ -1650,28 +1650,28 @@ static int i915_dpio_info(struct seq_file *m, void > *data) > > seq_printf(m, "DPIO_CTL: 0x%08x\n", I915_READ(DPIO_CTL)); > > - seq_printf(m, "DPIO_DIV_A: 0x%08x\n", > -vlv_dpio_read(dev_priv, PIPE_A, _DPIO_DIV_A)); > - seq_printf(m, "DPIO_DIV_B: 0x%08x\n", > -vlv_dpio_read(dev_priv, PIPE_A, _DPIO_DIV_B)); > - > - seq_printf(m, "DPIO_REFSFR_A: 0x%08x\n", > -vlv_dpio_read(dev_priv, PIPE_A, _DPIO_REFSFR_A)); > - seq_printf(m, "DPIO_REFSFR_B: 0x%08x\n", > -vlv_dpio_read(dev_priv, PIPE_A, _DPIO_REFSFR_B)); > - > - seq_printf(m, "DPIO_CORE_CLK_A: 0x%08x\n", > -vlv_dpio_read(dev_priv, PIPE_A, _DPIO_CORE_CLK_A)); > - seq_printf(m, "DPIO_CORE_CLK_B: 0x%08x\n", > -vlv_dpio_read(dev_priv, PIPE_A, _DPIO_CORE_CLK_B)); > - > - seq_printf(m, "DPIO_LPF_COEFF_A: 0x%08x\n", > -vlv_dpio_read(dev_priv, PIPE_A, _DPIO_LPF_COEFF_A)); > - seq_printf(m, "DPIO_LPF_COEFF_B: 0x%08x\n", > -vlv_dpio_read(dev_priv, PIPE_A, _DPIO_LPF_COEFF_B)); > + seq_printf(m, "DPIO PLL DW3 CH0 : 0x%08x\n", > +vlv_dpio_read(dev_priv, PIPE_A, VLV_PLL_DW3(0))); > + seq_printf(m, "DPIO PLL DW3 CH1: 0x%08x\n", > +vlv_dpio_read(dev_priv, PIPE_A, VLV_PLL_DW3(1))); > + > + seq_printf(m, "DPIO PLL DW5 CH0: 0x%08x\n", > +vlv_dpio_read(dev_priv, PIPE_A, VLV_PLL_DW5(0))); > + seq_printf(m, "DPIO PLL DW5 CH1: 0x%08x\n", > +vlv_dpio_read(dev_priv, PIPE_A, VLV_PLL_DW5(1))); > + > + seq_printf(m, "DPIO PLL DW7 CH0: 0x%08x\n", > +vlv_dpio_read(dev_priv, PIPE_A, VLV_PLL_DW7(0))); > + seq_printf(m, "DPIO PLL DW7 CH1: 0x%08x\n", > +vlv_dpio_read(dev_priv, PIPE_A, VLV_PLL_DW7(1))); > + > + seq_printf(m, "DPIO PLL DW12 CH0: 0x%08x\n", > +vlv_dpio_read(dev_priv, PIPE_A, VLV_PLL_DW12(0))); > + seq_printf(m, "DPIO PLL DW12 CH1: 0x%08x\n", > +vlv_dpio_read(dev_priv, PIPE_A, VLV_PLL_DW12(1))); > > seq_printf(m, "DPIO_FASTCLK_DISABLE: 0x%08x\n", > -vlv_dpio_read(dev_priv, PIPE_A, DPIO_FASTCLK_DISABLE)); > +vlv_dpio_read(dev_priv, PIPE_A, VLV_CMN_DW0)); > > mutex_unlock(&dev_priv->dpio_lock); > > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > index 969ca2e..c71b729 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -452,18 +452,13 @@ > #define DPIO_SFR_BYPASS (1<<1) > #define DPIO_CMNRST (1<<0) > > -#define _DPIO_TX3_SWING_CTL4_A 0x690 > -#define _DPIO_TX3_SWING_CTL4_B 0x2a90 > -#define DPIO_TX3_SWING_CTL4(pipe) _PIPE(pipe, _DPIO_TX3_SWING_CTL4_A, \ > - _DPIO_TX3_SWING_CTL4_B) > - > #define DPIO_PHY(pipe) ((pipe) >> 1) > #define DPIO_PHY_IOSF_PORT(phy) > (dev_priv->dpio_phy_iosf_port[phy]) > > /* > * Per pipe/PLL DPIO regs > */ > -#define _DPIO_DIV_A 0x800c > +#define _VLV_PLL_DW3_CH0 0x800c > #define DPIO_POST_DIV_SHIFT(28) /* 3 bits */ > #define DPIO_POST_DIV_DAC 0 > #define DPIO_POST_DIV_HDMIDP 1 /* DAC 225-400M rate */ > @@ -476,10 +471,10 @@ > #define DPIO
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix gen2 scanout position readout
I was going to get this for -collector but got a big conflict.
On Fri, Oct 11, 2013 at 3:52 PM, wrote:
> From: Ville Syrjälä
>
> Gen2 doesn't have the pixelcount register that gen3 and gen4 have.
> Instead we must use the scanline counter like we do for ctg+.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_irq.c | 21 +++--
> 1 file changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 63a9642..3c31a2f 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -592,7 +592,7 @@ static u32 gm45_get_vblank_counter(struct drm_device
> *dev, int pipe)
> return I915_READ(reg);
> }
>
> -static bool g4x_pipe_in_vblank(struct drm_device *dev, enum pipe pipe)
> +static bool intel_pipe_in_vblank(struct drm_device *dev, enum pipe pipe)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> uint32_t status;
> @@ -603,7 +603,13 @@ static bool g4x_pipe_in_vblank(struct drm_device *dev,
> enum pipe pipe)
> I915_DISPLAY_PIPE_B_VBLANK_INTERRUPT;
>
> return I915_READ(VLV_ISR) & status;
> - } else if (IS_G4X(dev)) {
> + } else if (IS_GEN2(dev)) {
> + status = pipe == PIPE_A ?
> + I915_DISPLAY_PIPE_A_VBLANK_INTERRUPT :
> + I915_DISPLAY_PIPE_B_VBLANK_INTERRUPT;
> +
> + return I915_READ16(ISR) & status;
> + } else if (INTEL_INFO(dev)->gen < 5) {
> status = pipe == PIPE_A ?
> I915_DISPLAY_PIPE_A_VBLANK_INTERRUPT :
> I915_DISPLAY_PIPE_B_VBLANK_INTERRUPT;
> @@ -658,11 +664,14 @@ static int i915_get_crtc_scanoutpos(struct drm_device
> *dev, int pipe,
>
> ret |= DRM_SCANOUTPOS_VALID | DRM_SCANOUTPOS_ACCURATE;
>
> - if (IS_G4X(dev) || INTEL_INFO(dev)->gen >= 5) {
> + if (IS_GEN2(dev) || IS_G4X(dev) || INTEL_INFO(dev)->gen >= 5) {
> /* No obvious pixelcount register. Only query vertical
> * scanout position from Display scan line register.
> */
> - position = I915_READ(PIPEDSL(pipe)) & 0x1fff;
> + if (IS_GEN2(dev))
> + position = I915_READ(PIPEDSL(pipe)) &
> DSL_LINEMASK_GEN2;
> + else
> + position = I915_READ(PIPEDSL(pipe)) &
> DSL_LINEMASK_GEN3;
>
> /*
> * The scanline counter increments at the leading edge
> @@ -671,7 +680,7 @@ static int i915_get_crtc_scanoutpos(struct drm_device
> *dev, int pipe,
> * to get a more accurate picture whether we're in vblank
> * or not.
> */
> - in_vbl = g4x_pipe_in_vblank(dev, pipe);
> + in_vbl = intel_pipe_in_vblank(dev, pipe);
> if ((in_vbl && position == vbl_start - 1) ||
> (!in_vbl && position == vbl_end - 1))
> position = (position + 1) % vtotal;
> @@ -701,7 +710,7 @@ static int i915_get_crtc_scanoutpos(struct drm_device
> *dev, int pipe,
> else
> position += vtotal - vbl_end;
>
> - if (IS_G4X(dev) || INTEL_INFO(dev)->gen >= 5) {
> + if (IS_GEN2(dev) || IS_G4X(dev) || INTEL_INFO(dev)->gen >= 5) {
> *vpos = position;
> *hpos = 0;
> } else {
> --
> 1.8.1.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] intel_drv.so segfault
>> > I'm getting the following segfault intermittently when using sna. >> > I've tried xf86-video-intel-2.99.905 and the latest from git a week or >> > so ago. >> >> Symbols, please. >> >> addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i 0x2fe790x3037f > > addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i 0x2fe79 0x3037f Maybe this needs to be run immediately after the crash? Or before rebooting? # addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i 0x2fe79 0x3037f ??:0 ??:0 - Grant ___ 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: Fix gen2 scanout position readout
On Wed, Nov 06, 2013 at 10:38:42AM -0200, Rodrigo Vivi wrote:
> I was going to get this for -collector but got a big conflict.
It should be already in. Although as it turns out it's partially
crap. Apparently I hadn't tested the ISR vblank bit behaviour
properly on non-PCH platforms. It doesn't actually work the way
we want, so there are patches in my latest vblank timestamp series
that kill the ISR parts and add a kludge to work around the scanline
counter's silly behaviour.
>
>
> On Fri, Oct 11, 2013 at 3:52 PM, wrote:
> > From: Ville Syrjälä
> >
> > Gen2 doesn't have the pixelcount register that gen3 and gen4 have.
> > Instead we must use the scanline counter like we do for ctg+.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_irq.c | 21 +++--
> > 1 file changed, 15 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 63a9642..3c31a2f 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -592,7 +592,7 @@ static u32 gm45_get_vblank_counter(struct drm_device
> > *dev, int pipe)
> > return I915_READ(reg);
> > }
> >
> > -static bool g4x_pipe_in_vblank(struct drm_device *dev, enum pipe pipe)
> > +static bool intel_pipe_in_vblank(struct drm_device *dev, enum pipe pipe)
> > {
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > uint32_t status;
> > @@ -603,7 +603,13 @@ static bool g4x_pipe_in_vblank(struct drm_device *dev,
> > enum pipe pipe)
> > I915_DISPLAY_PIPE_B_VBLANK_INTERRUPT;
> >
> > return I915_READ(VLV_ISR) & status;
> > - } else if (IS_G4X(dev)) {
> > + } else if (IS_GEN2(dev)) {
> > + status = pipe == PIPE_A ?
> > + I915_DISPLAY_PIPE_A_VBLANK_INTERRUPT :
> > + I915_DISPLAY_PIPE_B_VBLANK_INTERRUPT;
> > +
> > + return I915_READ16(ISR) & status;
> > + } else if (INTEL_INFO(dev)->gen < 5) {
> > status = pipe == PIPE_A ?
> > I915_DISPLAY_PIPE_A_VBLANK_INTERRUPT :
> > I915_DISPLAY_PIPE_B_VBLANK_INTERRUPT;
> > @@ -658,11 +664,14 @@ static int i915_get_crtc_scanoutpos(struct drm_device
> > *dev, int pipe,
> >
> > ret |= DRM_SCANOUTPOS_VALID | DRM_SCANOUTPOS_ACCURATE;
> >
> > - if (IS_G4X(dev) || INTEL_INFO(dev)->gen >= 5) {
> > + if (IS_GEN2(dev) || IS_G4X(dev) || INTEL_INFO(dev)->gen >= 5) {
> > /* No obvious pixelcount register. Only query vertical
> > * scanout position from Display scan line register.
> > */
> > - position = I915_READ(PIPEDSL(pipe)) & 0x1fff;
> > + if (IS_GEN2(dev))
> > + position = I915_READ(PIPEDSL(pipe)) &
> > DSL_LINEMASK_GEN2;
> > + else
> > + position = I915_READ(PIPEDSL(pipe)) &
> > DSL_LINEMASK_GEN3;
> >
> > /*
> > * The scanline counter increments at the leading edge
> > @@ -671,7 +680,7 @@ static int i915_get_crtc_scanoutpos(struct drm_device
> > *dev, int pipe,
> > * to get a more accurate picture whether we're in vblank
> > * or not.
> > */
> > - in_vbl = g4x_pipe_in_vblank(dev, pipe);
> > + in_vbl = intel_pipe_in_vblank(dev, pipe);
> > if ((in_vbl && position == vbl_start - 1) ||
> > (!in_vbl && position == vbl_end - 1))
> > position = (position + 1) % vtotal;
> > @@ -701,7 +710,7 @@ static int i915_get_crtc_scanoutpos(struct drm_device
> > *dev, int pipe,
> > else
> > position += vtotal - vbl_end;
> >
> > - if (IS_G4X(dev) || INTEL_INFO(dev)->gen >= 5) {
> > + if (IS_GEN2(dev) || IS_G4X(dev) || INTEL_INFO(dev)->gen >= 5) {
> > *vpos = position;
> > *hpos = 0;
> > } else {
> > --
> > 1.8.1.5
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
>
> --
> Rodrigo Vivi
> Blog: http://blog.vivi.eng.br
--
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] intel_drv.so segfault
On Wed, Nov 06, 2013 at 04:47:09AM -0800, Grant wrote: > >> > I'm getting the following segfault intermittently when using sna. > >> > I've tried xf86-video-intel-2.99.905 and the latest from git a week or > >> > so ago. > >> > >> Symbols, please. > >> > >> addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i 0x2fe790x3037f > > > > addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i 0x2fe79 0x3037f > > Maybe this needs to be run immediately after the crash? Or before rebooting? Ah, it does require xf86-video-intel to have been built with debug symbols (-g in CFLAGS) and not stripped upon installation. -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 51/62] drm/i915/bdw: Use HSW formula for ring freq scaling
On Sat, Nov 02, 2013 at 09:07:49PM -0700, Ben Widawsky wrote:
> The current formula we use for HSW is not what is in current docs.
> However, changing to the HSW formula on my HSW does not improve power
> usage, and decreases performance by about 5% in limited xonotic testing.
>
> For gen8, until we know otherwise, or run experiments, let's use
> the HSW formula - which should be the same used in the Windows driver
> (and thus help make an apples-applies comparison) on gen8.
>
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/intel_pm.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 6d14182..3dd30f7 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3924,7 +3924,10 @@ void gen6_update_ring_freq(struct drm_device *dev)
> int diff = dev_priv->rps.max_delay - gpu_freq;
> unsigned int ia_freq = 0, ring_freq = 0;
>
> - if (IS_HASWELL(dev)) {
> + if (INTEL_INFO(dev)->gen > 7) {
Our coding style is to use >= 8 or < 8 to be consistent with 0 based C
arrays and so hopefully avoiding off-by-ones. I.e. I've spent a bit of
time being stumped until I've noticed that this is gen8+ and actually
doesn't apply to ivb. Fixed while applying.
-Daniel
> + /* max(2 * GT, DDR). NB: GT is 50MHz units */
> + ring_freq = max(min_ring_freq, gpu_freq);
> + } else if (IS_HASWELL(dev)) {
> ring_freq = mult_frac(gpu_freq, 5, 4);
> ring_freq = max(min_ring_freq, ring_freq);
> /* leave ia_freq as the default, chosen by cpufreq */
> --
> 1.8.4.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] intel_drv.so segfault
>> >> > I'm getting the following segfault intermittently when using sna. >> >> > I've tried xf86-video-intel-2.99.905 and the latest from git a week or >> >> > so ago. >> >> >> >> Symbols, please. >> >> >> >> addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i >> >> 0x2fe790x3037f >> > >> > addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i 0x2fe79 >> > 0x3037f >> >> Maybe this needs to be run immediately after the crash? Or before rebooting? > > Ah, it does require xf86-video-intel to have been built with debug > symbols (-g in CFLAGS) and not stripped upon installation. I'm running Gentoo and I added -g to the following in make.conf: CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer -g" I rebooted but I still get nothing from the addr2line command. What am I missing? - Grant ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/5] drm-intel-collector - update
This is another drm-intel-collector updated notice: http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector Here goes the update list in order for better reviewers assignment: Patch drm/i915: Asynchronously perform the set-base for a simple modeset - Reviewed Patch drm/i915: Initialise min/max frequencies before updating RPS registers - Reviewer: Ville Syrjälä Patch drm/i915: Fix gen3/4 vblank counter wraparound - Reviewer: Patch drm/i915: Use frame counter for intel_wait_for_vblank() on CTG - Reviewer: Patch drm/i915: Require HW contexts (when possible) - Reviewer: Overall Process: drm-intel-collector - review request 1. Daniel pushs drm-intel-testing (every 2 weeks) 2. I rebase drm-intel-collector onto drm-intel-testing 3. Add Reviewer: tag with voluntered reviewers. If you don't believe you should be assigned on a particular patch please don't get mad just tell you wont review or volunteer someone else. 4. I resubmit remaining patches for review without picking any new (drm-intel-collector - review request) drm-intel-collector - updated 5. One week later I collect all simple (1-2) patches that wasn't yet reviewed and not queued by Daniel from one testing update until another. 6. Request automated QA's PRTS automated i-g-t tests comparing drm-intel-testing x drm-intel-collector 7. If tests are ok I send the update notification or the patches as a series to intel-gfx mailing list for better tracking and to be reviewed. (drm-intel-collector - updated) 8. Let me know volunteers for review new patches and also let me know if I've picked any patch that I shouldn't. There are some reasons that some patches can be left behind: 1. Your patch didn't applied cleanly and I couldn't easily solve the conflicts. 2. Kernel didn't compiled with your patch. 3. I simply missed it. If you believe this is the case please warn me. Please help me to get these patches reviewed and queued by Daniel. Also, please let me know if you have further ideas how to improve this process. Thanks in advance, Rodrigo. Ben Widawsky (1): drm/i915: Require HW contexts (when possible) Chris Wilson (2): drm/i915: Asynchronously perform the set-base for a simple modeset drm/i915: Initialise min/max frequencies before updating RPS registers Ville Syrjälä (2): drm/i915: Fix gen3/4 vblank counter wraparound drm/i915: Use frame counter for intel_wait_for_vblank() on CTG drivers/gpu/drm/i915/i915_debugfs.c | 2 +- drivers/gpu/drm/i915/i915_drv.c | 3 --- drivers/gpu/drm/i915/i915_drv.h | 3 +-- drivers/gpu/drm/i915/i915_gem.c | 8 +- drivers/gpu/drm/i915/i915_gem_context.c | 43 +++-- drivers/gpu/drm/i915/i915_irq.c | 2 +- drivers/gpu/drm/i915/i915_sysfs.c | 22 - drivers/gpu/drm/i915/intel_display.c| 19 +-- drivers/gpu/drm/i915/intel_pm.c | 19 --- 9 files changed, 57 insertions(+), 64 deletions(-) -- 1.8.3.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] intel_drv.so segfault
On Wed, Nov 06, 2013 at 06:22:40AM -0800, Grant wrote: > >> >> > I'm getting the following segfault intermittently when using sna. > >> >> > I've tried xf86-video-intel-2.99.905 and the latest from git a week or > >> >> > so ago. > >> >> > >> >> Symbols, please. > >> >> > >> >> addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i > >> >> 0x2fe790x3037f > >> > > >> > addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i 0x2fe79 > >> > 0x3037f > >> > >> Maybe this needs to be run immediately after the crash? Or before > >> rebooting? > > > > Ah, it does require xf86-video-intel to have been built with debug > > symbols (-g in CFLAGS) and not stripped upon installation. > > I'm running Gentoo and I added -g to the following in make.conf: > > CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer -g" > > I rebooted but I still get nothing from the addr2line command. What > am I missing? gentoo's /bin/install strips by default, iirc. Try addr2line -e /path/to/build/xf86-video-intel/src/.libs/intel_drv.so -i 0x2fe79 0x3037f -- 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] intel_drv.so segfault
On Wed, Nov 6, 2013 at 6:22 AM, Grant wrote: >>> >> > I'm getting the following segfault intermittently when using sna. >>> >> > I've tried xf86-video-intel-2.99.905 and the latest from git a week or >>> >> > so ago. >>> >> >>> >> Symbols, please. >>> >> >>> >> addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i >>> >> 0x2fe790x3037f >>> > >>> > addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i 0x2fe79 >>> > 0x3037f >>> >>> Maybe this needs to be run immediately after the crash? Or before >>> rebooting? >> >> Ah, it does require xf86-video-intel to have been built with debug >> symbols (-g in CFLAGS) and not stripped upon installation. > > I'm running Gentoo and I added -g to the following in make.conf: > > CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer -g" > > I rebooted but I still get nothing from the addr2line command. What > am I missing? FEATURES="nostrip" emerge xf86-video-intel > > - Grant > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/3] drm/sysfs: Don't pollute connector->kdev if drm_sysfs_connector_add() fails
From: Ville Syrjälä
Currently if drm_sysfs_connector_add() fails, it can leave connector->kdev
populated with an ERR_PTR value, or pointing to an already freed device.
Use a temporary kdev pointer during drm_sysfs_connector_add(), and
only set connector->kdev if the function succeeds. This avoids oopsing
if drm_sysfs_connector_add() gets called for a connector where
drm_sysfs_connector_add() previously failed.
Give drm_sysfs_device_add() the same treatment for the sake of
consistency.
v2: s/drm_connector_sysfs_add/drm_sysfs_connector_add
Make drm_sysfs_device_add() tolerate multiple calls
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_sysfs.c | 46 +++--
1 file changed, 28 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 1a35ea5..95c701a 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -370,6 +370,7 @@ static struct bin_attribute edid_attr = {
int drm_sysfs_connector_add(struct drm_connector *connector)
{
struct drm_device *dev = connector->dev;
+ struct device *kdev;
int attr_cnt = 0;
int opt_cnt = 0;
int i;
@@ -378,22 +379,22 @@ int drm_sysfs_connector_add(struct drm_connector
*connector)
if (connector->kdev)
return 0;
- connector->kdev = device_create(drm_class, dev->primary->kdev,
- 0, connector, "card%d-%s",
- dev->primary->index,
drm_get_connector_name(connector));
+ kdev = device_create(drm_class, dev->primary->kdev,
+0, connector, "card%d-%s",
+dev->primary->index,
drm_get_connector_name(connector));
DRM_DEBUG("adding \"%s\" to sysfs\n",
drm_get_connector_name(connector));
- if (IS_ERR(connector->kdev)) {
- DRM_ERROR("failed to register connector device: %ld\n",
PTR_ERR(connector->kdev));
- ret = PTR_ERR(connector->kdev);
+ if (IS_ERR(kdev)) {
+ DRM_ERROR("failed to register connector device: %ld\n",
PTR_ERR(kdev));
+ ret = PTR_ERR(kdev);
goto out;
}
/* Standard attributes */
for (attr_cnt = 0; attr_cnt < ARRAY_SIZE(connector_attrs); attr_cnt++) {
- ret = device_create_file(connector->kdev,
&connector_attrs[attr_cnt]);
+ ret = device_create_file(kdev, &connector_attrs[attr_cnt]);
if (ret)
goto err_out_files;
}
@@ -410,7 +411,7 @@ int drm_sysfs_connector_add(struct drm_connector *connector)
case DRM_MODE_CONNECTOR_Component:
case DRM_MODE_CONNECTOR_TV:
for (opt_cnt = 0; opt_cnt <
ARRAY_SIZE(connector_attrs_opt1); opt_cnt++) {
- ret = device_create_file(connector->kdev,
&connector_attrs_opt1[opt_cnt]);
+ ret = device_create_file(kdev,
&connector_attrs_opt1[opt_cnt]);
if (ret)
goto err_out_files;
}
@@ -419,21 +420,23 @@ int drm_sysfs_connector_add(struct drm_connector
*connector)
break;
}
- ret = sysfs_create_bin_file(&connector->kdev->kobj, &edid_attr);
+ ret = sysfs_create_bin_file(&kdev->kobj, &edid_attr);
if (ret)
goto err_out_files;
/* Let userspace know we have a new connector */
drm_sysfs_hotplug_event(dev);
+ connector->kdev = kdev;
+
return 0;
err_out_files:
for (i = 0; i < opt_cnt; i++)
- device_remove_file(connector->kdev, &connector_attrs_opt1[i]);
+ device_remove_file(kdev, &connector_attrs_opt1[i]);
for (i = 0; i < attr_cnt; i++)
- device_remove_file(connector->kdev, &connector_attrs[i]);
- device_unregister(connector->kdev);
+ device_remove_file(kdev, &connector_attrs[i]);
+ device_unregister(kdev);
out:
return ret;
@@ -501,6 +504,10 @@ EXPORT_SYMBOL(drm_sysfs_hotplug_event);
int drm_sysfs_device_add(struct drm_minor *minor)
{
char *minor_str;
+ struct device *kdev;
+
+ if (minor->kdev)
+ return 0;
if (minor->type == DRM_MINOR_CONTROL)
minor_str = "controlD%d";
@@ -509,13 +516,16 @@ int drm_sysfs_device_add(struct drm_minor *minor)
else
minor_str = "card%d";
- minor->kdev = device_create(drm_class, minor->dev->dev,
- MKDEV(DRM_MAJOR, minor->index),
- minor, minor_str, minor->index);
- if (IS_ERR(minor->kdev)) {
- DRM_ERROR("device create failed %ld\n", PTR_ERR(minor->kdev));
- return PTR_ER
[Intel-gfx] [PATCH] testcases: Slice Shutdown testscases.
1. sysfs half/full switch.
4. execbuf without I915_EXEC_USE_PREDICATE
5. execbuf with I915_EXEC_USE_PREDICATE
v2: include more tests and s/GT_FULL/USE_PREDICATE
v3: make it more reliable and fix few comments
v4: use number of slices on (1,2) instead of half and full strings.
v5: respect new naming convention
Signed-off-by: Rodrigo Vivi
---
tests/Makefile.am| 1 +
tests/pm_gt_slices.c | 268 +++
2 files changed, 269 insertions(+)
create mode 100644 tests/pm_gt_slices.c
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 0426ec0..e114bdf 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -57,6 +57,7 @@ TESTS_progs_M = \
kms_render \
kms_setmode \
$(NOUVEAU_TESTS_M) \
+ pm_gt_slices \
pm_pc8 \
prime_self_import \
template \
diff --git a/tests/pm_gt_slices.c b/tests/pm_gt_slices.c
new file mode 100644
index 000..8388aca
--- /dev/null
+++ b/tests/pm_gt_slices.c
@@ -0,0 +1,268 @@
+/*
+ * Copyright © 2013 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:
+ *Rodrigo Vivi
+ *
+ */
+
+/*
+ * Testcase: Test GT slice shutdown feature
+ *
+ * Sub tests:
+ * 1. sysfs half/full switch.
+ * 4. on execbuf without I915_EXEC_USE_PREDICATE
+ * 5. on execbuf with I915_EXEC_USE_PREDICATE
+ */
+
+#define _GNU_SOURCE
+#include
+#include
+#include
+#include
+#include "drmtest.h"
+
+static void exec(int fd, uint32_t handle, bool use_predicate)
+{
+struct drm_i915_gem_execbuffer2 execbuf;
+struct drm_i915_gem_exec_object2 gem_exec[1];
+uint32_t b[2] = {MI_BATCH_BUFFER_END};
+int loops = 100;
+int ret = 0;
+
+gem_write(fd, handle, 0, b, sizeof(b));
+
+gem_exec[0].handle = handle;
+gem_exec[0].relocation_count = 0;
+gem_exec[0].relocs_ptr = 0;
+gem_exec[0].alignment = 0;
+gem_exec[0].offset = 0;
+gem_exec[0].flags = 0;
+gem_exec[0].rsvd1 = 0;
+gem_exec[0].rsvd2 = 0;
+
+execbuf.buffers_ptr = (uintptr_t)gem_exec;
+execbuf.buffer_count = 1;
+execbuf.batch_start_offset = 0;
+execbuf.batch_len = 8;
+execbuf.cliprects_ptr = 0;
+execbuf.num_cliprects = 0;
+execbuf.DR1 = 0;
+execbuf.DR4 = 0;
+execbuf.flags = I915_EXEC_RENDER;
+ if (use_predicate)
+ execbuf.flags |= I915_EXEC_USE_PREDICATE;
+i915_execbuffer2_set_context_id(execbuf, 0);
+execbuf.rsvd2 = 0;
+
+while (loops-- && ret == 0) {
+ret = drmIoctl(fd,
+ DRM_IOCTL_I915_GEM_EXECBUFFER2,
+ &execbuf);
+}
+ gem_sync(fd, handle);
+}
+
+static int slices_on(const int device)
+{
+ char *path;
+ FILE *file;
+ int ret;
+ int slices;
+
+ ret = asprintf(&path, "/sys/class/drm/card%d/power/gt_slices",
+ device);
+ igt_assert(ret != -1);
+
+ file = fopen(path, "r");
+ igt_require(file);
+
+ ret = fscanf(file, "%d", &slices);
+ igt_assert(ret != 0);
+
+ fclose(file);
+ return slices;
+}
+
+static int set_status(const int device, int slices)
+{
+ char *path;
+ FILE *file;
+ int ret;
+ int attempts = 10;
+
+ ret = asprintf(&path, "/sys/class/drm/card%d/power/gt_slices",
+ device);
+ igt_assert(ret != -1);
+
+ while (attempts-- && ret != 0) {
+ file = fopen(path, "w");
+ igt_require(file);
+ ret = fprintf(file, "%d\n", slices);
+ igt_assert(ret != -1);
+ ret = fclose(file);
+ sleep(1);
+ }
+ return ret;
+}
+
+int main(int argc, char **argv)
+{
+ char *path;
+ FILE *file;
+ unsigned int rc6_enabl
[Intel-gfx] [ANNOUNCE] intel-gpu-tools 1.5
Hi all, Kernel 3.12 is already out and will be base of next quarterly release. So it is time to get intel-gpu-tools released also. Testsuit infrastructure is in a very good shape and it is so easy to create any test case nowadays. More about it explained above on Daniel's post. NEWS: - Some polishing of the test infrastructure, for details see: http://blog.ffwll.ch/2013/09/more-drmi915-testsuite-infrastructure.html - Haswell support for the DPF tool (tools/intel_l3_parity) and other improvements (Ben). - Stereo/3D support in testdisplay (Damien). - Support for gen7 gpu perf counters in tools/intel_perf_counters (Kenneth). - Improvements to the VBT decoder (Jani). - New tool to read legacy VGA registers (Ville). - New helpers in the test library to help deal with debugfs files and the new display pipe CRC support (Damien). - Introduction of a proper naming convention for all the testcases, see tests/NAMING-CONVENTION. - As usual tons of new testcases and improvements and bugfixes to existing ones. - The testsuite framework itself has gained some regression tests which can be run at compile-time with "make check". - New helpers for the drop_cache kernel interface and use drop_caches(RETIRE) to really make sure the gpu is idle in testcases (Oscar Mateo). Ben Widawsky (24): intel_l3_parity: Fix indentation intel_l3_parity: Assert all GEN7+ support intel_l3_parity: Use getopt for the l3 parity tool intel_l3_parity: Hardware info argument intel_l3_parity: slice support intel_l3_parity: Actually support multiple slices intel_l3_parity: Support error injection intel_l3_parity: Support a daemonic mode intel_l3_parity: Make compilation possible without udev configure.ac: require dri2proto for overlay gem_tiled_blits: Squash memory leak on simulation gem_tiled_blits: Squash bo leak on simulation pwrite_pread: use execbuf.batch_len for size pwrite_pread: Extract batch building pwrite_pread: Get devid only once gem_exec_faulting_reloc: use iterator for batchbuffer gem_linear_blits: Use iterator for blit batch setup gem_evict_*: Use iterator for blit batch gem_exec_blt: Use iterator for blit batch setup gem_pin: Use iterator for blit batch setup gem_ctx_bad_exec: skip vebox when appropriate gem_close_race: Fix linker flags gem_suspend: Skip on simulation debugfs_pipe_crc: skip on simulation Chris Wilson (7): overlay: Some very raw usage information tests: Simulate missed breadcrumb irqs intel_error_decode: Fix X/Y fence for gen2/3 tests: Add gem_close_race gem_close_race: Tidy up call to execbuffer gem_close_race: Bump the workload gem_close_race: Also test random closing of active fd Damien Lespiau (47): testdisplay: Distribute pass.png testdisplay: Add left/right images of a lovely scene lib: Dump information about the supported 3D stereo formats lib: Add a helper to paint a PNG using cairo lib: Split create_image_surface() out of create_cairo_ctx() lib: Add a helper to write a png from a struct kmstest_fb testdisplay: Move the code sanitizing depth into main() testdisplay: Map the fb inside paint_color_key() testdisplay: Properly handle the life cycle of framebuffers testdisplay: Fix CRTS typo testdisplay: Untangle dump_info() from the main testing loop testdisplay: Free the array of connectors testdisplay: Provide a full path when opening pngs testdisplay: Test the stereo 3D modes intel_infoframe: Display the VIC in decimal testdisplay: Remove the timing adjustements now that the kernel does it testdisplay: Use DRM_MODE_FLAG_3D_MASK lib: Adjust dump_modes() to the new stereo encoding testdisplay: Remove printing out the eyes geometry testdisplay: Respect specified_disp_id in the stereo loop testdisplay: Remove mode resetting now that we don't adjust the timings testdisplay: Make -o and -3 work together testdisplay: Print the stereo mode being tested lib: Add a small helper to open debugfs files lib: Add igt_debugfs_fopen() lib: Add a igt_assert_cmpint() lib: Add kmstest_paint_color() lib: Add a igt_display.h with a few enums and defines from the kernel lib: Make igt_debugfs_open() take the mode as argument lib: Add igt_wait_for_vblank() helper debugfs_pipe_crc: Let's check CRCs! tests/debugfs_pipe_crc: Test the read CRCs are not null lib: Don't wait for a vblank when enabling the CRCs rendercopy: Add a way to dump an .aub file with the rendercopy bos gitignore: Ignore intel_opregion_decode lib: Add a function to dump a scratch buf into a png tests/gem_render_copy: Add a simple render copy test tests/gem_render_copy: Only dump pngs when the -d option is given tests/gem_render
[Intel-gfx] [PATCH 3/6] drm/i915: Implement LRI based FBC tracking
From: Ville Syrjälä
As per the SNB and HSW PM guides, we should enable FBC render/blitter
tracking only during batches targetting the front buffer.
On SNB we must also update the FBC render tracking address whenever it
changes. And since the register in question is stored in the context,
we need to make sure we reload it with correct data after context
switches.
On IVB/HSW we use the render nuke mechanism, so no render tracking
address updates are needed. Hoever on the blitter side we need to
enable the blitter tracking like on SNB, and in addition we need
to issue the cache clean messages, which we already did.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_gem_context.c| 7
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 31
drivers/gpu/drm/i915/intel_display.c | 28 +--
drivers/gpu/drm/i915/intel_drv.h | 3 ++
drivers/gpu/drm/i915/intel_pm.c| 2 --
drivers/gpu/drm/i915/intel_ringbuffer.c| 58 +-
drivers/gpu/drm/i915/intel_ringbuffer.h| 2 ++
7 files changed, 126 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 72a3df3..d438ea1 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -404,6 +404,13 @@ mi_set_context(struct intel_ring_buffer *ring,
intel_ring_advance(ring);
+ /*
+* FBC RT address is stored in the context, so we may have just
+* restored it to an old value. Make sure we emit a new LRI
+* to update the address.
+*/
+ ring->fbc_address_dirty = true;
+
return ret;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 885d595..a8f8634 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -886,6 +886,35 @@ validate_exec_list(struct drm_i915_gem_exec_object2 *exec,
}
static void
+i915_gem_execbuffer_mark_fbc_dirty(struct intel_ring_buffer *ring,
+ struct list_head *vmas)
+{
+ struct i915_vma *vma;
+ struct drm_i915_gem_object *fbc_obj = NULL;
+ u32 fbc_address = -1;
+
+ list_for_each_entry(vma, vmas, exec_list) {
+ struct drm_i915_gem_object *obj = vma->obj;
+
+ if (obj->base.pending_write_domain == 0)
+ continue;
+
+ if (obj->pin_count) /* check for potential scanout */
+ intel_mark_fbc_dirty(obj, ring, &fbc_obj);
+ }
+
+ if (fbc_obj)
+ fbc_address = i915_gem_obj_ggtt_offset(fbc_obj);
+
+ /* need to nuke/cache_clean on IVB+? */
+ ring->fbc_dirty = fbc_obj != NULL;
+
+ /* need to update FBC tracking? */
+ ring->fbc_address_dirty = fbc_address != ring->fbc_address;
+ ring->fbc_address = fbc_address;
+}
+
+static void
i915_gem_execbuffer_move_to_active(struct list_head *vmas,
struct intel_ring_buffer *ring)
{
@@ -1150,6 +1179,8 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
if (flags & I915_DISPATCH_SECURE && !batch_obj->has_global_gtt_mapping)
i915_gem_gtt_bind_object(batch_obj, batch_obj->cache_level);
+ i915_gem_execbuffer_mark_fbc_dirty(ring, &eb->vmas);
+
ret = i915_gem_execbuffer_move_to_gpu(ring, &eb->vmas);
if (ret)
goto err;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 12cf362..49c40aa 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8064,6 +8064,32 @@ void intel_mark_idle(struct drm_device *dev)
gen6_rps_idle(dev->dev_private);
}
+void intel_mark_fbc_dirty(struct drm_i915_gem_object *obj,
+ struct intel_ring_buffer *ring,
+ struct drm_i915_gem_object **fbc_obj)
+{
+ struct drm_device *dev = obj->base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_crtc *crtc;
+
+ if (!i915_powersave)
+ return;
+
+ list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
+ if (!crtc->fb)
+ continue;
+
+ if (dev_priv->fbc.plane != to_intel_crtc(crtc)->plane)
+ continue;
+
+ if (to_intel_framebuffer(crtc->fb)->obj != obj)
+ continue;
+
+ WARN_ON(*fbc_obj && *fbc_obj != obj);
+ *fbc_obj = obj;
+ }
+}
+
void intel_mark_fb_busy(struct drm_i915_gem_object *obj,
struct intel_ring_buffer *ring)
{
@@ -8081,8 +8107,6 @@ void intel_mark_fb_busy(struct drm_i915_gem_object *obj,
continue;
intel_increase_pllclock(crtc);
- if (rin
[Intel-gfx] [PATCH 4/6] drm/i915: Kill sandybridge_blit_fbc_update()
From: Ville Syrjälä
No longer needed since the LRIs do the work.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 21 -
1 file changed, 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index bfec348..4b016d8 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -185,24 +185,6 @@ static bool g4x_fbc_enabled(struct drm_device *dev)
return I915_READ(DPFC_CONTROL) & DPFC_CTL_EN;
}
-static void sandybridge_blit_fbc_update(struct drm_device *dev)
-{
- struct drm_i915_private *dev_priv = dev->dev_private;
- u32 blt_ecoskpd;
-
- /* Make sure blitter notifies FBC of writes */
- gen6_gt_force_wake_get(dev_priv);
- blt_ecoskpd = I915_READ(GEN6_BLITTER_ECOSKPD);
- I915_WRITE(GEN6_BLITTER_ECOSKPD, blt_ecoskpd);
- blt_ecoskpd |= GEN6_BLITTER_FBC_NOTIFY;
- I915_WRITE(GEN6_BLITTER_ECOSKPD, blt_ecoskpd);
- blt_ecoskpd &= ~(GEN6_BLITTER_FBC_NOTIFY <<
-GEN6_BLITTER_LOCK_SHIFT);
- I915_WRITE(GEN6_BLITTER_ECOSKPD, blt_ecoskpd);
- POSTING_READ(GEN6_BLITTER_ECOSKPD);
- gen6_gt_force_wake_put(dev_priv);
-}
-
static void ironlake_enable_fbc(struct drm_crtc *crtc, unsigned long interval)
{
struct drm_device *dev = crtc->dev;
@@ -235,7 +217,6 @@ static void ironlake_enable_fbc(struct drm_crtc *crtc,
unsigned long interval)
I915_WRITE(SNB_DPFC_CTL_SA,
SNB_CPU_FENCE_ENABLE | obj->fence_reg);
I915_WRITE(DPFC_CPU_FENCE_OFFSET, crtc->y);
- sandybridge_blit_fbc_update(dev);
}
DRM_DEBUG_KMS("enabled fbc on plane %c\n",
plane_name(intel_crtc->plane));
@@ -291,8 +272,6 @@ static void gen7_enable_fbc(struct drm_crtc *crtc, unsigned
long interval)
SNB_CPU_FENCE_ENABLE | obj->fence_reg);
I915_WRITE(DPFC_CPU_FENCE_OFFSET, crtc->y);
- sandybridge_blit_fbc_update(dev);
-
DRM_DEBUG_KMS("enabled fbc on plane %d\n", intel_crtc->plane);
}
--
1.8.1.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/6] drm/i915: Emit SRM after the MSG_FBC_REND_STATE LRI
From: Ville Syrjälä The spec tells us that we need to emit an SRM after the LRI to MSG_FBC_REND_STATE. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/intel_ringbuffer.c | 6 -- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 0719c8b..7a4d3e1 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -235,6 +235,7 @@ */ #define MI_LOAD_REGISTER_IMM(x)MI_INSTR(0x22, 2*x-1) #define MI_STORE_REGISTER_MEM(x) MI_INSTR(0x24, 2*x-1) +#define MI_SRM_LRM_GLOBAL_GTT (1<<22) #define MI_FLUSH_DWMI_INSTR(0x26, 1) /* for GEN6 */ #define MI_FLUSH_DW_STORE_INDEX (1<<21) #define MI_INVALIDATE_TLB(1<<18) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index 752f208..4649bf5 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -285,14 +285,16 @@ static int gen7_ring_fbc_flush(struct intel_ring_buffer *ring, u32 value) if (!ring->fbc_dirty) return 0; - ret = intel_ring_begin(ring, 4); + ret = intel_ring_begin(ring, 6); if (ret) return ret; - intel_ring_emit(ring, MI_NOOP); /* WaFbcNukeOn3DBlt:ivb/hsw */ intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1)); intel_ring_emit(ring, MSG_FBC_REND_STATE); intel_ring_emit(ring, value); + intel_ring_emit(ring, MI_STORE_REGISTER_MEM(1) | MI_SRM_LRM_GLOBAL_GTT); + intel_ring_emit(ring, MSG_FBC_REND_STATE); + intel_ring_emit(ring, ring->scratch.gtt_offset + 256); intel_ring_advance(ring); ring->fbc_dirty = false; -- 1.8.1.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/6] drm/i915: Set has_fbc=true for all SNB+, except VLV
From: Ville Syrjälä
At least since SNB (perhaps even earlier) even the desktop parts
should have FBC.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index c0ab5d4..9b8c9bf 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -265,6 +265,7 @@ static const struct intel_device_info intel_ironlake_m_info
= {
static const struct intel_device_info intel_sandybridge_d_info = {
.gen = 6, .num_pipes = 2,
.need_gfx_hws = 1, .has_hotplug = 1,
+ .has_fbc = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING,
.has_llc = 1,
};
@@ -280,6 +281,7 @@ static const struct intel_device_info
intel_sandybridge_m_info = {
#define GEN7_FEATURES \
.gen = 7, .num_pipes = 3, \
.need_gfx_hws = 1, .has_hotplug = 1, \
+ .has_fbc = 1, \
.ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
.has_llc = 1
@@ -292,7 +294,6 @@ static const struct intel_device_info
intel_ivybridge_m_info = {
GEN7_FEATURES,
.is_ivybridge = 1,
.is_mobile = 1,
- .has_fbc = 1,
};
static const struct intel_device_info intel_ivybridge_q_info = {
@@ -307,6 +308,7 @@ static const struct intel_device_info
intel_valleyview_m_info = {
.num_pipes = 2,
.is_valleyview = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
+ .has_fbc = 0, /* legal, last one wins */
.has_llc = 0, /* legal, last one wins */
};
@@ -315,6 +317,7 @@ static const struct intel_device_info
intel_valleyview_d_info = {
.num_pipes = 2,
.is_valleyview = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
+ .has_fbc = 0, /* legal, last one wins */
.has_llc = 0, /* legal, last one wins */
};
@@ -332,7 +335,6 @@ static const struct intel_device_info intel_haswell_m_info
= {
.is_mobile = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
- .has_fbc = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
};
--
1.8.1.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/6] drm/i915: Limit FBC flush to post batch flush
From: Ville Syrjälä Don't issue the FBC nuke/cache clean command when invalidate_domains!=0. That would indicate that we're not being called for the post-batch flush. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_ringbuffer.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index e32c08a..752f208 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -354,7 +354,7 @@ gen7_render_ring_flush(struct intel_ring_buffer *ring, intel_ring_emit(ring, 0); intel_ring_advance(ring); - if (flush_domains) + if (!invalidate_domains && flush_domains) return gen7_ring_fbc_flush(ring, FBC_REND_NUKE); return 0; @@ -1837,7 +1837,7 @@ static int gen6_ring_flush(struct intel_ring_buffer *ring, } intel_ring_advance(ring); - if (IS_GEN7(dev) && flush) + if (IS_GEN7(dev) && !invalidate && flush) return gen7_ring_fbc_flush(ring, FBC_REND_CACHE_CLEAN); return 0; -- 1.8.1.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 56/62] drm/i915/bdw: Implement edp PSR workarounds
On Sat, Nov 02, 2013 at 09:07:54PM -0700, Ben Widawsky wrote:
> This implements a workaround for PSR dealing with some vblank issue.
>
> WaPsrDPAMaskVBlankInSRD && WaPsrDPRSUnmaskVBlankInSRD
>
> v2: forgot to git add bogus whitespace fix
>
> v3: Update with workaround names.
> Use for_each_pipe() and CHICKEN_PIPESL_1(pipe) macro (Ville)
>
> Cc: Art Runyan
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/i915_reg.h | 6 ++
> drivers/gpu/drm/i915/intel_pm.c | 17 +
> 2 files changed, 23 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index f97836e..9608f96 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4092,8 +4092,14 @@
> # define CHICKEN3_DGMG_DONE_FIX_DISABLE (1 << 2)
>
> #define CHICKEN_PAR1_1 0x42080
> +#define DPA_MASK_VBLANK_SRD (1 << 15)
> #define FORCE_ARB_IDLE_PLANES (1 << 14)
>
> +#define _CHICKEN_PIPESL_1_A 0x420b0
> +#define _CHICKEN_PIPESL_1_B 0x420b4
> +#define DPRS_MASK_VBLANK_SRD(1 << 0)
> +#define CHICKEN_PIPESL_1(pipe) _PIPE(pipe, _CHICKEN_PIPESL_1_A,
> _CHICKEN_PIPESL_1_B)
> +
> #define DISP_ARB_CTL 0x45000
> #define DISP_TILE_SURFACE_SWIZZLING (1<<13)
> #define DISP_FBC_WM_DIS (1<<15)
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 0245985..63f6e59 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -5288,6 +5288,23 @@ static void gen8_init_clock_gating(struct drm_device
> *dev)
>
> /* WaSwitchSolVfFArbitrationPriority */
> I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) | HSW_ECOCHK_ARB_PRIO_SOL);
> +
> + if (IS_BROADWELL(dev)) {
This check looks funny in a function which only runs on bdw. I've killed
it.
-Daniel
> + enum pipe i;
> +
> + /* WaPsrDPAMaskVBlankInSRD */
> + I915_WRITE(CHICKEN_PAR1_1,
> +I915_READ(CHICKEN_PAR1_1) | DPA_MASK_VBLANK_SRD);
> +
> + /* WaPsrDPRSUnmaskVBlankInSRD */
> + for_each_pipe(i) {
> + I915_WRITE(CHICKEN_PIPESL_1(i),
> +I915_READ(CHICKEN_PIPESL_1(i) |
> + DPRS_MASK_VBLANK_SRD));
> + }
> + }
> +
> +
> }
>
> static void haswell_init_clock_gating(struct drm_device *dev)
> --
> 1.8.4.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/6] drm/i915: Don't write ILK_FBC_RT_BASE directly on SNB
From: Ville Syrjälä We use LRIs to enable/disable the render tracking as needed. So leave ILK_FBC_RT_BASE alone when enabling FBC. TODO: Make ILK use the LRI mechanism too? Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_pm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 4b016d8..f58f476 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -209,7 +209,8 @@ static void ironlake_enable_fbc(struct drm_crtc *crtc, unsigned long interval) (stall_watermark << DPFC_RECOMP_STALL_WM_SHIFT) | (interval << DPFC_RECOMP_TIMER_COUNT_SHIFT)); I915_WRITE(ILK_DPFC_FENCE_YOFF, crtc->y); - I915_WRITE(ILK_FBC_RT_BASE, i915_gem_obj_ggtt_offset(obj) | ILK_FBC_RT_VALID); + if (IS_GEN5(dev)) + I915_WRITE(ILK_FBC_RT_BASE, i915_gem_obj_ggtt_offset(obj) | ILK_FBC_RT_VALID); /* enable it... */ I915_WRITE(ILK_DPFC_CONTROL, dpfc_ctl | DPFC_CTL_EN); -- 1.8.1.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5] drm/i915: Asynchronously perform the set-base for a simple modeset
From: Chris Wilson
A simple modeset, where we only wish to switch over to a new framebuffer
such as the transition from fbcon to X, takes around 30-60ms. This is
due to three factors:
1. We need to make sure the fb->obj is in the display domain, which
incurs a cache flush to ensure no dirt is left on the scanout.
2. We need to flush any pending rendering before performing the mmio
so that the frame is complete before it is shown.
3. We currently wait for the vblank after the mmio to be sure that the
old fb is no longer being shown before releasing it.
(1) can only be eliminated by userspace preparing the fb->obj in advance
to already be in the display domain. This can be done through use of the
create2 ioctl, or by reusing an existing fb->obj.
However, (2) and (3) are already solved by the existing page flip
mechanism, and it is surprisingly trivial to wire them up for use in the
set-base fast path. Though it can be argued that this represents a
subtle ABI break in that the set_config ioctl now returns before the old
framebuffer is unpinned. The danger is that userspace will start to
modify it before it is no longer being shown, however we should be able
to prevent that through proper domain tracking.
By combining all of the above, we can achieve an instaneous set_config:
[ 6.601] (II) intel(0): switch to mode 2560x1440@60.0 on pipe 0 using DP2,
position (0, 0), rotation normal
[ 6.601] (II) intel(0): Setting screen physical size to 677 x 381
v2 (by Vivi): page_flip_flag was added to intel_crtc_page_flip
in a previous commit. using 0.
Signed-off-by: Chris Wilson
Signed-off-by: Rodrigo Vivi
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_display.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f34252d..64390f3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9687,10 +9687,13 @@ static int intel_crtc_set_config(struct drm_mode_set
*set)
ret = intel_set_mode(set->crtc, set->mode,
set->x, set->y, set->fb);
} else if (config->fb_changed) {
- intel_crtc_wait_for_pending_flips(set->crtc);
-
- ret = intel_pipe_set_base(set->crtc,
- set->x, set->y, set->fb);
+ if (to_intel_framebuffer(set->fb)->obj->ring == NULL ||
+ save_set.x != set->x || save_set.y != set->y ||
+ intel_crtc_page_flip(set->crtc, set->fb, NULL, 0)) {
+ intel_crtc_wait_for_pending_flips(set->crtc);
+ ret = intel_pipe_set_base(set->crtc,
+ set->x, set->y, set->fb);
+ }
}
if (ret) {
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] drm/i915: Require HW contexts (when possible)
From: Ben Widawsky
v2: Fixed the botched locking on init_hw failure in i915_reset (Ville)
Call cleanup_ringbuffer on failed context create in init_hw (Ville)
v3: Add dev argument ti clean_ringbuffer
Reviewed-by: Kenneth Graunke
Signed-off-by: Ben Widawsky
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_drv.c | 3 ---
drivers/gpu/drm/i915/i915_drv.h | 3 +--
drivers/gpu/drm/i915/i915_gem.c | 8 +-
drivers/gpu/drm/i915/i915_gem_context.c | 43 +++--
drivers/gpu/drm/i915/i915_sysfs.c | 6 ++---
5 files changed, 31 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a0804fa..6544757 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -755,12 +755,9 @@ int i915_reset(struct drm_device *dev)
*/
if (drm_core_check_feature(dev, DRIVER_MODESET) ||
!dev_priv->ums.mm_suspended) {
- bool hw_contexts_disabled = dev_priv->hw_contexts_disabled;
dev_priv->ums.mm_suspended = 0;
ret = i915_gem_init_hw(dev);
- if (!hw_contexts_disabled && dev_priv->hw_contexts_disabled)
- DRM_ERROR("HW contexts didn't survive reset\n");
mutex_unlock(&dev->struct_mutex);
if (ret) {
DRM_ERROR("Failed hw init on reset %d\n", ret);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b12d942..e91d8fc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1447,7 +1447,6 @@ typedef struct drm_i915_private {
struct drm_property *broadcast_rgb_property;
struct drm_property *force_audio_property;
- bool hw_contexts_disabled;
uint32_t hw_context_size;
struct list_head context_list;
@@ -2151,7 +2150,7 @@ i915_gem_obj_ggtt_pin(struct drm_i915_gem_object *obj,
}
/* i915_gem_context.c */
-void i915_gem_context_init(struct drm_device *dev);
+int __must_check i915_gem_context_init(struct drm_device *dev);
void i915_gem_context_fini(struct drm_device *dev);
void i915_gem_context_close(struct drm_device *dev, struct drm_file *file);
int i915_switch_context(struct intel_ring_buffer *ring,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e7b39d7..bc52820 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4463,7 +4463,13 @@ i915_gem_init_hw(struct drm_device *dev)
* XXX: There was some w/a described somewhere suggesting loading
* contexts before PPGTT.
*/
- i915_gem_context_init(dev);
+ ret = i915_gem_context_init(dev);
+ if (ret) {
+ i915_gem_cleanup_ringbuffer(dev);
+ DRM_ERROR("Context initialization failed %d\n", ret);
+ return ret;
+ }
+
if (dev_priv->mm.aliasing_ppgtt) {
ret = dev_priv->mm.aliasing_ppgtt->enable(dev);
if (ret) {
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index cc619c1..4625670 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -244,36 +244,34 @@ err_destroy:
return ret;
}
-void i915_gem_context_init(struct drm_device *dev)
+int i915_gem_context_init(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
+ int ret;
- if (!HAS_HW_CONTEXTS(dev)) {
- dev_priv->hw_contexts_disabled = true;
- DRM_DEBUG_DRIVER("Disabling HW Contexts; old hardware\n");
- return;
- }
+ if (!HAS_HW_CONTEXTS(dev))
+ return 0;
/* If called from reset, or thaw... we've been here already */
- if (dev_priv->hw_contexts_disabled ||
- dev_priv->ring[RCS].default_context)
- return;
+ if (dev_priv->ring[RCS].default_context)
+ return 0;
dev_priv->hw_context_size = round_up(get_context_size(dev), 4096);
if (dev_priv->hw_context_size > (1<<20)) {
- dev_priv->hw_contexts_disabled = true;
DRM_DEBUG_DRIVER("Disabling HW Contexts; invalid size\n");
- return;
+ return -E2BIG;
}
- if (create_default_context(dev_priv)) {
- dev_priv->hw_contexts_disabled = true;
- DRM_DEBUG_DRIVER("Disabling HW Contexts; create failed\n");
- return;
+ ret = create_default_context(dev_priv);
+ if (ret) {
+ DRM_DEBUG_DRIVER("Disabling HW Contexts; create failed %d\n",
+ret);
+ return ret;
}
DRM_DEBUG_DRIVER("HW context support initialized\n");
+ return 0;
}
void i915_gem_context_fini(struct drm_device *dev)
@@ -281,7
[Intel-gfx] [PATCH 2/5] drm/i915: Initialise min/max frequencies before updating RPS registers
From: Chris Wilson
The RPS register writing routines use the current value of min/max to
set certain limits and interrupt gating. If we set those afterwards, we
risk setting up the hw incorrectly and losing power management events,
and worse, trigger some internal assertions.
Reorder the calling sequences to be correct, and remove the then
unrequired clamping from inside set_rps(). And for a bonus, fix the bug
of calling gen6_set_rps() from Valleyview.
Signed-off-by: Chris Wilson
Signed-off-by: Rodrigo Vivi
Reviewer: Ville Syrjälä
CC: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_sysfs.c | 16
drivers/gpu/drm/i915/intel_pm.c | 19 +--
3 files changed, 14 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7008aac..5b28602 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2758,7 +2758,7 @@ i915_max_freq_set(void *data, u64 val)
if (IS_VALLEYVIEW(dev)) {
val = vlv_freq_opcode(dev_priv->mem_freq, val);
dev_priv->rps.max_delay = val;
- gen6_set_rps(dev, val);
+ valleyview_set_rps(dev, val);
} else {
do_div(val, GT_FREQUENCY_MULTIPLIER);
dev_priv->rps.max_delay = val;
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index cef38fd..46291c4 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -342,15 +342,15 @@ static ssize_t gt_max_freq_mhz_store(struct device *kdev,
DRM_DEBUG("User requested overclocking to %d\n",
val * GT_FREQUENCY_MULTIPLIER);
+ dev_priv->rps.max_delay = val;
+
if (dev_priv->rps.cur_delay > val) {
- if (IS_VALLEYVIEW(dev_priv->dev))
- valleyview_set_rps(dev_priv->dev, val);
+ if (IS_VALLEYVIEW(dev))
+ valleyview_set_rps(dev, val);
else
- gen6_set_rps(dev_priv->dev, val);
+ gen6_set_rps(dev, val);
}
- dev_priv->rps.max_delay = val;
-
mutex_unlock(&dev_priv->rps.hw_lock);
return count;
@@ -411,15 +411,15 @@ static ssize_t gt_min_freq_mhz_store(struct device *kdev,
return -EINVAL;
}
+ dev_priv->rps.min_delay = val;
+
if (dev_priv->rps.cur_delay < val) {
if (IS_VALLEYVIEW(dev))
valleyview_set_rps(dev, val);
else
- gen6_set_rps(dev_priv->dev, val);
+ gen6_set_rps(dev, val);
}
- dev_priv->rps.min_delay = val;
-
mutex_unlock(&dev_priv->rps.hw_lock);
return count;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 09ac9e7..830865e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3414,26 +3414,19 @@ static void ironlake_disable_drps(struct drm_device
*dev)
* ourselves, instead of doing a rmw cycle (which might result in us clearing
* all limits and the gpu stuck at whatever frequency it is at atm).
*/
-static u32 gen6_rps_limits(struct drm_i915_private *dev_priv, u8 *val)
+static u32 gen6_rps_limits(struct drm_i915_private *dev_priv, u8 val)
{
u32 limits;
- limits = 0;
-
- if (*val >= dev_priv->rps.max_delay)
- *val = dev_priv->rps.max_delay;
- limits |= dev_priv->rps.max_delay << 24;
-
/* Only set the down limit when we've reached the lowest level to avoid
* getting more interrupts, otherwise leave this clear. This prevents a
* race in the hw when coming out of rc6: There's a tiny window where
* the hw runs at the minimal clock before selecting the desired
* frequency, if the down threshold expires in that window we will not
* receive a down interrupt. */
- if (*val <= dev_priv->rps.min_delay) {
- *val = dev_priv->rps.min_delay;
+ limits = dev_priv->rps.max_delay << 24;
+ if (val <= dev_priv->rps.min_delay)
limits |= dev_priv->rps.min_delay << 16;
- }
return limits;
}
@@ -3533,7 +3526,6 @@ static void gen6_set_rps_thresholds(struct
drm_i915_private *dev_priv, u8 val)
void gen6_set_rps(struct drm_device *dev, u8 val)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- u32 limits = gen6_rps_limits(dev_priv, &val);
WARN_ON(!mutex_is_locked(&dev_priv->rps.hw_lock));
WARN_ON(val > dev_priv->rps.max_delay);
@@ -3556,7 +3548,8 @@ void gen6_set_rps(struct drm_device *dev, u8 val)
/* Make sure we continue to get interrupts
* until we hit the minimum or maximum frequencies.
*/
- I915_WRITE(GEN6_RP_INTERRUPT_LIMITS, limits);
+
[Intel-gfx] [PATCH 3/5] drm/i915: Fix gen3/4 vblank counter wraparound
From: Ville Syrjälä When the hardware frame counter reads 0xff and we're already past vblank start, we'd return 0x100 as the vblank counter value. Once we'd cross into the next frame's active portion, the vblank counter would wrap to 0. So we're reporting two different vblank counter values for the same frame. Fix the problem by masking the cooked value by 0xff to make sure the counter wraps already after vblank start. Signed-off-by: Ville Syrjälä Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_irq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 2a44816..c474dac 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -583,7 +583,7 @@ static u32 i915_get_vblank_counter(struct drm_device *dev, int pipe) * Cook up a vblank counter by also checking the pixel * counter against vblank start. */ - return ((high1 << 8) | low) + (pixel >= vbl_start); + return (((high1 << 8) | low) + (pixel >= vbl_start)) & 0xff; } static u32 gm45_get_vblank_counter(struct drm_device *dev, int pipe) -- 1.8.3.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/5] drm/i915: Use frame counter for intel_wait_for_vblank() on CTG
From: Ville Syrjälä
Use the same wait_for_vblank code for CTG that we use for ILK+.
Also fix the name of the frame counter register while at it.
Signed-off-by: Ville Syrjälä
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_display.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 64390f3..7595d5a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -748,10 +748,10 @@ enum transcoder intel_pipe_to_cpu_transcoder(struct
drm_i915_private *dev_priv,
return intel_crtc->config.cpu_transcoder;
}
-static void ironlake_wait_for_vblank(struct drm_device *dev, int pipe)
+static void g4x_wait_for_vblank(struct drm_device *dev, int pipe)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- u32 frame, frame_reg = PIPEFRAME(pipe);
+ u32 frame, frame_reg = PIPE_FRMCOUNT_GM45(pipe);
frame = I915_READ(frame_reg);
@@ -772,8 +772,8 @@ void intel_wait_for_vblank(struct drm_device *dev, int pipe)
struct drm_i915_private *dev_priv = dev->dev_private;
int pipestat_reg = PIPESTAT(pipe);
- if (INTEL_INFO(dev)->gen >= 5) {
- ironlake_wait_for_vblank(dev, pipe);
+ if (IS_G4X(dev) || INTEL_INFO(dev)->gen >= 5) {
+ g4x_wait_for_vblank(dev, pipe);
return;
}
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/6] drm/i915: Implement LRI based FBC tracking
On Wed, Nov 06, 2013 at 05:39:02PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> As per the SNB and HSW PM guides, we should enable FBC render/blitter
> tracking only during batches targetting the front buffer.
>
> On SNB we must also update the FBC render tracking address whenever it
> changes. And since the register in question is stored in the context,
> we need to make sure we reload it with correct data after context
> switches.
>
> On IVB/HSW we use the render nuke mechanism, so no render tracking
> address updates are needed. Hoever on the blitter side we need to
> enable the blitter tracking like on SNB, and in addition we need
> to issue the cache clean messages, which we already did.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_gem_context.c| 7
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 31
> drivers/gpu/drm/i915/intel_display.c | 28 +--
> drivers/gpu/drm/i915/intel_drv.h | 3 ++
> drivers/gpu/drm/i915/intel_pm.c| 2 --
> drivers/gpu/drm/i915/intel_ringbuffer.c| 58
> +-
> drivers/gpu/drm/i915/intel_ringbuffer.h| 2 ++
> 7 files changed, 126 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index 72a3df3..d438ea1 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -404,6 +404,13 @@ mi_set_context(struct intel_ring_buffer *ring,
>
> intel_ring_advance(ring);
>
> + /*
> + * FBC RT address is stored in the context, so we may have just
> + * restored it to an old value. Make sure we emit a new LRI
> + * to update the address.
> + */
> + ring->fbc_address_dirty = true;
> +
> return ret;
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 885d595..a8f8634 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -886,6 +886,35 @@ validate_exec_list(struct drm_i915_gem_exec_object2
> *exec,
> }
>
> static void
> +i915_gem_execbuffer_mark_fbc_dirty(struct intel_ring_buffer *ring,
> +struct list_head *vmas)
> +{
> + struct i915_vma *vma;
> + struct drm_i915_gem_object *fbc_obj = NULL;
> + u32 fbc_address = -1;
> +
> + list_for_each_entry(vma, vmas, exec_list) {
> + struct drm_i915_gem_object *obj = vma->obj;
> +
> + if (obj->base.pending_write_domain == 0)
> + continue;
> +
> + if (obj->pin_count) /* check for potential scanout */
> + intel_mark_fbc_dirty(obj, ring, &fbc_obj);
if (obj->pin_display && intel_fbc_active(obj))
fbc_address = i915_gem_obj_ggtt_offset(obj);
> + }
> +
> + if (fbc_obj)
> + fbc_address = i915_gem_obj_ggtt_offset(fbc_obj);
> +
> + /* need to nuke/cache_clean on IVB+? */
> + ring->fbc_dirty = fbc_obj != NULL;
> +
> + /* need to update FBC tracking? */
> + ring->fbc_address_dirty = fbc_address != ring->fbc_address;
I'm not going to mention the unused bits in fbc_address
> + ring->fbc_address = fbc_address;
> +}
> +
> +static void
> i915_gem_execbuffer_move_to_active(struct list_head *vmas,
> struct intel_ring_buffer *ring)
> {
> @@ -1150,6 +1179,8 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
> *data,
> if (flags & I915_DISPATCH_SECURE && !batch_obj->has_global_gtt_mapping)
> i915_gem_gtt_bind_object(batch_obj, batch_obj->cache_level);
>
> + i915_gem_execbuffer_mark_fbc_dirty(ring, &eb->vmas);
> +
> ret = i915_gem_execbuffer_move_to_gpu(ring, &eb->vmas);
> if (ret)
> goto err;
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 12cf362..49c40aa 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -8064,6 +8064,32 @@ void intel_mark_idle(struct drm_device *dev)
> gen6_rps_idle(dev->dev_private);
> }
>
> +void intel_mark_fbc_dirty(struct drm_i915_gem_object *obj,
> + struct intel_ring_buffer *ring,
> + struct drm_i915_gem_object **fbc_obj)
> +{
> + struct drm_device *dev = obj->base.dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + struct drm_crtc *crtc;
> +
> + if (!i915_powersave)
> + return;
> +
> + list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
> + if (!crtc->fb)
> + continue;
> +
> + if (dev_priv->fbc.plane != to_intel_crtc(crtc)->plane)
> + continue;
> +
> + if (to_intel_framebuffer(crtc->fb)->obj != obj)
> + continue;
>
[Intel-gfx] [PATCH 0/5] drm-intel-collector - update
This is another drm-intel-collector updated notice: http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector Here goes the update list in order for better reviewers assignment: Patch drm/i915: Asynchronously perform the set-base for a simple modeset - Reviewed Patch drm/i915: Initialise min/max frequencies before updating RPS registers - Reviewer: Ville Syrjälä Patch drm/i915: Fix gen3/4 vblank counter wraparound - Reviewer: Patch drm/i915: Use frame counter for intel_wait_for_vblank() on CTG - Reviewer: Patch drm/i915: Require HW contexts (when possible) - Reviewer: Overall Process: drm-intel-collector - review request 1. Daniel pushs drm-intel-testing (every 2 weeks) 2. I rebase drm-intel-collector onto drm-intel-testing 3. Add Reviewer: tag with voluntered reviewers. If you don't believe you should be assigned on a particular patch please don't get mad just tell you wont review or volunteer someone else. 4. I resubmit remaining patches for review without picking any new (drm-intel-collector - review request) drm-intel-collector - updated 5. One week later I collect all simple (1-2) patches that wasn't yet reviewed and not queued by Daniel from one testing update until another. 6. Request automated QA's PRTS automated i-g-t tests comparing drm-intel-testing x drm-intel-collector 7. If tests are ok I send the update notification or the patches as a series to intel-gfx mailing list for better tracking and to be reviewed. (drm-intel-collector - updated) 8. Let me know volunteers for review new patches and also let me know if I've picked any patch that I shouldn't. There are some reasons that some patches can be left behind: 1. Your patch didn't applied cleanly and I couldn't easily solve the conflicts. 2. Kernel didn't compiled with your patch. 3. I simply missed it. If you believe this is the case please warn me. Please help me to get these patches reviewed and queued by Daniel. Also, please let me know if you have further ideas how to improve this process. Thanks in advance, Rodrigo. Ben Widawsky (1): drm/i915: Require HW contexts (when possible) Chris Wilson (2): drm/i915: Asynchronously perform the set-base for a simple modeset drm/i915: Initialise min/max frequencies before updating RPS registers Ville Syrjälä (2): drm/i915: Fix gen3/4 vblank counter wraparound drm/i915: Use frame counter for intel_wait_for_vblank() on CTG drivers/gpu/drm/i915/i915_debugfs.c | 2 +- drivers/gpu/drm/i915/i915_drv.c | 3 --- drivers/gpu/drm/i915/i915_drv.h | 3 +-- drivers/gpu/drm/i915/i915_gem.c | 8 +- drivers/gpu/drm/i915/i915_gem_context.c | 43 +++-- drivers/gpu/drm/i915/i915_irq.c | 2 +- drivers/gpu/drm/i915/i915_sysfs.c | 22 - drivers/gpu/drm/i915/intel_display.c| 19 +-- drivers/gpu/drm/i915/intel_pm.c | 19 --- 9 files changed, 57 insertions(+), 64 deletions(-) -- 1.8.3.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/6] drm/i915: Implement LRI based FBC tracking
On Wed, Nov 06, 2013 at 04:06:29PM +, Chris Wilson wrote:
> On Wed, Nov 06, 2013 at 05:39:02PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > As per the SNB and HSW PM guides, we should enable FBC render/blitter
> > tracking only during batches targetting the front buffer.
> >
> > On SNB we must also update the FBC render tracking address whenever it
> > changes. And since the register in question is stored in the context,
> > we need to make sure we reload it with correct data after context
> > switches.
> >
> > On IVB/HSW we use the render nuke mechanism, so no render tracking
> > address updates are needed. Hoever on the blitter side we need to
> > enable the blitter tracking like on SNB, and in addition we need
> > to issue the cache clean messages, which we already did.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_gem_context.c| 7
> > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 31
> > drivers/gpu/drm/i915/intel_display.c | 28 +--
> > drivers/gpu/drm/i915/intel_drv.h | 3 ++
> > drivers/gpu/drm/i915/intel_pm.c| 2 --
> > drivers/gpu/drm/i915/intel_ringbuffer.c| 58
> > +-
> > drivers/gpu/drm/i915/intel_ringbuffer.h| 2 ++
> > 7 files changed, 126 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> > b/drivers/gpu/drm/i915/i915_gem_context.c
> > index 72a3df3..d438ea1 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> > @@ -404,6 +404,13 @@ mi_set_context(struct intel_ring_buffer *ring,
> >
> > intel_ring_advance(ring);
> >
> > + /*
> > +* FBC RT address is stored in the context, so we may have just
> > +* restored it to an old value. Make sure we emit a new LRI
> > +* to update the address.
> > +*/
> > + ring->fbc_address_dirty = true;
> > +
> > return ret;
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > index 885d595..a8f8634 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > @@ -886,6 +886,35 @@ validate_exec_list(struct drm_i915_gem_exec_object2
> > *exec,
> > }
> >
> > static void
> > +i915_gem_execbuffer_mark_fbc_dirty(struct intel_ring_buffer *ring,
> > + struct list_head *vmas)
> > +{
> > + struct i915_vma *vma;
> > + struct drm_i915_gem_object *fbc_obj = NULL;
> > + u32 fbc_address = -1;
> > +
> > + list_for_each_entry(vma, vmas, exec_list) {
> > + struct drm_i915_gem_object *obj = vma->obj;
> > +
> > + if (obj->base.pending_write_domain == 0)
> > + continue;
> > +
> > + if (obj->pin_count) /* check for potential scanout */
> > + intel_mark_fbc_dirty(obj, ring, &fbc_obj);
>
> if (obj->pin_display && intel_fbc_active(obj))
> fbc_address = i915_gem_obj_ggtt_offset(obj);
Ah yeah, pin_display is good. Not sure I like intel_fbc_active() much.
But it needs to get replaced w/ some pipe config stuff or something
anyway eventually. I do already check fbc.plane == crtc->plane in
intel_mark_fbc_dirty() which should catch the case when fbc is disabled
anyway.
>
> > + }
> > +
> > + if (fbc_obj)
> > + fbc_address = i915_gem_obj_ggtt_offset(fbc_obj);
> > +
> > + /* need to nuke/cache_clean on IVB+? */
> > + ring->fbc_dirty = fbc_obj != NULL;
> > +
> > + /* need to update FBC tracking? */
> > + ring->fbc_address_dirty = fbc_address != ring->fbc_address;
>
> I'm not going to mention the unused bits in fbc_address
Just preparing myself for full 32bit addres space :)
>
> > + ring->fbc_address = fbc_address;
> > +}
> > +
> > +static void
> > i915_gem_execbuffer_move_to_active(struct list_head *vmas,
> >struct intel_ring_buffer *ring)
> > {
> > @@ -1150,6 +1179,8 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
> > *data,
> > if (flags & I915_DISPATCH_SECURE && !batch_obj->has_global_gtt_mapping)
> > i915_gem_gtt_bind_object(batch_obj, batch_obj->cache_level);
> >
> > + i915_gem_execbuffer_mark_fbc_dirty(ring, &eb->vmas);
> > +
> > ret = i915_gem_execbuffer_move_to_gpu(ring, &eb->vmas);
> > if (ret)
> > goto err;
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 12cf362..49c40aa 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -8064,6 +8064,32 @@ void intel_mark_idle(struct drm_device *dev)
> > gen6_rps_idle(dev->dev_private);
> > }
> >
> > +void intel_mark_fbc_dirty(struct drm_i915_gem_object *obj,
> > + struct intel_ring_buffer *ring,
> > + struct drm_i915_gem_object
Re: [Intel-gfx] [PATCH] drm/i915: Sanitize prepare_pipes after valleyview_modeset_global_pipes()
On Wed, Nov 06, 2013 at 12:42:20PM +0200, Ville Syrjälä wrote:
> On Wed, Nov 06, 2013 at 08:33:08AM +0100, Daniel Vetter wrote:
> > On Tue, Nov 05, 2013 at 10:34:12PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > valleyview_modeset_global_pipes() may add pipes that are getting fully
> > > disabled to prepare_pipes bitmask. The rest of the code doesn't expect
> > > this, so clear out any such pipes from the prepare_pipes bitmask.
> > >
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/intel_display.c | 6 +-
> > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index f97e895..ddbef9c 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -9514,10 +9514,14 @@ static int __intel_set_mode(struct drm_crtc *crtc,
> > >* mode set on this crtc. For other crtcs we need to use the
> > >* adjusted_mode bits in the crtc directly.
> > >*/
> > > - if (IS_VALLEYVIEW(dev))
> > > + if (IS_VALLEYVIEW(dev)) {
> > > valleyview_modeset_global_pipes(dev, &prepare_pipes,
> > > modeset_pipes, pipe_config);
> > >
> > > + /* may have added more to prepare_pipes than we should */
> > > + prepare_pipes &= ~disable_pipes;
> > > + }
> >
> > I'd have move the full "take disable_pipes out" block from affected_pipes.
> > Afacs there's no need to do it twice.
>
> I think we'd need to keep the '*modeset_pipes &= ~(*disable_pipes)' part
> in intel_modeset_affected_pipes(). Otherwise we might end up calling
> intel_modeset_pipe_config() for a disabled pipe. For prepare_pipes, it
> looks like we could move the masking to happen only once after
> valleyview_modeset_global_pipes(). Not sure if spreading it around like
> that makes sense.
Hm, good point. I've merged this, we can beautify this code once the real
atomic modeset stuff has landed and we can actually do modesets on more
than one pipe.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Improve vlv_gpu_freq() and vlv_freq_opcode()
On Tue, 5 Nov 2013 22:42:28 +0200
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We're currently miscalculating the VLV graphics clock a little bit.
> This is caused by rounding the step to integer MHz, which does not
> match reality. Change the formula to match the GUnit HAS to give
> more accurate answers.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_pm.c | 35 ---
> 1 file changed, 12 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index a5778e5..865035b 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -5947,57 +5947,46 @@ int sandybridge_pcode_write(struct drm_i915_private
> *dev_priv, u8 mbox, u32 val)
>
> int vlv_gpu_freq(int ddr_freq, int val)
> {
> - int mult, base;
> + int div;
>
> + /* 4 x czclk */
> switch (ddr_freq) {
> case 800:
> - mult = 20;
> - base = 120;
> + div = 10;
> break;
> case 1066:
> - mult = 22;
> - base = 133;
> + div = 12;
> break;
> case 1333:
> - mult = 21;
> - base = 125;
> + div = 16;
> break;
> default:
> return -1;
> }
>
> - return ((val - 0xbd) * mult) + base;
> + return DIV_ROUND_CLOSEST(ddr_freq * (val + 6 - 0xbd), 4 * div);
> }
>
> int vlv_freq_opcode(int ddr_freq, int val)
> {
> - int mult, base;
> + int mul;
>
> + /* 4 x czclk */
> switch (ddr_freq) {
> case 800:
> - mult = 20;
> - base = 120;
> + mul = 10;
> break;
> case 1066:
> - mult = 22;
> - base = 133;
> + mul = 12;
> break;
> case 1333:
> - mult = 21;
> - base = 125;
> + mul = 16;
> break;
> default:
> return -1;
> }
>
> - val /= mult;
> - val -= base / mult;
> - val += 0xbd;
> -
> - if (val > 0xea)
> - val = 0xea;
> -
> - return val;
> + return DIV_ROUND_CLOSEST(4 * mul * val, ddr_freq) + 0xbd - 6;
> }
>
> void intel_pm_init(struct drm_device *dev)
Yeah these values look better at 1066 and 1333. No differences at 800
though.
Reviewed-by: Jesse Barnes
--
Jesse Barnes, 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 2/4] drm/i915: Pass dev_priv to vlv_gpu_freq() and vlv_freq_opcode()
On Tue, Nov 05, 2013 at 01:01:47PM -0800, Jesse Barnes wrote:
> On Tue, 5 Nov 2013 22:42:29 +0200
> ville.syrj...@linux.intel.com wrote:
>
> > From: Ville Syrjälä
> >
> > We'll be looking at more than just mem_freq from dev_priv, so
> > just pass the whole thing.
> >
> > Signed-off-by: Ville Syrjälä
First two patches in this series merged to dinq, thanks.
-Daniel
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 17 +++--
> > drivers/gpu/drm/i915/i915_drv.h | 4 ++--
> > drivers/gpu/drm/i915/i915_sysfs.c | 13 ++---
> > drivers/gpu/drm/i915/intel_pm.c | 38
> > -
> > 4 files changed, 31 insertions(+), 41 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 7008aac..9770c2f 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -974,15 +974,14 @@ static int i915_cur_delayinfo(struct seq_file *m,
> > void *unused)
> >
> > val = vlv_punit_read(dev_priv, PUNIT_FUSE_BUS1);
> > seq_printf(m, "max GPU freq: %d MHz\n",
> > - vlv_gpu_freq(dev_priv->mem_freq, val));
> > + vlv_gpu_freq(dev_priv, val));
> >
> > val = vlv_punit_read(dev_priv, PUNIT_REG_GPU_LFM);
> > seq_printf(m, "min GPU freq: %d MHz\n",
> > - vlv_gpu_freq(dev_priv->mem_freq, val));
> > + vlv_gpu_freq(dev_priv, val));
> >
> > seq_printf(m, "current GPU freq: %d MHz\n",
> > - vlv_gpu_freq(dev_priv->mem_freq,
> > - (freq_sts >> 8) & 0xff));
> > + vlv_gpu_freq(dev_priv, (freq_sts >> 8) & 0xff));
> > mutex_unlock(&dev_priv->rps.hw_lock);
> > } else {
> > seq_puts(m, "no P-state info available\n");
> > @@ -2725,8 +2724,7 @@ i915_max_freq_get(void *data, u64 *val)
> > return ret;
> >
> > if (IS_VALLEYVIEW(dev))
> > - *val = vlv_gpu_freq(dev_priv->mem_freq,
> > - dev_priv->rps.max_delay);
> > + *val = vlv_gpu_freq(dev_priv, dev_priv->rps.max_delay);
> > else
> > *val = dev_priv->rps.max_delay * GT_FREQUENCY_MULTIPLIER;
> > mutex_unlock(&dev_priv->rps.hw_lock);
> > @@ -2756,7 +2754,7 @@ i915_max_freq_set(void *data, u64 val)
> > * Turbo will still be enabled, but won't go above the set value.
> > */
> > if (IS_VALLEYVIEW(dev)) {
> > - val = vlv_freq_opcode(dev_priv->mem_freq, val);
> > + val = vlv_freq_opcode(dev_priv, val);
> > dev_priv->rps.max_delay = val;
> > gen6_set_rps(dev, val);
> > } else {
> > @@ -2791,8 +2789,7 @@ i915_min_freq_get(void *data, u64 *val)
> > return ret;
> >
> > if (IS_VALLEYVIEW(dev))
> > - *val = vlv_gpu_freq(dev_priv->mem_freq,
> > - dev_priv->rps.min_delay);
> > + *val = vlv_gpu_freq(dev_priv, dev_priv->rps.min_delay);
> > else
> > *val = dev_priv->rps.min_delay * GT_FREQUENCY_MULTIPLIER;
> > mutex_unlock(&dev_priv->rps.hw_lock);
> > @@ -2822,7 +2819,7 @@ i915_min_freq_set(void *data, u64 val)
> > * Turbo will still be enabled, but won't go below the set value.
> > */
> > if (IS_VALLEYVIEW(dev)) {
> > - val = vlv_freq_opcode(dev_priv->mem_freq, val);
> > + val = vlv_freq_opcode(dev_priv, val);
> > dev_priv->rps.min_delay = val;
> > valleyview_set_rps(dev, val);
> > } else {
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 2aa7053..4bae871 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2412,8 +2412,8 @@ u32 intel_sbi_read(struct drm_i915_private *dev_priv,
> > u16 reg,
> > void intel_sbi_write(struct drm_i915_private *dev_priv, u16 reg, u32 value,
> > enum intel_sbi_destination destination);
> >
> > -int vlv_gpu_freq(int ddr_freq, int val);
> > -int vlv_freq_opcode(int ddr_freq, int val);
> > +int vlv_gpu_freq(struct drm_i915_private *dev_priv, int val);
> > +int vlv_freq_opcode(struct drm_i915_private *dev_priv, int val);
> >
> > #define I915_READ8(reg)
> > dev_priv->uncore.funcs.mmio_readb(dev_priv, (reg), true)
> > #define I915_WRITE8(reg, val)
> > dev_priv->uncore.funcs.mmio_writeb(dev_priv, (reg), (val), true)
> > diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
> > b/drivers/gpu/drm/i915/i915_sysfs.c
> > index cef38fd..5e81cf1 100644
> > --- a/drivers/gpu/drm/i915/i915_sysfs.c
> > +++ b/drivers/gpu/drm/i915/i915_sysfs.c
> > @@ -259,7 +259,7 @@ static ssize_t gt_cur_freq_mhz_show(struct device *kdev,
> > if (IS_VALLEYVIEW(dev_priv->dev)) {
> > u32 freq;
> > freq = vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS);
> > -
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Add support for VLV GPLL bypass
On Tue, Nov 05, 2013 at 01:03:37PM -0800, Jesse Barnes wrote: > I don't think we want to add this; even though it's a small amount of > code it's totally unnecessary on real hw, and will probably just bit > rot. Wholeheartedly agreed. Stuff that isn't used bitrots and then confuses because "this can't possibly work ... oh, unused." Sometimes the dot encompass a few months though. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] drm/i915: move opregion asle request handling to a work queue
On 10/31/2013 09:55 AM, Jani Nikula wrote:
Doing this has been long overdue anyway, but now we really need it in
preparation for per connector backlight handling.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/intel_opregion.c | 20 ++--
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2c1921d..6308711 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -242,6 +242,7 @@ struct intel_opregion {
struct opregion_asle __iomem *asle;
void __iomem *vbt;
u32 __iomem *lid_state;
+ struct work_struct asle_work;
};
#define OPREGION_SIZE(8*1024)
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index b82050c..892d520 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -486,9 +486,13 @@ static u32 asle_isct_state(struct drm_device *dev)
return ASLC_ISCT_STATE_FAILED;
}
-void intel_opregion_asle_intr(struct drm_device *dev)
+static void asle_work(struct work_struct *work)
{
- struct drm_i915_private *dev_priv = dev->dev_private;
+ struct intel_opregion *opregion =
+ container_of(work, struct intel_opregion, asle_work);
+ struct drm_i915_private *dev_priv =
+ container_of(opregion, struct drm_i915_private, opregion);
+ struct drm_device *dev = dev_priv->dev;
struct opregion_asle __iomem *asle = dev_priv->opregion.asle;
u32 aslc_stat = 0;
u32 aslc_req;
@@ -535,6 +539,14 @@ void intel_opregion_asle_intr(struct drm_device *dev)
iowrite32(aslc_stat, &asle->aslc);
}
+void intel_opregion_asle_intr(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ if (dev_priv->opregion.asle)
+ schedule_work(&dev_priv->opregion.asle_work);
+}
+
#define ACPI_EV_DISPLAY_SWITCH (1<<0)
#define ACPI_EV_LID(1<<1)
#define ACPI_EV_DOCK (1<<2)
@@ -735,6 +747,8 @@ void intel_opregion_fini(struct drm_device *dev)
if (opregion->asle)
iowrite32(ASLE_ARDY_NOT_READY, &opregion->asle->ardy);
+ cancel_work_sync(&dev_priv->opregion.asle_work);
+
if (opregion->acpi) {
iowrite32(0, &opregion->acpi->drdy);
@@ -828,6 +842,8 @@ int intel_opregion_setup(struct drm_device *dev)
return -ENOTSUPP;
}
+ INIT_WORK(&opregion->asle_work, asle_work);
+
base = acpi_os_ioremap(asls, OPREGION_SIZE);
if (!base)
return -ENOMEM;
Tested-by: Joe Konno
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/7] drm/i915: make backlight functions take a connector
On 10/31/2013 09:55 AM, Jani Nikula wrote:
From: Jesse Barnes
On VLV/BYT, backlight controls a per-pipe, so when adjusting the
backlight we need to pass the correct info. So make the externally
visible backlight functions take a connector argument, which can be used
internally to figure out the pipe backlight to adjust.
v2: make connector pipe lookup check for NULL crtc (Jani)
fixup connector check in ASLE code (Jani)
v3: make sure we take the mode config lock around lookups (Daniel)
v4: fix double unlock in panel_get_brightness (Daniel)
v5: push ASLE work into a work queue (Daniel)
v6: separate ASLE work to a prep patch, rebase (Jani)
Signed-off-by: Jesse Barnes
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/intel_display.c | 12 +
drivers/gpu/drm/i915/intel_dp.c |5 +-
drivers/gpu/drm/i915/intel_drv.h |8 +--
drivers/gpu/drm/i915/intel_lvds.c |9 ++--
drivers/gpu/drm/i915/intel_opregion.c | 38 ++-
drivers/gpu/drm/i915/intel_panel.c| 86 +++--
7 files changed, 122 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6308711..83eda64 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -54,6 +54,7 @@
#define DRIVER_DATE "20080730"
enum pipe {
+ INVALID_PIPE = -1,
PIPE_A = 0,
PIPE_B,
PIPE_C,
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8f40ae3..606a594 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9858,6 +9858,18 @@ static void intel_crtc_init(struct drm_device *dev, int
pipe)
drm_crtc_helper_add(&intel_crtc->base, &intel_helper_funcs);
}
+enum pipe intel_get_pipe_from_connector(struct intel_connector *connector)
+{
+ struct drm_encoder *encoder = connector->base.encoder;
+
+ WARN_ON(!mutex_is_locked(&connector->base.dev->mode_config.mutex));
+
+ if (!encoder)
+ return INVALID_PIPE;
+
+ return to_intel_crtc(encoder->crtc)->pipe;
+}
+
int intel_get_pipe_from_crtc_id(struct drm_device *dev, void *data,
struct drm_file *file)
{
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8db1fda..0ca98825 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1249,7 +1249,6 @@ void ironlake_edp_backlight_on(struct intel_dp *intel_dp)
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = intel_dig_port->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- int pipe = to_intel_crtc(intel_dig_port->base.base.crtc)->pipe;
u32 pp;
u32 pp_ctrl_reg;
@@ -1272,7 +1271,7 @@ void ironlake_edp_backlight_on(struct intel_dp *intel_dp)
I915_WRITE(pp_ctrl_reg, pp);
POSTING_READ(pp_ctrl_reg);
- intel_panel_enable_backlight(dev, pipe);
+ intel_panel_enable_backlight(intel_dp->attached_connector);
}
void ironlake_edp_backlight_off(struct intel_dp *intel_dp)
@@ -1285,7 +1284,7 @@ void ironlake_edp_backlight_off(struct intel_dp *intel_dp)
if (!is_edp(intel_dp))
return;
- intel_panel_disable_backlight(dev);
+ intel_panel_disable_backlight(intel_dp->attached_connector);
DRM_DEBUG_KMS("\n");
pp = ironlake_get_pp_control(intel_dp);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 9d2624f..1e49aa8 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -630,6 +630,7 @@ void intel_connector_attach_encoder(struct intel_connector
*connector,
struct drm_encoder *intel_best_encoder(struct drm_connector *connector);
struct drm_display_mode *intel_crtc_mode_get(struct drm_device *dev,
struct drm_crtc *crtc);
+enum pipe intel_get_pipe_from_connector(struct intel_connector *connector);
int intel_get_pipe_from_crtc_id(struct drm_device *dev, void *data,
struct drm_file *file_priv);
enum transcoder intel_pipe_to_cpu_transcoder(struct drm_i915_private
*dev_priv,
@@ -802,10 +803,11 @@ void intel_pch_panel_fitting(struct intel_crtc *crtc,
void intel_gmch_panel_fitting(struct intel_crtc *crtc,
struct intel_crtc_config *pipe_config,
int fitting_mode);
-void intel_panel_set_backlight(struct drm_device *dev, u32 level, u32 max);
+void intel_panel_set_backlight(struct intel_connector *connector, u32 level,
+ u32 max);
int intel_panel_setup_backlight(struct drm_connector *connector);
-void intel_panel_enable_backlight(struct drm_device *dev, enum pipe pipe);
-void intel_panel_disable_ba
Re: [Intel-gfx] [PATCH 3/7] drm/i915/vlv: use per-pipe backlight controls v2
On 10/31/2013 09:55 AM, Jani Nikula wrote:
From: Jesse Barnes
With the connector and pipe passed around, we can now set the backlight
on the right pipe on VLV/BYT.
v2: drop combination mode check for VLV (Jani)
add save/restore code for VLV backlight regs (Jani)
check for existing modulation freq when initializing backlight regs (Jani)
Signed-off-by: Jesse Barnes
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h |3 ++
drivers/gpu/drm/i915/i915_reg.h | 15
drivers/gpu/drm/i915/i915_suspend.c | 29 +++
drivers/gpu/drm/i915/intel_panel.c | 67 ---
4 files changed, 102 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 83eda64..16fae30 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -745,6 +745,9 @@ struct i915_suspend_saved_registers {
u32 saveBLC_HIST_CTL;
u32 saveBLC_PWM_CTL;
u32 saveBLC_PWM_CTL2;
+ u32 saveBLC_HIST_CTL_B;
+ u32 saveBLC_PWM_CTL_B;
+ u32 saveBLC_PWM_CTL2_B;
u32 saveBLC_CPU_PWM_CTL;
u32 saveBLC_CPU_PWM_CTL2;
u32 saveFPB0;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 4d2db59..e2f3dd4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2387,6 +2387,21 @@
#define PFIT_AUTO_RATIOS (dev_priv->info->display_mmio_offset + 0x61238)
+#define _VLV_BLC_PWM_CTL2_A (dev_priv->info->display_mmio_offset + 0x61250)
+#define _VLV_BLC_PWM_CTL2_B (dev_priv->info->display_mmio_offset + 0x61350)
+#define VLV_BLC_PWM_CTL2(pipe) _PIPE(pipe, _VLV_BLC_PWM_CTL2_A, \
+_VLV_BLC_PWM_CTL2_B)
+
+#define _VLV_BLC_PWM_CTL_A (dev_priv->info->display_mmio_offset + 0x61254)
+#define _VLV_BLC_PWM_CTL_B (dev_priv->info->display_mmio_offset + 0x61354)
+#define VLV_BLC_PWM_CTL(pipe) _PIPE(pipe, _VLV_BLC_PWM_CTL_A, \
+ _VLV_BLC_PWM_CTL_B)
+
+#define _VLV_BLC_HIST_CTL_A (dev_priv->info->display_mmio_offset + 0x61260)
+#define _VLV_BLC_HIST_CTL_B (dev_priv->info->display_mmio_offset + 0x61360)
+#define VLV_BLC_HIST_CTL(pipe) _PIPE(pipe, _VLV_BLC_HIST_CTL_A, \
+_VLV_BLC_HIST_CTL_B)
+
/* Backlight control */
#define BLC_PWM_CTL2 (dev_priv->info->display_mmio_offset + 0x61250) /* 965+
only */
#define BLM_PWM_ENABLE (1 << 31)
diff --git a/drivers/gpu/drm/i915/i915_suspend.c
b/drivers/gpu/drm/i915/i915_suspend.c
index a088f1f..98790c7 100644
--- a/drivers/gpu/drm/i915/i915_suspend.c
+++ b/drivers/gpu/drm/i915/i915_suspend.c
@@ -214,6 +214,22 @@ static void i915_save_display(struct drm_device *dev)
dev_priv->regfile.saveBLC_CPU_PWM_CTL2 =
I915_READ(BLC_PWM_CPU_CTL2);
if (HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev))
dev_priv->regfile.saveLVDS = I915_READ(PCH_LVDS);
+ } else if (IS_VALLEYVIEW(dev)) {
+ dev_priv->regfile.savePP_CONTROL = I915_READ(PP_CONTROL);
+ dev_priv->regfile.savePFIT_PGM_RATIOS =
I915_READ(PFIT_PGM_RATIOS);
+
+ dev_priv->regfile.saveBLC_PWM_CTL =
+ I915_READ(VLV_BLC_PWM_CTL(PIPE_A));
+ dev_priv->regfile.saveBLC_HIST_CTL =
+ I915_READ(VLV_BLC_HIST_CTL(PIPE_A));
+ dev_priv->regfile.saveBLC_PWM_CTL2 =
+ I915_READ(VLV_BLC_PWM_CTL2(PIPE_A));
+ dev_priv->regfile.saveBLC_PWM_CTL_B =
+ I915_READ(VLV_BLC_PWM_CTL(PIPE_B));
+ dev_priv->regfile.saveBLC_HIST_CTL_B =
+ I915_READ(VLV_BLC_HIST_CTL(PIPE_B));
+ dev_priv->regfile.saveBLC_PWM_CTL2_B =
+ I915_READ(VLV_BLC_PWM_CTL2(PIPE_B));
} else {
dev_priv->regfile.savePP_CONTROL = I915_READ(PP_CONTROL);
dev_priv->regfile.savePFIT_PGM_RATIOS =
I915_READ(PFIT_PGM_RATIOS);
@@ -302,6 +318,19 @@ static void i915_restore_display(struct drm_device *dev)
I915_WRITE(PCH_PP_CONTROL, dev_priv->regfile.savePP_CONTROL);
I915_WRITE(RSTDBYCTL,
dev_priv->regfile.saveMCHBAR_RENDER_STANDBY);
+ } else if (IS_VALLEYVIEW(dev)) {
+ I915_WRITE(VLV_BLC_PWM_CTL(PIPE_A),
+ dev_priv->regfile.saveBLC_PWM_CTL);
+ I915_WRITE(VLV_BLC_HIST_CTL(PIPE_A),
+ dev_priv->regfile.saveBLC_HIST_CTL);
+ I915_WRITE(VLV_BLC_PWM_CTL2(PIPE_A),
+ dev_priv->regfile.saveBLC_PWM_CTL2);
+ I915_WRITE(VLV_BLC_PWM_CTL(PIPE_B),
+ dev_priv->regfile.saveBLC_PWM_CTL);
+ I915_WRITE(VLV_BLC_HIST_CTL(PIPE_B),
+ dev_priv->regfile.saveBLC_HIST_CTL);
+ I915_WRITE(VLV_BL
Re: [Intel-gfx] [PATCH 4/7] drm/i915: clean up backlight conditional build
On 10/31/2013 09:55 AM, Jani Nikula wrote:
I've always felt the backlight device conditional build has been all
backwards. Make it feel right.
Gently move things towards connector based stuff while at it.
There should be no functional changes, except for a slight
reordering/interleaving of connector backlight and sysfs destroy calls.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_display.c |9 +++--
drivers/gpu/drm/i915/intel_drv.h |2 +-
drivers/gpu/drm/i915/intel_panel.c | 65 +++---
3 files changed, 42 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 606a594..774407d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11007,12 +11007,11 @@ void intel_modeset_cleanup(struct drm_device *dev)
/* flush any delayed tasks or pending work */
flush_scheduled_work();
- /* destroy backlight, if any, before the connectors */
- intel_panel_destroy_backlight(dev);
-
- /* destroy the sysfs files before encoders/connectors */
- list_for_each_entry(connector, &dev->mode_config.connector_list, head)
+ /* destroy the backlight and sysfs files before encoders/connectors */
+ list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
+ intel_panel_destroy_backlight(connector);
drm_sysfs_connector_remove(connector);
+ }
drm_mode_config_cleanup(dev);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1e49aa8..5548180 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -808,7 +808,7 @@ void intel_panel_set_backlight(struct intel_connector
*connector, u32 level,
int intel_panel_setup_backlight(struct drm_connector *connector);
void intel_panel_enable_backlight(struct intel_connector *connector);
void intel_panel_disable_backlight(struct intel_connector *connector);
-void intel_panel_destroy_backlight(struct drm_device *dev);
+void intel_panel_destroy_backlight(struct drm_connector *connector);
enum drm_connector_status intel_panel_detect(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index f161ac0..a0d13d3 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -709,16 +709,6 @@ static void intel_panel_init_backlight_regs(struct
drm_device *dev)
}
}
-static void intel_panel_init_backlight(struct drm_device *dev)
-{
- struct drm_i915_private *dev_priv = dev->dev_private;
-
- intel_panel_init_backlight_regs(dev);
-
- dev_priv->backlight.level = intel_panel_get_backlight(dev, 0);
- dev_priv->backlight.enabled = dev_priv->backlight.level != 0;
-}
-
enum drm_connector_status
intel_panel_detect(struct drm_device *dev)
{
@@ -742,7 +732,7 @@ intel_panel_detect(struct drm_device *dev)
}
#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
-static int intel_panel_update_status(struct backlight_device *bd)
+static int intel_backlight_device_update_status(struct backlight_device *bd)
{
struct intel_connector *connector = bl_get_data(bd);
struct drm_device *dev = connector->base.dev;
@@ -756,7 +746,7 @@ static int intel_panel_update_status(struct
backlight_device *bd)
return 0;
}
-static int intel_panel_get_brightness(struct backlight_device *bd)
+static int intel_backlight_device_get_brightness(struct backlight_device *bd)
{
struct intel_connector *connector = bl_get_data(bd);
struct drm_device *dev = connector->base.dev;
@@ -771,20 +761,18 @@ static int intel_panel_get_brightness(struct
backlight_device *bd)
return intel_panel_get_backlight(connector->base.dev, pipe);
}
-static const struct backlight_ops intel_panel_bl_ops = {
- .update_status = intel_panel_update_status,
- .get_brightness = intel_panel_get_brightness,
+static const struct backlight_ops intel_backlight_device_ops = {
+ .update_status = intel_backlight_device_update_status,
+ .get_brightness = intel_backlight_device_get_brightness,
};
-int intel_panel_setup_backlight(struct drm_connector *connector)
+static int intel_backlight_device_register(struct intel_connector *connector)
{
- struct drm_device *dev = connector->dev;
+ struct drm_device *dev = connector->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct backlight_properties props;
unsigned long flags;
- intel_panel_init_backlight(dev);
-
if (WARN_ON(dev_priv->backlight.device))
return -ENODEV;
@@ -802,9 +790,9 @@ int intel_panel_setup_backlight(struct drm_connector
*connector)
}
dev_priv->backlight.device =
backlight_device_register("intel_backlight",
- co
Re: [Intel-gfx] [PATCH 6/7] drm/i915: handle backlight through chip specific functions
On 10/31/2013 09:55 AM, Jani Nikula wrote:
The backlight code has grown rather hairy, not least because the
hardware registers and bits have repeatedly been shuffled around. And
this isn't expected to get any easier with new hardware. Make things
easier for our (read: my) poor brains, and split the code up into chip
specific functions.
There should be no functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h |7 +
drivers/gpu/drm/i915/intel_display.c |2 +
drivers/gpu/drm/i915/intel_drv.h |1 +
drivers/gpu/drm/i915/intel_panel.c | 442 ++
4 files changed, 297 insertions(+), 155 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 16b93a6..0753e7c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -409,6 +409,13 @@ struct drm_i915_display_funcs {
/* render clock increase/decrease */
/* display clock increase/decrease */
/* pll clock increase/decrease */
+
+ uint32_t (*get_max_backlight)(struct drm_device *dev, enum pipe pipe);
+ uint32_t (*get_backlight)(struct drm_device *dev, enum pipe pipe);
+ void (*set_backlight)(struct drm_device *dev, enum pipe pipe,
+ uint32_t level);
+ void (*disable_backlight)(struct drm_device *dev, enum pipe pipe);
+ void (*enable_backlight)(struct drm_device *dev, enum pipe pipe);
};
struct intel_uncore_funcs {
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 774407d..d25d23c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10355,6 +10355,8 @@ static void intel_init_display(struct drm_device *dev)
dev_priv->display.queue_flip = intel_gen7_queue_flip;
break;
}
+
+ intel_panel_init_backlight_funcs(dev);
}
/*
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 9460e54..b367f2f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -816,6 +816,7 @@ int intel_panel_setup_backlight(struct drm_connector
*connector);
void intel_panel_enable_backlight(struct intel_connector *connector);
void intel_panel_disable_backlight(struct intel_connector *connector);
void intel_panel_destroy_backlight(struct drm_connector *connector);
+void intel_panel_init_backlight_funcs(struct drm_device *dev);
enum drm_connector_status intel_panel_detect(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 0a4aeaf..03e806f 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -338,79 +338,105 @@ static int is_backlight_combination_mode(struct
drm_device *dev)
return 0;
}
-/* XXX: query mode clock or hardware clock and program max PWM appropriately
- * when it's 0.
- */
-static u32 i915_read_blc_pwm_ctl(struct drm_device *dev, enum pipe pipe)
+static u32 pch_get_max_backlight(struct drm_device *dev, enum pipe pipe)
{
struct drm_i915_private *dev_priv = dev->dev_private;
u32 val;
- WARN_ON_SMP(!spin_is_locked(&dev_priv->backlight_lock));
+ val = I915_READ(BLC_PWM_PCH_CTL2);
+ if (dev_priv->regfile.saveBLC_PWM_CTL2 == 0) {
+ dev_priv->regfile.saveBLC_PWM_CTL2 = val;
+ } else if (val == 0) {
+ val = dev_priv->regfile.saveBLC_PWM_CTL2;
+ I915_WRITE(BLC_PWM_PCH_CTL2, val);
+ }
- /* Restore the CTL value if it lost, e.g. GPU reset */
+ val >>= 16;
- if (HAS_PCH_SPLIT(dev_priv->dev)) {
- val = I915_READ(BLC_PWM_PCH_CTL2);
- if (dev_priv->regfile.saveBLC_PWM_CTL2 == 0) {
- dev_priv->regfile.saveBLC_PWM_CTL2 = val;
- } else if (val == 0) {
- val = dev_priv->regfile.saveBLC_PWM_CTL2;
- I915_WRITE(BLC_PWM_PCH_CTL2, val);
- }
- } else if (IS_VALLEYVIEW(dev)) {
- val = I915_READ(VLV_BLC_PWM_CTL(pipe));
- if (dev_priv->regfile.saveBLC_PWM_CTL == 0) {
- dev_priv->regfile.saveBLC_PWM_CTL = val;
- dev_priv->regfile.saveBLC_PWM_CTL2 =
- I915_READ(VLV_BLC_PWM_CTL2(pipe));
- } else if (val == 0) {
- val = dev_priv->regfile.saveBLC_PWM_CTL;
- I915_WRITE(VLV_BLC_PWM_CTL(pipe), val);
- I915_WRITE(VLV_BLC_PWM_CTL2(pipe),
- dev_priv->regfile.saveBLC_PWM_CTL2);
- }
+ return val;
+}
- if (!val)
- val = 0x0f42;
- } else {
- val = I915_READ(BLC_PWM_CTL);
- if (dev_priv->regfile.saveBLC_PWM_CTL == 0) {
-
Re: [Intel-gfx] [PATCH 5/7] drm/i915: make backlight info per-connector
On 10/31/2013 09:55 AM, Jani Nikula wrote:
Move from dev_priv to connector->panel.
We still don't allow multiple sysfs interfaces, though.
There should be no functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_dma.c |2 +-
drivers/gpu/drm/i915/i915_drv.h |9 +---
drivers/gpu/drm/i915/i915_suspend.c |8 ++--
drivers/gpu/drm/i915/intel_drv.h|7 +++
drivers/gpu/drm/i915/intel_panel.c | 85 +++
5 files changed, 61 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 0cab2d0..9a2a175 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1486,7 +1486,7 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
spin_lock_init(&dev_priv->irq_lock);
spin_lock_init(&dev_priv->gpu_error.lock);
- spin_lock_init(&dev_priv->backlight.lock);
+ spin_lock_init(&dev_priv->backlight_lock);
spin_lock_init(&dev_priv->uncore.lock);
spin_lock_init(&dev_priv->mm.object_stat_lock);
mutex_init(&dev_priv->dpio_lock);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 16fae30..16b93a6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1349,13 +1349,8 @@ typedef struct drm_i915_private {
struct intel_overlay *overlay;
unsigned int sprite_scaling_enabled;
- /* backlight */
- struct {
- int level;
- bool enabled;
- spinlock_t lock; /* bl registers and the above bl fields */
- struct backlight_device *device;
- } backlight;
+ /* backlight registers and fields in struct intel_panel */
+ spinlock_t backlight_lock;
/* LVDS info */
bool no_aux_handshake;
diff --git a/drivers/gpu/drm/i915/i915_suspend.c
b/drivers/gpu/drm/i915/i915_suspend.c
index 98790c7..eadf8e1 100644
--- a/drivers/gpu/drm/i915/i915_suspend.c
+++ b/drivers/gpu/drm/i915/i915_suspend.c
@@ -203,7 +203,7 @@ static void i915_save_display(struct drm_device *dev)
if (!drm_core_check_feature(dev, DRIVER_MODESET))
i915_save_display_reg(dev);
- spin_lock_irqsave(&dev_priv->backlight.lock, flags);
+ spin_lock_irqsave(&dev_priv->backlight_lock, flags);
/* LVDS state */
if (HAS_PCH_SPLIT(dev)) {
@@ -241,7 +241,7 @@ static void i915_save_display(struct drm_device *dev)
dev_priv->regfile.saveLVDS = I915_READ(LVDS);
}
- spin_unlock_irqrestore(&dev_priv->backlight.lock, flags);
+ spin_unlock_irqrestore(&dev_priv->backlight_lock, flags);
if (!IS_I830(dev) && !IS_845G(dev) && !HAS_PCH_SPLIT(dev))
dev_priv->regfile.savePFIT_CONTROL = I915_READ(PFIT_CONTROL);
@@ -287,7 +287,7 @@ static void i915_restore_display(struct drm_device *dev)
if (!drm_core_check_feature(dev, DRIVER_MODESET))
i915_restore_display_reg(dev);
- spin_lock_irqsave(&dev_priv->backlight.lock, flags);
+ spin_lock_irqsave(&dev_priv->backlight_lock, flags);
/* LVDS state */
if (INTEL_INFO(dev)->gen >= 4 && !HAS_PCH_SPLIT(dev))
@@ -341,7 +341,7 @@ static void i915_restore_display(struct drm_device *dev)
I915_WRITE(PP_CONTROL, dev_priv->regfile.savePP_CONTROL);
}
- spin_unlock_irqrestore(&dev_priv->backlight.lock, flags);
+ spin_unlock_irqrestore(&dev_priv->backlight_lock, flags);
/* only restore FBC info on the platform that supports FBC*/
intel_disable_fbc(dev);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 5548180..9460e54 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -156,6 +156,13 @@ struct intel_encoder {
struct intel_panel {
struct drm_display_mode *fixed_mode;
int fitting_mode;
+
+ /* backlight */
+ struct {
+ u32 level;
+ bool enabled;
+ struct backlight_device *device;
+ } backlight;
};
struct intel_connector {
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index a0d13d3..0a4aeaf 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -346,7 +346,7 @@ static u32 i915_read_blc_pwm_ctl(struct drm_device *dev,
enum pipe pipe)
struct drm_i915_private *dev_priv = dev->dev_private;
u32 val;
- WARN_ON_SMP(!spin_is_locked(&dev_priv->backlight.lock));
+ WARN_ON_SMP(!spin_is_locked(&dev_priv->backlight_lock));
/* Restore the CTL value if it lost, e.g. GPU reset */
@@ -449,7 +449,7 @@ static u32 intel_panel_get_backlight(struct drm_device *dev,
unsigned long flags;
int reg;
- spin_lock_irqsave(&dev_priv->backlight.lock, flags);
+ spin_lock_irqsave(&dev_priv
Re: [Intel-gfx] [PATCH 7/7] drm/i915: make asle notifications update backlight on all connectors
On 10/31/2013 09:55 AM, Jani Nikula wrote:
ALthough usually there's only one connector that supports backlight,
this also finds the correct connector. Before, we only updated the
connector on pipe A, which might not be the one with backlight. (This
only made a difference on BYT.)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_drv.h |1 +
drivers/gpu/drm/i915/intel_opregion.c | 43 ++---
drivers/gpu/drm/i915/intel_panel.c|4 +++
3 files changed, 18 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index b367f2f..3d2e0d2 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -159,6 +159,7 @@ struct intel_panel {
/* backlight */
struct {
+ bool present;
u32 level;
bool enabled;
struct backlight_device *device;
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index 91b68dc..a0b5a99 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -396,13 +396,10 @@ int intel_opregion_notify_adapter(struct drm_device *dev,
pci_power_t state)
static u32 asle_set_backlight(struct drm_device *dev, u32 bclp)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- struct drm_encoder *encoder;
struct drm_connector *connector;
- struct intel_connector *intel_connector = NULL;
- struct drm_crtc *crtc = dev_priv->pipe_to_crtc_mapping[0];
+ struct intel_connector *intel_connector;
+ struct intel_panel *panel;
struct opregion_asle __iomem *asle = dev_priv->opregion.asle;
- u32 ret = 0;
- bool found = false;
DRM_DEBUG_DRIVER("bclp = 0x%08x\n", bclp);
@@ -414,38 +411,24 @@ static u32 asle_set_backlight(struct drm_device *dev, u32
bclp)
return ASLC_BACKLIGHT_FAILED;
mutex_lock(&dev->mode_config.mutex);
+
/*
-* Could match the OpRegion connector here instead, but we'd also need
-* to verify the connector could handle a backlight call.
+* Update backlight on all connectors that support backlight (usually
+* only one).
*/
- list_for_each_entry(encoder, &dev->mode_config.encoder_list, head)
- if (encoder->crtc == crtc) {
- found = true;
- break;
- }
-
- if (!found) {
- ret = ASLC_BACKLIGHT_FAILED;
- goto out;
- }
-
- list_for_each_entry(connector, &dev->mode_config.connector_list, head)
- if (connector->encoder == encoder)
- intel_connector = to_intel_connector(connector);
-
- if (!intel_connector) {
- ret = ASLC_BACKLIGHT_FAILED;
- goto out;
- }
-
DRM_DEBUG_KMS("updating opregion backlight %d/255\n", bclp);
- intel_panel_set_backlight(intel_connector, bclp, 255);
+ list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
+ intel_connector = to_intel_connector(connector);
+ panel = &intel_connector->panel;
+ if (panel->backlight.present)
+ intel_panel_set_backlight(intel_connector, bclp, 255);
+ }
iowrite32(DIV_ROUND_UP(bclp * 100, 255) | ASLE_CBLV_VALID, &asle->cblv);
-out:
mutex_unlock(&dev->mode_config.mutex);
- return ret;
+
+ return 0;
}
static u32 asle_set_als_illum(struct drm_device *dev, u32 alsi)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 03e806f..e46226c 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -946,13 +946,17 @@ int intel_panel_setup_backlight(struct drm_connector
*connector)
intel_backlight_device_register(intel_connector);
+ panel->backlight.present = true;
+
return 0;
}
void intel_panel_destroy_backlight(struct drm_connector *connector)
{
struct intel_connector *intel_connector = to_intel_connector(connector);
+ struct intel_panel *panel = &intel_connector->panel;
+ panel->backlight.present = false;
intel_backlight_device_unregister(intel_connector);
}
Tested-by: Joe Konno
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/5] BDW libdrm support
Nothing special here... I'm fine with not pushing any of the AUB stuff if anyone has issues. Ben Widawsky (2): intel/bdw: Add broadwell chipset IDs intel/bdw: Handle gen8 bufmgr_init Damien Lespiau (2): intel/bdw: Add gen8 to the decode init intel/bdw: Update MI_BATCH_BUFFER_START for aub dumps Kenneth Graunke (1): intel/bdw/aub: Update AUB trace block writes for 48-bit addressing. intel/intel_bufmgr_gem.c | 24 +++- intel/intel_chipset.h| 22 +- intel/intel_decode.c | 4 +++- 3 files changed, 43 insertions(+), 7 deletions(-) -- 1.8.4.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5] intel/bdw: Add broadwell chipset IDs
From: Ben Widawsky v2: Rename s//IRIS/ Signed-off-by: Ben Widawsky --- intel/intel_chipset.h | 22 +- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h index aeb439e..e5589be 100644 --- a/intel/intel_chipset.h +++ b/intel/intel_chipset.h @@ -148,6 +148,12 @@ #define PCI_CHIP_HASWELL_CRW_E_GT1 0x0D0E /* Reserved */ #define PCI_CHIP_HASWELL_CRW_E_GT2 0x0D1E #define PCI_CHIP_HASWELL_CRW_E_GT3 0x0D2E +#define BDW_SPARE 0x2 +#define BDW_ULT0x6 +#define BDW_SERVER 0xa +#define BDW_IRIS 0xb +#define BDW_WORKSTATION0xd +#define BDW_ULX0xe #define PCI_CHIP_VALLEYVIEW_PO 0x0f30 /* VLV PO board */ #define PCI_CHIP_VALLEYVIEW_1 0x0f31 @@ -296,10 +302,24 @@ IS_HSW_GT2(devid) || \ IS_HSW_GT3(devid)) +#define IS_BROADWELL(devid) (((devid & 0xff00) != 0x1600) ? 0 : \ + (((devid & 0x00f0) >> 4) > 3) ? 0 : \ + ((devid & 0x000f) == BDW_SPARE) ? 1 : \ + ((devid & 0x000f) == BDW_ULT) ? 1 : \ + ((devid & 0x000f) == BDW_IRIS) ? 1 : \ + ((devid & 0x000f) == BDW_SERVER) ? 1 : \ + ((devid & 0x000f) == BDW_WORKSTATION) ? 1 : \ + ((devid & 0x000f) == BDW_ULX) ? 1 : 0) + + +#define IS_GEN8(devid) IS_BROADWELL(devid) + #define IS_9XX(dev)(IS_GEN3(dev) || \ IS_GEN4(dev) || \ IS_GEN5(dev) || \ IS_GEN6(dev) || \ -IS_GEN7(dev)) +IS_GEN7(dev) || \ +IS_GEN8(dev)) + #endif /* _INTEL_CHIPSET_H */ -- 1.8.4.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] intel/bdw: Add gen8 to the decode init
From: Damien Lespiau Signed-off-by: Damien Lespiau Reviewed-by: Kenneth Graunke Signed-off-by: Ben Widawsky --- intel/intel_decode.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/intel/intel_decode.c b/intel/intel_decode.c index 1b80b75..c0a0caf 100644 --- a/intel/intel_decode.c +++ b/intel/intel_decode.c @@ -3827,7 +3827,9 @@ drm_intel_decode_context_alloc(uint32_t devid) ctx->devid = devid; ctx->out = stdout; - if (IS_GEN7(devid)) + if (IS_GEN8(devid)) + ctx->gen = 8; + else if (IS_GEN7(devid)) ctx->gen = 7; else if (IS_GEN6(devid)) ctx->gen = 6; -- 1.8.4.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] intel/bdw: Update MI_BATCH_BUFFER_START for aub dumps
From: Damien Lespiau
The command now takes a 48bits address and is thus 1 byte longer.
Signed-off-by: Damien Lespiau
Signed-off-by: Ben Widawsky
---
intel/intel_bufmgr_gem.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 3eb6e2e..029ca5d 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -2028,8 +2028,14 @@ aub_build_dump_ringbuffer(drm_intel_bufmgr_gem
*bufmgr_gem,
/* Make a ring buffer to execute our batchbuffer. */
memset(ringbuffer, 0, sizeof(ringbuffer));
- ringbuffer[ring_count++] = AUB_MI_BATCH_BUFFER_START;
- ringbuffer[ring_count++] = batch_buffer;
+ if (bufmgr_gem->gen >= 8) {
+ ringbuffer[ring_count++] = AUB_MI_BATCH_BUFFER_START | (3 - 2);
+ ringbuffer[ring_count++] = batch_buffer;
+ ringbuffer[ring_count++] = 0;
+ } else {
+ ringbuffer[ring_count++] = AUB_MI_BATCH_BUFFER_START;
+ ringbuffer[ring_count++] = batch_buffer;
+ }
/* Write out the ring. This appears to trigger execution of
* the ring in the simulator.
--
1.8.4.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/5] intel/bdw/aub: Update AUB trace block writes for 48-bit addressing.
From: Kenneth Graunke
Since our aub file dumping's GTT handling is totally fake, we always put
everything in the low 4GB anyway and shouldn't ever need to set
AddressHigh to anything other than 0.
Signed-off-by: Kenneth Graunke
[ben: slight commit message change]
Signed-off-by: Ben Widawsky
---
intel/intel_bufmgr_gem.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 32a226c..3eb6e2e 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -1944,12 +1944,14 @@ aub_write_trace_block(drm_intel_bo *bo, uint32_t type,
uint32_t subtype,
aub_out(bufmgr_gem,
CMD_AUB_TRACE_HEADER_BLOCK |
- (5 - 2));
+ ((bufmgr_gem->gen >= 8 ? 6 : 5) - 2));
aub_out(bufmgr_gem,
AUB_TRACE_MEMTYPE_GTT | type | AUB_TRACE_OP_DATA_WRITE);
aub_out(bufmgr_gem, subtype);
aub_out(bufmgr_gem, bo_gem->aub_offset + offset);
aub_out(bufmgr_gem, size);
+ if (bufmgr_gem->gen >= 8)
+ aub_out(bufmgr_gem, 0);
aub_write_bo_data(bo, offset, size);
}
@@ -2034,12 +2036,14 @@ aub_build_dump_ringbuffer(drm_intel_bufmgr_gem
*bufmgr_gem,
*/
aub_out(bufmgr_gem,
CMD_AUB_TRACE_HEADER_BLOCK |
- (5 - 2));
+ ((bufmgr_gem->gen >= 8 ? 6 : 5) - 2));
aub_out(bufmgr_gem,
AUB_TRACE_MEMTYPE_GTT | ring | AUB_TRACE_OP_COMMAND_WRITE);
aub_out(bufmgr_gem, 0); /* general/surface subtype */
aub_out(bufmgr_gem, bufmgr_gem->aub_offset);
aub_out(bufmgr_gem, ring_count * 4);
+ if (bufmgr_gem->gen >= 8)
+ aub_out(bufmgr_gem, 0);
/* FIXME: Need some flush operations here? */
aub_out_data(bufmgr_gem, ringbuffer, ring_count * 4);
@@ -2952,11 +2956,13 @@ drm_intel_bufmgr_gem_set_aub_dump(drm_intel_bufmgr
*bufmgr, int enable)
aub_out(bufmgr_gem, 0); /* comment len */
/* Set up the GTT. The max we can handle is 256M */
- aub_out(bufmgr_gem, CMD_AUB_TRACE_HEADER_BLOCK | (5 - 2));
+ aub_out(bufmgr_gem, CMD_AUB_TRACE_HEADER_BLOCK | ((bufmgr_gem->gen >= 8
? 6 : 5) - 2));
aub_out(bufmgr_gem, AUB_TRACE_MEMTYPE_NONLOCAL | 0 |
AUB_TRACE_OP_DATA_WRITE);
aub_out(bufmgr_gem, 0); /* subtype */
aub_out(bufmgr_gem, 0); /* offset */
aub_out(bufmgr_gem, gtt_size); /* size */
+ if (bufmgr_gem->gen >= 8)
+ aub_out(bufmgr_gem, 0);
for (i = 0x000; i < gtt_size; i += 4, entry += 0x1000) {
aub_out(bufmgr_gem, entry);
}
--
1.8.4.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] intel/bdw: Handle gen8 bufmgr_init
From: Ben Widawsky
[bwidawsk: Added Damien's SOB]
Signed-off-by: Damien Lespiau
Reviewed-by: Kenneth Graunke
Signed-off-by: Ben Widawsky
---
intel/intel_bufmgr_gem.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 278f5c8..32a226c 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -3124,6 +3124,8 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size)
bufmgr_gem->gen = 6;
else if (IS_GEN7(bufmgr_gem->pci_device))
bufmgr_gem->gen = 7;
+ else if (IS_GEN8(bufmgr_gem->pci_device))
+ bufmgr_gem->gen = 8;
else {
free(bufmgr_gem);
return NULL;
--
1.8.4.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 4/6] drm/i915: Kill sandybridge_blit_fbc_update()
From: Ville Syrjälä
No longer needed since the LRIs do the work.
v2: Rebased due to hunk getting dropped from an ealier patch
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 23 ---
1 file changed, 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index dc306e1..4b016d8 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -185,26 +185,6 @@ static bool g4x_fbc_enabled(struct drm_device *dev)
return I915_READ(DPFC_CONTROL) & DPFC_CTL_EN;
}
-static void sandybridge_blit_fbc_update(struct drm_device *dev)
-{
- struct drm_i915_private *dev_priv = dev->dev_private;
- u32 blt_ecoskpd;
-
- /* Make sure blitter notifies FBC of writes */
- gen6_gt_force_wake_get(dev_priv);
- blt_ecoskpd = I915_READ(GEN6_BLITTER_ECOSKPD);
- blt_ecoskpd |= GEN6_BLITTER_FBC_NOTIFY <<
- GEN6_BLITTER_LOCK_SHIFT;
- I915_WRITE(GEN6_BLITTER_ECOSKPD, blt_ecoskpd);
- blt_ecoskpd |= GEN6_BLITTER_FBC_NOTIFY;
- I915_WRITE(GEN6_BLITTER_ECOSKPD, blt_ecoskpd);
- blt_ecoskpd &= ~(GEN6_BLITTER_FBC_NOTIFY <<
-GEN6_BLITTER_LOCK_SHIFT);
- I915_WRITE(GEN6_BLITTER_ECOSKPD, blt_ecoskpd);
- POSTING_READ(GEN6_BLITTER_ECOSKPD);
- gen6_gt_force_wake_put(dev_priv);
-}
-
static void ironlake_enable_fbc(struct drm_crtc *crtc, unsigned long interval)
{
struct drm_device *dev = crtc->dev;
@@ -237,7 +217,6 @@ static void ironlake_enable_fbc(struct drm_crtc *crtc,
unsigned long interval)
I915_WRITE(SNB_DPFC_CTL_SA,
SNB_CPU_FENCE_ENABLE | obj->fence_reg);
I915_WRITE(DPFC_CPU_FENCE_OFFSET, crtc->y);
- sandybridge_blit_fbc_update(dev);
}
DRM_DEBUG_KMS("enabled fbc on plane %c\n",
plane_name(intel_crtc->plane));
@@ -293,8 +272,6 @@ static void gen7_enable_fbc(struct drm_crtc *crtc, unsigned
long interval)
SNB_CPU_FENCE_ENABLE | obj->fence_reg);
I915_WRITE(DPFC_CPU_FENCE_OFFSET, crtc->y);
- sandybridge_blit_fbc_update(dev);
-
DRM_DEBUG_KMS("enabled fbc on plane %d\n", intel_crtc->plane);
}
--
1.8.1.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 5/6] drm/i915: Don't write ILK/IVB_FBC_RT_BASE directly
From: Ville Syrjälä We use LRIs to enable/disable the render tracking as needed. So leave ILK_FBC_RT_BASE alone when enabling FBC on SNB. While at it, kill the IVB_FBC_RT_BASE completely since we don't use render tracking on IVB+. TODO: Make ILK use the LRI mechanism too? v2: Drop the IVB_FBC_RT_BASE write too Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_pm.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 4b016d8..471217a 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -209,7 +209,8 @@ static void ironlake_enable_fbc(struct drm_crtc *crtc, unsigned long interval) (stall_watermark << DPFC_RECOMP_STALL_WM_SHIFT) | (interval << DPFC_RECOMP_TIMER_COUNT_SHIFT)); I915_WRITE(ILK_DPFC_FENCE_YOFF, crtc->y); - I915_WRITE(ILK_FBC_RT_BASE, i915_gem_obj_ggtt_offset(obj) | ILK_FBC_RT_VALID); + if (IS_GEN5(dev)) + I915_WRITE(ILK_FBC_RT_BASE, i915_gem_obj_ggtt_offset(obj) | ILK_FBC_RT_VALID); /* enable it... */ I915_WRITE(ILK_DPFC_CONTROL, dpfc_ctl | DPFC_CTL_EN); @@ -253,8 +254,6 @@ static void gen7_enable_fbc(struct drm_crtc *crtc, unsigned long interval) struct drm_i915_gem_object *obj = intel_fb->obj; struct intel_crtc *intel_crtc = to_intel_crtc(crtc); - I915_WRITE(IVB_FBC_RT_BASE, i915_gem_obj_ggtt_offset(obj)); - I915_WRITE(ILK_DPFC_CONTROL, DPFC_CTL_EN | DPFC_CTL_LIMIT_1X | IVB_DPFC_CTL_FENCE_EN | intel_crtc->plane << IVB_DPFC_CTL_PLANE_SHIFT); -- 1.8.1.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/6] drm/i915: Implement LRI based FBC tracking
From: Ville Syrjälä
As per the SNB and HSW PM guides, we should enable FBC render/blitter
tracking only during batches targetting the front buffer.
On SNB we must also update the FBC render tracking address whenever it
changes. And since the register in question is stored in the context,
we need to make sure we reload it with correct data after context
switches.
On IVB/HSW we use the render nuke mechanism, so no render tracking
address updates are needed. Hoever on the blitter side we need to
enable the blitter tracking like on SNB, and in addition we need
to issue the cache clean messages, which we already did.
v2: Introduce intel_fb_obj_has_fbc()
Fix crtc locking around crtc->fb access
Drop a hunk that was included by accident in v1
Set fbc_address_dirty=false not true after emitting the LRI
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_gem_context.c| 7
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 31
drivers/gpu/drm/i915/intel_display.c | 29 +--
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.c| 58 +-
drivers/gpu/drm/i915/intel_ringbuffer.h| 2 ++
6 files changed, 125 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 72a3df3..d438ea1 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -404,6 +404,13 @@ mi_set_context(struct intel_ring_buffer *ring,
intel_ring_advance(ring);
+ /*
+* FBC RT address is stored in the context, so we may have just
+* restored it to an old value. Make sure we emit a new LRI
+* to update the address.
+*/
+ ring->fbc_address_dirty = true;
+
return ret;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 885d595..db25158 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -886,6 +886,35 @@ validate_exec_list(struct drm_i915_gem_exec_object2 *exec,
}
static void
+i915_gem_execbuffer_mark_fbc_dirty(struct intel_ring_buffer *ring,
+ struct list_head *vmas)
+{
+ struct i915_vma *vma;
+ struct drm_i915_gem_object *fbc_obj = NULL;
+ u32 fbc_address = -1;
+
+ list_for_each_entry(vma, vmas, exec_list) {
+ struct drm_i915_gem_object *obj = vma->obj;
+
+ if (obj->base.pending_write_domain &&
+ intel_fb_obj_has_fbc(obj)) {
+ WARN_ON(fbc_obj && fbc_obj != obj);
+ fbc_obj = obj;
+ }
+ }
+
+ if (fbc_obj)
+ fbc_address = i915_gem_obj_ggtt_offset(fbc_obj);
+
+ /* need to nuke/cache_clean on IVB+? */
+ ring->fbc_dirty = fbc_obj != NULL;
+
+ /* need to update FBC tracking? */
+ ring->fbc_address_dirty = fbc_address != ring->fbc_address;
+ ring->fbc_address = fbc_address;
+}
+
+static void
i915_gem_execbuffer_move_to_active(struct list_head *vmas,
struct intel_ring_buffer *ring)
{
@@ -1150,6 +1179,8 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
if (flags & I915_DISPATCH_SECURE && !batch_obj->has_global_gtt_mapping)
i915_gem_gtt_bind_object(batch_obj, batch_obj->cache_level);
+ i915_gem_execbuffer_mark_fbc_dirty(ring, &eb->vmas);
+
ret = i915_gem_execbuffer_move_to_gpu(ring, &eb->vmas);
if (ret)
goto err;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 12cf362..fb080b6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8064,6 +8064,33 @@ void intel_mark_idle(struct drm_device *dev)
gen6_rps_idle(dev->dev_private);
}
+bool intel_fb_obj_has_fbc(struct drm_i915_gem_object *obj)
+{
+ struct drm_device *dev = obj->base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_crtc *crtc;
+
+ /* check for potential scanout */
+ if (!obj->pin_display)
+ return false;
+
+ list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
+ bool has_fbc;
+
+ if (dev_priv->fbc.plane != to_intel_crtc(crtc)->plane)
+ continue;
+
+ mutex_lock(&crtc->mutex);
+ has_fbc = crtc->fb && to_intel_framebuffer(crtc->fb)->obj ==
obj;
+ mutex_unlock(&crtc->mutex);
+
+ if (has_fbc)
+ return true;
+ }
+
+ return false;
+}
+
void intel_mark_fb_busy(struct drm_i915_gem_object *obj,
struct intel_ring_buffer *ring)
{
@@ -8081,8 +8108,6 @@ void intel_mark_fb_busy(struct drm_i915_gem_object *obj,
Re: [Intel-gfx] [PATCH v2 3/6] drm/i915: Implement LRI based FBC tracking
On Wed, Nov 06, 2013 at 07:23:25PM +0200, ville.syrj...@linux.intel.com wrote:
> +bool intel_fb_obj_has_fbc(struct drm_i915_gem_object *obj)
> +{
> + struct drm_device *dev = obj->base.dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + struct drm_crtc *crtc;
> +
> + /* check for potential scanout */
> + if (!obj->pin_display)
> + return false;
if (dev_oriv->fbc.plane == -1)
return false;
crtc = dev_priv->plane_to_crtc[dev_priv->fbc.plane];
mutex_lock(&crtc->mutex);
has_fbc = crtc->fb && to_intel_framebuffer(crtc->fb)->obj == obj;
mutex_unlock(&crtc->mutex);
return has_fbc
}
Perhaps?
-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 v2 3/6] drm/i915: Implement LRI based FBC tracking
On Wed, Nov 06, 2013 at 05:36:01PM +, Chris Wilson wrote:
> On Wed, Nov 06, 2013 at 07:23:25PM +0200, ville.syrj...@linux.intel.com wrote:
> > +bool intel_fb_obj_has_fbc(struct drm_i915_gem_object *obj)
> > +{
> > + struct drm_device *dev = obj->base.dev;
> > + struct drm_i915_private *dev_priv = dev->dev_private;
> > + struct drm_crtc *crtc;
> > +
> > + /* check for potential scanout */
> > + if (!obj->pin_display)
> > + return false;
>
> if (dev_oriv->fbc.plane == -1)
> return false;
>
> crtc = dev_priv->plane_to_crtc[dev_priv->fbc.plane];
>
> mutex_lock(&crtc->mutex);
> has_fbc = crtc->fb && to_intel_framebuffer(crtc->fb)->obj == obj;
> mutex_unlock(&crtc->mutex);
>
> return has_fbc
> }
>
> Perhaps?
Oh yeah, much nicer. Except now the locking I came up here sucks. Need
to rethink that part somehow. Maybe I'll just slap an
ACCESS_ONCE(crtc->fb) there. Hmm, but I guess I'd also need to grab a
reference to the fb to avoid it disappearing while were looking at it.
This is starting to be a bit hairy. So maybe I should just stick our
current fbc scanout object to dev_priv->fbc.obj, and update it when
doing page flips/modeset. I really didn't want to start messing about
with fbc locking but looks like there's no way around it.
--
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] intel_drv.so segfault
>> > I'm getting the following segfault intermittently when using sna. >> > I've tried xf86-video-intel-2.99.905 and the latest from git a week or >> > so ago. >> >> Symbols, please. >> >> addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i >> 0x2fe790x3037f > > addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i 0x2fe79 > 0x3037f Maybe this needs to be run immediately after the crash? Or before rebooting? >>> >>> Ah, it does require xf86-video-intel to have been built with debug >>> symbols (-g in CFLAGS) and not stripped upon installation. >> >> I'm running Gentoo and I added -g to the following in make.conf: >> >> CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer -g" >> >> I rebooted but I still get nothing from the addr2line command. What >> am I missing? > > FEATURES="nostrip" emerge xf86-video-intel Thank you, here's what I get: # addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i 0x2fe79 0x3037f /var/tmp/portage/x11-drivers/xf86-video-intel-2.99.905-r1/work/xf86-video-intel-2.99.905/src/sna/sna_accel.c:6079 /var/tmp/portage/x11-drivers/xf86-video-intel-2.99.905-r1/work/xf86-video-intel-2.99.905/src/sna/sna_accel.c:6240 (discriminator 1) - Grant ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] intel_drv.so segfault
On Wed, Nov 06, 2013 at 10:08:18AM -0800, Grant wrote: > Thank you, here's what I get: > > # addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i 0x2fe79 0x3037f > /var/tmp/portage/x11-drivers/xf86-video-intel-2.99.905-r1/work/xf86-video-intel-2.99.905/src/sna/sna_accel.c:6079 > /var/tmp/portage/x11-drivers/xf86-video-intel-2.99.905-r1/work/xf86-video-intel-2.99.905/src/sna/sna_accel.c:6240 > (discriminator 1) I need to know what commit id that corresponds to as well. Thanks, -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] tests/gem_reloc_overflow: Add gen8+ specifc tests
From: Rafael Barbalho
Broadwell introduces 64-bit relocation addresses which add extra
corner cases. The test was refactored slightly with some tests that
were in the source offset tests were moved to the more generic reloc
test area. The source offset tests are now gen aware and called twice to
test both cpu & gtt relocation paths. In addition 2 new gen8+ test
were added to the test:
* Relocation straddling page a page
* Insufficient space for a relocation at the end of the buffer.
Signed-off-by: Rafael Barbalho
Conflicts:
tests/gem_reloc_overflow.c
---
tests/gem_reloc_overflow.c | 148 +++--
1 file changed, 103 insertions(+), 45 deletions(-)
diff --git a/tests/gem_reloc_overflow.c b/tests/gem_reloc_overflow.c
index f7ba1d7..38ad2a5 100644
--- a/tests/gem_reloc_overflow.c
+++ b/tests/gem_reloc_overflow.c
@@ -24,6 +24,7 @@
* Authors:
*Kees Cook
*Daniel Vetter
+ *Rafael Barbalho
*
*/
@@ -60,13 +61,14 @@ struct drm_i915_gem_relocation_entry *reloc;
uint32_t handle;
uint32_t batch_handle;
-
-static void source_offset_tests(void)
+static void source_offset_tests(int devid, bool reloc_gtt)
{
struct drm_i915_gem_relocation_entry single_reloc;
+ char *dst_gtt;
+ char *relocation_type;
igt_fixture {
- handle = gem_create(fd, 4096);
+ handle = gem_create(fd, 8192);
execobjs[1].handle = batch_handle;
execobjs[1].relocation_count = 0;
@@ -76,21 +78,70 @@ static void source_offset_tests(void)
execobjs[0].relocation_count = 1;
execobjs[0].relocs_ptr = (uintptr_t) &single_reloc;
execbuf.buffer_count = 2;
+
+ if (reloc_gtt) {
+ dst_gtt = gem_mmap(fd, handle, 8192, PROT_READ |
PROT_WRITE);
+ igt_assert(dst_gtt != MAP_FAILED);
+ gem_set_domain(fd, handle, I915_GEM_DOMAIN_GTT,
I915_GEM_DOMAIN_GTT);
+ memset(dst_gtt, 0, 8192);
+ munmap(dst_gtt, 8192);
+ relocation_type = "reloc-gtt";
+ } else {
+ relocation_type = "reloc-cpu";
+ }
}
- igt_subtest("source-offset-end") {
- single_reloc.offset = 4096 - 4;
- single_reloc.delta = 0;
- single_reloc.target_handle = handle;
- single_reloc.read_domains = I915_GEM_DOMAIN_RENDER;
- single_reloc.write_domain = I915_GEM_DOMAIN_RENDER;
- single_reloc.presumed_offset = 0;
+ if (intel_gen(devid) >= 8) {
+ igt_subtest_f("source-offset-page-stradle-gen8+-%s",
relocation_type) {
+ single_reloc.offset = 4096 - 4;
+ single_reloc.delta = 0;
+ single_reloc.target_handle = handle;
+ single_reloc.read_domains = I915_GEM_DOMAIN_RENDER;
+ single_reloc.write_domain = I915_GEM_DOMAIN_RENDER;
+ single_reloc.presumed_offset = 0;
+
+ igt_assert(ioctl(fd, DRM_IOCTL_I915_GEM_EXECBUFFER2,
&execbuf) == 0);
+ single_reloc.delta = 1024;
+ igt_assert(ioctl(fd, DRM_IOCTL_I915_GEM_EXECBUFFER2,
&execbuf) == 0);
+ }
- igt_assert(ioctl(fd, DRM_IOCTL_I915_GEM_EXECBUFFER2, &execbuf)
== 0);
+ igt_subtest_f("source-offset-end-gen8+-%s", relocation_type) {
+ single_reloc.offset = 8192 - 8;
+ single_reloc.delta = 0;
+ single_reloc.target_handle = handle;
+ single_reloc.read_domains = I915_GEM_DOMAIN_RENDER;
+ single_reloc.write_domain = I915_GEM_DOMAIN_RENDER;
+ single_reloc.presumed_offset = 0;
+
+ igt_assert(ioctl(fd, DRM_IOCTL_I915_GEM_EXECBUFFER2,
&execbuf) == 0);
+ }
+
+ igt_subtest_f("source-offset-overflow-gen8+-%s",
relocation_type) {
+ single_reloc.offset = 8192 - 4;
+ single_reloc.delta = 0;
+ single_reloc.target_handle = handle;
+ single_reloc.read_domains = I915_GEM_DOMAIN_RENDER;
+ single_reloc.write_domain = I915_GEM_DOMAIN_RENDER;
+ single_reloc.presumed_offset = 0;
+
+ igt_assert(ioctl(fd, DRM_IOCTL_I915_GEM_EXECBUFFER2,
&execbuf) != 0);
+ igt_assert(errno == EINVAL);
+ }
+ } else {
+ igt_subtest_f("source-offset-end-%s", relocation_type) {
+ single_reloc.offset = 8192 - 4;
+ single_reloc.delta = 0;
+ single_reloc.target_handle = handle;
+ single_reloc.read_
Re: [Intel-gfx] intel_drv.so segfault
>> Thank you, here's what I get: >> >> # addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i 0x2fe79 >> 0x3037f >> /var/tmp/portage/x11-drivers/xf86-video-intel-2.99.905-r1/work/xf86-video-intel-2.99.905/src/sna/sna_accel.c:6079 >> /var/tmp/portage/x11-drivers/xf86-video-intel-2.99.905-r1/work/xf86-video-intel-2.99.905/src/sna/sna_accel.c:6240 >> (discriminator 1) > > I need to know what commit id that corresponds to as well. Thanks, > -Chris I'm sorry Chris, I'm just a lowly user. How can I get that info for you? - Grant ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] intel_drv.so segfault
On Wed, Nov 6, 2013 at 10:17 AM, Grant wrote: >>> Thank you, here's what I get: >>> >>> # addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i 0x2fe79 >>> 0x3037f >>> /var/tmp/portage/x11-drivers/xf86-video-intel-2.99.905-r1/work/xf86-video-intel-2.99.905/src/sna/sna_accel.c:6079 >>> /var/tmp/portage/x11-drivers/xf86-video-intel-2.99.905-r1/work/xf86-video-intel-2.99.905/src/sna/sna_accel.c:6240 >>> (discriminator 1) >> >> I need to know what commit id that corresponds to as well. Thanks, >> -Chris > > I'm sorry Chris, I'm just a lowly user. How can I get that info for you? I happen to have a few Gentoo systems sitting under my desk - if you can send me the output of emerge -pv xf86-video-intel I can assist with backtracking that to a specific commit. -James > > - Grant > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] intel_drv.so segfault
Thank you, here's what I get: # addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i 0x2fe79 0x3037f /var/tmp/portage/x11-drivers/xf86-video-intel-2.99.905-r1/work/xf86-video-intel-2.99.905/src/sna/sna_accel.c:6079 /var/tmp/portage/x11-drivers/xf86-video-intel-2.99.905-r1/work/xf86-video-intel-2.99.905/src/sna/sna_accel.c:6240 (discriminator 1) >>> >>> I need to know what commit id that corresponds to as well. Thanks, >>> -Chris >> >> I'm sorry Chris, I'm just a lowly user. How can I get that info for you? > > I happen to have a few Gentoo systems sitting under my desk - if you > can send me the output of > > emerge -pv xf86-video-intel > > I can assist with backtracking that to a specific commit. > > -James Many thanks James! # emerge -pv xf86-video-intel These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ~] x11-drivers/xf86-video-intel-2.99.905-r1 USE="dri sna udev -glamor -uxa -xvmc" 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB - Grant ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] tests/gem_reloc_overflow: Add gen8+ specifc tests
On Wed, Nov 06, 2013 at 06:12:12PM +, rafael.barba...@intel.com wrote:
> From: Rafael Barbalho
>
> Broadwell introduces 64-bit relocation addresses which add extra
> corner cases. The test was refactored slightly with some tests that
> were in the source offset tests were moved to the more generic reloc
> test area. The source offset tests are now gen aware and called twice to
> test both cpu & gtt relocation paths. In addition 2 new gen8+ test
> were added to the test:
>
> * Relocation straddling page a page
> * Insufficient space for a relocation at the end of the buffer.
>
> Signed-off-by: Rafael Barbalho
>
> Conflicts:
> tests/gem_reloc_overflow.c
> ---
> tests/gem_reloc_overflow.c | 148
> +++--
> 1 file changed, 103 insertions(+), 45 deletions(-)
>
> diff --git a/tests/gem_reloc_overflow.c b/tests/gem_reloc_overflow.c
> index f7ba1d7..38ad2a5 100644
> --- a/tests/gem_reloc_overflow.c
> +++ b/tests/gem_reloc_overflow.c
> @@ -24,6 +24,7 @@
> * Authors:
> *Kees Cook
> *Daniel Vetter
> + *Rafael Barbalho
> *
> */
>
> @@ -60,13 +61,14 @@ struct drm_i915_gem_relocation_entry *reloc;
> uint32_t handle;
> uint32_t batch_handle;
>
> -
> -static void source_offset_tests(void)
> +static void source_offset_tests(int devid, bool reloc_gtt)
> {
> struct drm_i915_gem_relocation_entry single_reloc;
> + char *dst_gtt;
> + char *relocation_type;
>
> igt_fixture {
> - handle = gem_create(fd, 4096);
> + handle = gem_create(fd, 8192);
>
> execobjs[1].handle = batch_handle;
> execobjs[1].relocation_count = 0;
> @@ -76,21 +78,70 @@ static void source_offset_tests(void)
> execobjs[0].relocation_count = 1;
> execobjs[0].relocs_ptr = (uintptr_t) &single_reloc;
> execbuf.buffer_count = 2;
> +
> + if (reloc_gtt) {
> + dst_gtt = gem_mmap(fd, handle, 8192, PROT_READ |
> PROT_WRITE);
> + igt_assert(dst_gtt != MAP_FAILED);
> + gem_set_domain(fd, handle, I915_GEM_DOMAIN_GTT,
> I915_GEM_DOMAIN_GTT);
> + memset(dst_gtt, 0, 8192);
> + munmap(dst_gtt, 8192);
> + relocation_type = "reloc-gtt";
> + } else {
> + relocation_type = "reloc-cpu";
> + }
> }
>
> - igt_subtest("source-offset-end") {
> - single_reloc.offset = 4096 - 4;
> - single_reloc.delta = 0;
> - single_reloc.target_handle = handle;
> - single_reloc.read_domains = I915_GEM_DOMAIN_RENDER;
> - single_reloc.write_domain = I915_GEM_DOMAIN_RENDER;
> - single_reloc.presumed_offset = 0;
> + if (intel_gen(devid) >= 8) {
> + igt_subtest_f("source-offset-page-stradle-gen8+-%s",
> relocation_type) {
> + single_reloc.offset = 4096 - 4;
> + single_reloc.delta = 0;
> + single_reloc.target_handle = handle;
> + single_reloc.read_domains = I915_GEM_DOMAIN_RENDER;
> + single_reloc.write_domain = I915_GEM_DOMAIN_RENDER;
> + single_reloc.presumed_offset = 0;
> +
> + igt_assert(ioctl(fd, DRM_IOCTL_I915_GEM_EXECBUFFER2,
> &execbuf) == 0);
> + single_reloc.delta = 1024;
> + igt_assert(ioctl(fd, DRM_IOCTL_I915_GEM_EXECBUFFER2,
> &execbuf) == 0);
> + }
>
> - igt_assert(ioctl(fd, DRM_IOCTL_I915_GEM_EXECBUFFER2, &execbuf)
> == 0);
> + igt_subtest_f("source-offset-end-gen8+-%s", relocation_type) {
> + single_reloc.offset = 8192 - 8;
> + single_reloc.delta = 0;
> + single_reloc.target_handle = handle;
> + single_reloc.read_domains = I915_GEM_DOMAIN_RENDER;
> + single_reloc.write_domain = I915_GEM_DOMAIN_RENDER;
> + single_reloc.presumed_offset = 0;
> +
> + igt_assert(ioctl(fd, DRM_IOCTL_I915_GEM_EXECBUFFER2,
> &execbuf) == 0);
> + }
> +
> + igt_subtest_f("source-offset-overflow-gen8+-%s",
> relocation_type) {
> + single_reloc.offset = 8192 - 4;
> + single_reloc.delta = 0;
> + single_reloc.target_handle = handle;
> + single_reloc.read_domains = I915_GEM_DOMAIN_RENDER;
> + single_reloc.write_domain = I915_GEM_DOMAIN_RENDER;
> + single_reloc.presumed_offset = 0;
> +
> + igt_assert(ioctl(fd, DRM_IOCTL_I915_GEM_EXECBUFFER2,
> &execbuf) != 0);
> + igt_assert(errno == EINVAL);
> + }
> + } else {
> + igt_subtest_f("source-offset-end-%s", relocation_type) {
> +
[Intel-gfx] [WIP] Wrap fb objects from BIOS/bootloader
There was a TODO from last time that Daniel and I talked about: - reconstruct fb state in our get_config callbacks instead - reconstruct per-crtc fb state and allocate separate buffers if needed - make sure we only preserve the buffer if it's the preferred mode Just wanted to get this refreshed version out there to get some eyes on it. Thanks, Jesse ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/5] BDW libdrm support
On 11/06/2013 09:15 AM, Ben Widawsky wrote: > Nothing special here... I'm fine with not pushing any of the AUB stuff if > anyone has issues. > > Ben Widawsky (2): > intel/bdw: Add broadwell chipset IDs > intel/bdw: Handle gen8 bufmgr_init > > Damien Lespiau (2): > intel/bdw: Add gen8 to the decode init > intel/bdw: Update MI_BATCH_BUFFER_START for aub dumps > > Kenneth Graunke (1): > intel/bdw/aub: Update AUB trace block writes for 48-bit addressing. > > intel/intel_bufmgr_gem.c | 24 +++- > intel/intel_chipset.h| 22 +- > intel/intel_decode.c | 4 +++- > 3 files changed, 43 insertions(+), 7 deletions(-) For the series: Reviewed-by: Kenneth Graunke ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon v4
Retrieve current framebuffer config info from the regs and create an fb
object for the buffer the BIOS or boot loader left us. This should
allow for smooth transitions to userspace apps once we finish the
initial configuration construction.
v2: check for non-native modes and adjust (Jesse)
fixup aperture and cmap frees (Imre)
use unlocked unref if init_bios fails (Jesse)
fix curly brace around DSPADDR check (Imre)
comment failure path for pin_and_fence (Imre)
v3: fixup fixup of aperture frees (Chris)
v4: update to current bits (locking & pin_and_fence hack) (Jesse)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_dma.c | 8 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_display.c | 14 +-
drivers/gpu/drm/i915/intel_drv.h | 4 +
drivers/gpu/drm/i915/intel_fbdev.c | 295 +--
5 files changed, 308 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 0cab2d0..d8eed45 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1277,6 +1277,7 @@ static const struct vga_switcheroo_client_ops
i915_switcheroo_ops = {
static int i915_load_modeset_init(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
+ bool was_vga_enabled;
int ret;
ret = intel_parse_bios(dev);
@@ -1315,7 +1316,11 @@ static int i915_load_modeset_init(struct drm_device *dev)
/* Important: The output setup functions called by modeset_init need
* working irqs for e.g. gmbus and dp aux transfers. */
- intel_modeset_init(dev);
+ intel_modeset_init(dev, &was_vga_enabled);
+
+ /* Wrap existing BIOS mode configuration prior to GEM takeover */
+ if (!was_vga_enabled)
+ intel_fbdev_init_bios(dev);
ret = i915_gem_init(dev);
if (ret)
@@ -1333,6 +1338,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
return 0;
}
+ /* Install a default KMS/GEM fbcon if we failed to wrap the BIOS fb */
ret = intel_fbdev_init(dev);
if (ret)
goto cleanup_gem;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d1590f7..100d3cf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2372,7 +2372,7 @@ static inline void intel_unregister_dsm_handler(void) {
return; }
/* modesetting */
extern void intel_modeset_init_hw(struct drm_device *dev);
extern void intel_modeset_suspend_hw(struct drm_device *dev);
-extern void intel_modeset_init(struct drm_device *dev);
+extern void intel_modeset_init(struct drm_device *dev, bool *was_vga_enabled);
extern void intel_modeset_gem_init(struct drm_device *dev);
extern void intel_modeset_cleanup(struct drm_device *dev);
extern int intel_modeset_vga_set_state(struct drm_device *dev, bool state);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 71b3bb7..f6e4792 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10735,12 +10735,17 @@ static void intel_init_quirks(struct drm_device *dev)
}
/* Disable the VGA plane that we never use */
-static void i915_disable_vga(struct drm_device *dev)
+static bool i915_disable_vga(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
+ bool was_enabled;
u8 sr1;
u32 vga_reg = i915_vgacntrl_reg(dev);
+ was_enabled = !(I915_READ(vga_reg) & VGA_DISP_DISABLE);
+ DRM_DEBUG_KMS("VGA output is currently %s\n",
+ was_enabled ? "enabled" : "disabled");
+
vga_get_uninterruptible(dev->pdev, VGA_RSRC_LEGACY_IO);
outb(SR01, VGA_SR_INDEX);
sr1 = inb(VGA_SR_DATA);
@@ -10750,6 +10755,8 @@ static void i915_disable_vga(struct drm_device *dev)
I915_WRITE(vga_reg, VGA_DISP_DISABLE);
POSTING_READ(vga_reg);
+
+ return was_enabled;
}
void intel_modeset_init_hw(struct drm_device *dev)
@@ -10777,7 +10784,8 @@ void intel_modeset_suspend_hw(struct drm_device *dev)
intel_suspend_hw(dev);
}
-void intel_modeset_init(struct drm_device *dev)
+void intel_modeset_init(struct drm_device *dev,
+ bool *was_vga_enabled)
{
struct drm_i915_private *dev_priv = dev->dev_private;
int i, j, ret;
@@ -10831,7 +10839,7 @@ void intel_modeset_init(struct drm_device *dev)
intel_shared_dpll_init(dev);
/* Just disable it once at startup */
- i915_disable_vga(dev);
+ *was_vga_enabled = i915_disable_vga(dev);
intel_setup_outputs(dev);
/* Just in case the BIOS is doing something questionable. */
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1876ea1..be048d9 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i
Re: [Intel-gfx] intel_drv.so segfault
On Wed, Nov 6, 2013 at 10:48 AM, Grant wrote: > Thank you, here's what I get: > > # addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i 0x2fe79 > 0x3037f Grant - I'm assuming that this was done on the emerged xf86-video-intel, not the git-compiled one? > /var/tmp/portage/x11-drivers/xf86-video-intel-2.99.905-r1/work/xf86-video-intel-2.99.905/src/sna/sna_accel.c:6079 git blame shows sna_accel.c:6079 (as of the 2.99.905 tag) last touched by 85fdc314 > /var/tmp/portage/x11-drivers/xf86-video-intel-2.99.905-r1/work/xf86-video-intel-2.99.905/src/sna/sna_accel.c:6240 git blame shows sna_accel.c:6240 (as of the 2.99.905 tag) last touched by 07a46333 Also note that xf86-video-intel-2.99.905-r1 has a backport patch of 8e44b1f5543f6d36c33c743f1ba2143514f8afbf (sna: Fix canonical mode name to correctly use asprintf) applied that touches sna/sna_display.c -James > (discriminator 1) I need to know what commit id that corresponds to as well. Thanks, -Chris >>> >>> I'm sorry Chris, I'm just a lowly user. How can I get that info for you? >> >> I happen to have a few Gentoo systems sitting under my desk - if you >> can send me the output of >> >> emerge -pv xf86-video-intel >> >> I can assist with backtracking that to a specific commit. >> >> -James > > Many thanks James! > > # emerge -pv xf86-video-intel > These are the packages that would be merged, in order: > Calculating dependencies... done! > [ebuild R ~] x11-drivers/xf86-video-intel-2.99.905-r1 USE="dri > sna udev -glamor -uxa -xvmc" 0 kB > Total: 1 package (1 reinstall), Size of downloads: 0 kB > > - Grant ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] More questions and patches for 835GM/ns2501 DVO
On 06.11.2013 11:34, Daniel Vetter wrote: } To clarify: Do you need this patch to make the single-pipe mode work reliably? It's a bit unclear in your answer ... Well, from what I can tell, I haven't seen the above warning since, but it was neither easily reproducable. "Working reliable" is probably a bit too much. (-; No, the vertical position of the boot console is off, panning flickers, and the two-monitor case is close to non-working. But other than that, it works now regardless of whether the bios is set to internal or shared monitors. So I would guess it works as good as it currently can. (-: The harddisk of the R31 (the other laptop with the same dreadful chipset) died today, so I fished a "new old one" from our pile of junk, and re-installed Linux. It currently compiles the latest git, so please have some patience with a 1.2Ghz Celeron. Will be ready tomorrow, hopefully with more results for the "anti-flicker" patch. Anyhow. This patch is currently *only* tested for the linear framebuffer alignment, and most certainly not "right". I believe its some sort of memory alignment issue, and I need to dig a bit deeper what exactly happens there. Greetings, Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Restore rps/rc6 on reset
On Tue, 2013-11-05 at 20:38 +, Mcgee, Jeff wrote: > On Mon, 2013-11-04 at 09:44 +0100, Daniel Vetter wrote: > > On Thu, Oct 31, 2013 at 8:52 PM, wrote: > > > From: Jeff McGee > > > > > > A check of rps/rc6 state after i915_reset determined that the ring > > > MAX_IDLE registers were returned to their hardware defaults and that > > > the GEN6_PMIMR register was set to mask all interrupts. This change > > > restores those values to their pre-reset states by re-initializing > > > rps/rc6 in i915_reset. A full re-initialization was opted for versus > > > a targeted set of restore operations for simplicity and maintain- > > > ability. Note that the re-initialization is not done for Ironlake, > > > due to a past comment that it causes problems. > > > > > > Also updated the rps initialization sequence to preserve existing > > > min/max values in the case of a re-init. We assume the values were > > > validated upon being set and do not do further range checking. The > > > debugfs interface for changing min/max was updated with range > > > checking to ensure this condition (already present in sysfs > > > interface). > > > > > > Issue: VIZ-3142 > > > Issue: AXIA-4676 > > > OTC-Tracker: VIZ-3143 > > > Signed-off-by: Jeff McGee > > > > Can I have a testcase in i-g-t for this please? I think the following > > should work: > > > > 1. Throw a dummy load onto the gpu, check that cagf goes up. > > > > 2. Limit min/max to a non-default value (and install an igt atexit > > handler to undo this). > > > > 3. Throw a dummy load onto the gpu, check that cagf jumps from the > > idle freq to the selected one directly. > > > > 4. Inject a gpu hang with the stop_rings stuff (see e.g. kms_flip.c or > > ZZ_hangman). > > > > 5. Reject that the limts still work as in step 3. > > > > Cheers, Daniel > > I'll see what can be done. I understand the emphasis on adding > formalized tests. There will have to be some resourcing discussions on > the product side if this is now a requirement for upstream patch > acceptance. > > Jeff This discussion is starting in VPG Android, but it may be a while until test code gets submitted. This is a fairly serious bug and easy to reproduce manually. So please consider the patch without the test case for now. Thanks Jeff ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] tests/gem_reloc_overflow: Add gen8+ specifc tests
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Wednesday, November 06, 2013 6:52 PM
> To: Barbalho, Rafael
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] tests/gem_reloc_overflow: Add gen8+
> specifc tests
>
* snip *
> > @@ -185,6 +208,36 @@ static void reloc_tests(void)
> > igt_assert(errno == EINVAL);
> > }
> >
> > + igt_fixture {
> > + execobjs[0].handle = batch_handle;
> > + execobjs[0].relocation_count = 0;
> > + execobjs[0].relocs_ptr = 0;
> > +
> > + execbuf.buffer_count = 1;
> > + }
> > +
> > + igt_subtest("batch-start-unaligned") {
> > + execbuf.batch_start_offset = 1;
> > + execbuf.batch_len = 8;
> > +
> > + igt_assert(ioctl(fd, DRM_IOCTL_I915_GEM_EXECBUFFER2,
> &execbuf) != 0);
> > + igt_assert(errno == EINVAL);
> > + }
> > +
> > + igt_subtest("batch-end-unaligned") {
> > + execbuf.batch_start_offset = 0;
> > + execbuf.batch_len = 7;
> > +
> > + igt_assert(ioctl(fd, DRM_IOCTL_I915_GEM_EXECBUFFER2,
> &execbuf) != 0);
> > + igt_assert(errno == EINVAL);
> > + }
> > +
> > + igt_fixture {
> > + /* Undo damage for next tests. */
> > + execbuf.batch_start_offset = 0;
> > + execbuf.batch_len = 8;
> > + }
>
> Moving these tests around is tricky - they should be carefully constructed so
> that the wrong batch start/end is the only thing which is wrong with the
> metadata, and that with correct start/len (0, 8) it would execute perfectly.
>
> This is to make sure that we really exercise this cornercase and don't get
> caught in some other check (that originally was done later but then might
> have moved around).
>
> tldr; Have you check that this is still true?
When I first moved the test I did try to make sure to move the igt_fixture
that set up the state for the tests did the correct thing. Just to make sure
that I
didn't screw things up I've re-run tests with an annotated kernel and it is
behaving as expected with the driver returning false from
i915_gem_check_execbuffer due to buffer misalignment.
tldr; Yes.
Thanks,
Raf
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Bug 64521] New: BUG kmalloc-4096 (Tainted: G W ): Poison overwritten
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Wed, 06 Nov 2013 19:12:29 + bugzilla-dae...@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=64521 > > Bug ID: 64521 >Summary: BUG kmalloc-4096 (Tainted: GW ): Poison > overwritten >Product: Memory Management >Version: 2.5 > Kernel Version: 3.11.7 > Hardware: All > OS: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Slab Allocator > Assignee: a...@linux-foundation.org > Reporter: mikhail.v.gavri...@gmail.com > Regression: No > > Created attachment 113671 > --> https://bugzilla.kernel.org/attachment.cgi?id=113671&action=edit > dmesg output > > $ uname -a > Linux localhost.localdomain 3.11.7-300.fc20.x86_64+debug #1 SMP Mon Nov 4 > 14:54:17 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux > > [14065.872585] perf samples too long (2552 > 2500), lowering > kernel.perf_event_max_sample_rate to 5 > [23825.627427] > = > [23825.627438] BUG kmalloc-4096 (Tainted: GW ): Poison overwritten > [23825.627442] > - > > [23825.627449] INFO: 0x880311f7a5ee-0x880311f7a5ee. First byte 0x7b > instead of 0x6b > [23825.627495] INFO: Allocated in i915_gem_execbuffer2+0x51/0x290 [i915] > age=89 > cpu=6 pid=2995 > [23825.627503] __slab_alloc+0x45f/0x526 > [23825.627509] __kmalloc+0x322/0x3b0 > [23825.627534] i915_gem_execbuffer2+0x51/0x290 [i915] > [23825.627554] drm_ioctl+0x542/0x680 [drm] > [23825.627561] do_vfs_ioctl+0x305/0x530 > [23825.627566] SyS_ioctl+0x81/0xa0 > [23825.627576] tracesys+0xdd/0xe2 > [23825.627601] INFO: Freed in i915_gem_execbuffer2+0xed/0x290 [i915] age=89 > cpu=6 pid=2995 > [23825.627607] __slab_free+0x3a/0x382 > [23825.627611] kfree+0x2c0/0x2f0 > [23825.627632] i915_gem_execbuffer2+0xed/0x290 [i915] > [23825.627649] drm_ioctl+0x542/0x680 [drm] > [23825.627653] do_vfs_ioctl+0x305/0x530 > [23825.627657] SyS_ioctl+0x81/0xa0 > [23825.627663] tracesys+0xdd/0xe2 > [23825.627668] INFO: Slab 0xea000c47de00 objects=7 used=7 fp=0x > (null) flags=0x5ff0004080 > [23825.627672] INFO: Object 0x880311f7a290 @offset=8848 > fp=0x880311f79148 > > [23825.627679] Bytes b4 880311f7a280: d6 ea 65 01 01 00 00 00 5a 5a 5a 5a > 5a 5a 5a 5a ..e. > [23825.627684] Object 880311f7a290: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [23825.627688] Object 880311f7a2a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [23825.627692] Object 880311f7a2b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [23825.627696] Object 880311f7a2c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [23825.627700] Object 880311f7a2d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [23825.627704] Object 880311f7a2e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [23825.627708] Object 880311f7a2f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [23825.627711] Object 880311f7a300: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [23825.627715] Object 880311f7a310: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [23825.627719] Object 880311f7a320: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [23825.627723] Object 880311f7a330: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [23825.627727] Object 880311f7a340: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [23825.627731] Object 880311f7a350: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [23825.627735] Object 880311f7a360: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [23825.627739] Object 880311f7a370: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [23825.627743] Object 880311f7a380: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [23825.627747] Object 880311f7a390: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [23825.627751] Object 880311f7a3a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [23825.627755] Object 880311f7a3b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [23825.627759] Object 880311f7a3c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b > [23825.627762] Object 880311f7a3d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b
Re: [Intel-gfx] [RFC 3/6] drm/i915: add enable_runtime_pm option
2013/11/4 Ville Syrjälä :
> On Mon, Oct 28, 2013 at 03:27:39PM +0200, Imre Deak wrote:
>> On Tue, 2013-10-22 at 17:30 -0200, Paulo Zanoni wrote:
>> > From: Paulo Zanoni
>> >
>> > And leave it off by default. We have way too many driver entry points,
>> > we can't assume this will work without regressions without tons of
>> > testing first. This option allows people to test and fix the problems.
>> >
>> > Signed-off-by: Paulo Zanoni
>> > ---
>> > drivers/gpu/drm/i915/i915_dma.c | 4 ++--
>> > drivers/gpu/drm/i915/i915_drv.c | 8 ++--
>> > drivers/gpu/drm/i915/i915_drv.h | 1 +
>> > drivers/gpu/drm/i915/intel_pm.c | 4 ++--
>> > 4 files changed, 11 insertions(+), 6 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_dma.c
>> > b/drivers/gpu/drm/i915/i915_dma.c
>> > index 6aa044e..dd4f424 100644
>> > --- a/drivers/gpu/drm/i915/i915_dma.c
>> > +++ b/drivers/gpu/drm/i915/i915_dma.c
>> > @@ -1458,7 +1458,7 @@ static void i915_init_runtime_pm(struct
>> > drm_i915_private *dev_priv)
>> >
>> > dev_priv->pm.suspended = false;
>> >
>> > - if (!HAS_RUNTIME_PM(dev))
>> > + if (!HAS_RUNTIME_PM(dev) || !i915_enable_runtime_pm)
>> > return;
>> >
>> > pm_runtime_set_active(device);
>> > @@ -1475,7 +1475,7 @@ static void i915_fini_runtime_pm(struct
>> > drm_i915_private *dev_priv)
>> > struct drm_device *dev = dev_priv->dev;
>> > struct device *device = &dev->pdev->dev;
>> >
>> > - if (!HAS_RUNTIME_PM(dev))
>> > + if (!HAS_RUNTIME_PM(dev) || !i915_enable_runtime_pm)
>> > return;
>> >
>> > /* Make sure we're not suspended first. */
>> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
>> > b/drivers/gpu/drm/i915/i915_drv.c
>> > index a999a3f..c75b78f 100644
>> > --- a/drivers/gpu/drm/i915/i915_drv.c
>> > +++ b/drivers/gpu/drm/i915/i915_drv.c
>> > @@ -154,6 +154,10 @@ module_param_named(prefault_disable,
>> > i915_prefault_disable, bool, 0600);
>> > MODULE_PARM_DESC(prefault_disable,
>> > "Disable page prefaulting for pread/pwrite/reloc
>> > (default:false). For developers only.");
>> >
>> > +int i915_enable_runtime_pm __read_mostly = 0;
>> > +module_param_named(enable_runtime_pm, i915_enable_runtime_pm, int, 0600);
>> > +MODULE_PARM_DESC(enable_runtime_pm, "Enable runtime PM on supported
>> > platforms (default: disabled)");
>> > +
>> > static struct drm_driver driver;
>> > extern int intel_agp_enabled;
>> >
>> > @@ -890,7 +894,7 @@ static int i915_runtime_suspend(struct device *device)
>> > struct drm_device *dev = pci_get_drvdata(pdev);
>> > struct drm_i915_private *dev_priv = dev->dev_private;
>> >
>> > - WARN_ON(!HAS_RUNTIME_PM(dev));
>> > + WARN_ON(!HAS_RUNTIME_PM(dev) || !i915_enable_runtime_pm);
>> >
>> > DRM_DEBUG_KMS("Suspending device\n");
>> >
>> > @@ -909,7 +913,7 @@ static int i915_runtime_resume(struct device *device)
>> > struct drm_device *dev = pci_get_drvdata(pdev);
>> > struct drm_i915_private *dev_priv = dev->dev_private;
>> >
>> > - WARN_ON(!HAS_RUNTIME_PM(dev));
>> > + WARN_ON(!HAS_RUNTIME_PM(dev) || !i915_enable_runtime_pm);
>>
>> This could a problem if someone disables runtime_pm through sysfs while
>> the device is suspended. One solution would be just to do a get/put in
>> the handler of i915_enable_runtime_pm and not check for it afterwards.
>
> There's already a standard interface for enabling/disabling runtime PM
> under sysfs. Why do we want this custom one?
Mostly to avoid those people that run powertop and switch everything
to "good". But I don't really have a strong opinion here, I'm fine
with just discarding this patch.
>
> --
> Ville Syrjälä
> Intel OTC
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 1/6] drm/i915: add initial Runtime PM functions
2013/10/28 Imre Deak :
> On Tue, 2013-10-22 at 17:30 -0200, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> This patch adds the initial infrastructure to allow a Runtime PM
>> implementation that sets the device to its D3 state. The patch just
>> adds the necessary callbacks and the initial infrastructure.
>>
>> We still don't have any platform that actually uses this
>> infrastructure, we still don't call get/put in all the places we need
>> to, and we don't have any function to save/restore the state of the
>> registers. This is not a problem since no platform uses the code added
>> by this patch. We have a few people simultaneously working on runtime
>> PM, so this initial code could help everybody make their plans.
>>
>> Signed-off-by: Paulo Zanoni
>> ---
>> drivers/gpu/drm/i915/i915_dma.c | 38 +
>> drivers/gpu/drm/i915/i915_drv.c | 42
>> +
>> drivers/gpu/drm/i915/i915_drv.h | 7 +++
>> drivers/gpu/drm/i915/intel_drv.h| 2 ++
>> drivers/gpu/drm/i915/intel_pm.c | 26 +++
>> drivers/gpu/drm/i915/intel_uncore.c | 9
>> 6 files changed, 124 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_dma.c
>> b/drivers/gpu/drm/i915/i915_dma.c
>> index fd848ef..6aa044e 100644
>> --- a/drivers/gpu/drm/i915/i915_dma.c
>> +++ b/drivers/gpu/drm/i915/i915_dma.c
>> @@ -42,6 +42,8 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>>
>> #define LP_RING(d) (&((struct drm_i915_private *)(d))->ring[RCS])
>>
>> @@ -1449,6 +1451,38 @@ static void i915_dump_device_info(struct
>> drm_i915_private *dev_priv)
>> #undef SEP_COMMA
>> }
>>
>> +static void i915_init_runtime_pm(struct drm_i915_private *dev_priv)
>> +{
>> + struct drm_device *dev = dev_priv->dev;
>> + struct device *device = &dev->pdev->dev;
>> +
>> + dev_priv->pm.suspended = false;
>> +
>> + if (!HAS_RUNTIME_PM(dev))
>> + return;
>> +
>> + pm_runtime_set_active(device);
>> + pm_runtime_enable(device);
>> +
>> + pm_runtime_set_autosuspend_delay(device, 1); /* 10s */
>> + pm_runtime_mark_last_busy(device);
>> + pm_runtime_use_autosuspend(device);
>> + pm_runtime_allow(device);
>
> This shouldn't be needed as we get here already with an allowed state.
> It's not a problem as it's just a nop here, but imo it's confusing that
> we don't have the corresponding pm_runtime_forbid() in
> i915_fini_runtime_pm().
If we don't call this, when we boot the machine the "power/control"
sysfs file will be "on", which means runtime PM is disabled. We have
to manually "echo auto > control" to enable runtime PM then. But I
guess leaving runtime PM disabled by default might be what we want, so
I'll remove the call here.
>
>> +}
>> +
>> +static void i915_fini_runtime_pm(struct drm_i915_private *dev_priv)
>> +{
>> + struct drm_device *dev = dev_priv->dev;
>> + struct device *device = &dev->pdev->dev;
>> +
>> + if (!HAS_RUNTIME_PM(dev))
>> + return;
>> +
>> + /* Make sure we're not suspended first. */
>> + pm_runtime_get_sync(device);
>> + pm_runtime_disable(device);
>> +}
>> +
>
> Could we have the above functions in intel_pm.c?
Done.
>
>> /**
>> * i915_driver_load - setup chip and create an initial config
>> * @dev: DRM device
>> @@ -1664,6 +1698,8 @@ int i915_driver_load(struct drm_device *dev, unsigned
>> long flags)
>> if (IS_GEN5(dev))
>> intel_gpu_ips_init(dev_priv);
>>
>> + i915_init_runtime_pm(dev_priv);
>> +
>> return 0;
>>
>> out_power_well:
>> @@ -1704,6 +1740,8 @@ int i915_driver_unload(struct drm_device *dev)
>> struct drm_i915_private *dev_priv = dev->dev_private;
>> int ret;
>>
>> + i915_fini_runtime_pm(dev_priv);
>> +
>> intel_gpu_ips_teardown();
>>
>> if (HAS_POWER_WELL(dev)) {
>> diff --git a/drivers/gpu/drm/i915/i915_drv.c
>> b/drivers/gpu/drm/i915/i915_drv.c
>> index 85ae0dc..08fc7ea 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.c
>> +++ b/drivers/gpu/drm/i915/i915_drv.c
>> @@ -469,6 +469,8 @@ static int i915_drm_freeze(struct drm_device *dev)
>> struct drm_i915_private *dev_priv = dev->dev_private;
>> struct drm_crtc *crtc;
>>
>> + intel_runtime_pm_get(dev_priv);
>> +
>> /* ignore lid events during suspend */
>> mutex_lock(&dev_priv->modeset_restore_lock);
>> dev_priv->modeset_restore = MODESET_SUSPENDED;
>> @@ -653,6 +655,8 @@ static int __i915_drm_thaw(struct drm_device *dev, bool
>> restore_gtt_mappings)
>> mutex_lock(&dev_priv->modeset_restore_lock);
>> dev_priv->modeset_restore = MODESET_DONE;
>> mutex_unlock(&dev_priv->modeset_restore_lock);
>> +
>> + intel_runtime_pm_put(dev_priv);
>> return error;
>> }
>>
>> @@ -880,6 +884,42 @@ static int i915_pm_poweroff(struct device *dev)
>> return i915_drm_freeze(drm_dev);
>> }
>>
>> +static int i915_runtime_suspend(struct device *devic
Re: [Intel-gfx] intel_drv.so segfault
>> Thank you, here's what I get: >> >> # addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i 0x2fe79 >> 0x3037f > > Grant - I'm assuming that this was done on the emerged > xf86-video-intel, not the git-compiled one? Yes, that is correct. I emerged the git-compiled one too with a - ebuild from the x11 overlay but that was replaced a week ago. >> /var/tmp/portage/x11-drivers/xf86-video-intel-2.99.905-r1/work/xf86-video-intel-2.99.905/src/sna/sna_accel.c:6079 > > git blame shows sna_accel.c:6079 (as of the 2.99.905 tag) last touched > by 85fdc314 > >> /var/tmp/portage/x11-drivers/xf86-video-intel-2.99.905-r1/work/xf86-video-intel-2.99.905/src/sna/sna_accel.c:6240 > > git blame shows sna_accel.c:6240 (as of the 2.99.905 tag) last touched > by 07a46333 > > Also note that xf86-video-intel-2.99.905-r1 has a backport patch of > 8e44b1f5543f6d36c33c743f1ba2143514f8afbf (sna: Fix canonical mode name > to correctly use asprintf) applied that touches sna/sna_display.c I actually just emerged xf86-video-intel-2.99.905-r1 for the first time today, I'd been using 2.99.905. It sounds like that might fix it? - Grant > I need to know what commit id that corresponds to as well. Thanks, > -Chris I'm sorry Chris, I'm just a lowly user. How can I get that info for you? >>> >>> I happen to have a few Gentoo systems sitting under my desk - if you >>> can send me the output of >>> >>> emerge -pv xf86-video-intel >>> >>> I can assist with backtracking that to a specific commit. >>> >>> -James >> >> Many thanks James! >> >> # emerge -pv xf86-video-intel >> These are the packages that would be merged, in order: >> Calculating dependencies... done! >> [ebuild R ~] x11-drivers/xf86-video-intel-2.99.905-r1 USE="dri >> sna udev -glamor -uxa -xvmc" 0 kB >> Total: 1 package (1 reinstall), Size of downloads: 0 kB >> >> - Grant ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/10] drm/i915: FBC fixes v2
One more attempt at making FBC suck a bit less. The main thing as before is getting the LRI based render/blitter tracking in place. In this updates series I decided the way to avoid the kms locks in execbuffer is to keep an extra reference to the fb. I added a bunch of locking (struct_mutex and crtc->mutex) to some places to hopefully make it bit less racy. I think/hope that it doesn't make it more likely to deadlock. We do grab both locks in the fbc work now, and we do cancel the work while holding at least one of the locks, so it seems a bit bad. But we cancel the work in a lazy fashion (no _sync or anything) so I don't think it should deadlock due to that. And we already grabbed struct_mutex there anyway, and we already held it while cancelling the work, so it's no worse at least :P The disable_fbc/update_fbc calls from the page flip code are lacking kms lock protection, but we can't simply add it there due to possibility of deadlocks. So at least the render/blitter tracking seems to work now without upsetting lockdep, so it seems a bit better than what we had at least. Maybe someone else will get inspired by this and fix this mess up for real... I've only run this on my IVB, and just running X + some apps w/o a compositor. No extensive tests or anything. But if I frob some debug register to disable some tracking bits the screen gets corrupted, so it seems to be doing its job. I pushed it here in case someone is interested in a git tree: git://gitorious.org/vsyrjala/linux.git fbc_fixes Ville Syrjälä (10): drm/i915: Use plane_name() in gen7_enable_fbc() drm/i915: Grab struct_mutex around all FBC updates drm/i915: Have FBC keep references to the fb drm/i915: Grab crtc->mutex in intel_fbc_work_fn() drm/i915: Limit FBC flush to post batch flush drm/i915: Emit SRM after the MSG_FBC_REND_STATE LRI drm/i915: Implement LRI based FBC tracking drm/i915: Kill sandybridge_blit_fbc_update() drm/i915: Don't write ILK/IVB_FBC_RT_BASE directly drm/i915: Set has_fbc=true for all SNB+, except VLV drivers/gpu/drm/i915/i915_drv.c| 6 +- drivers/gpu/drm/i915/i915_drv.h| 6 +- drivers/gpu/drm/i915/i915_gem_context.c| 7 +++ drivers/gpu/drm/i915/i915_gem_execbuffer.c | 31 ++ drivers/gpu/drm/i915/i915_reg.h| 1 + drivers/gpu/drm/i915/intel_display.c | 27 +++- drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_pm.c| 98 -- drivers/gpu/drm/i915/intel_ringbuffer.c| 66 ++-- drivers/gpu/drm/i915/intel_ringbuffer.h| 2 + 10 files changed, 188 insertions(+), 57 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/10] drm/i915: Have FBC keep references to the fb
From: Ville Syrjälä
In order to do the FBC tracking properly for execbuffer, we need to
figure out if the object being rendered to is the current front buffer.
However in order to do that purely based on the crtc, we'd need to
grab crtc->mutex, but we can't since we're already holding struct_mutex.
So let's keep the current fb around in dev_priv->fbc.fb and consult that
one. We're holding a reference to it for the entire time FBC is enabled,
so there's no danger of it disappearing while we're looking at it.
Assuming FBC updates always happens while holding struct_mutex that is.
Also change the delayed enable mechanism to grab a reference to the fb.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 6 ++--
drivers/gpu/drm/i915/intel_pm.c | 63 -
2 files changed, 47 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c842928..42a4375 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -352,7 +352,9 @@ struct dpll;
struct drm_i915_display_funcs {
bool (*fbc_enabled)(struct drm_device *dev);
- void (*enable_fbc)(struct drm_crtc *crtc, unsigned long interval);
+ void (*enable_fbc)(struct drm_crtc *crtc,
+ struct drm_framebuffer *fb,
+ unsigned long interval);
void (*disable_fbc)(struct drm_device *dev);
int (*get_display_clock_speed)(struct drm_device *dev);
int (*get_fifo_size)(struct drm_device *dev, int plane);
@@ -652,7 +654,7 @@ struct i915_hw_context {
struct i915_fbc {
unsigned long size;
- unsigned int fb_id;
+ struct drm_framebuffer *fb;
enum plane plane;
int y;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index dc306e1..8780b87 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -86,11 +86,12 @@ static void i8xx_disable_fbc(struct drm_device *dev)
DRM_DEBUG_KMS("disabled FBC\n");
}
-static void i8xx_enable_fbc(struct drm_crtc *crtc, unsigned long interval)
+static void i8xx_enable_fbc(struct drm_crtc *crtc,
+ struct drm_framebuffer *fb,
+ unsigned long interval)
{
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- struct drm_framebuffer *fb = crtc->fb;
struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
struct drm_i915_gem_object *obj = intel_fb->obj;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
@@ -136,11 +137,12 @@ static bool i8xx_fbc_enabled(struct drm_device *dev)
return I915_READ(FBC_CONTROL) & FBC_CTL_EN;
}
-static void g4x_enable_fbc(struct drm_crtc *crtc, unsigned long interval)
+static void g4x_enable_fbc(struct drm_crtc *crtc,
+ struct drm_framebuffer *fb,
+ unsigned long interval)
{
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- struct drm_framebuffer *fb = crtc->fb;
struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
struct drm_i915_gem_object *obj = intel_fb->obj;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
@@ -205,11 +207,12 @@ static void sandybridge_blit_fbc_update(struct drm_device
*dev)
gen6_gt_force_wake_put(dev_priv);
}
-static void ironlake_enable_fbc(struct drm_crtc *crtc, unsigned long interval)
+static void ironlake_enable_fbc(struct drm_crtc *crtc,
+ struct drm_framebuffer *fb,
+ unsigned long interval)
{
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- struct drm_framebuffer *fb = crtc->fb;
struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
struct drm_i915_gem_object *obj = intel_fb->obj;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
@@ -265,11 +268,12 @@ static bool ironlake_fbc_enabled(struct drm_device *dev)
return I915_READ(ILK_DPFC_CONTROL) & DPFC_CTL_EN;
}
-static void gen7_enable_fbc(struct drm_crtc *crtc, unsigned long interval)
+static void gen7_enable_fbc(struct drm_crtc *crtc,
+ struct drm_framebuffer *fb,
+ unsigned long interval)
{
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- struct drm_framebuffer *fb = crtc->fb;
struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
struct drm_i915_gem_object *obj = intel_fb->obj;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
@@ -308,6 +312,22 @@ bool intel_fbc_enabled(struct drm_device *dev)
return dev_priv->display.fbc_enabled(dev);
}
+static void intel_setup_fbc(struc
[Intel-gfx] [PATCH 01/10] drm/i915: Grab struct_mutex around all FBC updates
From: Ville Syrjälä We need some protection for the FBC state, and since struct_mutex is it currently in most places, make sure all FBC update/disable calles are protected by it. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 12cf362..bce6e07 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -3576,8 +3576,10 @@ static void haswell_crtc_disable_planes(struct drm_crtc *crtc) drm_vblank_off(dev, pipe); /* FBC must be disabled before disabling the plane on HSW. */ + mutex_lock(&dev->struct_mutex); if (dev_priv->fbc.plane == plane) intel_disable_fbc(dev); + mutex_unlock(&dev->struct_mutex); hsw_disable_ips(intel_crtc); @@ -3717,8 +3719,10 @@ static void ironlake_crtc_disable(struct drm_crtc *crtc) intel_crtc_wait_for_pending_flips(crtc); drm_vblank_off(dev, pipe); + mutex_lock(&dev->struct_mutex); if (dev_priv->fbc.plane == plane) intel_disable_fbc(dev); + mutex_unlock(&dev->struct_mutex); intel_crtc_update_cursor(crtc, false); intel_disable_planes(crtc); @@ -4102,7 +4106,9 @@ static void valleyview_crtc_enable(struct drm_crtc *crtc) intel_enable_planes(crtc); intel_crtc_update_cursor(crtc, true); + mutex_lock(&dev->struct_mutex); intel_update_fbc(dev); + mutex_unlock(&dev->struct_mutex); for_each_encoder_on_crtc(dev, crtc, encoder) encoder->enable(encoder); @@ -4146,7 +4152,9 @@ static void i9xx_crtc_enable(struct drm_crtc *crtc) /* Give the overlay scaler a chance to enable if it's on this pipe */ intel_crtc_dpms_overlay(intel_crtc, true); + mutex_lock(&dev->struct_mutex); intel_update_fbc(dev); + mutex_unlock(&dev->struct_mutex); for_each_encoder_on_crtc(dev, crtc, encoder) encoder->enable(encoder); @@ -4210,7 +4218,9 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc) intel_crtc->active = false; intel_update_watermarks(crtc); + mutex_lock(&dev->struct_mutex); intel_update_fbc(dev); + mutex_unlock(&dev->struct_mutex); } static void i9xx_crtc_off(struct drm_crtc *crtc) -- 1.8.1.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/10] drm/i915: Emit SRM after the MSG_FBC_REND_STATE LRI
From: Ville Syrjälä The spec tells us that we need to emit an SRM after the LRI to MSG_FBC_REND_STATE. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/intel_ringbuffer.c | 6 -- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 0719c8b..7a4d3e1 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -235,6 +235,7 @@ */ #define MI_LOAD_REGISTER_IMM(x)MI_INSTR(0x22, 2*x-1) #define MI_STORE_REGISTER_MEM(x) MI_INSTR(0x24, 2*x-1) +#define MI_SRM_LRM_GLOBAL_GTT (1<<22) #define MI_FLUSH_DWMI_INSTR(0x26, 1) /* for GEN6 */ #define MI_FLUSH_DW_STORE_INDEX (1<<21) #define MI_INVALIDATE_TLB(1<<18) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index 752f208..4649bf5 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -285,14 +285,16 @@ static int gen7_ring_fbc_flush(struct intel_ring_buffer *ring, u32 value) if (!ring->fbc_dirty) return 0; - ret = intel_ring_begin(ring, 4); + ret = intel_ring_begin(ring, 6); if (ret) return ret; - intel_ring_emit(ring, MI_NOOP); /* WaFbcNukeOn3DBlt:ivb/hsw */ intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1)); intel_ring_emit(ring, MSG_FBC_REND_STATE); intel_ring_emit(ring, value); + intel_ring_emit(ring, MI_STORE_REGISTER_MEM(1) | MI_SRM_LRM_GLOBAL_GTT); + intel_ring_emit(ring, MSG_FBC_REND_STATE); + intel_ring_emit(ring, ring->scratch.gtt_offset + 256); intel_ring_advance(ring); ring->fbc_dirty = false; -- 1.8.1.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/10] drm/i915: Grab crtc->mutex in intel_fbc_work_fn()
From: Ville Syrjälä
Make the FBC code a bit less racy by grabbing crtc->mutex
in intel_fbc_work_fn() when we go digging through the crtc
state.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 8780b87..dc65bb4 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -333,9 +333,12 @@ static void intel_fbc_work_fn(struct work_struct *__work)
struct intel_fbc_work *work =
container_of(to_delayed_work(__work),
struct intel_fbc_work, work);
+ struct drm_crtc *crtc = work->crtc;
struct drm_device *dev = work->crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
+ mutex_lock(&crtc->mutex);
+
mutex_lock(&dev->struct_mutex);
if (work == dev_priv->fbc.fbc_work) {
/* Double check that we haven't switched fb without cancelling
@@ -347,6 +350,8 @@ static void intel_fbc_work_fn(struct work_struct *__work)
}
mutex_unlock(&dev->struct_mutex);
+ mutex_unlock(&crtc->mutex);
+
drm_framebuffer_reference(work->fb);
kfree(work);
--
1.8.1.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/10] drm/i915: Limit FBC flush to post batch flush
From: Ville Syrjälä Don't issue the FBC nuke/cache clean command when invalidate_domains!=0. That would indicate that we're not being called for the post-batch flush. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_ringbuffer.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index e32c08a..752f208 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -354,7 +354,7 @@ gen7_render_ring_flush(struct intel_ring_buffer *ring, intel_ring_emit(ring, 0); intel_ring_advance(ring); - if (flush_domains) + if (!invalidate_domains && flush_domains) return gen7_ring_fbc_flush(ring, FBC_REND_NUKE); return 0; @@ -1837,7 +1837,7 @@ static int gen6_ring_flush(struct intel_ring_buffer *ring, } intel_ring_advance(ring); - if (IS_GEN7(dev) && flush) + if (IS_GEN7(dev) && !invalidate && flush) return gen7_ring_fbc_flush(ring, FBC_REND_CACHE_CLEAN); return 0; -- 1.8.1.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 06/10] drm/i915: Implement LRI based FBC tracking
From: Ville Syrjälä
As per the SNB and HSW PM guides, we should enable FBC render/blitter
tracking only during batches targetting the front buffer.
On SNB we must also update the FBC render tracking address whenever it
changes. And since the register in question is stored in the context,
we need to make sure we reload it with correct data after context
switches.
On IVB/HSW we use the render nuke mechanism, so no render tracking
address updates are needed. Hoever on the blitter side we need to
enable the blitter tracking like on SNB, and in addition we need
to issue the cache clean messages, which we already did.
v2: Introduce intel_fb_obj_has_fbc()
Fix crtc locking around crtc->fb access
Drop a hunk that was included by accident in v1
Set fbc_address_dirty=false not true after emitting the LRI
v3: Now that fbc hangs on to the fb intel_fb_obj_has_fbc() doesn't
need to upset lockdep anymore
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_gem_context.c| 7
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 31
drivers/gpu/drm/i915/intel_display.c | 17 +++--
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.c| 58 +-
drivers/gpu/drm/i915/intel_ringbuffer.h| 2 ++
6 files changed, 113 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 72a3df3..d438ea1 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -404,6 +404,13 @@ mi_set_context(struct intel_ring_buffer *ring,
intel_ring_advance(ring);
+ /*
+* FBC RT address is stored in the context, so we may have just
+* restored it to an old value. Make sure we emit a new LRI
+* to update the address.
+*/
+ ring->fbc_address_dirty = true;
+
return ret;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 885d595..db25158 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -886,6 +886,35 @@ validate_exec_list(struct drm_i915_gem_exec_object2 *exec,
}
static void
+i915_gem_execbuffer_mark_fbc_dirty(struct intel_ring_buffer *ring,
+ struct list_head *vmas)
+{
+ struct i915_vma *vma;
+ struct drm_i915_gem_object *fbc_obj = NULL;
+ u32 fbc_address = -1;
+
+ list_for_each_entry(vma, vmas, exec_list) {
+ struct drm_i915_gem_object *obj = vma->obj;
+
+ if (obj->base.pending_write_domain &&
+ intel_fb_obj_has_fbc(obj)) {
+ WARN_ON(fbc_obj && fbc_obj != obj);
+ fbc_obj = obj;
+ }
+ }
+
+ if (fbc_obj)
+ fbc_address = i915_gem_obj_ggtt_offset(fbc_obj);
+
+ /* need to nuke/cache_clean on IVB+? */
+ ring->fbc_dirty = fbc_obj != NULL;
+
+ /* need to update FBC tracking? */
+ ring->fbc_address_dirty = fbc_address != ring->fbc_address;
+ ring->fbc_address = fbc_address;
+}
+
+static void
i915_gem_execbuffer_move_to_active(struct list_head *vmas,
struct intel_ring_buffer *ring)
{
@@ -1150,6 +1179,8 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
if (flags & I915_DISPATCH_SECURE && !batch_obj->has_global_gtt_mapping)
i915_gem_gtt_bind_object(batch_obj, batch_obj->cache_level);
+ i915_gem_execbuffer_mark_fbc_dirty(ring, &eb->vmas);
+
ret = i915_gem_execbuffer_move_to_gpu(ring, &eb->vmas);
if (ret)
goto err;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index bce6e07..c29e9d4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8074,6 +8074,21 @@ void intel_mark_idle(struct drm_device *dev)
gen6_rps_idle(dev->dev_private);
}
+bool intel_fb_obj_has_fbc(struct drm_i915_gem_object *obj)
+{
+ struct drm_device *dev = obj->base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ /* check for potential scanout */
+ if (!obj->pin_display)
+ return false;
+
+ if (!dev_priv->fbc.fb)
+ return false;
+
+ return to_intel_framebuffer(dev_priv->fbc.fb)->obj == obj;
+}
+
void intel_mark_fb_busy(struct drm_i915_gem_object *obj,
struct intel_ring_buffer *ring)
{
@@ -8091,8 +8106,6 @@ void intel_mark_fb_busy(struct drm_i915_gem_object *obj,
continue;
intel_increase_pllclock(crtc);
- if (ring && intel_fbc_enabled(dev))
- ring->fbc_dirty = true;
}
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 6d701
[Intel-gfx] [PATCH v2 08/10] drm/i915: Don't write ILK/IVB_FBC_RT_BASE directly
From: Ville Syrjälä We use LRIs to enable/disable the render tracking as needed. So leave ILK_FBC_RT_BASE alone when enabling FBC on SNB. While at it, kill the IVB_FBC_RT_BASE completely since we don't use render tracking on IVB+. TODO: Make ILK use the LRI mechanism too? v2: Drop the IVB_FBC_RT_BASE write too Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_pm.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 3f600ba..4f5293e7 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -212,7 +212,8 @@ static void ironlake_enable_fbc(struct drm_crtc *crtc, (stall_watermark << DPFC_RECOMP_STALL_WM_SHIFT) | (interval << DPFC_RECOMP_TIMER_COUNT_SHIFT)); I915_WRITE(ILK_DPFC_FENCE_YOFF, crtc->y); - I915_WRITE(ILK_FBC_RT_BASE, i915_gem_obj_ggtt_offset(obj) | ILK_FBC_RT_VALID); + if (IS_GEN5(dev)) + I915_WRITE(ILK_FBC_RT_BASE, i915_gem_obj_ggtt_offset(obj) | ILK_FBC_RT_VALID); /* enable it... */ I915_WRITE(ILK_DPFC_CONTROL, dpfc_ctl | DPFC_CTL_EN); @@ -257,8 +258,6 @@ static void gen7_enable_fbc(struct drm_crtc *crtc, struct drm_i915_gem_object *obj = intel_fb->obj; struct intel_crtc *intel_crtc = to_intel_crtc(crtc); - I915_WRITE(IVB_FBC_RT_BASE, i915_gem_obj_ggtt_offset(obj)); - I915_WRITE(ILK_DPFC_CONTROL, DPFC_CTL_EN | DPFC_CTL_LIMIT_1X | IVB_DPFC_CTL_FENCE_EN | intel_crtc->plane << IVB_DPFC_CTL_PLANE_SHIFT); -- 1.8.1.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 07/10] drm/i915: Kill sandybridge_blit_fbc_update()
From: Ville Syrjälä
No longer needed since the LRIs do the work.
v2: Rebased due to hunk getting dropped from an ealier patch
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 23 ---
1 file changed, 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index dc65bb4..3f600ba 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -187,26 +187,6 @@ static bool g4x_fbc_enabled(struct drm_device *dev)
return I915_READ(DPFC_CONTROL) & DPFC_CTL_EN;
}
-static void sandybridge_blit_fbc_update(struct drm_device *dev)
-{
- struct drm_i915_private *dev_priv = dev->dev_private;
- u32 blt_ecoskpd;
-
- /* Make sure blitter notifies FBC of writes */
- gen6_gt_force_wake_get(dev_priv);
- blt_ecoskpd = I915_READ(GEN6_BLITTER_ECOSKPD);
- blt_ecoskpd |= GEN6_BLITTER_FBC_NOTIFY <<
- GEN6_BLITTER_LOCK_SHIFT;
- I915_WRITE(GEN6_BLITTER_ECOSKPD, blt_ecoskpd);
- blt_ecoskpd |= GEN6_BLITTER_FBC_NOTIFY;
- I915_WRITE(GEN6_BLITTER_ECOSKPD, blt_ecoskpd);
- blt_ecoskpd &= ~(GEN6_BLITTER_FBC_NOTIFY <<
-GEN6_BLITTER_LOCK_SHIFT);
- I915_WRITE(GEN6_BLITTER_ECOSKPD, blt_ecoskpd);
- POSTING_READ(GEN6_BLITTER_ECOSKPD);
- gen6_gt_force_wake_put(dev_priv);
-}
-
static void ironlake_enable_fbc(struct drm_crtc *crtc,
struct drm_framebuffer *fb,
unsigned long interval)
@@ -240,7 +220,6 @@ static void ironlake_enable_fbc(struct drm_crtc *crtc,
I915_WRITE(SNB_DPFC_CTL_SA,
SNB_CPU_FENCE_ENABLE | obj->fence_reg);
I915_WRITE(DPFC_CPU_FENCE_OFFSET, crtc->y);
- sandybridge_blit_fbc_update(dev);
}
DRM_DEBUG_KMS("enabled fbc on plane %c\n",
plane_name(intel_crtc->plane));
@@ -297,8 +276,6 @@ static void gen7_enable_fbc(struct drm_crtc *crtc,
SNB_CPU_FENCE_ENABLE | obj->fence_reg);
I915_WRITE(DPFC_CPU_FENCE_OFFSET, crtc->y);
- sandybridge_blit_fbc_update(dev);
-
DRM_DEBUG_KMS("enabled fbc on plane %d\n", intel_crtc->plane);
}
--
1.8.1.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/10] drm/i915: Set has_fbc=true for all SNB+, except VLV
From: Ville Syrjälä
At least since SNB (perhaps even earlier) even the desktop parts
should have FBC.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index c0ab5d4..9b8c9bf 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -265,6 +265,7 @@ static const struct intel_device_info intel_ironlake_m_info
= {
static const struct intel_device_info intel_sandybridge_d_info = {
.gen = 6, .num_pipes = 2,
.need_gfx_hws = 1, .has_hotplug = 1,
+ .has_fbc = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING,
.has_llc = 1,
};
@@ -280,6 +281,7 @@ static const struct intel_device_info
intel_sandybridge_m_info = {
#define GEN7_FEATURES \
.gen = 7, .num_pipes = 3, \
.need_gfx_hws = 1, .has_hotplug = 1, \
+ .has_fbc = 1, \
.ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
.has_llc = 1
@@ -292,7 +294,6 @@ static const struct intel_device_info
intel_ivybridge_m_info = {
GEN7_FEATURES,
.is_ivybridge = 1,
.is_mobile = 1,
- .has_fbc = 1,
};
static const struct intel_device_info intel_ivybridge_q_info = {
@@ -307,6 +308,7 @@ static const struct intel_device_info
intel_valleyview_m_info = {
.num_pipes = 2,
.is_valleyview = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
+ .has_fbc = 0, /* legal, last one wins */
.has_llc = 0, /* legal, last one wins */
};
@@ -315,6 +317,7 @@ static const struct intel_device_info
intel_valleyview_d_info = {
.num_pipes = 2,
.is_valleyview = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
+ .has_fbc = 0, /* legal, last one wins */
.has_llc = 0, /* legal, last one wins */
};
@@ -332,7 +335,6 @@ static const struct intel_device_info intel_haswell_m_info
= {
.is_mobile = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
- .has_fbc = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
};
--
1.8.1.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/10] drm/i915: Use plane_name() in gen7_enable_fbc()
From: Ville Syrjälä
All the other .enable_fbc() funcs use plane_name(). Make
gen7_enable_fbc() do the same.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 4f5293e7..48f6eda 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -275,7 +275,7 @@ static void gen7_enable_fbc(struct drm_crtc *crtc,
SNB_CPU_FENCE_ENABLE | obj->fence_reg);
I915_WRITE(DPFC_CPU_FENCE_OFFSET, crtc->y);
- DRM_DEBUG_KMS("enabled fbc on plane %d\n", intel_crtc->plane);
+ DRM_DEBUG_KMS("enabled fbc on plane %c\n",
plane_name(intel_crtc->plane));
}
bool intel_fbc_enabled(struct drm_device *dev)
--
1.8.1.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] intel/bdw: Update MI_BATCH_BUFFER_START for aub dumps
Ben Widawsky writes: > From: Damien Lespiau > > The command now takes a 48bits address and is thus 1 byte longer. I think you mean "1 dword" Other than that, patches 2-5 are Reviewed-by: Eric Anholt (patch 1, I don't know anything about the set of PCI IDs so I've skipped it). pgpQrR6AoDlrj.pgp Description: PGP signature ___ 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/vlv: Rename VLV DPIO register to be more structure to match configdb document.
On 11/06 14:02, Ville Syrjälä wrote: > > -#define _DPIO_IREF_CTL_A 0x8040 > > -#define _DPIO_IREF_CTL_B 0x8060 > > -#define DPIO_IREF_CTL(pipe) _PIPE(pipe, _DPIO_IREF_CTL_A, _DPIO_IREF_CTL_B) > > +#define _VLV_PLL_DW10_CH0 0x8040 > > +#define _VLV_PLL_DW10_CH1 0x8060 > > +#define VLV_PLL_DW10(ch) _PIPE(ch, _VLV_PLL_DW10_CH0, _VLV_PLL_DW10_CH1) > > Configdb starts counting from DW8 at 0x8040/60, which kind of make sense > since the first PLL block ends at DW7. > The spreadsheet I refer to is using DW10. The spreadsheet might be incorrect. Looking at the register offset, it won't be anymore space left after first PLL block. Make sense for DW8 for second PLL block. > > > > -#define DPIO_IREF_BCAST0xc044 > > -#define _DPIO_IREF_A 0x8044 > > -#define _DPIO_IREF_B 0x8064 > > -#define DPIO_IREF(pipe) _PIPE(pipe, _DPIO_IREF_A, _DPIO_IREF_B) > > +#define VLV_PLL_DW11_BCAST 0xc044 > > +#define _VLV_PLL_DW11_CH0 0x8044 > > +#define _VLV_PLL_DW11_CH1 0x8064 > > +#define VLV_PLL_DW11(ch) _PIPE(ch, _VLV_PLL_DW11_CH0, _VLV_PLL_DW11_CH1) > > ... which would make this DW9 > > > > > -#define _DPIO_PLL_CML_A0x804c > > -#define _DPIO_PLL_CML_B0x806c > > -#define DPIO_PLL_CML(pipe) _PIPE(pipe, _DPIO_PLL_CML_A, _DPIO_PLL_CML_B) > > +#define _VLV_PLL_DW13_CH0 0x804c > > +#define _VLV_PLL_DW13_CH1 0x806c > > +#define VLV_PLL_DW13(ch) _PIPE(ch, _VLV_PLL_DW13_CH0, _VLV_PLL_DW13_CH1) > jj > ... DW11 > > > > > -#define _DPIO_LPF_COEFF_A 0x8048 > > -#define _DPIO_LPF_COEFF_B 0x8068 > > -#define DPIO_LPF_COEFF(pipe) _PIPE(pipe, _DPIO_LPF_COEFF_A, > > _DPIO_LPF_COEFF_B) > > +#define _VLV_PLL_DW12_CH0 0x8048 > > +#define _VLV_PLL_DW12_CH1 0x8068 > > +#define VLV_PLL_DW12(ch) _PIPE(ch, _VLV_PLL_DW12_CH0, _VLV_PLL_DW12_CH1) > > ... DW10 > > Maybe also reorder this with the previous one to keep the PLL > register defiens in numerical order. > > > > > -#define DPIO_CALIBRATION 0x80ac > > +#define VLV_REF_DW11 0x80ac > > And this is DW13 in configdb. So in the ref block it starts counting from > DW10 for some reason. Yay for consistency. Going to add a comment for the DW to start counting. The spreadsheet I am using start counting at DW8. :( > > The rest looks good to me. I double checked the cpp output to make sure > that the actual changes were limited to i915_debugfs.c. > > > > > -#define DPIO_FASTCLK_DISABLE 0x8100 > > +#define VLV_CMN_DW00x8100 > > > > /* > > * Per DDI channel DPIO regs > > */ > > > > -#define _DPIO_PCS_TX_0 0x8200 > > -#define _DPIO_PCS_TX_1 0x8400 > > +#define _VLV_PCS_DW0_CH0 0x8200 > > +#define _VLV_PCS_DW0_CH1 0x8400 > > #define DPIO_PCS_TX_LANE2_RESET (1<<16) > > #define DPIO_PCS_TX_LANE1_RESET (1<<7) > > -#define DPIO_PCS_TX(port) _PORT(port, _DPIO_PCS_TX_0, _DPIO_PCS_TX_1) > > +#define VLV_PCS_DW0(ch) _PORT(ch, _VLV_PCS_DW0_CH0, _VLV_PCS_DW0_CH1) > > > > -#define _DPIO_PCS_CLK_00x8204 > > -#define _DPIO_PCS_CLK_10x8404 > > +#define _VLV_PCS_DW1_CH0 0x8204 > > +#define _VLV_PCS_DW1_CH1 0x8404 > > #define DPIO_PCS_CLK_CRI_RXEB_EIOS_EN(1<<22) > > #define DPIO_PCS_CLK_CRI_RXDIGFILTSG_EN (1<<21) > > #define DPIO_PCS_CLK_DATAWIDTH_SHIFT (6) > > #define DPIO_PCS_CLK_SOFT_RESET (1<<5) > > -#define DPIO_PCS_CLK(port) _PORT(port, _DPIO_PCS_CLK_0, _DPIO_PCS_CLK_1) > > - > > -#define _DPIO_PCS_CTL_OVR1_A 0x8224 > > -#define _DPIO_PCS_CTL_OVR1_B 0x8424 > > -#define DPIO_PCS_CTL_OVER1(port) _PORT(port, _DPIO_PCS_CTL_OVR1_A, \ > > - _DPIO_PCS_CTL_OVR1_B) > > - > > -#define _DPIO_PCS_STAGGER0_A 0x822c > > -#define _DPIO_PCS_STAGGER0_B 0x842c > > -#define DPIO_PCS_STAGGER0(port) _PORT(port, _DPIO_PCS_STAGGER0_A, \ > > - _DPIO_PCS_STAGGER0_B) > > - > > -#define _DPIO_PCS_STAGGER1_A 0x8230 > > -#define _DPIO_PCS_STAGGER1_B 0x8430 > > -#define DPIO_PCS_STAGGER1(port) _PORT(port, _DPIO_PCS_STAGGER1_A, \ > > - _DPIO_PCS_STAGGER1_B) > > - > > -#define _DPIO_PCS_CLOCKBUF0_A 0x8238 > > -#define _DPIO_PCS_CLOCKBUF0_B 0x8438 > > -#define DPIO_PCS_CLOCKBUF0(port) _PORT(port, _DPIO_PCS_CLOCKBUF0_A, \ > > - _DPIO_PCS_CLOCKBUF0_B) > > - > > -#define _DPIO_PCS_CLOCKBUF8_A 0x825c > > -#define _DPIO_PCS_CLOCKBUF8_B 0x845c > > -#define DPIO_PCS_CLOCKBUF8(port) _PORT(port, _DPIO_PCS_CLOCKBUF8_A, \ > > - _DPIO_PCS_CLOCKBUF8_B) > > - > > -#define _DPIO_TX_SWING_CTL2_
[Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_panel.c between commit 5bdebb183c97
("drm/sysfs: sort out minor and connector device object lifetimes") from
the drm tree and commit 752aa88a1e78 ("drm/i915: make backlight functions
take a connector") from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/intel_panel.c
index 09b2994c9b37,cad41ac330e8..
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@@ -726,7 -802,8 +802,8 @@@ int intel_panel_setup_backlight(struct
}
dev_priv->backlight.device =
backlight_device_register("intel_backlight",
- connector->kdev, dev,
-&connector->kdev,
++connector->kdev,
+ to_intel_connector(connector),
&intel_panel_bl_ops, &props);
if (IS_ERR(dev_priv->backlight.device)) {
pgpIn6m6y_Wsu.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
