Re: [Intel-gfx] [PATCH v2 5/7] drm/i915: Move intel_dp->lane_count into pipe_config
Reviewed-by: Sivakumar Thulasimani
On Monday 06 July 2015 07:09 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Currently we clobber intel_dp->lane_count in compute config, which means
after a rejected modeset we may no longer be able to retrain the current
link. Move lane_count into pipe_config to avoid that.
v2: Add missing ':' to the pipe config debug dump
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 3 ++
drivers/gpu/drm/i915/intel_ddi.c | 10 +++---
drivers/gpu/drm/i915/intel_display.c | 7 +++--
drivers/gpu/drm/i915/intel_dp.c | 60
drivers/gpu/drm/i915/intel_dp_mst.c | 6 +++-
drivers/gpu/drm/i915/intel_drv.h | 3 +-
6 files changed, 61 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d5c794a..f5dc75c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4096,6 +4096,7 @@ enum skl_disp_power_wells {
/* How many wires to use. I guess 3 was too hard */
#define DP_PORT_WIDTH(width)(((width) - 1) << 19)
#define DP_PORT_WIDTH_MASK (7 << 19)
+#define DP_PORT_WIDTH_SHIFT 19
/* Mystic DPCD version 1.1 special mode */
#define DP_ENHANCED_FRAMING (1 << 18)
@@ -7128,6 +7129,8 @@ enum skl_disp_power_wells {
#define DDI_BUF_IS_IDLE (1<<7)
#define DDI_A_4_LANES(1<<4)
#define DDI_PORT_WIDTH(width)(((width) - 1) << 1)
+#define DDI_PORT_WIDTH_MASK (7 << 1)
+#define DDI_PORT_WIDTH_SHIFT 1
#define DDI_INIT_DISPLAY_DETECTED(1<<0)
/* DDI Buffer Translations */
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 96fb472..8df596d 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -723,11 +723,11 @@ void intel_ddi_init_dp_buf_reg(struct intel_encoder
*encoder)
struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
struct intel_digital_port *intel_dig_port =
enc_to_dig_port(&encoder->base);
+ struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
intel_dp->DP = intel_dig_port->saved_port_bits |
DDI_BUF_CTL_ENABLE | DDI_BUF_TRANS_SELECT(0);
- intel_dp->DP |= DDI_PORT_WIDTH(intel_dp->lane_count);
-
+ intel_dp->DP |= DDI_PORT_WIDTH(crtc->config->lane_count);
}
static struct intel_encoder *
@@ -1913,7 +1913,7 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc
*crtc)
} else
temp |= TRANS_DDI_MODE_SELECT_DP_SST;
- temp |= DDI_PORT_WIDTH(intel_dp->lane_count);
+ temp |= DDI_PORT_WIDTH(intel_crtc->config->lane_count);
} else if (type == INTEL_OUTPUT_DP_MST) {
struct intel_dp *intel_dp = &enc_to_mst(encoder)->primary->dp;
@@ -1922,7 +1922,7 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc *crtc)
} else
temp |= TRANS_DDI_MODE_SELECT_DP_SST;
- temp |= DDI_PORT_WIDTH(intel_dp->lane_count);
+ temp |= DDI_PORT_WIDTH(intel_crtc->config->lane_count);
} else {
WARN(1, "Invalid encoder type %d for pipe %c\n",
intel_encoder->type, pipe_name(pipe));
@@ -3072,6 +3072,8 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
case TRANS_DDI_MODE_SELECT_DP_SST:
case TRANS_DDI_MODE_SELECT_DP_MST:
pipe_config->has_dp_encoder = true;
+ pipe_config->lane_count =
+ ((temp & DDI_PORT_WIDTH_MASK) >> DDI_PORT_WIDTH_SHIFT)
+ 1;
intel_dp_get_m_n(intel_crtc, pipe_config);
break;
default:
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 136b533..d56973f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11981,14 +11981,16 @@ static void intel_dump_pipe_config(struct intel_crtc
*crtc,
pipe_config->fdi_m_n.gmch_m, pipe_config->fdi_m_n.gmch_n,
pipe_config->fdi_m_n.link_m, pipe_config->fdi_m_n.link_n,
pipe_config->fdi_m_n.tu);
- DRM_DEBUG_KMS("dp: %i, gmch_m: %u, gmch_n: %u, link_m: %u, link_n: %u, tu:
%u\n",
+ DRM_DEBUG_KMS("dp: %i, lanes: %i, gmch_m: %u, gmch_n: %u, link_m: %u,
link_n: %u, tu: %u\n",
pipe_config->has_dp_encoder,
+ pipe_config->lane_count,
pipe_config->dp_m_n.gmch_m, pipe_config->dp_m_n.gmch_n,
pipe_config->dp_m_n.link_m, pipe_config->dp_m_n.link_n,
pipe_config->dp_m_n.tu);
- DRM_DEBUG_KMS("dp: %i, gmch_m2: %u, gmch_n2: %u, link_m2: %u, link_n2: %u, tu2: %u\n",
+ DRM_DEB
Re: [Intel-gfx] [PATCH 3/7] prime_mmap: Add basic tests to write in a bo using CPU
On Wed, Aug 12, 2015 at 08:29:16PM -0300, Tiago Vignatti wrote:
> This patch adds test_correct_cpu_write, which maps the texture buffer through
> a
> prime fd and then writes directly to it using the CPU. It stresses the driver
> to guarantee cache synchronization among the different domains.
>
> This test also adds test_forked_cpu_write, which creates the GEM bo in one
> process and pass the prime handle of the it to another process, which in turn
> uses the handle only to map and write. Grossly speaking this test simulates
> Chrome OS architecture, where the Web content ("unpriviledged process") maps
> and CPU-draws a buffer, which was previously allocated in the GPU process
> ("priviledged process").
>
> This requires kernel modifications (Daniel Thompson's "drm: prime: Honour
> O_RDWR during prime-handle-to-fd").
>
> Signed-off-by: Tiago Vignatti
Squash with previous patch?
> ---
> lib/ioctl_wrappers.c | 5 +++-
> tests/prime_mmap.c | 65
>
> 2 files changed, 69 insertions(+), 1 deletion(-)
>
> diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
> index 53bd635..941fa66 100644
> --- a/lib/ioctl_wrappers.c
> +++ b/lib/ioctl_wrappers.c
> @@ -1125,6 +1125,9 @@ void gem_require_ring(int fd, int ring_id)
>
> /* prime */
>
> +#ifndef DRM_RDWR
> +#define DRM_RDWR O_RDWR
> +#endif
> /**
> * prime_handle_to_fd:
> * @fd: open i915 drm file descriptor
> @@ -1142,7 +1145,7 @@ int prime_handle_to_fd(int fd, uint32_t handle)
>
> memset(&args, 0, sizeof(args));
> args.handle = handle;
> - args.flags = DRM_CLOEXEC;
> + args.flags = DRM_CLOEXEC | DRM_RDWR;
This needs to be optional otherwise all the existing prime tests start
falling over on older kernels. Probably need a
prime_handle_to_fd_with_mmap, which doesn an igt_skip if it fails.
-Daniel
> args.fd = -1;
>
> do_ioctl(fd, DRM_IOCTL_PRIME_HANDLE_TO_FD, &args);
> diff --git a/tests/prime_mmap.c b/tests/prime_mmap.c
> index dc59e8f..ad91371 100644
> --- a/tests/prime_mmap.c
> +++ b/tests/prime_mmap.c
> @@ -22,6 +22,7 @@
> *
> * Authors:
> *Rob Bradford
> + *Tiago Vignatti
> *
> */
>
> @@ -66,6 +67,12 @@ fill_bo(uint32_t handle, size_t size)
> }
>
> static void
> +fill_bo_cpu(char *ptr)
> +{
> + memcpy(ptr, pattern, sizeof(pattern));
> +}
> +
> +static void
> test_correct(void)
> {
> int dma_buf_fd;
> @@ -180,6 +187,62 @@ test_forked(void)
> gem_close(fd, handle);
> }
>
> +/* test CPU write. This has a rather big implication for the driver which
> must
> + * guarantee cache synchronization when writing the bo using CPU. */
> +static void
> +test_correct_cpu_write(void)
> +{
> + int dma_buf_fd;
> + char *ptr;
> + uint32_t handle;
> +
> + handle = gem_create(fd, BO_SIZE);
> +
> + dma_buf_fd = prime_handle_to_fd(fd, handle);
> + igt_assert(errno == 0);
> +
> + /* Check correctness of map using write protection (PROT_WRITE) */
> + ptr = mmap(NULL, BO_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED,
> dma_buf_fd, 0);
> + igt_assert(ptr != MAP_FAILED);
> +
> + /* Fill bo using CPU */
> + fill_bo_cpu(ptr);
> +
> + /* Check pattern correctness */
> + igt_assert(memcmp(ptr, pattern, sizeof(pattern)) == 0);
> +
> + munmap(ptr, BO_SIZE);
> + close(dma_buf_fd);
> + gem_close(fd, handle);
> +}
> +
> +/* map from another process and then write using CPU */
> +static void
> +test_forked_cpu_write(void)
> +{
> + int dma_buf_fd;
> + char *ptr;
> + uint32_t handle;
> +
> + handle = gem_create(fd, BO_SIZE);
> +
> + dma_buf_fd = prime_handle_to_fd(fd, handle);
> + igt_assert(errno == 0);
> +
> + igt_fork(childno, 1) {
> + ptr = mmap(NULL, BO_SIZE, PROT_READ | PROT_WRITE , MAP_SHARED,
> dma_buf_fd, 0);
> + igt_assert(ptr != MAP_FAILED);
> + fill_bo_cpu(ptr);
> +
> + igt_assert(memcmp(ptr, pattern, sizeof(pattern)) == 0);
> + munmap(ptr, BO_SIZE);
> + close(dma_buf_fd);
> + }
> + close(dma_buf_fd);
> + igt_waitchildren();
> + gem_close(fd, handle);
> +}
> +
> static void
> test_refcounting(void)
> {
> @@ -346,6 +409,8 @@ igt_main
> { "test_map_unmap", test_map_unmap },
> { "test_reprime", test_reprime },
> { "test_forked", test_forked },
> + { "test_correct_cpu_write", test_correct_cpu_write },
> + { "test_forked_cpu_write", test_forked_cpu_write },
> { "test_refcounting", test_refcounting },
> { "test_dup", test_dup },
> { "test_errors", test_errors },
> --
> 2.1.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
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] prime_mmap: Add new test for calling mmap() on dma-buf fds
On Wed, Aug 12, 2015 at 08:29:14PM -0300, Tiago Vignatti wrote:
> From: Rob Bradford
>
> This test has the following subtests:
> - test_correct for correctness of the data
> - test_map_unmap checks for mapping idempotency
> - test_reprime checks for dma-buf creation idempotency
> - test_forked checks for multiprocess access
> - test_refcounting checks for buffer reference counting
> - test_dup chats that dup()ing the fd works
> - test_errors checks the error return values for failures
> - test_aperture_limit tests multiple buffer creation at the gtt aperture
>limit
>
> Signed-off-by: Rob Bradford
> Signed-off-by: Tiago Vignatti
> ---
> tests/Makefile.sources | 1 +
> tests/prime_mmap.c | 383
> +
> 2 files changed, 384 insertions(+)
> create mode 100644 tests/prime_mmap.c
>
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index c94714b..5b2072e 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -90,6 +90,7 @@ TESTS_progs_M = \
> pm_rps \
> pm_rc6_residency \
> pm_sseu \
> + prime_mmap \
> prime_self_import \
> template \
> $(NULL)
> diff --git a/tests/prime_mmap.c b/tests/prime_mmap.c
> new file mode 100644
> index 000..4dc2055
> --- /dev/null
> +++ b/tests/prime_mmap.c
> @@ -0,0 +1,383 @@
> +/*
> + * Copyright © 2014 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:
> + *Rob Bradford
> + *
> + */
> +
> +/*
> + * Testcase: Check whether mmap()ing dma-buf works
> + */
> +#define _GNU_SOURCE
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "drm.h"
> +#include "i915_drm.h"
> +#include "drmtest.h"
> +#include "igt_debugfs.h"
> +#include "ioctl_wrappers.h"
> +
> +#define BO_SIZE (16*1024)
> +
> +static int fd;
> +
> +char pattern[] = {0xff, 0x00, 0x00, 0x00,
> + 0x00, 0xff, 0x00, 0x00,
> + 0x00, 0x00, 0xff, 0x00,
> + 0x00, 0x00, 0x00, 0xff};
> +
> +static void
> +fill_bo(uint32_t handle, size_t size)
> +{
> + off_t i;
> + for (i = 0; i < size; i+=sizeof(pattern))
> + {
> + gem_write(fd, handle, i, pattern, sizeof(pattern));
> + }
> +}
> +
> +static int
> +pattern_check(char *ptr, size_t size)
> +{
> + off_t i;
> + for (i = 0; i < size; i+=sizeof(pattern))
> + {
> + if (memcmp(ptr, pattern, sizeof(pattern)) != 0)
> + return 1;
> + }
> +
> + return 0;
> +}
> +
> +static void
> +test_correct(void)
> +{
> + int dma_buf_fd;
> + char *ptr1, *ptr2;
> + uint32_t handle;
> +
> + handle = gem_create(fd, BO_SIZE);
> + fill_bo(handle, BO_SIZE);
> +
> + dma_buf_fd = prime_handle_to_fd(fd, handle);
> + igt_assert(errno == 0);
> +
> + /* Check correctness vs GEM_MMAP_GTT */
> + ptr1 = gem_mmap(fd, handle, BO_SIZE, PROT_READ | PROT_WRITE);
> + ptr2 = mmap(NULL, BO_SIZE, PROT_READ, MAP_SHARED, dma_buf_fd, 0);
> + igt_assert(ptr1 != MAP_FAILED);
> + igt_assert(ptr2 != MAP_FAILED);
> + igt_assert(memcmp(ptr1, ptr2, BO_SIZE) == 0);
> +
> + /* Check pattern correctness */
> + igt_assert(pattern_check(ptr2, BO_SIZE) == 0);
> +
> + munmap(ptr1, BO_SIZE);
> + munmap(ptr2, BO_SIZE);
> + close(dma_buf_fd);
> + gem_close(fd, handle);
> +}
> +
> +static void
> +test_map_unmap(void)
> +{
> + int dma_buf_fd;
> + char *ptr;
> + uint32_t handle;
> +
> + handle = gem_create(fd, BO_SIZE);
> + fill_bo(handle, BO_SIZE);
> +
> + dma_buf_fd = prime_handle_to_fd(fd, handle);
> + igt_assert(errno == 0);
> +
> + ptr = mmap(NULL, BO_SIZE, PROT_READ, MAP_SHARED, dma_buf_fd, 0);
> + igt_assert(ptr != MAP_FAILED);
> + igt_assert(pattern_check(ptr, BO_SIZE) ==
Re: [Intel-gfx] [PATCH] lib/rendercopy_gen9: Setup Push constant pointer before sending BTP commands
Hi, On ke, 2015-08-12 at 18:35 -0700, Ben Widawsky wrote: > On Wed, Aug 12, 2015 at 03:10:18PM +0300, Joonas Lahtinen wrote: > > On ke, 2015-08-12 at 12:26 +0100, Arun Siluvery wrote: > > > From Gen9, by default push constant command is not committed to > > > the > > > shader unit > > > untill the corresponding shader's BTP_* command is parsed. This > > > is > > > the > > > behaviour when set shader is enabled. This patch updates the > > > batch to > > > follow > > > this requirement otherwise it results in gpu hang. > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89959 > > > > > > Set shader need to be disabled if legacy behaviour is required. > > > > > > Cc: Ben Widawsky > > > Cc: Joonas Lahtinen > > > Cc: Mika Kuoppala > > > Signed-off-by: Arun Siluvery > > > > Reviewed-by: Joonas Lahtinen > > > > Repeating what I said on the mesa thread: > Does anyone understand why this actually causes a hang on the IGT > test? I > certainly don't. The docs are pretty clear that the constant command > is not > committed until the BTP command, but I can't make any sense of how it > related to > a GPU hang. > Changing the order makes the hang go away and come back for sure, we've all been experiencing that. System validation said it is a programming restriction, so I'm not sure how relevant it is what goes wrong if it's not followed. And the legacy mode bits were added to support the old behavior of having the order like it has been previously, so I do not see why question it without visibility to the actual RTL. And enabling the legacy bits makes the hang go away, too. If I had the RTL sources, then it would be more relevant to take educated guesses as to why a set of hundreds of thousands of transistors doesn't work as it should :) Without that, if it gets stuck, it gets stuck. Regards, Joonas > [snip] > > --- > Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] topic/drm-misc
Hi Dave, Final drm-misc pull for 4.3: - fbdev emulation Kconfig option for everyone thanks to Archit. It's not everything yet bit this is fairly tricky since it spawns all drivers. - vgaarb & vgaswitcheroo polish from Thierry - some drm_irq.c cleanups (Thierry) - struct_mutex crusade from me - more fbdev panic handling removal - various things all over in drm core&helpers Note that this pull is relative to my earlier drm-misc pull that's still outstanding, so please take them both. Eric, this contains the patch to make encoder->mode_fixup optional I talked about in my vc4 review. You can base vc4 on this tag here, it'll stay stable. Cheers, Daniel The following changes since commit 8c10342cb48f3140d9abeadcfd2fa6625d447282: drm/atomic: Update legacy DPMS state during modesets, v3. (2015-07-27 16:23:29 +0200) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2015-08-13 for you to fetch changes up to d4853630b334017cab9a4602f5e9677e3b792c8a: drm/atomic: Use KMS VBLANK API (2015-08-12 17:41:30 +0200) Archit Taneja (25): drm/fb_helper: Add drm_fb_helper functions to manage fb_info creation drm/fb_helper: Create a wrapper for unlink_framebuffer drm/fb_helper: Create wrappers for fb_sys_read/write funcs drm/fb_helper: Create wrappers for blit, copyarea and fillrect funcs drm/fb_helper: Create a wrapper for fb_set_suspend drm/rockchip: Use new drm_fb_helper functions drm/armada: Use new drm_fb_helper functions drm/ast: Use new drm_fb_helper functions drm/tegra: Use new drm_fb_helper functions drm/msm: Use new drm_fb_helper functions drm/exynos: Use new drm_fb_helper functions drm/gma500: Use new drm_fb_helper functions drm/qxl: Use new drm_fb_helper functions drm/udl: Use new drm_fb_helper functions drm/fb_cma_helper: Use new drm_fb_helper functions drm/cirrus: Use new drm_fb_helper functions drm/omap: Use new drm_fb_helper functions drm/mgag200: Use new drm_fb_helper functions drm/radeon: Use new drm_fb_helper functions drm/i915: Use new drm_fb_helper functions drm/nouveau: Use new drm_fb_helper functions drm/bochs: Use new drm_fb_helper functions drm/amdgpu: Use new drm_fb_helper functions drm/virtio: Use new drm_fb_helper functions drm: Add top level Kconfig option for DRM fbdev emulation Daniel Vetter (19): drm/omap: Fixup compile fail drm/fbdev: Return -EBUSY when oopsing drm/fb-helper: Stop using trylocks in force_restore drm: Remove __drm_modeset_lock_all drm: Fixup locking WARNINGs in drm_mode_config_reset drm/gem: Be more friendly with locking checks drm/ast: Don't grab dev->struct_mutex for in mmap offset ioctl drm/bochs: Don't grab dev->struct_mutex for in mmap offset ioctl drm/mga200g: Don't grab dev->struct_mutex for in mmap offset ioctl drm/mga200g: Hold a proper reference for cursor_set drm/cirrus: Don't grab dev->struct_mutex for in mmap offset ioctl drm/cma-helper: Don't grab dev->struct_mutex for in mmap offset ioctl drm/rockchip: Don't grab dev->struct_mutex for in mmap offset ioctl drm/nouveau: Don't take dev->struct_mutex in ttm_fini drm/qxl: Don't take dev->struct_mutex in bo_force_delete drm/edid: Use ARRAY_SIZE in drm_add_modes_noedid drm/atomic: Paper over locking WARN in default_state_clear drm/atomic: Call ww_acquire_done after check phase is complete drm/i915: Use CONFIG_DRM_FBDEV_EMULATION Geert Uytterhoeven (2): drm/fb-helper: Clarify drm_fb_helper_restore_fbdev_mode*() drm/fb-helper: Move drm_fb_helper_force_kernel_mode() inside #ifdef Inki Dae (1): drm/atomic: fix null pointer access to mode_fixup callback Maarten Lankhorst (1): drm/core: Set mode to NULL when connectors in a set drops to 0. Thierry Reding (16): drm: Remove two-level menu in Kconfig vgaarb: Stop complaining about absent devices vgaarb: Use vgaarb: prefix consistently in messages vgaarb: Fix a few checkpatch errors and warnings vga_switcheroo: Use pr_*() instead of printk() vga_switcheroo: Cleanup header comment vga_switcheroo: Use pr_fmt() vga_switcheroo: Wrap overly long lines vga_switcheroo: Remove unnecessary checks drm/plane: Use consistent data types for format count drm/plane: Remove redundant extern drm/irq: Remove negative CRTC index special-case drm/irq: Check for valid VBLANK before dereference drm/irq: Make pipe unsigned and name consistent drm/irq: Document return values more consistently drm/atomic: Use KMS VBLANK API Viresh Kumar (1): drivers: gpu: Drop unlikely before IS_ERR(_OR_NULL) drivers/gpu/drm/Kconfig | 20 ++ drivers/gpu/drm/Makefile
Re: [Intel-gfx] [PATCH v3 01/11] drm/i915: Store max dotclock
On Wed, 2015-08-12 at 22:01 +0300, Ville Syrjälä wrote:
> On Wed, Aug 12, 2015 at 08:30:23PM +0300, Ville Syrjälä wrote:
> > On Fri, Jul 31, 2015 at 03:13:50PM +0300, Mika Kahola wrote:
> > > Store max dotclock into dev_priv structure so we are able
> > > to filter out the modes that are not supported by our
> > > platforms.
> > >
> > > V2:
> > > - limit the max dot clock frequency to max CD clock frequency
> > > for the gen9 and above
> > > - limit the max dot clock frequency to 90% of the max CD clock
> > > frequency for the older gens
> > > - for Cherryview the max dot clock frequency is limited to 95%
> > > of the max CD clock frequency
> > > - for gen2 and gen3 the max dot clock limit is set to 90% of the
> > > 2X max CD clock frequency
> > >
> > > Signed-off-by: Mika Kahola
> > > ---
> > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > drivers/gpu/drm/i915/intel_display.c | 19 +++
> > > 2 files changed, 20 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 04aa34a..1f69211b 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -1777,6 +1777,7 @@ struct drm_i915_private {
> > > unsigned int fsb_freq, mem_freq, is_ddr3;
> > > unsigned int skl_boot_cdclk;
> > > unsigned int cdclk_freq, max_cdclk_freq;
> > > + unsigned int max_dotclk;
> >
> > nit: maybe max_dotclk_freq for extra consistentcy?
> >
> > > unsigned int hpll_freq;
> > >
> > > /**
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 43b0f17..c9c6d19 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -5259,6 +5259,23 @@ static void
> > > modeset_update_crtc_power_domains(struct drm_atomic_state *state)
> > > modeset_put_power_domains(dev_priv, put_domains[i]);
> > > }
> > >
> > > +static int intel_compute_max_dotclk(struct drm_i915_private *dev_priv)
> > > +{
> > > + int max_cdclk_freq = dev_priv->max_cdclk_freq;
> > > + int max_dotclk_freq;
> > > +
> > > + if (INTEL_INFO(dev_priv)->gen >= 9)
> > > + max_dotclk_freq = max_cdclk_freq;
> > > + else if (IS_CHERRYVIEW(dev_priv))
> > > + max_dotclk_freq = DIV_ROUND_UP(max_cdclk_freq * 95, 100);
> > > + else if (INTEL_INFO(dev_priv)->gen == 2 || INTEL_INFO(dev_priv)->gen ==
> > > 3)
> >
> > intel_crtc_compute_config() uses 'gen < 4' as the condition around the
> > double_wide handling. Maybe do the same here for consistency.
> >
> > > + max_dotclk_freq = DIV_ROUND_UP(2 * max_cdclk_freq * 90, 100);
> > > + else
> > > + max_dotclk_freq = DIV_ROUND_UP(max_cdclk_freq * 90, 100);
> >
> > These should round down to match what we do in the calc_cdclk funcs.
> >
> > Also to add another bikeshed color, there's no need for the local
> > max_dotclk_freq variable, you can just 'return ' from each
> > branch.
> >
> > With at least the rounding fixed this can have
> > Reviewed-by: Ville Syrjälä
> >
> > > +
> > > + return max_dotclk_freq;
> > > +}
> > > +
> > > static void intel_update_max_cdclk(struct drm_device *dev)
> > > {
> > > struct drm_i915_private *dev_priv = dev->dev_private;
> > > @@ -5298,6 +5315,8 @@ static void intel_update_max_cdclk(struct
> > > drm_device *dev)
> > > dev_priv->max_cdclk_freq = dev_priv->cdclk_freq;
> > > }
> > >
> > > + dev_priv->max_dotclk = intel_compute_max_dotclk(dev_priv);
> > > +
> > > DRM_DEBUG_DRIVER("Max CD clock rate: %d kHz\n",
> > >dev_priv->max_cdclk_freq);
>
> Oh and I think it would be nice to add a DRM_DEBUG_DRIVER for the
> compute max_dotclk so that we'll have it handy in bug reports without
> having to recompute it in ones head.
>
Thanks Ville for the review. I will work my way up towards v4 based on
your comments.
Cheers,
Mika
> > > }
> > > --
> > > 1.9.1
> > >
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> > --
> > Ville Syrjälä
> > Intel OTC
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Set alternate aux for DDI-E
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 7119 -Summary- Platform Delta drm-intel-nightly Series Applied ILK -1 302/302 301/302 SNB 315/315 315/315 IVB -11 336/336 325/336 BYT -1 283/283 282/283 HSW 378/378 378/378 -Detailed- Platform Testdrm-intel-nightly Series Applied *ILK igt@kms_flip@flip-vs-dpms-interruptible PASS(1) DMESG_WARN(1) *IVB igt@kms_cursor_crc@cursor-128x128-onscreen PASS(1) FAIL(1) *IVB igt@kms_cursor_crc@cursor-128x128-random PASS(1) FAIL(1) *IVB igt@kms_cursor_crc@cursor-128x128-sliding PASS(1) FAIL(1) *IVB igt@kms_cursor_crc@cursor-256x256-offscreen PASS(1) FAIL(1) *IVB igt@kms_cursor_crc@cursor-256x256-onscreen PASS(1) FAIL(1) *IVB igt@kms_cursor_crc@cursor-256x256-sliding PASS(1) FAIL(1) *IVB igt@kms_cursor_crc@cursor-64x64-offscreen PASS(1) FAIL(1) *IVB igt@kms_cursor_crc@cursor-64x64-onscreen PASS(1) FAIL(1) *IVB igt@kms_cursor_crc@cursor-64x64-random PASS(1) FAIL(1) *IVB igt@kms_cursor_crc@cursor-64x64-sliding PASS(1) FAIL(1) *IVB igt@kms_cursor_crc@cursor-size-change PASS(1) FAIL(1) *BYT igt@gem_tiled_partial_pwrite_pread@reads PASS(1) FAIL(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Only dither on 6bpc panels
On Thu, 13 Aug 2015, Mario Kleiner wrote:
> Thanks for the quick fix! Comments below...
>
> On 08/12/2015 11:43 AM, Daniel Vetter wrote:
>> In
>>
>> commit d328c9d78d64ca11e744fe227096990430a88477
>> Author: Daniel Vetter
>> Date: Fri Apr 10 16:22:37 2015 +0200
>>
>> drm/i915: Select starting pipe bpp irrespective or the primary plane
>>
>> we started to select the pipe bpp from sink capabilities and not from
>> the primary framebuffer - that one might change (and we don't want to
>> incur a modeset) and sprites might contain higher bpp content too.
>>
>> Problem is that now if you have a 10bpc screen and display 24bpp rgb
>> primary then we select dithering, and apparently that mangles the high
>> 8 bits even (even thought you'd expect dithering only to affect how
>> 12bpc gets mapped into 10bpc). And that mangling upsets certain users.
>>
>
> Probably doesn't matter, but your explanation of the former problem here
> is slightly off. We also selected dithering on a 8 bpc screen displaying
> a 24bpp rgb primary, because pipe_bpp is 24 for such a typical 8 bpc
> sink, but since the commit mentioned above, base_bpp is always the
> absolute maximum supported by the hardware, e.g., 36 bpp on my Ironlake
> chip. Iow. the only way to not get dithering would have been to connect
> a deep color 12 bpc display, so pipe_bpp == 36 == base_bpp.
>
>> Hence only enable dithering on 6bpc screens where we difinitely and
>> always want it.
>>
>
> Other than that, i tested the patch on both 8 bpc output with my
> measurement equipment and on the internal laptop 6 bpc panel, and
> everything is fine now - No banding on the 6 bpc panel, no banding or
> equipment failure on the external 8 bpc output. Life is good again :)
>
> Reviewed-and-tested-by: Mario Kleiner
Pushed to drm-intel-fixes, thanks for the patch and review and testing.
BR,
Jani.
>
> thanks,
> -mario
>
>> Cc: Mario Kleiner
>> Reported-by: Mario Kleiner
>> Signed-off-by: Daniel Vetter
>> ---
>> drivers/gpu/drm/i915/intel_display.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 9a2f229a1c3a..128462e0a0b5 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -12186,7 +12186,9 @@ encoder_retry:
>> goto encoder_retry;
>> }
>>
>> -pipe_config->dither = pipe_config->pipe_bpp != base_bpp;
>> +/* Dithering seems to not pass-through bits correctly when it should, so
>> + * only enable it on 6bpc panels. */
>> +pipe_config->dither = pipe_config->pipe_bpp == 6*3;
>> DRM_DEBUG_KMS("plane bpp: %i, pipe bpp: %i, dithering: %i\n",
>>base_bpp, pipe_config->pipe_bpp, pipe_config->dither);
>>
>>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/21] drm/i915/gtt: Workaround for HW preload not flushing pdps
Hi Michel, Thanks for the reply! I yet have another question: right now the mark_tlb_dirty() will be called if any level of PPGTT table is changed. But for the EXECLIST context submission, we only need LRI commands if there are L3 PDP root pointer changes right? Thanks! Regards, -Zhiyuan On Wed, Aug 12, 2015 at 03:56:49PM +0800, Michel Thierry wrote: > On 8/11/2015 1:05 PM, Zhiyuan Lv wrote: > >Hi Mika/Dave/Michel, > > > >I saw the patch of using LRI for root pointer update has been merged to > >drm-intel. When we consider i915 driver to run inside a virtual machine, e.g. > >with XenGT, we may still need Mika's this patch like below: > > > >" > > if (intel_vgpu_active(ppgtt->base.dev)) > > gen8_preallocate_top_level_pdps(ppgtt); > >" > > > >Could you share with us your opinion? Thanks in advance! > > Hi Zhiyuan, > > The change looks ok to me. If you need to preallocate the PDPs, > gen8_ppgtt_init is the right place to do it. Only add a similar > vgpu_active check to disable the LRI updates (in > gen8_emit_bb_start). > > > > >The reason behind is that LRI command will make shadow PPGTT implementation > >hard. In XenGT, we construct shadow page table for each PPGTT in guest i915 > >driver, and then track every guest page table change in order to update > >shadow > >page table accordingly. The problem of page table updates with GPU command is > >that they cannot be trapped by hypervisor to finish the shadow page table > >update work. In XenGT, the only change we have is the command scan in context > >submission. But that is not exactly the right time to do shadow page table > >update. > > > >Mika's patch can address the problem nicely. With the preallocation, the root > >pointers in EXECLIST context will always keep the same. Then we can treat any > >attempt to change guest PPGTT with GPU commands as malicious behavior. > >Thanks! > > > >Regards, > >-Zhiyuan > > > >On Thu, Jun 11, 2015 at 04:57:42PM +0300, Mika Kuoppala wrote: > >>Dave Gordon writes: > >> > >>>On 10/06/15 12:42, Michel Thierry wrote: > On 5/29/2015 1:53 PM, Michel Thierry wrote: > >On 5/29/2015 12:05 PM, Michel Thierry wrote: > >>On 5/22/2015 6:04 PM, Mika Kuoppala wrote: > >>>With BDW/SKL and 32bit addressing mode only, the hardware preloads > >>>pdps. However the TLB invalidation only has effect on levels below > >>>the pdps. This means that if pdps change, hw might access with > >>>stale pdp entry. > >>> > >>>To combat this problem, preallocate the top pdps so that hw sees > >>>them as immutable for each context. > >>> > >>>Cc: Ville Syrjälä > >>>Cc: Rafael Barbalho > >>>Signed-off-by: Mika Kuoppala > >>>--- > >>> drivers/gpu/drm/i915/i915_gem_gtt.c | 50 > >>>+ > >>> drivers/gpu/drm/i915/i915_reg.h | 17 + > >>> drivers/gpu/drm/i915/intel_lrc.c| 15 +-- > >>> 3 files changed, 68 insertions(+), 14 deletions(-) > >>> > >>>diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c > >>>b/drivers/gpu/drm/i915/i915_gem_gtt.c > >>>index 0ffd459..1a5ad4c 100644 > >>>--- a/drivers/gpu/drm/i915/i915_gem_gtt.c > >>>+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c > >>>@@ -941,6 +941,48 @@ err_out: > >>> return ret; > >>> } > >>> > >>>+/* With some architectures and 32bit legacy mode, hardware pre-loads > >>>the > >>>+ * top level pdps but the tlb invalidation only invalidates the > >>>lower levels. > >>>+ * This might lead to hw fetching with stale pdp entries if top level > >>>+ * structure changes, ie va space grows with dynamic page tables. > >>>+ */ > >>> > >>>Is this still necessary if we reload PDPs via LRI instructions whenever > >>>the address map has changed? That always (AFAICT) causes sufficient > >>>invalidation, so then we might not need to preallocate at all :) > >>> > >> > >>LRI reload gets my vote. Please ignore this patch. > >>-Mika > >> > >>>.Dave. > >>___ > >>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 mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] benckmarks/Android.mk: Fix building benchmarks for Android
The commit "benchmarks: Do not install to system-wide bin/" changed the benchmark file list from bin_PROGRAMS to benchmarks_PROGRAMS. However Android.mk was not updated, resulting in IGT failing to build for Android. This commit adds that change. It also adds LOCAL_MODULE_PATH to specify where the built benchmarks should be put. --- benchmarks/Android.mk | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/benchmarks/Android.mk b/benchmarks/Android.mk index da11c44..ed9a903 100644 --- a/benchmarks/Android.mk +++ b/benchmarks/Android.mk @@ -19,6 +19,7 @@ define add_benchmark LOCAL_MODULE := $1_benchmark LOCAL_MODULE_TAGS := optional +LOCAL_MODULE_PATH := $(ANDROID_PRODUCT_OUT)/$(TARGET_COPY_OUT_VENDOR)/intel/validation/core/igt/benchmarks LOCAL_STATIC_LIBRARIES := libintel_gpu_tools @@ -31,6 +32,6 @@ endef ## -benchmark_list := $(bin_PROGRAMS) +benchmark_list := $(benchmarks_PROGRAMS) $(foreach item,$(benchmark_list),$(eval $(call add_benchmark,$(item -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/21] drm/i915/gtt: Workaround for HW preload not flushing pdps
Hi Dave, On Wed, Aug 12, 2015 at 04:09:18PM +0100, Dave Gordon wrote: > On 12/08/15 08:56, Thierry, Michel wrote: > >On 8/11/2015 1:05 PM, Zhiyuan Lv wrote: > >>Hi Mika/Dave/Michel, > >> > >>I saw the patch of using LRI for root pointer update has been merged to > >>drm-intel. When we consider i915 driver to run inside a virtual machine, > >>e.g. > >>with XenGT, we may still need Mika's this patch like below: > >> > >>" > >> if (intel_vgpu_active(ppgtt->base.dev)) > >> gen8_preallocate_top_level_pdps(ppgtt); > >>" > >> > >>Could you share with us your opinion? Thanks in advance! > > > >Hi Zhiyuan, > > > >The change looks ok to me. If you need to preallocate the PDPs, > >gen8_ppgtt_init is the right place to do it. Only add a similar > >vgpu_active check to disable the LRI updates (in gen8_emit_bb_start). > > > >>The reason behind is that LRI command will make shadow PPGTT implementation > >>hard. In XenGT, we construct shadow page table for each PPGTT in guest i915 > >>driver, and then track every guest page table change in order to update > >>shadow > >>page table accordingly. The problem of page table updates with GPU command > >>is > >>that they cannot be trapped by hypervisor to finish the shadow page table > >>update work. In XenGT, the only change we have is the command scan in > >>context > >>submission. But that is not exactly the right time to do shadow page table > >>update. > >> > >>Mika's patch can address the problem nicely. With the preallocation, the > >>root > >>pointers in EXECLIST context will always keep the same. Then we can treat > >>any > >>attempt to change guest PPGTT with GPU commands as malicious behavior. > >>Thanks! > >> > >>Regards, > >>-Zhiyuan > > The bad thing that was happening if we didn't use LRIs was that the > CPU would try to push the new mappings to the GPU by updating PDP > registers in the saved context image. This is unsafe if the context > is running, as switching away from it would result in the > CPU-updated values being overwritten by the older values in the GPU > h/w registers (if the context were known to be idle, then it would > be safe). Thank you very much for the detailed explanation! And I am curious that if the root pointers update does not have side effect to the current running context, for instance, only changing NULL to PD without modifying existing pdpes, can we use "Force PD Restore" bit in ctx descriptor? Regards, -Zhiyuan > > Preallocating the top-level PDPs should mean that the values need > never change, so there's then no need to update the context image, > thus avoiding the write hazard :) > > .Dave. > > >>On Thu, Jun 11, 2015 at 04:57:42PM +0300, Mika Kuoppala wrote: > >>>Dave Gordon writes: > >>> > On 10/06/15 12:42, Michel Thierry wrote: > >On 5/29/2015 1:53 PM, Michel Thierry wrote: > >>On 5/29/2015 12:05 PM, Michel Thierry wrote: > >>>On 5/22/2015 6:04 PM, Mika Kuoppala wrote: > With BDW/SKL and 32bit addressing mode only, the hardware preloads > pdps. However the TLB invalidation only has effect on levels below > the pdps. This means that if pdps change, hw might access with > stale pdp entry. > > To combat this problem, preallocate the top pdps so that hw sees > them as immutable for each context. > > Cc: Ville Syrjälä > Cc: Rafael Barbalho > Signed-off-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/i915_gem_gtt.c | 50 > + > drivers/gpu/drm/i915/i915_reg.h | 17 + > drivers/gpu/drm/i915/intel_lrc.c| 15 +-- > 3 files changed, 68 insertions(+), 14 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c > b/drivers/gpu/drm/i915/i915_gem_gtt.c > index 0ffd459..1a5ad4c 100644 > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c > @@ -941,6 +941,48 @@ err_out: > return ret; > } > > +/* With some architectures and 32bit legacy mode, hardware pre-loads > + * the top level pdps but the tlb invalidation only invalidates the > + * lower levels. > + * This might lead to hw fetching with stale pdp entries if top level > + * structure changes, ie va space grows with dynamic page tables. > + */ > > Is this still necessary if we reload PDPs via LRI instructions whenever > the address map has changed? That always (AFAICT) causes sufficient > invalidation, so then we might not need to preallocate at all :) > >>> > >>>LRI reload gets my vote. Please ignore this patch. > >>>-Mika > >>> > .Dave. > >>>___ > >>>Intel-gfx mailing list > >>>Intel-gfx@lists.freedesktop.org > >>>http://lists.freedesktop.org/mailman/listinfo/intel-gfx > >
[Intel-gfx] [PATCH i-g-t] benckmarks/Android.mk: Fix building benchmarks for Android
The commit "benchmarks: Do not install to system-wide bin/" changed the benchmark file list from bin_PROGRAMS to benchmarks_PROGRAMS. However Android.mk was not updated, resulting in IGT failing to build for Android. This commit adds that change. It also adds LOCAL_MODULE_PATH to specify where the built benchmarks should be put. Signed-off-by: Derek Morton --- benchmarks/Android.mk | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/benchmarks/Android.mk b/benchmarks/Android.mk index da11c44..ed9a903 100644 --- a/benchmarks/Android.mk +++ b/benchmarks/Android.mk @@ -19,6 +19,7 @@ define add_benchmark LOCAL_MODULE := $1_benchmark LOCAL_MODULE_TAGS := optional +LOCAL_MODULE_PATH := $(ANDROID_PRODUCT_OUT)/$(TARGET_COPY_OUT_VENDOR)/intel/validation/core/igt/benchmarks LOCAL_STATIC_LIBRARIES := libintel_gpu_tools @@ -31,6 +32,6 @@ endef ## -benchmark_list := $(bin_PROGRAMS) +benchmark_list := $(benchmarks_PROGRAMS) $(foreach item,$(benchmark_list),$(eval $(call add_benchmark,$(item -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] benckmarks/Android.mk: Fix building benchmarks for Android
This is the same as the previously sent patch but with Signed-off-by added to the commit message. //Derek > > >-Original Message- >From: Morton, Derek J >Sent: Thursday, August 13, 2015 10:51 AM >To: intel-gfx@lists.freedesktop.org >Cc: Wood, Thomas; Gore, Tim; ch...@chris-wilson.co.uk; Morton, Derek J >Subject: [PATCH i-g-t] benckmarks/Android.mk: Fix building benchmarks for >Android > >The commit "benchmarks: Do not install to system-wide bin/" changed the >benchmark file list from bin_PROGRAMS to benchmarks_PROGRAMS. >However Android.mk was not updated, resulting in IGT failing to build for >Android. >This commit adds that change. It also adds LOCAL_MODULE_PATH to specify where >the built benchmarks should be put. > >Signed-off-by: Derek Morton >--- > benchmarks/Android.mk | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > >diff --git a/benchmarks/Android.mk b/benchmarks/Android.mk index >da11c44..ed9a903 100644 >--- a/benchmarks/Android.mk >+++ b/benchmarks/Android.mk >@@ -19,6 +19,7 @@ define add_benchmark > > LOCAL_MODULE := $1_benchmark > LOCAL_MODULE_TAGS := optional >+LOCAL_MODULE_PATH := >+ $(ANDROID_PRODUCT_OUT)/$(TARGET_COPY_OUT_VENDOR)/intel/validation/core >+ /igt/benchmarks > > LOCAL_STATIC_LIBRARIES := libintel_gpu_tools > >@@ -31,6 +32,6 @@ endef > > ## > >-benchmark_list := $(bin_PROGRAMS) >+benchmark_list := $(benchmarks_PROGRAMS) > > $(foreach item,$(benchmark_list),$(eval $(call add_benchmark,$(item >-- >1.9.1 > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Adding break for one case
Signed-off-by: Xiong Zhang --- drivers/gpu/drm/i915/intel_display.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 65cc5b1..801187c 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -1100,6 +1100,7 @@ bool ibx_digital_port_connected(struct drm_i915_private *dev_priv, break; case PORT_E: bit = SDE_PORTE_HOTPLUG_SPT; + break; default: return true; } -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/skl: Adding DDI_E power well domain
From B spec, DDI_E port belong to PowerWell 2, but
DDI_E share the powerwell_req/staus register bit with
DDI_A which belong to DDI_A_E_POWER_WELL.
In order to communicate with the connector on DDI-E, both
DDI_A_E_POWER_WELL and POWER_WELL_2 must be enabled.
Currently intel_dp_power_get(DDI_E) only enable
DDI_A_E_POWER_WELL, this patch will not only enable
DDI_a_E_POWER_WELL but also enable POWER_WELL_2.
This patch also fix the DDI-E hotplug function.
Signed-off-by: Xiong Zhang
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_display.c| 3 ++-
drivers/gpu/drm/i915/intel_runtime_pm.c | 2 ++
4 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 86734be..5523b6e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2564,6 +2564,8 @@ static const char *power_domain_str(enum
intel_display_power_domain domain)
return "PORT_DDI_D_2_LANES";
case POWER_DOMAIN_PORT_DDI_D_4_LANES:
return "PORT_DDI_D_4_LANES";
+ case POWER_DOMAIN_PORT_DDI_E_2_LANES:
+ return "PORT_DDI_E_2_LANES";
case POWER_DOMAIN_PORT_DSI:
return "PORT_DSI";
case POWER_DOMAIN_PORT_CRT:
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b157865..ee71f90 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -182,6 +182,7 @@ enum intel_display_power_domain {
POWER_DOMAIN_PORT_DDI_C_4_LANES,
POWER_DOMAIN_PORT_DDI_D_2_LANES,
POWER_DOMAIN_PORT_DDI_D_4_LANES,
+ POWER_DOMAIN_PORT_DDI_E_2_LANES,
POWER_DOMAIN_PORT_DSI,
POWER_DOMAIN_PORT_CRT,
POWER_DOMAIN_PORT_OTHER,
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 801187c..ccd3f0b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5150,7 +5150,6 @@ static enum intel_display_power_domain
port_to_power_domain(enum port port)
{
switch (port) {
case PORT_A:
- case PORT_E:
return POWER_DOMAIN_PORT_DDI_A_4_LANES;
case PORT_B:
return POWER_DOMAIN_PORT_DDI_B_4_LANES;
@@ -5158,6 +5157,8 @@ static enum intel_display_power_domain
port_to_power_domain(enum port port)
return POWER_DOMAIN_PORT_DDI_C_4_LANES;
case PORT_D:
return POWER_DOMAIN_PORT_DDI_D_4_LANES;
+ case PORT_E:
+ return POWER_DOMAIN_PORT_DDI_E_2_LANES;
default:
WARN_ON_ONCE(1);
return POWER_DOMAIN_PORT_OTHER;
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 821644d..af7fdb3 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -297,6 +297,7 @@ static void hsw_set_power_well(struct drm_i915_private
*dev_priv,
BIT(POWER_DOMAIN_PORT_DDI_C_4_LANES) | \
BIT(POWER_DOMAIN_PORT_DDI_D_2_LANES) | \
BIT(POWER_DOMAIN_PORT_DDI_D_4_LANES) | \
+ BIT(POWER_DOMAIN_PORT_DDI_E_2_LANES) | \
BIT(POWER_DOMAIN_AUX_B) | \
BIT(POWER_DOMAIN_AUX_C) | \
BIT(POWER_DOMAIN_AUX_D) | \
@@ -316,6 +317,7 @@ static void hsw_set_power_well(struct drm_i915_private
*dev_priv,
#define SKL_DISPLAY_DDI_A_E_POWER_DOMAINS (\
BIT(POWER_DOMAIN_PORT_DDI_A_2_LANES) | \
BIT(POWER_DOMAIN_PORT_DDI_A_4_LANES) | \
+ BIT(POWER_DOMAIN_PORT_DDI_E_2_LANES) | \
BIT(POWER_DOMAIN_INIT))
#define SKL_DISPLAY_DDI_B_POWER_DOMAINS ( \
BIT(POWER_DOMAIN_PORT_DDI_B_2_LANES) | \
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/21] drm/i915/gtt: Workaround for HW preload not flushing pdps
On 8/13/2015 5:36 PM, Zhiyuan Lv wrote: Hi Dave, On Wed, Aug 12, 2015 at 04:09:18PM +0100, Dave Gordon wrote: On 12/08/15 08:56, Thierry, Michel wrote: On 8/11/2015 1:05 PM, Zhiyuan Lv wrote: Hi Mika/Dave/Michel, I saw the patch of using LRI for root pointer update has been merged to drm-intel. When we consider i915 driver to run inside a virtual machine, e.g. with XenGT, we may still need Mika's this patch like below: " if (intel_vgpu_active(ppgtt->base.dev)) gen8_preallocate_top_level_pdps(ppgtt); " Could you share with us your opinion? Thanks in advance! Hi Zhiyuan, The change looks ok to me. If you need to preallocate the PDPs, gen8_ppgtt_init is the right place to do it. Only add a similar vgpu_active check to disable the LRI updates (in gen8_emit_bb_start). The reason behind is that LRI command will make shadow PPGTT implementation hard. In XenGT, we construct shadow page table for each PPGTT in guest i915 driver, and then track every guest page table change in order to update shadow page table accordingly. The problem of page table updates with GPU command is that they cannot be trapped by hypervisor to finish the shadow page table update work. In XenGT, the only change we have is the command scan in context submission. But that is not exactly the right time to do shadow page table update. Mika's patch can address the problem nicely. With the preallocation, the root pointers in EXECLIST context will always keep the same. Then we can treat any attempt to change guest PPGTT with GPU commands as malicious behavior. Thanks! Regards, -Zhiyuan The bad thing that was happening if we didn't use LRIs was that the CPU would try to push the new mappings to the GPU by updating PDP registers in the saved context image. This is unsafe if the context is running, as switching away from it would result in the CPU-updated values being overwritten by the older values in the GPU h/w registers (if the context were known to be idle, then it would be safe). Thank you very much for the detailed explanation! And I am curious that if the root pointers update does not have side effect to the current running context, for instance, only changing NULL to PD without modifying existing pdpes, can we use "Force PD Restore" bit in ctx descriptor? We've been explicitly asked to not use "Force PD Restore". Regards, -Zhiyuan Preallocating the top-level PDPs should mean that the values need never change, so there's then no need to update the context image, thus avoiding the write hazard :) .Dave. On Thu, Jun 11, 2015 at 04:57:42PM +0300, Mika Kuoppala wrote: Dave Gordon writes: On 10/06/15 12:42, Michel Thierry wrote: On 5/29/2015 1:53 PM, Michel Thierry wrote: On 5/29/2015 12:05 PM, Michel Thierry wrote: On 5/22/2015 6:04 PM, Mika Kuoppala wrote: With BDW/SKL and 32bit addressing mode only, the hardware preloads pdps. However the TLB invalidation only has effect on levels below the pdps. This means that if pdps change, hw might access with stale pdp entry. To combat this problem, preallocate the top pdps so that hw sees them as immutable for each context. Cc: Ville Syrjälä Cc: Rafael Barbalho Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_gem_gtt.c | 50 + drivers/gpu/drm/i915/i915_reg.h | 17 + drivers/gpu/drm/i915/intel_lrc.c| 15 +-- 3 files changed, 68 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index 0ffd459..1a5ad4c 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -941,6 +941,48 @@ err_out: return ret; } +/* With some architectures and 32bit legacy mode, hardware pre-loads + * the top level pdps but the tlb invalidation only invalidates the + * lower levels. + * This might lead to hw fetching with stale pdp entries if top level + * structure changes, ie va space grows with dynamic page tables. + */ Is this still necessary if we reload PDPs via LRI instructions whenever the address map has changed? That always (AFAICT) causes sufficient invalidation, so then we might not need to preallocate at all :) LRI reload gets my vote. Please ignore this patch. -Mika .Dave. ___ 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 mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] lib/rendercopy_gen9: Setup Push constant pointer before sending BTP commands
Arun Siluvery writes:
> From Gen9, by default push constant command is not committed to the shader
> unit
> untill the corresponding shader's BTP_* command is parsed. This is the
> behaviour when set shader is enabled. This patch updates the batch to follow
> this requirement otherwise it results in gpu hang.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89959
>
> Set shader need to be disabled if legacy behaviour is required.
>
> Cc: Ben Widawsky
> Cc: Joonas Lahtinen
> Cc: Mika Kuoppala
> Signed-off-by: Arun Siluvery
> ---
>
with skl-y,
Tested-by: Mika Kuoppala
> If this patch is applied then we don't need to disable set shader bit
> in kernel and the following can be discarded.
>
> http://lists.freedesktop.org/archives/intel-gfx/2015-August/073425.html
>
> lib/rendercopy_gen9.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/lib/rendercopy_gen9.c b/lib/rendercopy_gen9.c
> index 4a4a604..9537480 100644
> --- a/lib/rendercopy_gen9.c
> +++ b/lib/rendercopy_gen9.c
> @@ -590,13 +590,9 @@ gen8_emit_multisample(struct intel_batchbuffer *batch) {
>
> static void
> gen8_emit_vs(struct intel_batchbuffer *batch) {
> - OUT_BATCH(GEN7_3DSTATE_BINDING_TABLE_POINTERS_VS);
> + OUT_BATCH(GEN6_3DSTATE_CONSTANT_VS | (11-2));
> OUT_BATCH(0);
> -
> - OUT_BATCH(GEN7_3DSTATE_SAMPLER_STATE_POINTERS_VS);
> OUT_BATCH(0);
> -
> - OUT_BATCH(GEN6_3DSTATE_CONSTANT_VS | (11-2));
> OUT_BATCH(0);
> OUT_BATCH(0);
> OUT_BATCH(0);
> @@ -605,7 +601,11 @@ gen8_emit_vs(struct intel_batchbuffer *batch) {
> OUT_BATCH(0);
> OUT_BATCH(0);
> OUT_BATCH(0);
> +
> + OUT_BATCH(GEN7_3DSTATE_BINDING_TABLE_POINTERS_VS);
> OUT_BATCH(0);
> +
> + OUT_BATCH(GEN7_3DSTATE_SAMPLER_STATE_POINTERS_VS);
> OUT_BATCH(0);
>
> OUT_BATCH(GEN6_3DSTATE_VS | (9-2));
> @@ -998,14 +998,14 @@ void gen9_render_copyfunc(struct intel_batchbuffer
> *batch,
>
> gen8_emit_sf(batch);
>
> + gen8_emit_ps(batch, ps_kernel_off);
> +
> OUT_BATCH(GEN7_3DSTATE_BINDING_TABLE_POINTERS_PS);
> OUT_BATCH(ps_binding_table);
>
> OUT_BATCH(GEN7_3DSTATE_SAMPLER_STATE_POINTERS_PS);
> OUT_BATCH(ps_sampler_state);
>
> - gen8_emit_ps(batch, ps_kernel_off);
> -
> OUT_BATCH(GEN6_3DSTATE_SCISSOR_STATE_POINTERS);
> OUT_BATCH(scissor_state);
>
> --
> 1.9.1
>
> ___
> 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] [PATCH 02/21] drm/i915/gtt: Workaround for HW preload not flushing pdps
On 8/13/2015 5:08 PM, Zhiyuan Lv wrote: Hi Michel, Thanks for the reply! I yet have another question: right now the mark_tlb_dirty() will be called if any level of PPGTT table is changed. But for the EXECLIST context submission, we only need LRI commands if there are L3 PDP root pointer changes right? Thanks! mark_tlbs_dirty is not only for execlists mode, we re-used it since it was already there. The update is only required when a PDP is allocated. -Michel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v2] benckmarks/Android.mk: Fix building benchmarks for Android
The commit "benchmarks: Do not install to system-wide bin/" changed
the benchmark file list from bin_PROGRAMS to benchmarks_PROGRAMS.
However Android.mk was not updated, resulting in IGT failing to
build for Android.
This commit adds that change. It also adds LOCAL_MODULE_PATH to
specify where the built benchmarks should be put.
v2: I discovered that the existing definitions of LOCAL_MODULE_PATH
were creating what should have been an invalid path. Not sure how it
was ever working previously, but fixed now.
Signed-off-by: Derek Morton
---
benchmarks/Android.mk | 3 ++-
lib/tests/Android.mk | 2 +-
tests/Android.mk | 2 +-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/benchmarks/Android.mk b/benchmarks/Android.mk
index da11c44..207a177 100644
--- a/benchmarks/Android.mk
+++ b/benchmarks/Android.mk
@@ -19,6 +19,7 @@ define add_benchmark
LOCAL_MODULE := $1_benchmark
LOCAL_MODULE_TAGS := optional
+LOCAL_MODULE_PATH :=
$(TARGET_OUT_VENDOR)/intel/validation/core/igt/benchmarks
LOCAL_STATIC_LIBRARIES := libintel_gpu_tools
@@ -31,6 +32,6 @@ endef
##
-benchmark_list := $(bin_PROGRAMS)
+benchmark_list := $(benchmarks_PROGRAMS)
$(foreach item,$(benchmark_list),$(eval $(call add_benchmark,$(item
diff --git a/lib/tests/Android.mk b/lib/tests/Android.mk
index 7ad0300..df8e159 100644
--- a/lib/tests/Android.mk
+++ b/lib/tests/Android.mk
@@ -18,7 +18,7 @@ define add_test
LOCAL_SHARED_LIBRARIES := ${IGT_LOCAL_SHARED_LIBRARIES}
LOCAL_MODULE_TAGS := optional
-LOCAL_MODULE_PATH :=
$(ANDROID_PRODUCT_OUT)/$(TARGET_COPY_OUT_VENDOR)/intel/validation/core/igt
+LOCAL_MODULE_PATH := $(TARGET_OUT_VENDOR)/intel/validation/core/igt
include $(BUILD_EXECUTABLE)
endef
diff --git a/tests/Android.mk b/tests/Android.mk
index 10ef3e2..8457125 100644
--- a/tests/Android.mk
+++ b/tests/Android.mk
@@ -20,7 +20,7 @@ define add_test
LOCAL_MODULE_TAGS := optional
# ask linker to define a specific symbol; we use this to identify IGT tests
LOCAL_LDFLAGS := -Wl,--defsym=$2=0
-LOCAL_MODULE_PATH :=
$(ANDROID_PRODUCT_OUT)/$(TARGET_COPY_OUT_VENDOR)/intel/validation/core/igt
+LOCAL_MODULE_PATH := $(TARGET_OUT_VENDOR)/intel/validation/core/igt
include $(BUILD_EXECUTABLE)
endef
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Spam less on dp aux send/receive problems
Daniel Vetter writes:
> On Mon, Aug 10, 2015 at 02:01:56PM +0300, Jani Nikula wrote:
>> On Mon, 10 Aug 2015, Jani Nikula wrote:
>> > On Thu, 06 Aug 2015, Mika Kuoppala wrote:
>> >> If we encounter frequent problems with dp aux channel
>> >> communications, we end up spamming the dmesg with the
>> >> exact similar trace and status.
>> >>
>> >> Inject a new backtrace only if we have new information
>> >> to share as otherwise we flush out all other important
>> >> stuff.
>> >>
>> >> Signed-off-by: Mika Kuoppala
>> >> ---
>> >> drivers/gpu/drm/i915/intel_dp.c | 11 +--
>> >> 1 file changed, 9 insertions(+), 2 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c
>> >> b/drivers/gpu/drm/i915/intel_dp.c
>> >> index df7e2cf..6b2f7af 100644
>> >> --- a/drivers/gpu/drm/i915/intel_dp.c
>> >> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> >> @@ -849,8 +849,15 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
>> >> }
>> >>
>> >> if (try == 3) {
>> >> - WARN(1, "dp_aux_ch not started status 0x%08x\n",
>> >> - I915_READ(ch_ctl));
>> >> + static u32 last_status = -1;
>> >> + const u32 status = I915_READ(ch_ctl);
>> >> +
>> >> + if (status != last_status) {
>> >> + WARN(1, "dp_aux_ch not started status 0x%08x\n",
>> >> + status);
>> >> + last_status = status;
>> >> + }
>> >> +
>> >
>> > But now you'll also skip the logging even if there's been a day and a
>> > million successful transfers since the last error... I understand your
>> > concern, but if you feel you must do something like this, please at
>> > least reset last_status on success.
>>
>> Hmh, I see now that this has already been merged... :(
>
> Well I like the idea, Mika please supply a fixup patch.
I have a fixup to clear the last status on success.
And I also patch which get rids of the trickery
and then just WARN_ON_ONCE if try == 3, suggested
by Jani.
As this was just in a way of skl debugging by flooding
logs, both approaches are fine with. What is the
preferred approach for the display devs?
-Mika
> -Daniel
>
>>
>>
>> >
>> > BR,
>> > Jani.
>> >
>> >
>> >> ret = -EBUSY;
>> >> goto out;
>> >> }
>> >> --
>> >> 2.1.4
>> >>
>> >> ___
>> >> Intel-gfx mailing list
>> >> Intel-gfx@lists.freedesktop.org
>> >> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>> >
>> > --
>> > Jani Nikula, Intel Open Source Technology Center
>>
>> --
>> Jani Nikula, Intel Open Source Technology Center
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2 v2 addendum] drm/i915: Allow parsing of variable size child device entries from VBT
On Wed, Aug 12, 2015 at 03:13:35PM +0300, Jani Nikula wrote:
> On Wed, 12 Aug 2015, David Weinehall wrote:
> > Some more fixup is needed; the bits from Antti's patch
> > that actually expanded the struct to fully fit the newer
> > versions of the child_device_config was part of the second
> > patch; since that patch hasn't been merged yet we need this bit:
> >
> > This applies on top of the patch you already merged
> > (the Iboost patch will need corresponding adjustment to
> > remove the changes I split out):
> >
> > Expand common_child_dev_config to be able to fit all information
> > defined by the latest VBT specification.
> >
> > Signed-off-by: David Weinehall
> > CC: Antti Koskipaa
> > ---
> > intel_bios.c |7 ++-
> > intel_bios.h |4
> > 2 files changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_bios.c
> > b/drivers/gpu/drm/i915/intel_bios.c
> > index 990acc20771a..40e2cc4e7419 100644
> > --- a/drivers/gpu/drm/i915/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/intel_bios.c
> > @@ -1038,6 +1038,10 @@ parse_device_mapping(struct drm_i915_private
> > *dev_priv,
> > DRM_DEBUG_KMS("No general definition block is found, no devices
> > defined.\n");
> > return;
> > }
> > + /* Remember to keep this in sync with child_device_config;
> > +* whenever a new feature is added to BDB that causes that
> > +* struct to grow this needs to be updated too
> > +*/
>
> BUILD_BUG_ON(something about sizeof child device config) ?
The idea is nice, but... We get the size to copy (expected_size)
from the version-switch statement (so it's not available during build);
thus we cannot know at compile time whether expected_size is larger than
sizeof(child_device_config).
This is yet another argument in favour of a version:feature
table I think; that would allow for compile-time validation.
Unless someone else volunteers to refactor this code I can dig in once
I get back from vacation.
Kind regards, David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v2] benckmarks/Android.mk: Fix building benchmarks for Android
On 13 August 2015 at 11:27, Derek Morton wrote:
> The commit "benchmarks: Do not install to system-wide bin/" changed
> the benchmark file list from bin_PROGRAMS to benchmarks_PROGRAMS.
> However Android.mk was not updated, resulting in IGT failing to
> build for Android.
> This commit adds that change. It also adds LOCAL_MODULE_PATH to
> specify where the built benchmarks should be put.
>
> v2: I discovered that the existing definitions of LOCAL_MODULE_PATH
> were creating what should have been an invalid path. Not sure how it
> was ever working previously, but fixed now.
Patch merged, thanks.
>
> Signed-off-by: Derek Morton
> ---
> benchmarks/Android.mk | 3 ++-
> lib/tests/Android.mk | 2 +-
> tests/Android.mk | 2 +-
> 3 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/benchmarks/Android.mk b/benchmarks/Android.mk
> index da11c44..207a177 100644
> --- a/benchmarks/Android.mk
> +++ b/benchmarks/Android.mk
> @@ -19,6 +19,7 @@ define add_benchmark
>
> LOCAL_MODULE := $1_benchmark
> LOCAL_MODULE_TAGS := optional
> +LOCAL_MODULE_PATH :=
> $(TARGET_OUT_VENDOR)/intel/validation/core/igt/benchmarks
>
> LOCAL_STATIC_LIBRARIES := libintel_gpu_tools
>
> @@ -31,6 +32,6 @@ endef
>
> ##
>
> -benchmark_list := $(bin_PROGRAMS)
> +benchmark_list := $(benchmarks_PROGRAMS)
>
> $(foreach item,$(benchmark_list),$(eval $(call add_benchmark,$(item
> diff --git a/lib/tests/Android.mk b/lib/tests/Android.mk
> index 7ad0300..df8e159 100644
> --- a/lib/tests/Android.mk
> +++ b/lib/tests/Android.mk
> @@ -18,7 +18,7 @@ define add_test
> LOCAL_SHARED_LIBRARIES := ${IGT_LOCAL_SHARED_LIBRARIES}
>
> LOCAL_MODULE_TAGS := optional
> -LOCAL_MODULE_PATH :=
> $(ANDROID_PRODUCT_OUT)/$(TARGET_COPY_OUT_VENDOR)/intel/validation/core/igt
> +LOCAL_MODULE_PATH := $(TARGET_OUT_VENDOR)/intel/validation/core/igt
>
> include $(BUILD_EXECUTABLE)
> endef
> diff --git a/tests/Android.mk b/tests/Android.mk
> index 10ef3e2..8457125 100644
> --- a/tests/Android.mk
> +++ b/tests/Android.mk
> @@ -20,7 +20,7 @@ define add_test
> LOCAL_MODULE_TAGS := optional
> # ask linker to define a specific symbol; we use this to identify IGT
> tests
> LOCAL_LDFLAGS := -Wl,--defsym=$2=0
> -LOCAL_MODULE_PATH :=
> $(ANDROID_PRODUCT_OUT)/$(TARGET_COPY_OUT_VENDOR)/intel/validation/core/igt
> +LOCAL_MODULE_PATH := $(TARGET_OUT_VENDOR)/intel/validation/core/igt
>
> include $(BUILD_EXECUTABLE)
> endef
> --
> 1.9.1
>
___
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: Adding break for one case
On 13.08.2015 13:36, Timo Aaltonen wrote: > On 13.08.2015 13:00, Xiong Zhang wrote: >> Signed-off-by: Xiong Zhang >> --- >> drivers/gpu/drm/i915/intel_display.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/drivers/gpu/drm/i915/intel_display.c >> b/drivers/gpu/drm/i915/intel_display.c >> index 65cc5b1..801187c 100644 >> --- a/drivers/gpu/drm/i915/intel_display.c >> +++ b/drivers/gpu/drm/i915/intel_display.c >> @@ -1100,6 +1100,7 @@ bool ibx_digital_port_connected(struct >> drm_i915_private *dev_priv, >> break; >> case PORT_E: >> bit = SDE_PORTE_HOTPLUG_SPT; >> +break; >> default: >> return true; >> } >> > > shouldn't this belong to [5/6]? Nevermind, I see now that it got merged already. -- t ___ 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: Adding break for one case
On 13.08.2015 13:00, Xiong Zhang wrote: > Signed-off-by: Xiong Zhang > --- > drivers/gpu/drm/i915/intel_display.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 65cc5b1..801187c 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -1100,6 +1100,7 @@ bool ibx_digital_port_connected(struct drm_i915_private > *dev_priv, > break; > case PORT_E: > bit = SDE_PORTE_HOTPLUG_SPT; > + break; > default: > return true; > } > shouldn't this belong to [5/6]? -- t ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/bdw: Check for slice, subslice and EU count for BDW
Added checks for available slices, subslices and EUs for Broadwell. This
information is filled in intel_device_info and is available to user with
GET_PARAM.
Added checks for enabled slices, subslices and EU for Broadwell. This
information is based on available counts but takes power gated slices
into account. It can be read in debugfs.
Introduce new register defines that contain information on slices on
Broadwell.
Cc: Jeff Mcgee
Signed-off-by: Łukasz Daniluk
---
drivers/gpu/drm/i915/i915_debugfs.c | 35 +--
drivers/gpu/drm/i915/i915_dma.c | 89 +
drivers/gpu/drm/i915/i915_reg.h | 19 +++-
3 files changed, 138 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 23a69307..a17f912 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4838,7 +4838,6 @@ struct sseu_dev_status {
static void cherryview_sseu_device_status(struct drm_device *dev,
struct sseu_dev_status *stat)
{
- struct drm_i915_private *dev_priv = dev->dev_private;
const int ss_max = 2;
int ss;
u32 sig1[ss_max], sig2[ss_max];
@@ -4870,7 +4869,6 @@ static void cherryview_sseu_device_status(struct
drm_device *dev,
static void gen9_sseu_device_status(struct drm_device *dev,
struct sseu_dev_status *stat)
{
- struct drm_i915_private *dev_priv = dev->dev_private;
int s_max = 3, ss_max = 4;
int s, ss;
u32 s_reg[s_max], eu_reg[2*s_max], eu_mask[2];
@@ -4932,13 +4930,42 @@ static void gen9_sseu_device_status(struct drm_device
*dev,
}
}
+static void broadwell_sseu_device_status(struct drm_device *dev,
+struct sseu_dev_status *stat)
+{
+ int s;
+ u32 slice_info = I915_READ(GEN8_R_PWR_CLK_STATE);
+
+ /*
+* If first bit of slice_info is 0, there is no specific power
+* state set. Otherwise we read the count of enabled slices
+* from it.
+*/
+ if (slice_info & (1<<31))
+ stat->slice_total = (slice_info & GEN8_RPCS_S_CNT_MASK)
+ >> GEN8_RPCS_S_CNT_SHIFT;
+ else
+ stat->slice_total = INTEL_INFO(dev)->slice_total;
+
+ stat->subslice_per_slice = INTEL_INFO(dev)->subslice_per_slice;
+ stat->eu_per_subslice = INTEL_INFO(dev)->eu_per_subslice;
+ stat->subslice_total = stat->slice_total * stat->subslice_per_slice;
+ stat->eu_total = stat->eu_per_subslice * stat->subslice_total;
+
+ /* subtract fused off EU(s) from enabled slice(s) */
+ for (s = 0; s < stat.slice_total; s++) {
+ u8 subslice_7eu = INTEL_INFO(dev)->subslice_7eu[s];
+ stat->eu_total -= hweight8(subslice_7eu);
+ }
+}
+
static int i915_sseu_status(struct seq_file *m, void *unused)
{
struct drm_info_node *node = (struct drm_info_node *) m->private;
struct drm_device *dev = node->minor->dev;
struct sseu_dev_status stat;
- if ((INTEL_INFO(dev)->gen < 8) || IS_BROADWELL(dev))
+ if ((INTEL_INFO(dev)->gen < 8))
return -ENODEV;
seq_puts(m, "SSEU Device Info\n");
@@ -4963,6 +4990,8 @@ static int i915_sseu_status(struct seq_file *m, void
*unused)
memset(&stat, 0, sizeof(stat));
if (IS_CHERRYVIEW(dev)) {
cherryview_sseu_device_status(dev, &stat);
+ } else if (IS_BROADWELL(dev)) {
+ broadwell_sseu_device_status(dev, &stat);
} else if (INTEL_INFO(dev)->gen >= 9) {
gen9_sseu_device_status(dev, &stat);
}
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index ab37d11..2d52b1e 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -705,6 +705,93 @@ static void gen9_sseu_info_init(struct drm_device *dev)
info->has_eu_pg = (info->eu_per_subslice > 2);
}
+static void broadwell_sseu_info_init(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct intel_device_info *info;
+ const int s_max = 3, ss_max = 3, eu_max = 8;
+ int s, ss;
+ u32 fuse2, eu_disable[s_max], s_enable, ss_disable;
+
+ fuse2 = I915_READ(GEN8_FUSE2);
+ s_enable = (fuse2 & GEN8_F2_S_ENA_MASK) >>
+ GEN8_F2_S_ENA_SHIFT;
+ ss_disable = (fuse2 & GEN8_F2_SS_DIS_MASK) >>
+ GEN8_F2_SS_DIS_SHIFT;
+
+ eu_disable[0] = I915_READ(GEN8_EU_DISABLE0) &
+ GEN8_EU_DIS0_S0_MASK;
+ eu_disable[1] = (I915_READ(GEN8_EU_DISABLE0) >>
+ GEN8_EU_DIS0_S1_SHIFT) |
+ ((I915_READ(GEN8_EU_DISABLE1) &
+ GEN8_EU_DIS1_S1_MASK) <<
+(32 - GEN8_EU_DIS0_S1_SHIFT));
+ eu_disable[2] = (I915_READ(GEN8_EU_DISABLE1) >>
+
Re: [Intel-gfx] [PATCH 1/2 v2 addendum] drm/i915: Allow parsing of variable size child device entries from VBT
On Thu, 13 Aug 2015, David Weinehall wrote:
> On Wed, Aug 12, 2015 at 03:13:35PM +0300, Jani Nikula wrote:
>> On Wed, 12 Aug 2015, David Weinehall wrote:
>> > Some more fixup is needed; the bits from Antti's patch
>> > that actually expanded the struct to fully fit the newer
>> > versions of the child_device_config was part of the second
>> > patch; since that patch hasn't been merged yet we need this bit:
>> >
>> > This applies on top of the patch you already merged
>> > (the Iboost patch will need corresponding adjustment to
>> > remove the changes I split out):
>> >
>> > Expand common_child_dev_config to be able to fit all information
>> > defined by the latest VBT specification.
>> >
>> > Signed-off-by: David Weinehall
>> > CC: Antti Koskipaa
>> > ---
>> > intel_bios.c |7 ++-
>> > intel_bios.h |4
>> > 2 files changed, 10 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_bios.c
>> > b/drivers/gpu/drm/i915/intel_bios.c
>> > index 990acc20771a..40e2cc4e7419 100644
>> > --- a/drivers/gpu/drm/i915/intel_bios.c
>> > +++ b/drivers/gpu/drm/i915/intel_bios.c
>> > @@ -1038,6 +1038,10 @@ parse_device_mapping(struct drm_i915_private
>> > *dev_priv,
>> >DRM_DEBUG_KMS("No general definition block is found, no devices
>> > defined.\n");
>> >return;
>> >}
>> > + /* Remember to keep this in sync with child_device_config;
>> > + * whenever a new feature is added to BDB that causes that
>> > + * struct to grow this needs to be updated too
>> > + */
>>
>> BUILD_BUG_ON(something about sizeof child device config) ?
>
> The idea is nice, but... We get the size to copy (expected_size)
> from the version-switch statement (so it's not available during build);
> thus we cannot know at compile time whether expected_size is larger than
> sizeof(child_device_config).
>
> This is yet another argument in favour of a version:feature
> table I think; that would allow for compile-time validation.
>
> Unless someone else volunteers to refactor this code I can dig in once
> I get back from vacation.
Right. To be clear, my question should not block this from being merged.
BR,
Jani
>
>
> Kind regards, David
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/21] drm/i915/gtt: Workaround for HW preload not flushing pdps
On 13/08/15 11:12, Michel Thierry wrote: On 8/13/2015 5:08 PM, Zhiyuan Lv wrote: Hi Michel, Thanks for the reply! I yet have another question: right now the mark_tlb_dirty() will be called if any level of PPGTT table is changed. But for the EXECLIST context submission, we only need LRI commands if there are L3 PDP root pointer changes right? Thanks! mark_tlbs_dirty is not only for execlists mode, we re-used it since it was already there. The update is only required when a PDP is allocated. -Michel Doesn't that depend on whether the context is running? The LRI reload has the side effect of flushing all current knowledge of mappings, so every level of PD gets refreshed from memory. If we're not updating the top level PDPs, and we know the context isn't active, then we *assume* that lower-level PDs will be refreshed when the context is next loaded. (This hasn't been true on all hardware, some of which cached previously-retrieved PDs across ctx save-and-reload, and that's one reason why there's a "Force PD Restore" bit, but we've been told not to use it on current h/w). AFAICT, current chips don't cache previous PDs and don't need the "Force" bit for this case. OTOH, if we don't know whether the context is running, then we can't be sure when (or whether) any PD updates will be seen. As long as the changes of interest are only ever *from* NULL *to* non-NULL, we *expect* it to work, because (we *assume*) the GPU won't cache negative results from PD lookups; so any lookup that previously hit an invalid mapping will be re-fetched next time it's required (and may now be good). If we don't reload the PDPs with LRIs, then perhaps to be safe we need to inject some other instruction that will just force a re-fetch of the lower-level PDs from memory, without altering any top-level PDPs? In conjunction with preallocating the top-level entries, that ought to guarantee that the updates would be seen just before the point where they're about to be used? .Dave. ___ 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: Commit planes on each crtc separately.
On Wed, 12 Aug 2015, Ander Conselvan De Oliveira wrote:
> For both patches,
>
> Reviewed-by: Ander Conselvan de Oliveira
Both pushed to drm-intel-fixes, thanks for the patches and review.
BR,
Jani.
>
> On Tue, 2015-08-11 at 12:31 +0200, Maarten Lankhorst wrote:
>> This patch is based on the upstream commit 5ac1c4bcf073ad and amended
>> for v4.2 to make sure it works as intended.
>>
>> Repeated calls to begin_crtc_commit can cause warnings like this:
>> [ 169.127746] BUG: sleeping function called from invalid context at
>> kernel/locking/mutex.c:616
>> [ 169.127835] in_atomic(): 0, irqs_disabled(): 1, pid: 1947, name: kms_flip
>> [ 169.127840] 3 locks held by kms_flip/1947:
>> [ 169.127843] #0: (&dev->mode_config.mutex){+.+.+.}, at:
>> []
>> __drm_modeset_lock_all+0x9c/0x130
>> [ 169.127860] #1: (crtc_ww_class_acquire){+.+.+.}, at:
>> []
>> __drm_modeset_lock_all+0xad/0x130
>> [ 169.127870] #2: (crtc_ww_class_mutex){+.+.+.}, at: []
>> drm_modeset_lock+0x38/0x110
>> [ 169.127879] irq event stamp: 665690
>> [ 169.127882] hardirqs last enabled at (665689): []
>> _raw_spin_unlock_irqrestore+0x55/0x70
>> [ 169.127889] hardirqs last disabled at (665690): []
>> intel_pipe_update_start+0x113/0x5c0 [i915]
>> [ 169.127936] softirqs last enabled at (665470): []
>> __do_softirq+0x236/0x650
>> [ 169.127942] softirqs last disabled at (665465): []
>> irq_exit+0xc5/0xd0
>> [ 169.127951] CPU: 1 PID: 1947 Comm: kms_flip Not tainted 4.1.0-rc4-patser+
>> #4039
>> [ 169.127954] Hardware name: LENOVO 2349AV8/2349AV8, BIOS G1ETA5WW (2.65 )
>> 04/15/2014
>> [ 169.127957] 8800c49036f0 8800cde5fa28 817f6907
>> 8001
>> [ 169.127964] 8800cde5fa58 810aebed
>> 0046
>> [ 169.127970] 81c5d518 0268
>> 8800cde5fa88
>> [ 169.127981] Call Trace:
>> [ 169.127992] [] dump_stack+0x4f/0x7b
>> [ 169.128001] [] ___might_sleep+0x16d/0x270
>> [ 169.128008] [] __might_sleep+0x48/0x90
>> [ 169.128017] [] mutex_lock_nested+0x29/0x410
>> [ 169.128073] [] ? vgpu_write64+0x220/0x220 [i915]
>> [ 169.128138] [] ?
>> ironlake_update_primary_plane+0x2ff/0x410 [i915]
>> [ 169.128198] [] intel_frontbuffer_flush+0x25/0x70 [i915]
>> [ 169.128253] [] intel_finish_crtc_commit+0x4c/0x180
>> [i915]
>> [ 169.128279] []
>> drm_atomic_helper_commit_planes+0x12c/0x240 [drm_kms_helper]
>> [ 169.128338] [] __intel_set_mode+0x684/0x830 [i915]
>> [ 169.128378] [] intel_crtc_set_config+0x49a/0x620 [i915]
>> [ 169.128385] [] ? mutex_unlock+0x9/0x10
>> [ 169.128391] [] drm_mode_set_config_internal+0x69/0x120
>> [ 169.128398] [] ? might_fault+0x57/0xb0
>> [ 169.128403] [] drm_mode_setcrtc+0x253/0x620
>> [ 169.128409] [] drm_ioctl+0x1a0/0x6a0
>> [ 169.128415] [] ? get_parent_ip+0x11/0x50
>> [ 169.128424] [] do_vfs_ioctl+0x2f8/0x530
>> [ 169.128429] [] ? trace_hardirqs_on+0xd/0x10
>> [ 169.128435] [] ? selinux_file_ioctl+0x56/0x100
>> [ 169.128439] [] SyS_ioctl+0x81/0xa0
>> [ 169.128445] [] system_call_fastpath+0x12/0x6f
>>
>> Solve it by using the newly introduced
>> drm_atomic_helper_commit_planes_on_crtc.
>>
>> The problem here was that the drm_atomic_helper_commit_planes() helper
>> we were using was basically designed to do
>>
>> begin_crtc_commit(crtc #1)
>> begin_crtc_commit(crtc #2)
>> ...
>> commit all planes
>> finish_crtc_commit(crtc #1)
>> finish_crtc_commit(crtc #2)
>>
>> The problem here is that since our hardware relies on vblank evasion,
>> our CRTC 'begin' function waits until we're out of the danger zone in
>> which register writes might wind up straddling the vblank, then disables
>> interrupts; our 'finish' function re-enables interrupts after the
>> registers have been written. The expectation is that the operations between
>> 'begin' and 'end' must be performed without sleeping (since interrupts
>> are disabled) and should happen as quickly as possible. By clumping all
>> of the 'begin' calls together, we introducing a couple problems:
>> * Subsequent 'begin' invocations might sleep (which is illegal)
>> * The first 'begin' ensured that we were far enough from the vblank that
>>we could write our registers safely and ensure they all fell within
>>the same frame. Adding extra delay waiting for subsequent CRTC's
>>wasn't accounted for and could put us back into the 'danger zone' for
>>CRTC #1.
>>
>> This commit solves the problem by using a new helper that allows an
>> order of operations like:
>>
>>for each crtc {
>> begin_crtc_commit(crtc) // sleep (maybe), then disable interrupts
>> commit planes for this specific CRTC
>> end_crtc_commit(crtc)// reenable interrupts
>>}
>>
>> so that sleeps will only be performed while interrupts are enabled and
>> we can be sure that registers for a CRTC will be written immediately
>> once we know we're in the safe zone.
>>
>> The crt
Re: [Intel-gfx] [4.2-rc4] acpi|drm|i915: circular locking dependency: acpi_video_get_backlight_type
On Thu, Aug 13, 2015 at 08:52:23AM +0200, Sedat Dilek wrote:
> On Wed, Aug 12, 2015 at 9:26 PM, Ville Syrjälä
> wrote:
> > On Mon, Aug 10, 2015 at 08:29:00PM +0200, Sedat Dilek wrote:
> >> On Sat, Aug 1, 2015 at 2:23 PM, Sedat Dilek wrote:
> >> > On Mon, Jul 27, 2015 at 12:33 AM, Sedat Dilek
> >> > wrote:
> >> >> Hi,
> >> >>
> >> >> this my first build of a 4.2-rcN Linux-kernel and I see this...
> >> >>
> >> >
> >> > Just FYI:
> >> >
> >> > I am *not* seeing this with drm-intel-nightly from below url.
> >> >
> >> > Also, I plan to test Linux v4.2-rc5.
> >> >
> >>
> >> [ CC Linus ]
> >>
> >> Knock Knock Knock.
> >>
> >> This issue still remains here (with CONFIG_DRM_I915=m)...
> >>
> >> [ 18.269792] ==
> >> [ 18.269798] [ INFO: possible circular locking dependency detected ]
> >> [ 18.269805] 4.2.0-rc6-1-iniza-small #1 Not tainted
> >> [ 18.269810] ---
> >> [ 18.269816] modprobe/727 is trying to acquire lock:
> >> [ 18.269822] (init_mutex){+.+.+.}, at: []
> >> acpi_video_get_backlight_type+0x17/0x164 [video]
> >> [ 18.269840]
> >> [ 18.269840] but task is already holding lock:
> >> [ 18.269848] (&(&backlight_notifier)->rwsem){..}, at:
> >> [] __blocking_notifier_call_chain+0x39/0x70
> >> [ 18.269864]
> >> [ 18.269864] which lock already depends on the new lock.
> >> [ 18.269864]
> >> [ 18.269875]
> >> [ 18.269875] the existing dependency chain (in reverse order) is:
> >> [ 18.269884]
> >> ...
> >>
> >> Full dmesg log and kernel-config attached.
> >>
> >> Shall I add Rusty and modules/modprobe folks?
> >
> > Just got back from vacation and was greeted by this same lockdep splat.
> >
> > On a hunch I reverted
> >
> > commit 93a291dfaf9c328ca5a9cea1733af1a128efe890
> > Author: Hans de Goede
> > Date: Tue Jun 16 16:27:52 2015 +0200
> >
> > ACPI / video: Move backlight notifier to video_detect.c
> >
> > and the problem seems to be gone. Hans, any thoughts?
> >
>
> Reverting this commit on top of Linux v4.2-rc6 causes troubles here.
>
> $ LC_ALL=C git revert 93a291dfaf9c328ca5a9cea1733af1
> error: could not revert 93a291dfaf9c... ACPI / video: Move backlight
> notifier to video_detect.c
> hint: after resolving the conflicts, mark the corrected paths
> hint: with 'git add ' or 'git rm '
> hint: and commit the result with 'git commit'
>
> Provide a suitable patch and I test for you.
Hmm. Oh yeah, I had to revert a couple of other ones to get the first
one to revert cleanly:
commit d0a530ba424ec1be7630f7fce2db9860b9429b8f
Author: Hans de Goede
Date: Tue Jun 16 16:28:12 2015 +0200
acpi-video-detect: Remove old API
commit e7d024c00a4a7b617390db863bdd5b9dc65821f7
Author: Hans de Goede
Date: Tue Jun 16 16:28:13 2015 +0200
ACPI / video: Make acpi_video_unregister_backlight() private
>
> - Sedat -
>
> >>
> >> - Sedat -
> >>
> >> > - Sedat -
> >> >
> >> > [1]
> >> > http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2015-08-01-unstable/
> >> > [2]
> >> > http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2015-08-01-unstable/linux-image-4.2.0-994-generic_4.2.0-994.201508010158_amd64.deb
> >> >
> >> >> [ 24.001043] [drm] Memory usable by graphics device = 2048M
> >> >> [ 24.001118] [drm] Replacing VGA console driver
> >> >> [ 24.011642] [drm] Supports vblank timestamp caching Rev 2
> >> >> (21.10.2013).
> >> >> [ 24.011646] [drm] Driver supports precise vblank timestamp query.
> >> >> [ 24.012480] vgaarb: device changed decodes:
> >> >> PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
> >> >> [ 24.028005]
> >> >> [ 24.028014] ==
> >> >> [ 24.028020] [ INFO: possible circular locking dependency detected ]
> >> >> [ 24.028027] 4.2.0-rc4-1-iniza-small #1 Not tainted
> >> >> [ 24.028032] ---
> >> >> [ 24.028038] modprobe/740 is trying to acquire lock:
> >> >> [ 24.028043] (init_mutex){+.+.+.}, at: []
> >> >> acpi_video_get_backlight_type+0x17/0x164 [video]
> >> >> [ 24.028060]
> >> >> [ 24.028060] but task is already holding lock:
> >> >> [ 24.028068] (&(&backlight_notifier)->rwsem){..}, at:
> >> >> [] __blocking_notifier_call_chain+0x39/0x70
> >> >> [ 24.028083]
> >> >> [ 24.028083] which lock already depends on the new lock.
> >> >> [ 24.028083]
> >> >> [ 24.028095]
> >> >> [ 24.028095] the existing dependency chain (in reverse order) is:
> >> >> [ 24.028103]
> >> >> [ 24.028103] -> #1 (&(&backlight_notifier)->rwsem){..}:
> >> >> [ 24.028113][] lock_acquire+0xcf/0x280
> >> >> [ 24.028121][] down_write+0x49/0x80
> >> >> [ 24.028129][]
> >> >> blocking_notifier_chain_register+0x21/0xb0
> >> >> [ 24.028138][]
> >> >> backlight_register_notifier+0x18/0x20
> >> >> [ 24.028147][]
> >> >> acpi_video_get_backlight_t
Re: [Intel-gfx] [PATCH 1/7] drm/i915: Clean up DP/HDMI limited color range handling
On Thu, Aug 13, 2015 at 11:46:56AM +0530, Sivakumar Thulasimani wrote:
> sdvo is still using color_range name in it's functions. would be good to
> rename that as well along with dp & hdmi done here.
Doh. I forgot about sdvo completely. I'll take a look to make sure it
conforms to the same style. Thanks for spotting it.
>
> otherwise changes are fine
> Reviewed-by: Sivakumar Thulasimani
>
> On Monday 06 July 2015 05:40 PM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Currently we treat intel_{dp,hdmi}->color_range as partly user
> > controller value (via the property) but we also change it during
> > .compute_config() when using the "Automatic" mode. That is a bit
> > confusing, so let's just change things so that we store the user
> > property values in intel_dp, and only change what's stored in
> > pipe_config during .compute_config().
> >
> > There should be no functional change.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 25 -
> > drivers/gpu/drm/i915/intel_drv.h | 4 ++--
> > drivers/gpu/drm/i915/intel_hdmi.c | 26 --
> > 3 files changed, 26 insertions(+), 29 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index fcc64e5..decefa1 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -1455,15 +1455,13 @@ found:
> > * CEA-861-E - 5.1 Default Encoding Parameters
> > * VESA DisplayPort Ver.1.2a - 5.1.1.1 Video Colorimetry
> > */
> > - if (bpp != 18 && drm_match_cea_mode(adjusted_mode) > 1)
> > - intel_dp->color_range = DP_COLOR_RANGE_16_235;
> > - else
> > - intel_dp->color_range = 0;
> > + pipe_config->limited_color_range =
> > + bpp != 18 && drm_match_cea_mode(adjusted_mode) > 1;
> > + } else {
> > + pipe_config->limited_color_range =
> > + intel_dp->limited_color_range;
> > }
> >
> > - if (intel_dp->color_range)
> > - pipe_config->limited_color_range = true;
> > -
> > intel_dp->lane_count = lane_count;
> >
> > if (intel_dp->num_sink_rates) {
> > @@ -1605,8 +1603,9 @@ static void intel_dp_prepare(struct intel_encoder
> > *encoder)
> > trans_dp &= ~TRANS_DP_ENH_FRAMING;
> > I915_WRITE(TRANS_DP_CTL(crtc->pipe), trans_dp);
> > } else {
> > - if (!HAS_PCH_SPLIT(dev) && !IS_VALLEYVIEW(dev))
> > - intel_dp->DP |= intel_dp->color_range;
> > + if (!HAS_PCH_SPLIT(dev) && !IS_VALLEYVIEW(dev) &&
> > + crtc->config->limited_color_range)
> > + intel_dp->DP |= DP_COLOR_RANGE_16_235;
> >
> > if (adjusted_mode->flags & DRM_MODE_FLAG_PHSYNC)
> > intel_dp->DP |= DP_SYNC_HS_HIGH;
> > @@ -4663,7 +4662,7 @@ intel_dp_set_property(struct drm_connector *connector,
> >
> > if (property == dev_priv->broadcast_rgb_property) {
> > bool old_auto = intel_dp->color_range_auto;
> > - uint32_t old_range = intel_dp->color_range;
> > + bool old_range = intel_dp->limited_color_range;
> >
> > switch (val) {
> > case INTEL_BROADCAST_RGB_AUTO:
> > @@ -4671,18 +4670,18 @@ intel_dp_set_property(struct drm_connector
> > *connector,
> > break;
> > case INTEL_BROADCAST_RGB_FULL:
> > intel_dp->color_range_auto = false;
> > - intel_dp->color_range = 0;
> > + intel_dp->limited_color_range = false;
> > break;
> > case INTEL_BROADCAST_RGB_LIMITED:
> > intel_dp->color_range_auto = false;
> > - intel_dp->color_range = DP_COLOR_RANGE_16_235;
> > + intel_dp->limited_color_range = true;
> > break;
> > default:
> > return -EINVAL;
> > }
> >
> > if (old_auto == intel_dp->color_range_auto &&
> > - old_range == intel_dp->color_range)
> > + old_range == intel_dp->limited_color_range)
> > return 0;
> >
> > goto done;
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 3f0a890..983a7a7 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -669,7 +669,7 @@ struct cxsr_latency {
> > struct intel_hdmi {
> > u32 hdmi_reg;
> > int ddc_bus;
> > - uint32_t color_range;
> > + bool limited_color_range;
> > bool color_range_auto;
> > bool has_hdmi_sink;
> > bool has_audio;
> > @@ -714,7 +714,7 @@ struct intel_dp {
> > uint32_t DP;
> > bool has_audio;
> > enum hdmi_force_audio force_audio;
> > - uint32_t color_range;
>
Re: [Intel-gfx] [PATCH 02/21] drm/i915/gtt: Workaround for HW preload not flushing pdps
On 13/08/15 12:42, Dave Gordon wrote: On 13/08/15 11:12, Michel Thierry wrote: On 8/13/2015 5:08 PM, Zhiyuan Lv wrote: Hi Michel, Thanks for the reply! I yet have another question: right now the mark_tlb_dirty() will be called if any level of PPGTT table is changed. But for the EXECLIST context submission, we only need LRI commands if there are L3 PDP root pointer changes right? Thanks! mark_tlbs_dirty is not only for execlists mode, we re-used it since it was already there. The update is only required when a PDP is allocated. -Michel Doesn't that depend on whether the context is running? The LRI reload has the side effect of flushing all current knowledge of mappings, so every level of PD gets refreshed from memory. If we're not updating the top level PDPs, and we know the context isn't active, then we *assume* that lower-level PDs will be refreshed when the context is next loaded. (This hasn't been true on all hardware, some of which cached previously-retrieved PDs across ctx save-and-reload, and that's one reason why there's a "Force PD Restore" bit, but we've been told not to use it on current h/w). AFAICT, current chips don't cache previous PDs and don't need the "Force" bit for this case. OTOH, if we don't know whether the context is running, then we can't be sure when (or whether) any PD updates will be seen. As long as the changes of interest are only ever *from* NULL *to* non-NULL, we *expect* it to work, because (we *assume*) the GPU won't cache negative results from PD lookups; so any lookup that previously hit an invalid mapping will be re-fetched next time it's required (and may now be good). If we don't reload the PDPs with LRIs, then perhaps to be safe we need to inject some other instruction that will just force a re-fetch of the lower-level PDs from memory, without altering any top-level PDPs? In conjunction with preallocating the top-level entries, that ought to guarantee that the updates would be seen just before the point where they're about to be used? .Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx I found the following comment in the BSpec: "Pre-loading of Page Directory Entries (PD load) for 32b legacy mode is not supported from Gen9 onwards. PD entries are loaded on demand when there is a miss in the PDE cache of the corresponding page walker. Any new page additions by the driver are transparent to the HW, and the new page translations will be fetched on demand. However, any removal of the pages by the driver should initiate a TLB invalidation to remove the stale entries." So, I think that confirms that we should inject some form of TLB invalidation into the ring before the next batch uses any updated PDs. Presumably an MI_FLUSH_DW with TLB_INVALIDATE would do? .Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] tools/null_state/gen9: Send atleast one valid component in VF state
Ben Widawsky writes: > On Fri, Jul 31, 2015 at 04:27:07PM +0100, Arun Siluvery wrote: >> A programming restriction exists for this instruction, atleast one component >> of one valid vertex element must be enabled. >> >> Cc: Ben Widawsky >> Cc: Chris Wilson >> Signed-off-by: Arun Siluvery >> --- >> tools/null_state_gen/intel_renderstate_gen9.c | 7 ++- >> 1 file changed, 6 insertions(+), 1 deletion(-) >> >> diff --git a/tools/null_state_gen/intel_renderstate_gen9.c >> b/tools/null_state_gen/intel_renderstate_gen9.c >> index 6f808f8..b3766ea 100644 >> --- a/tools/null_state_gen/intel_renderstate_gen9.c >> +++ b/tools/null_state_gen/intel_renderstate_gen9.c >> @@ -440,7 +440,12 @@ int gen9_setup_null_render_state(struct >> intel_batchbuffer *batch) >> /* Vertex buffers */ >> gen8_emit_vertex_buffers(batch); >> gen8_emit_vertex_elements(batch); >> -OUT_CMD(GEN9_3DSTATE_COMPONENT_PACKING, 5); >> + >> +OUT_BATCH(GEN9_3DSTATE_COMPONENT_PACKING | 3); >> +OUT_BATCH(1); >> +OUT_BATCH(0); >> +OUT_BATCH(0); >> +OUT_BATCH(0); >> >> OUT_BATCH(GEN6_3DSTATE_VF_STATISTICS | 1 /* Enable */); >> > > Like I said on IRC, I don't think this does anything unless you set bit 9 of > 3DSTATE_VF.0. Also, I believe you should be setting 0xf, not 1 since you'd > want > to use all 4 components. > > So I'm not really sure what we're aiming to do. If you make it 0xf, and add a > comment about how this command doesn't do anything because we're not setting > up > 3DSTATE_VF packing, it's: > Reviewed-by: Ben Widawsky > I messed with this one. The version with 0x1 went with your r-b. The generator side change only so we can amend the version that gets committed to kernel side still. Sorry about this. -Mika > I'm still more in favor of dropping the command altogether, that too would be: > Reviewed-by: Ben Widawsky > > -- > Ben Widawsky, Intel Open Source Technology Center > ___ > 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] [PATCH 3/3] drm/i915/bxt: WA for swapped HPD pins in A stepping
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 7125 -Summary- Platform Delta drm-intel-nightly Series Applied ILK -1 302/302 301/302 SNB 315/315 315/315 IVB 336/336 336/336 BYT 283/283 283/283 HSW 378/378 378/378 -Detailed- Platform Testdrm-intel-nightly Series Applied *ILK igt@kms_flip@flip-vs-dpms-interruptible PASS(1) DMESG_WARN(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] tools/null_state/gen9: Send all components in VF state
Fix commit 59cdc16b1a6f069f944ff17851a59edf8f72d45d Author: Arun Siluvery Date: Fri Jul 31 16:27:07 2015 +0100 tools/null_state/gen9: Send atleast one valid component in VF state to honor the Reviewed-by, send all four components as noted by Ben in his review. Cc: Ben Widawsky Cc: Arun Siluvery Signed-off-by: Mika Kuoppala --- tools/null_state_gen/intel_renderstate_gen9.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/null_state_gen/intel_renderstate_gen9.c b/tools/null_state_gen/intel_renderstate_gen9.c index b3766ea..37bc675 100644 --- a/tools/null_state_gen/intel_renderstate_gen9.c +++ b/tools/null_state_gen/intel_renderstate_gen9.c @@ -442,7 +442,7 @@ int gen9_setup_null_render_state(struct intel_batchbuffer *batch) gen8_emit_vertex_elements(batch); OUT_BATCH(GEN9_3DSTATE_COMPONENT_PACKING | 3); - OUT_BATCH(1); + OUT_BATCH(0xf); OUT_BATCH(0); OUT_BATCH(0); OUT_BATCH(0); -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2 v2 addendum v2] drm/i915: Allow parsing of variable size child device entries from VBT
On Wed, Aug 12, 2015 at 05:19:35PM +0300, Jani Nikula wrote:
> On Wed, 12 Aug 2015, David Weinehall wrote:
> > Some more fixup is needed; the bits from Antti's patch
> > that actually expanded the struct to fully fit the newer
> > versions of the child_device_config was part of the second
> > patch; since that patch hasn't been merged yet we need this bit:
> >
> > This applies on top of the patch you already merged
> > (the Iboost patch will need corresponding adjustment to
> > remove the changes I split out):
> >
> > Expand common_child_dev_config to be able to fit all information
> > defined by the latest VBT specification.
> >
> > Signed-off-by: David Weinehall
> > CC: Antti Koskipaa
> > ---
> > intel_bios.c |7 ++-
> > intel_bios.h |4
> > 2 files changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_bios.c
> > b/drivers/gpu/drm/i915/intel_bios.c
> > index 990acc20771a..40e2cc4e7419 100644
> > --- a/drivers/gpu/drm/i915/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/intel_bios.c
> > @@ -1038,6 +1038,10 @@ parse_device_mapping(struct drm_i915_private
> > *dev_priv,
> > DRM_DEBUG_KMS("No general definition block is found, no devices
> > defined.\n");
> > return;
> > }
> > + /* Remember to keep this in sync with child_device_config;
> > +* whenever a new feature is added to BDB that causes that
> > +* struct to grow this needs to be updated too
> > +*/
> > if (bdb->version < 195) {
> > expected_size = 33;
> > } else if (bdb->version == 195) {
> > @@ -1051,7 +1055,8 @@ parse_device_mapping(struct drm_i915_private
> > *dev_priv,
> > }
> >
> > if (expected_size > sizeof(*p_child)) {
> > - DRM_ERROR("child_device_config cannot fit in p_child\n");
> > + DRM_ERROR("child_device_config (size %u) cannot fit in p_child
> > (size %u); bdb->version: %u\n",
> > + expected_size, sizeof(*p_child), bdb->version);
>
> drivers/gpu/drm/i915/intel_bios.c: In function ‘parse_device_mapping’:
> drivers/gpu/drm/i915/intel_bios.c:1058:3: warning: format ‘%u’ expects
> argument of type ‘unsigned int’, but argument 3 has type ‘long unsigned int’
> [-Wformat=]
>DRM_ERROR("child_device_config (size %u) cannot fit in p_child (size %u);
> bdb->version: %u\n",
>^
> CC [M] drivers/gpu/drm/i915/intel_fifo_underrun.o
Well spotted. Or rather, stupid of me to forget that sizeof yields
size_t as type, thus necessitating %zu as conversion specifier.
Fixed version:
Expand common_child_dev_config to be able to fit all information
defined by the latest VBT specification.
v2: Use proper conversion specifier for size_t (%zu)
Signed-off-by: David Weinehall
CC: Antti Koskipaa
intel_bios.c |7 ++-
intel_bios.h |4
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 990acc20771a..5673ed53797b 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1038,6 +1038,10 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
DRM_DEBUG_KMS("No general definition block is found, no devices
defined.\n");
return;
}
+ /* Remember to keep this in sync with child_device_config;
+* whenever a new feature is added to BDB that causes that
+* struct to grow this needs to be updated too
+*/
if (bdb->version < 195) {
expected_size = 33;
} else if (bdb->version == 195) {
@@ -1051,7 +1055,8 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
}
if (expected_size > sizeof(*p_child)) {
- DRM_ERROR("child_device_config cannot fit in p_child\n");
+ DRM_ERROR("child_device_config (size %u) cannot fit in p_child
(size %zu); bdb->version: %u\n",
+ expected_size, sizeof(*p_child), bdb->version);
return;
}
diff --git a/drivers/gpu/drm/i915/intel_bios.h
b/drivers/gpu/drm/i915/intel_bios.h
index f7ad6a585129..71cb96f77870 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -239,6 +239,10 @@ struct common_child_dev_config {
u8 not_common2[2];
u8 ddc_pin;
u16 edid_ptr;
+ u8 obsolete;
+ u8 flags_1;
+ u8 not_common3[13];
+ u8 iboost_level;
} __packed;
/* This field changes depending on the BDB version, so the most reliable way to
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] mmap on the dma-buf directly
On 08/13/2015 08:09 AM, Thomas Hellstrom wrote:
Tiago,
I take it, this is intended to be a generic interface used mostly for 2D
rendering.
yup. "generic" is an important point that I've actually forgot to
mention in the description, which is probably the whole motivation for
bringing this up.
We want avoid link any vendor-specific library to the unpriviledged
process for security reasons, so it's a requirement to it not have
access to driver-specific ioctls when mapping the buffers. The use-case
for it is texturing from CPU rendered buffer, like you said, with the
intention of passing these buffers among processes without performing
any copy in the user-space ("zero-copy").
In that case, using SYNC is crucial for performance of incoherent
architectures and I'd rather see it mandatory than an option. It could
perhaps be made mandatory preferrably using an error or a one-time
kernel warning. If nobody uses the SYNC interface, it is of little use.
hmm I'm not sure it is little use. Our hardware (the "LLC" capable) has
this very specific case where the cache gets dirty wrt the GPU, which is
when the same buffer is shared with the scanout device. This is not
something will happen in Chrome OS for example, so we wouldn't need the
SYNC markers there.
In any case I think that making it mandatory works for us, but I'll have
to check with Daniel/Chris whether there are performance penalties when
accessing it and so on.
Also I think the syncing needs to be extended to two dimensions. A long
time ago when this was brought up people argued why we should limit it
to two dimensions, but I believe two dimensions addresses most
performance-problematic use-cases. A default implementation of
twodimensional sync can easily be made using the one-dimensional API.
two dimension sync? You're saying that there could be a GPU access API
in dma-buf as well? I don't get it, what's the use-case? I'm sure I
missed the discussions because I wasn't particularly interested in this
whole thingy before :)
Thanks for reviewing, Thomas.
Tiago
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/7] prime_mmap: Add basic tests to write in a bo using CPU
On 08/13/2015 04:01 AM, Daniel Vetter wrote:
On Wed, Aug 12, 2015 at 08:29:16PM -0300, Tiago Vignatti wrote:
This patch adds test_correct_cpu_write, which maps the texture buffer through a
prime fd and then writes directly to it using the CPU. It stresses the driver
to guarantee cache synchronization among the different domains.
This test also adds test_forked_cpu_write, which creates the GEM bo in one
process and pass the prime handle of the it to another process, which in turn
uses the handle only to map and write. Grossly speaking this test simulates
Chrome OS architecture, where the Web content ("unpriviledged process") maps
and CPU-draws a buffer, which was previously allocated in the GPU process
("priviledged process").
This requires kernel modifications (Daniel Thompson's "drm: prime: Honour
O_RDWR during prime-handle-to-fd").
Signed-off-by: Tiago Vignatti
Squash with previous patch?
why? if the whole point is to decrease the amount of patches, then I
prefer to squash 2/7 with the 1/7 (although they're from different
authors and would be nice to keep separately the changes from each).
This patch here introduces this writing to mmap'ed dma-buf fd, a concept
that is still in debate, requiring a kernel counter-part so that's why I
preferred to keep it away.
---
lib/ioctl_wrappers.c | 5 +++-
tests/prime_mmap.c | 65
2 files changed, 69 insertions(+), 1 deletion(-)
diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index 53bd635..941fa66 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -1125,6 +1125,9 @@ void gem_require_ring(int fd, int ring_id)
/* prime */
+#ifndef DRM_RDWR
+#define DRM_RDWR O_RDWR
+#endif
/**
* prime_handle_to_fd:
* @fd: open i915 drm file descriptor
@@ -1142,7 +1145,7 @@ int prime_handle_to_fd(int fd, uint32_t handle)
memset(&args, 0, sizeof(args));
args.handle = handle;
- args.flags = DRM_CLOEXEC;
+ args.flags = DRM_CLOEXEC | DRM_RDWR;
This needs to be optional otherwise all the existing prime tests start
falling over on older kernels. Probably need a
prime_handle_to_fd_with_mmap, which doesn an igt_skip if it fails.
true. Thank you.
-Daniel
args.fd = -1;
do_ioctl(fd, DRM_IOCTL_PRIME_HANDLE_TO_FD, &args);
diff --git a/tests/prime_mmap.c b/tests/prime_mmap.c
index dc59e8f..ad91371 100644
--- a/tests/prime_mmap.c
+++ b/tests/prime_mmap.c
@@ -22,6 +22,7 @@
*
* Authors:
*Rob Bradford
+ *Tiago Vignatti
*
*/
@@ -66,6 +67,12 @@ fill_bo(uint32_t handle, size_t size)
}
static void
+fill_bo_cpu(char *ptr)
+{
+ memcpy(ptr, pattern, sizeof(pattern));
+}
+
+static void
test_correct(void)
{
int dma_buf_fd;
@@ -180,6 +187,62 @@ test_forked(void)
gem_close(fd, handle);
}
+/* test CPU write. This has a rather big implication for the driver which must
+ * guarantee cache synchronization when writing the bo using CPU. */
+static void
+test_correct_cpu_write(void)
+{
+ int dma_buf_fd;
+ char *ptr;
+ uint32_t handle;
+
+ handle = gem_create(fd, BO_SIZE);
+
+ dma_buf_fd = prime_handle_to_fd(fd, handle);
+ igt_assert(errno == 0);
+
+ /* Check correctness of map using write protection (PROT_WRITE) */
+ ptr = mmap(NULL, BO_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED,
dma_buf_fd, 0);
+ igt_assert(ptr != MAP_FAILED);
+
+ /* Fill bo using CPU */
+ fill_bo_cpu(ptr);
+
+ /* Check pattern correctness */
+ igt_assert(memcmp(ptr, pattern, sizeof(pattern)) == 0);
+
+ munmap(ptr, BO_SIZE);
+ close(dma_buf_fd);
+ gem_close(fd, handle);
+}
+
+/* map from another process and then write using CPU */
+static void
+test_forked_cpu_write(void)
+{
+ int dma_buf_fd;
+ char *ptr;
+ uint32_t handle;
+
+ handle = gem_create(fd, BO_SIZE);
+
+ dma_buf_fd = prime_handle_to_fd(fd, handle);
+ igt_assert(errno == 0);
+
+ igt_fork(childno, 1) {
+ ptr = mmap(NULL, BO_SIZE, PROT_READ | PROT_WRITE , MAP_SHARED,
dma_buf_fd, 0);
+ igt_assert(ptr != MAP_FAILED);
+ fill_bo_cpu(ptr);
+
+ igt_assert(memcmp(ptr, pattern, sizeof(pattern)) == 0);
+ munmap(ptr, BO_SIZE);
+ close(dma_buf_fd);
+ }
+ close(dma_buf_fd);
+ igt_waitchildren();
+ gem_close(fd, handle);
+}
+
static void
test_refcounting(void)
{
@@ -346,6 +409,8 @@ igt_main
{ "test_map_unmap", test_map_unmap },
{ "test_reprime", test_reprime },
{ "test_forked", test_forked },
+ { "test_correct_cpu_write", test_correct_cpu_write },
+ { "test_forked_cpu_write", test_forked_cpu_write },
{ "test_refcounting", test_refcounting },
{ "test_dup", test_dup },
{ "test_errors", test_errors },
--
2.1.0
Re: [Intel-gfx] [4.2-rc4] acpi|drm|i915: circular locking dependency: acpi_video_get_backlight_type
Hi,
On 12-08-15 21:26, Ville Syrjälä wrote:
On Mon, Aug 10, 2015 at 08:29:00PM +0200, Sedat Dilek wrote:
On Sat, Aug 1, 2015 at 2:23 PM, Sedat Dilek wrote:
On Mon, Jul 27, 2015 at 12:33 AM, Sedat Dilek wrote:
Hi,
this my first build of a 4.2-rcN Linux-kernel and I see this...
Just FYI:
I am *not* seeing this with drm-intel-nightly from below url.
Also, I plan to test Linux v4.2-rc5.
[ CC Linus ]
Knock Knock Knock.
This issue still remains here (with CONFIG_DRM_I915=m)...
[ 18.269792] ==
[ 18.269798] [ INFO: possible circular locking dependency detected ]
[ 18.269805] 4.2.0-rc6-1-iniza-small #1 Not tainted
[ 18.269810] ---
[ 18.269816] modprobe/727 is trying to acquire lock:
[ 18.269822] (init_mutex){+.+.+.}, at: []
acpi_video_get_backlight_type+0x17/0x164 [video]
[ 18.269840]
[ 18.269840] but task is already holding lock:
[ 18.269848] (&(&backlight_notifier)->rwsem){..}, at:
[] __blocking_notifier_call_chain+0x39/0x70
[ 18.269864]
[ 18.269864] which lock already depends on the new lock.
[ 18.269864]
[ 18.269875]
[ 18.269875] the existing dependency chain (in reverse order) is:
[ 18.269884]
...
Full dmesg log and kernel-config attached.
Shall I add Rusty and modules/modprobe folks?
Just got back from vacation and was greeted by this same lockdep splat.
On a hunch I reverted
commit 93a291dfaf9c328ca5a9cea1733af1a128efe890
Author: Hans de Goede
Date: Tue Jun 16 16:27:52 2015 +0200
ACPI / video: Move backlight notifier to video_detect.c
and the problem seems to be gone. Hans, any thoughts?
Looking into this atm, lockdep clearly is right.
Sorry about this I have put a lot of thinking into avoiding
these kind of issues with this patch-set, but I did not realize
there was another lock "hiding" inside the notifier-chain.
Further analysis shows that the lock inside the notifier-chain
causes similar problems vs register_count_mutex from
drivers/acpi/acpi_video.c. I'm working on a fix for this
atm.
Regards,
Hans
- Sedat -
- Sedat -
[1]
http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2015-08-01-unstable/
[2]
http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2015-08-01-unstable/linux-image-4.2.0-994-generic_4.2.0-994.201508010158_amd64.deb
[ 24.001043] [drm] Memory usable by graphics device = 2048M
[ 24.001118] [drm] Replacing VGA console driver
[ 24.011642] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 24.011646] [drm] Driver supports precise vblank timestamp query.
[ 24.012480] vgaarb: device changed decodes:
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[ 24.028005]
[ 24.028014] ==
[ 24.028020] [ INFO: possible circular locking dependency detected ]
[ 24.028027] 4.2.0-rc4-1-iniza-small #1 Not tainted
[ 24.028032] ---
[ 24.028038] modprobe/740 is trying to acquire lock:
[ 24.028043] (init_mutex){+.+.+.}, at: []
acpi_video_get_backlight_type+0x17/0x164 [video]
[ 24.028060]
[ 24.028060] but task is already holding lock:
[ 24.028068] (&(&backlight_notifier)->rwsem){..}, at:
[] __blocking_notifier_call_chain+0x39/0x70
[ 24.028083]
[ 24.028083] which lock already depends on the new lock.
[ 24.028083]
[ 24.028095]
[ 24.028095] the existing dependency chain (in reverse order) is:
[ 24.028103]
[ 24.028103] -> #1 (&(&backlight_notifier)->rwsem){..}:
[ 24.028113][] lock_acquire+0xcf/0x280
[ 24.028121][] down_write+0x49/0x80
[ 24.028129][]
blocking_notifier_chain_register+0x21/0xb0
[ 24.028138][] backlight_register_notifier+0x18/0x20
[ 24.028147][]
acpi_video_get_backlight_type+0xfa/0x164 [video]
[ 24.028158][] 0xa00a20e9
[ 24.028164][] do_one_initcall+0x88/0x1c0
[ 24.028172][] do_init_module+0x61/0x1ec
[ 24.028179][] load_module+0x2008/0x25c0
[ 24.028187][] SyS_init_module+0x126/0x140
[ 24.028194][] entry_SYSCALL_64_fastpath+0x16/0x7a
[ 24.028202]
[ 24.028202] -> #0 (init_mutex){+.+.+.}:
[ 24.028211][] __lock_acquire+0x1f5d/0x21c0
[ 24.028218][] lock_acquire+0xcf/0x280
[ 24.028225][] mutex_lock_nested+0x65/0x3c0
[ 24.028233][]
acpi_video_get_backlight_type+0x17/0x164 [video]
[ 24.028243][]
acpi_video_backlight_notify+0x19/0x2f [video]
[ 24.028253][] notifier_call_chain+0x5d/0x80
[ 24.028260][]
__blocking_notifier_call_chain+0x51/0x70
[ 24.028269][]
blocking_notifier_call_chain+0x16/0x20
[ 24.028278][] backlight_device_register+0x197/0x240
[ 24.028286][]
intel_backlight_register+0xb3/0x180 [i915]
[ 24.028336][]
intel_modeset_gem_init+0x176/0x190 [i915]
[ 24.028371][] i915_driver_load+
Re: [Intel-gfx] [PATCH 3/7] prime_mmap: Add basic tests to write in a bo using CPU
On Thu, Aug 13, 2015 at 11:26:57AM -0300, Tiago Vignatti wrote:
> On 08/13/2015 04:01 AM, Daniel Vetter wrote:
> >On Wed, Aug 12, 2015 at 08:29:16PM -0300, Tiago Vignatti wrote:
> >>This patch adds test_correct_cpu_write, which maps the texture buffer
> >>through a
> >>prime fd and then writes directly to it using the CPU. It stresses the
> >>driver
> >>to guarantee cache synchronization among the different domains.
> >>
> >>This test also adds test_forked_cpu_write, which creates the GEM bo in one
> >>process and pass the prime handle of the it to another process, which in
> >>turn
> >>uses the handle only to map and write. Grossly speaking this test simulates
> >>Chrome OS architecture, where the Web content ("unpriviledged process")
> >>maps
> >>and CPU-draws a buffer, which was previously allocated in the GPU process
> >>("priviledged process").
> >>
> >>This requires kernel modifications (Daniel Thompson's "drm: prime: Honour
> >>O_RDWR during prime-handle-to-fd").
> >>
> >>Signed-off-by: Tiago Vignatti
> >
> >Squash with previous patch?
>
> why? if the whole point is to decrease the amount of patches, then I prefer
> to squash 2/7 with the 1/7 (although they're from different authors and
> would be nice to keep separately the changes from each). This patch here
> introduces this writing to mmap'ed dma-buf fd, a concept that is still in
> debate, requiring a kernel counter-part so that's why I preferred to keep it
> away.
Replied to the wrong patch, I meant merging patch 1&2 ofc ;-)
-Daniel
>
>
> >>---
> >> lib/ioctl_wrappers.c | 5 +++-
> >> tests/prime_mmap.c | 65
> >>
> >> 2 files changed, 69 insertions(+), 1 deletion(-)
> >>
> >>diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
> >>index 53bd635..941fa66 100644
> >>--- a/lib/ioctl_wrappers.c
> >>+++ b/lib/ioctl_wrappers.c
> >>@@ -1125,6 +1125,9 @@ void gem_require_ring(int fd, int ring_id)
> >>
> >> /* prime */
> >>
> >>+#ifndef DRM_RDWR
> >>+#define DRM_RDWR O_RDWR
> >>+#endif
> >> /**
> >> * prime_handle_to_fd:
> >> * @fd: open i915 drm file descriptor
> >>@@ -1142,7 +1145,7 @@ int prime_handle_to_fd(int fd, uint32_t handle)
> >>
> >>memset(&args, 0, sizeof(args));
> >>args.handle = handle;
> >>- args.flags = DRM_CLOEXEC;
> >>+ args.flags = DRM_CLOEXEC | DRM_RDWR;
> >
> >This needs to be optional otherwise all the existing prime tests start
> >falling over on older kernels. Probably need a
> >prime_handle_to_fd_with_mmap, which doesn an igt_skip if it fails.
>
> true. Thank you.
>
>
> >-Daniel
> >
> >>args.fd = -1;
> >>
> >>do_ioctl(fd, DRM_IOCTL_PRIME_HANDLE_TO_FD, &args);
> >>diff --git a/tests/prime_mmap.c b/tests/prime_mmap.c
> >>index dc59e8f..ad91371 100644
> >>--- a/tests/prime_mmap.c
> >>+++ b/tests/prime_mmap.c
> >>@@ -22,6 +22,7 @@
> >> *
> >> * Authors:
> >> *Rob Bradford
> >>+ *Tiago Vignatti
> >> *
> >> */
> >>
> >>@@ -66,6 +67,12 @@ fill_bo(uint32_t handle, size_t size)
> >> }
> >>
> >> static void
> >>+fill_bo_cpu(char *ptr)
> >>+{
> >>+ memcpy(ptr, pattern, sizeof(pattern));
> >>+}
> >>+
> >>+static void
> >> test_correct(void)
> >> {
> >>int dma_buf_fd;
> >>@@ -180,6 +187,62 @@ test_forked(void)
> >>gem_close(fd, handle);
> >> }
> >>
> >>+/* test CPU write. This has a rather big implication for the driver which
> >>must
> >>+ * guarantee cache synchronization when writing the bo using CPU. */
> >>+static void
> >>+test_correct_cpu_write(void)
> >>+{
> >>+ int dma_buf_fd;
> >>+ char *ptr;
> >>+ uint32_t handle;
> >>+
> >>+ handle = gem_create(fd, BO_SIZE);
> >>+
> >>+ dma_buf_fd = prime_handle_to_fd(fd, handle);
> >>+ igt_assert(errno == 0);
> >>+
> >>+ /* Check correctness of map using write protection (PROT_WRITE) */
> >>+ ptr = mmap(NULL, BO_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED,
> >>dma_buf_fd, 0);
> >>+ igt_assert(ptr != MAP_FAILED);
> >>+
> >>+ /* Fill bo using CPU */
> >>+ fill_bo_cpu(ptr);
> >>+
> >>+ /* Check pattern correctness */
> >>+ igt_assert(memcmp(ptr, pattern, sizeof(pattern)) == 0);
> >>+
> >>+ munmap(ptr, BO_SIZE);
> >>+ close(dma_buf_fd);
> >>+ gem_close(fd, handle);
> >>+}
> >>+
> >>+/* map from another process and then write using CPU */
> >>+static void
> >>+test_forked_cpu_write(void)
> >>+{
> >>+ int dma_buf_fd;
> >>+ char *ptr;
> >>+ uint32_t handle;
> >>+
> >>+ handle = gem_create(fd, BO_SIZE);
> >>+
> >>+ dma_buf_fd = prime_handle_to_fd(fd, handle);
> >>+ igt_assert(errno == 0);
> >>+
> >>+ igt_fork(childno, 1) {
> >>+ ptr = mmap(NULL, BO_SIZE, PROT_READ | PROT_WRITE , MAP_SHARED,
> >>dma_buf_fd, 0);
> >>+ igt_assert(ptr != MAP_FAILED);
> >>+ fill_bo_cpu(ptr);
> >>+
> >>+ igt_assert(memcmp(ptr, pattern, sizeof(pattern)) == 0);
> >>+ munmap(ptr, BO_SIZE);
> >>+ close(dma_buf_fd);
> >>+ }
> >>+ close(dma_buf_fd);
> >>+ igt_waitchildren();
> >>+ ge
Re: [Intel-gfx] [PATCH v4] mmap on the dma-buf directly
On Thu, Aug 13, 2015 at 11:09:07AM -0300, Tiago Vignatti wrote:
> On 08/13/2015 08:09 AM, Thomas Hellstrom wrote:
> >Tiago,
> >
> >I take it, this is intended to be a generic interface used mostly for 2D
> >rendering.
>
> yup. "generic" is an important point that I've actually forgot to mention in
> the description, which is probably the whole motivation for bringing this
> up.
>
> We want avoid link any vendor-specific library to the unpriviledged process
> for security reasons, so it's a requirement to it not have access to
> driver-specific ioctls when mapping the buffers. The use-case for it is
> texturing from CPU rendered buffer, like you said, with the intention of
> passing these buffers among processes without performing any copy in the
> user-space ("zero-copy").
>
> >In that case, using SYNC is crucial for performance of incoherent
> >architectures and I'd rather see it mandatory than an option. It could
> >perhaps be made mandatory preferrably using an error or a one-time
> >kernel warning. If nobody uses the SYNC interface, it is of little use.
>
> hmm I'm not sure it is little use. Our hardware (the "LLC" capable) has this
> very specific case where the cache gets dirty wrt the GPU, which is when the
> same buffer is shared with the scanout device. This is not something will
> happen in Chrome OS for example, so we wouldn't need the SYNC markers there.
>
> In any case I think that making it mandatory works for us, but I'll have to
> check with Daniel/Chris whether there are performance penalties when
> accessing it and so on.
2 more ioctls per upload should be bearable, imo we should make this
mandatory.
> >Also I think the syncing needs to be extended to two dimensions. A long
> >time ago when this was brought up people argued why we should limit it
> >to two dimensions, but I believe two dimensions addresses most
> >performance-problematic use-cases. A default implementation of
> >twodimensional sync can easily be made using the one-dimensional API.
>
> two dimension sync? You're saying that there could be a GPU access API in
> dma-buf as well? I don't get it, what's the use-case? I'm sure I missed the
> discussions because I wasn't particularly interested in this whole thingy
> before :)
Most of the things I've seen that use subranges for up/download use linear
buffers where individual images are just packed in a queue, each with
their own stride. Adding a notion of 2d to dma-buf would be a big
departure from the "dma-buf doesn't track metadata" design. If there's a
real need I guess we can do it, but only after careful consideration, and
imo it shouldn't be in basic dma-buf mmap support.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/4] drm/i915: SDVO limited color range and pixel repeat fixes
From: Ville Syrjälä While looking at cleaning up the SDVO limited color range handling I noticed the new FIXMEs that we're not supposed to use the limited color range bit in the port registers. After a bit of work I managed to produce a few patches that should hopefully deal with this correctly. I also tossed in a patch that tries to deal with DBLCLK modes. Sadly I have no HDMI SDVO devices, so couldn't test this. My DVI SDVO device apparently doesn't support the colormetry stuff at all. Ville Syrjälä (4): drm/i915: Clean up SDVO limited color range handling drm/i915: Fix SDVO colorimetry bit defines drm/i915: Implement limited color range for SDVO properly drm/i915: Make SDVO deal with HDMI pixel repeat drivers/gpu/drm/i915/intel_sdvo.c | 87 +++--- drivers/gpu/drm/i915/intel_sdvo_regs.h | 8 ++-- 2 files changed, 64 insertions(+), 31 deletions(-) -- 2.4.6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915: Implement limited color range for SDVO properly
From: Ville Syrjälä
The SDVO/HDMI port register limited color range bit can only be used
with TMDS encoding and not SDVO encoding, ie. to be used only when
using the port as a HDMI port as opposed to a SDVO port.
To implement limited color range support for SDVO->HDMI we need to ask
the SDVO device to do the range compression. Do so, but first check if
the device even supports the colorimetry selection.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_sdvo.c | 63 +++
1 file changed, 44 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 33e58c1..0d1fed4 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -85,6 +85,8 @@ struct intel_sdvo {
*/
struct intel_sdvo_caps caps;
+ uint8_t colorimetry_cap;
+
/* Pixel clock limitations reported by the SDVO device, in kHz */
int pixel_clock_min, pixel_clock_max;
@@ -1164,14 +1166,16 @@ static bool intel_sdvo_compute_config(struct
intel_encoder *encoder,
pipe_config->has_hdmi_sink = intel_sdvo->has_hdmi_monitor;
- if (intel_sdvo->color_range_auto) {
- /* See CEA-861-E - 5.1 Default Encoding Parameters */
- pipe_config->limited_color_range =
- pipe_config->has_hdmi_sink &&
- drm_match_cea_mode(adjusted_mode) > 1;
- } else {
- pipe_config->limited_color_range =
- intel_sdvo->limited_color_range;
+ if (intel_sdvo->colorimetry_cap & SDVO_COLORIMETRY_RGB220) {
+ if (intel_sdvo->color_range_auto) {
+ /* See CEA-861-E - 5.1 Default Encoding Parameters */
+ pipe_config->limited_color_range =
+ pipe_config->has_hdmi_sink &&
+ drm_match_cea_mode(adjusted_mode) > 1;
+ } else {
+ pipe_config->limited_color_range =
+ intel_sdvo->limited_color_range;
+ }
}
/* Clock computation needs to happen after pixel multiplier. */
@@ -1232,8 +1236,12 @@ static void intel_sdvo_pre_enable(struct intel_encoder
*intel_encoder)
if (crtc->config->has_hdmi_sink) {
intel_sdvo_set_encode(intel_sdvo, SDVO_ENCODE_HDMI);
- intel_sdvo_set_colorimetry(intel_sdvo,
- SDVO_COLORIMETRY_RGB256);
+ if (crtc->config->limited_color_range)
+ intel_sdvo_set_colorimetry(intel_sdvo,
+ SDVO_COLORIMETRY_RGB220);
+ else
+ intel_sdvo_set_colorimetry(intel_sdvo,
+ SDVO_COLORIMETRY_RGB256);
intel_sdvo_set_avi_infoframe(intel_sdvo, adjusted_mode);
} else
intel_sdvo_set_encode(intel_sdvo, SDVO_ENCODE_DVI);
@@ -1265,10 +1273,6 @@ static void intel_sdvo_pre_enable(struct intel_encoder
*intel_encoder)
/* The real mode polarity is set by the SDVO commands, using
* struct intel_sdvo_dtd. */
sdvox = SDVO_VSYNC_ACTIVE_HIGH | SDVO_HSYNC_ACTIVE_HIGH;
- /* FIXME: this bit is only valid when using TMDS
-* encoding and 8 bit per color mode. */
- if (!HAS_PCH_SPLIT(dev) && crtc->config->limited_color_range)
- sdvox |= HDMI_COLOR_RANGE_16_235;
if (INTEL_INFO(dev)->gen < 5)
sdvox |= SDVO_BORDER_ENABLE;
} else {
@@ -1418,8 +1422,16 @@ static void intel_sdvo_get_config(struct intel_encoder
*encoder,
}
}
- if (sdvox & HDMI_COLOR_RANGE_16_235)
- pipe_config->limited_color_range = true;
+ if (intel_sdvo_get_value(intel_sdvo, SDVO_CMD_GET_COLORIMETRY,
+&val, 1)) {
+ switch (val) {
+ case SDVO_COLORIMETRY_RGB220:
+ pipe_config->limited_color_range = true;
+ break;
+ default:
+ break;
+ }
+ }
if (intel_sdvo_get_value(intel_sdvo, SDVO_CMD_GET_ENCODE,
&val, 1)) {
@@ -1570,6 +1582,17 @@ static bool intel_sdvo_get_capabilities(struct
intel_sdvo *intel_sdvo, struct in
return true;
}
+static uint8_t intel_sdvo_get_colorimetry_cap(struct intel_sdvo *intel_sdvo)
+{
+ uint8_t cap;
+
+ if (!intel_sdvo_get_value(intel_sdvo, SDVO_CMD_GET_COLORIMETRY_CAP,
+ &cap, sizeof(cap)))
+ return SDVO_COLORIMETRY_RGB256;
+
+ return cap;
+}
+
static uint16_t intel_sdvo_get_hotplug_support(struct intel_sdvo *intel_sdvo)
{
struct drm_device *dev
[Intel-gfx] [PATCH 2/4] drm/i915: Fix SDVO colorimetry bit defines
From: Ville Syrjälä
Fix up the SDVO colorimetry bits to match the spec.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_sdvo_regs.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo_regs.h
b/drivers/gpu/drm/i915/intel_sdvo_regs.h
index 2e2d4eb..bcddd81 100644
--- a/drivers/gpu/drm/i915/intel_sdvo_regs.h
+++ b/drivers/gpu/drm/i915/intel_sdvo_regs.h
@@ -699,10 +699,10 @@ struct intel_sdvo_enhancements_arg {
#define SDVO_CMD_GET_PIXEL_REPLI 0x8c
#define SDVO_CMD_GET_COLORIMETRY_CAP 0x8d
#define SDVO_CMD_SET_COLORIMETRY 0x8e
- #define SDVO_COLORIMETRY_RGB256 0x0
- #define SDVO_COLORIMETRY_RGB220 0x1
- #define SDVO_COLORIMETRY_YCrCb422 0x3
- #define SDVO_COLORIMETRY_YCrCb444 0x4
+ #define SDVO_COLORIMETRY_RGB256 (1 << 0)
+ #define SDVO_COLORIMETRY_RGB220 (1 << 1)
+ #define SDVO_COLORIMETRY_YCrCb422(1 << 2)
+ #define SDVO_COLORIMETRY_YCrCb444(1 << 3)
#define SDVO_CMD_GET_COLORIMETRY 0x8f
#define SDVO_CMD_GET_AUDIO_ENCRYPT_PREFER 0x90
#define SDVO_CMD_SET_AUDIO_STAT0x91
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915: Clean up SDVO limited color range handling
From: Ville Syrjälä
Clean up the limited color range handling for SDVO as was done for
HDMI/DP previously.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_sdvo.c | 27 ---
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index c98098e..33e58c1 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -103,7 +103,7 @@ struct intel_sdvo {
* This is used to select the color range of RBG outputs in HDMI mode.
* It is only valid when using TMDS encoding and 8 bit per color mode.
*/
- uint32_t color_range;
+ bool limited_color_range;
bool color_range_auto;
/**
@@ -1166,15 +1166,12 @@ static bool intel_sdvo_compute_config(struct
intel_encoder *encoder,
if (intel_sdvo->color_range_auto) {
/* See CEA-861-E - 5.1 Default Encoding Parameters */
- /* FIXME: This bit is only valid when using TMDS encoding and 8
-* bit per color mode. */
- if (pipe_config->has_hdmi_sink &&
- drm_match_cea_mode(adjusted_mode) > 1)
- pipe_config->limited_color_range = true;
+ pipe_config->limited_color_range =
+ pipe_config->has_hdmi_sink &&
+ drm_match_cea_mode(adjusted_mode) > 1;
} else {
- if (pipe_config->has_hdmi_sink &&
- intel_sdvo->color_range == HDMI_COLOR_RANGE_16_235)
- pipe_config->limited_color_range = true;
+ pipe_config->limited_color_range =
+ intel_sdvo->limited_color_range;
}
/* Clock computation needs to happen after pixel multiplier. */
@@ -1268,6 +1265,8 @@ static void intel_sdvo_pre_enable(struct intel_encoder
*intel_encoder)
/* The real mode polarity is set by the SDVO commands, using
* struct intel_sdvo_dtd. */
sdvox = SDVO_VSYNC_ACTIVE_HIGH | SDVO_HSYNC_ACTIVE_HIGH;
+ /* FIXME: this bit is only valid when using TMDS
+* encoding and 8 bit per color mode. */
if (!HAS_PCH_SPLIT(dev) && crtc->config->limited_color_range)
sdvox |= HDMI_COLOR_RANGE_16_235;
if (INTEL_INFO(dev)->gen < 5)
@@ -2017,7 +2016,7 @@ intel_sdvo_set_property(struct drm_connector *connector,
if (property == dev_priv->broadcast_rgb_property) {
bool old_auto = intel_sdvo->color_range_auto;
- uint32_t old_range = intel_sdvo->color_range;
+ bool old_range = intel_sdvo->limited_color_range;
switch (val) {
case INTEL_BROADCAST_RGB_AUTO:
@@ -2025,20 +2024,18 @@ intel_sdvo_set_property(struct drm_connector *connector,
break;
case INTEL_BROADCAST_RGB_FULL:
intel_sdvo->color_range_auto = false;
- intel_sdvo->color_range = 0;
+ intel_sdvo->limited_color_range = false;
break;
case INTEL_BROADCAST_RGB_LIMITED:
intel_sdvo->color_range_auto = false;
- /* FIXME: this bit is only valid when using TMDS
-* encoding and 8 bit per color mode. */
- intel_sdvo->color_range = HDMI_COLOR_RANGE_16_235;
+ intel_sdvo->limited_color_range = true;
break;
default:
return -EINVAL;
}
if (old_auto == intel_sdvo->color_range_auto &&
- old_range == intel_sdvo->color_range)
+ old_range == intel_sdvo->limited_color_range)
return 0;
goto done;
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915: Make SDVO deal with HDMI pixel repeat
From: Ville Syrjälä
With SDVO the pipe config pixel_multiplier only concerns itself with the
data on the SDVO bus. Any HDMI specific pixel repeat must be handled by
the SDVO device itself. To do that simply configure the SDVO pixel
replication factor appropriately. We already set up the infoframe PRB
values correctly via the infoframe helpers.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_sdvo.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 0d1fed4..f4a5c08 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -931,6 +931,12 @@ static bool intel_sdvo_set_colorimetry(struct intel_sdvo
*intel_sdvo,
return intel_sdvo_set_value(intel_sdvo, SDVO_CMD_SET_COLORIMETRY,
&mode, 1);
}
+static bool intel_sdvo_set_pixel_replication(struct intel_sdvo *intel_sdvo,
+uint8_t pixel_repeat)
+{
+ return intel_sdvo_set_value(intel_sdvo, SDVO_CMD_SET_PIXEL_REPLI,
&pixel_repeat, 1);
+}
+
#if 0
static void intel_sdvo_dump_hdmi_buf(struct intel_sdvo *intel_sdvo)
{
@@ -1243,6 +1249,11 @@ static void intel_sdvo_pre_enable(struct intel_encoder
*intel_encoder)
intel_sdvo_set_colorimetry(intel_sdvo,
SDVO_COLORIMETRY_RGB256);
intel_sdvo_set_avi_infoframe(intel_sdvo, adjusted_mode);
+
+ if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
+ intel_sdvo_set_pixel_replication(intel_sdvo, 1);
+ else
+ intel_sdvo_set_pixel_replication(intel_sdvo, 0);
} else
intel_sdvo_set_encode(intel_sdvo, SDVO_ENCODE_DVI);
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Dont enable hpd for eDP
On Thu, Aug 13, 2015 at 09:35:21AM +0530, Sivakumar Thulasimani wrote: > > > On 8/12/2015 6:26 PM, Daniel Vetter wrote: > > On Mon, Aug 10, 2015 at 05:51:48PM +0530, Sivakumar Thulasimani wrote: > >> > >> On 8/10/2015 5:44 PM, Jani Nikula wrote: > >>> On Mon, 10 Aug 2015, Sivakumar Thulasimani > >>> wrote: > On 8/10/2015 5:07 PM, Jani Nikula wrote: > > On Mon, 10 Aug 2015, Sivakumar Thulasimani > > wrote: > >> Reviewed-by: Sivakumar Thulasimani > >> > >> On 8/10/2015 10:35 AM, Sonika Jindal wrote: > >>> With HPD support added for all ports including PORT_A, setting > >>> hpd_pin will > >>> result in enabling of hpd to edp as well. There is no need to enable > >>> HPD on > >>> PORT_A hence this patch removes hpd_pin update for PORT_A, where edp > >>> will > >>> be connected. it can be added back when required > > What? You can't just go ahead and remove HPD from eDP sinks. > > > > BR, > > Jani. > Nope, we are not removing HPD for edp sinks, it was never there in the > first place. It was > enabled for CHV (even there by mistake since PORT B/C was both DP and > eDP) but it was > never there for any other plaforms nor is it used for any purpose (PSR > must use it, but i > dont see code for it as well). > >>> Are you saying there's no HPD enabled in our *hardware* for eDP? Or > >>> driver? > >>> > >>> My point is, is this patch making it harder to enable eDP hpd handling > >>> (e.g. for PSR or DP link re-training) in the future? We currently take > >>> it into account in a few places, and if we start removing that, it will > >>> be a loss of effort to first remove and then add it back. > >>> > >>> BR, > >>> Jani. > >> i was referring to our driver only. > >> > >> Our VLV/CHV code already receives hpd for every pps on and off which is > >> later ignored. if we dont disable HPD on eDPs this behavior will be > >> extended > >> for all platforms which i feel is too costly to keep enabled when there is > >> no > >> purpose for it right now. > > don't optimize code because you "feel it's costly", only do it when you > > have hard numbers. One interrupt per pps on or off transition won't be > > measurable at all. > > -Daniel > let me rephrase my concern then :) > a) HPD was never enabled before this patch for edp It was for port!=A, which means all VLV/CHV + some other machines with eDP on port D. > b) this patch series will enable hpd for edp > so why should we allow hpd for edp when no one is using it and will > cause problems > unless ignored explicitly ? It's not clear it would cause problems. My ILK still seems happy now that I enabled port A HPD on it [1]. As are the VLV/CHV machines. On BSW we had problems but that turned out to be misconfigured pullups on the HPD pins. Before that got fixed there was a lot of noise on the line whenever the panel was off, and that spurred me to write the patch series to keep the HPD disabled while the port is disabled [2]. [1] http://lists.freedesktop.org/archives/intel-gfx/2015-August/073559.html [2] http://lists.freedesktop.org/archives/intel-gfx/2015-January/058173.html -- 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 02/21] drm/i915/gtt: Workaround for HW preload not flushing pdps
On Thu, Aug 13, 2015 at 01:03:30PM +0100, Dave Gordon wrote: > On 13/08/15 12:42, Dave Gordon wrote: > >On 13/08/15 11:12, Michel Thierry wrote: > >>On 8/13/2015 5:08 PM, Zhiyuan Lv wrote: > >>>Hi Michel, > >>> > >>>Thanks for the reply! > >>> > >>>I yet have another question: right now the mark_tlb_dirty() will be > >>>called if any level of PPGTT table is changed. But for the EXECLIST > >>>context submission, we only need LRI commands if there are L3 PDP root > >>>pointer changes right? Thanks! > >> > >>mark_tlbs_dirty is not only for execlists mode, we re-used it since it > >>was already there. > >> > >>The update is only required when a PDP is allocated. > >> > >>-Michel > > > >Doesn't that depend on whether the context is running? The LRI reload > >has the side effect of flushing all current knowledge of mappings, so > >every level of PD gets refreshed from memory. > > > >If we're not updating the top level PDPs, and we know the context isn't > >active, then we *assume* that lower-level PDs will be refreshed when the > >context is next loaded. (This hasn't been true on all hardware, some of > >which cached previously-retrieved PDs across ctx save-and-reload, and > >that's one reason why there's a "Force PD Restore" bit, but we've been > >told not to use it on current h/w). AFAICT, current chips don't cache > >previous PDs and don't need the "Force" bit for this case. > > > >OTOH, if we don't know whether the context is running, then we can't be > >sure when (or whether) any PD updates will be seen. As long as the > >changes of interest are only ever *from* NULL *to* non-NULL, we *expect* > >it to work, because (we *assume*) the GPU won't cache negative results > >from PD lookups; so any lookup that previously hit an invalid mapping > >will be re-fetched next time it's required (and may now be good). > > > >If we don't reload the PDPs with LRIs, then perhaps to be safe we need > >to inject some other instruction that will just force a re-fetch of the > >lower-level PDs from memory, without altering any top-level PDPs? In > >conjunction with preallocating the top-level entries, that ought to > >guarantee that the updates would be seen just before the point where > >they're about to be used? > > > >.Dave. > >___ > >Intel-gfx mailing list > >Intel-gfx@lists.freedesktop.org > >http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > I found the following comment in the BSpec: > > "Pre-loading of Page Directory Entries (PD load) for 32b legacy mode > is not supported from Gen9 onwards. PD entries are loaded on demand > when there is a miss in the PDE cache of the corresponding page > walker. Any new page additions by the driver are transparent to the > HW, and the new page translations will be fetched on demand. > However, any removal of the pages by the driver should initiate a > TLB invalidation to remove the stale entries." > > So, I think that confirms that we should inject some form of TLB > invalidation into the ring before the next batch uses any updated > PDs. Presumably an MI_FLUSH_DW with TLB_INVALIDATE would do? Hi Dave and Michel, So the conclusion is still the same: that for 32b legacy mode, emit_pdps() is only needed for PDP changes. Other level page table changes can be handled by TLB_INVALIDATE with ring buffer commands. Is that correct? Thanks! Regards, -Zhiyuan > > .Dave. > ___ > 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] [PATCH 2/4] drm/i915: Adding Panel Filter function for DP
On Mon, Aug 10, 2015 at 03:26:09PM +0800, Xiong Zhang wrote:
> Only internal eDP, LVDS, DVI screen could set scalling mode, some
> customers need to set scalling mode for external DP, HDMI, VGA
> screen. Let's fulfill this.
>
> bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90989
>
> Signed-off-by: Xiong Zhang
> ---
> drivers/gpu/drm/i915/intel_dp.c | 63
> -
> 1 file changed, 44 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index f1b9f93..2da334b 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -207,7 +207,13 @@ intel_dp_mode_valid(struct drm_connector *connector,
> int target_clock = mode->clock;
> int max_rate, mode_rate, max_lanes, max_link_clock;
>
> - if (is_edp(intel_dp) && fixed_mode) {
> + if (mode->clock < 1)
> + return MODE_CLOCK_LOW;
> +
> + if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> + return MODE_H_ILLEGAL;
> +
> + if (!intel_panel_scale_none(&intel_connector->panel)) {
> if (mode->hdisplay > fixed_mode->hdisplay)
> return MODE_PANEL;
>
> @@ -226,12 +232,6 @@ intel_dp_mode_valid(struct drm_connector *connector,
> if (mode_rate > max_rate)
> return MODE_CLOCK_HIGH;
>
> - if (mode->clock < 1)
> - return MODE_CLOCK_LOW;
> -
> - if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> - return MODE_H_ILLEGAL;
> -
> return MODE_OK;
> }
>
> @@ -1378,7 +1378,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
> pipe_config->has_drrs = false;
> pipe_config->has_audio = intel_dp->has_audio && port != PORT_A;
>
> - if (is_edp(intel_dp) && intel_connector->panel.fixed_mode) {
> + if (!intel_panel_scale_none(&intel_connector->panel)) {
> intel_fixed_panel_mode(intel_connector->panel.fixed_mode,
> adjusted_mode);
>
> @@ -4592,6 +4592,23 @@ static int intel_dp_get_modes(struct drm_connector
> *connector)
> edid = intel_connector->detect_edid;
> if (edid) {
> int ret = intel_connector_update_modes(connector, edid);
> +
> + if (ret && intel_connector->panel.fixed_mode == NULL) {
> + /* init fixed mode as preferred mode for DP */
> + struct drm_display_mode *fixed_mode = NULL;
> + struct drm_display_mode *scan;
> +
> + list_for_each_entry(scan, &connector->probed_modes,
> head) {
> + if (scan->type & DRM_MODE_TYPE_PREFERRED)
> + fixed_mode =
> drm_mode_duplicate(connector->dev,
> + scan);
> + }
> +
> + if (fixed_mode)
> + intel_panel_init(&intel_connector->panel,
> + fixed_mode, NULL);
> + }
How are we supposed to get rid of a stale fixed_mode when some other
display gets plugged in?
Also what would happen if the preferred mode can't be supported due to
some source limitation?
In general I'm not entirely happy with having this kind of policy in
the kernel. I'd much prefer if we could get crtc size and border properties
done so that userspace could set up the scaling any which way it chooses.
> +
> if (ret)
> return ret;
> }
> @@ -4688,15 +4705,14 @@ intel_dp_set_property(struct drm_connector *connector,
> goto done;
> }
>
> - if (is_edp(intel_dp) &&
> - property == connector->dev->mode_config.scaling_mode_property) {
> - if (val == DRM_MODE_SCALE_NONE) {
> - DRM_DEBUG_KMS("no scaling not supported\n");
> + if (property == connector->dev->mode_config.scaling_mode_property) {
> + if (is_edp(intel_dp) && val == DRM_MODE_SCALE_NONE) {
> + DRM_DEBUG_KMS("eDP: no scaling not supported\n");
> return -EINVAL;
> }
>
> if (intel_connector->panel.fitting_mode == val) {
> - /* the eDP scaling property is not changed */
> + /* the connector scaling property is not changed */
> return 0;
> }
> intel_connector->panel.fitting_mode = val;
> @@ -4989,13 +5005,22 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
> struct drm_connector *connect
> intel_attach_broadcast_rgb_property(connector);
> intel_dp->color_range_auto = true;
>
> - if (is_edp(intel_dp)) {
> + /* Each pipe has panel filter since Ironlake. */
> + if (INTEL_INFO(connector->dev)->gen >= 5) {
> drm_mode_create_scaling_mode_property(connector->dev);
> - drm_object_
Re: [Intel-gfx] [PATCH 2/2] drm/doc: Update docs about device instance setup
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 7129 -Summary- Platform Delta drm-intel-nightly Series Applied ILK -1 302/302 301/302 SNB 315/315 315/315 IVB 336/336 336/336 BYT 283/283 283/283 HSW 378/378 378/378 -Detailed- Platform Testdrm-intel-nightly Series Applied *ILK igt@kms_flip@wf_vblank-vs-modeset-interruptible PASS(1) DMESG_WARN(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] ACPI / video: Fix circular lock dependency issue in the video-detect code
Before this commit, the following would happen:
a) acpi_video_get_backlight_type() gets called
b) acpi_video_get_backlight_type() calls acpi_video_init_backlight_type()
c) acpi_video_init_backlight_type() locks its function static init_mutex
d) acpi_video_init_backlight_type() calls backlight_register_notifier()
e) backlight_register_notifier() takes its notifier-chain lock
And when the backlight notifier chain gets called we've:
1) blocking_notifier_call_chain() gets called
2) blocking_notifier_call_chain() takes the notifier-chain lock
3) blocking_notifier_call_chain() calls acpi_video_backlight_notify()
4) acpi_video_backlight_notify() calls acpi_video_get_backlight_type()
5) acpi_video_get_backlight_type() calls acpi_video_init_backlight_type()
6) acpi_video_init_backlight_type() locks its function static init_mutex
So in the first call sequence we have:
a) init_mutex gets locked
b) notifier-chain gets locked
and in the second call sequence we have:
1) notifier-chain gets locked
2) init_mutex gets locked
And we've a circular locking dependency. This specific locking dependency
is fixable without using the big hammer otherwise known as a workqueue,
but further analysis shows a similar problem with the backlight notifier
chain lock vs register_count_mutex from drivers/acpi/acpi_video.c,
and fixing that becomes problematic.
So this commit simply fixes this with the big hammer, performance
wise this is a non issue as we expect the work to get scheduled
exactly zero or one times during normal system use.
Signed-off-by: Hans de Goede
---
drivers/acpi/video_detect.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 815f75e..2922f1f 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
ACPI_MODULE_NAME("video");
@@ -41,6 +42,7 @@ void acpi_video_unregister_backlight(void);
static bool backlight_notifier_registered;
static struct notifier_block backlight_nb;
+static struct work_struct backlight_notify_work;
static enum acpi_backlight_type acpi_backlight_cmdline = acpi_backlight_undef;
static enum acpi_backlight_type acpi_backlight_dmi = acpi_backlight_undef;
@@ -262,6 +264,13 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
{ },
};
+/* This uses a workqueue to avoid various locking ordering issues */
+static void acpi_video_backlight_notify_work(struct work_struct *work)
+{
+ if (acpi_video_get_backlight_type() != acpi_backlight_video)
+ acpi_video_unregister_backlight();
+}
+
static int acpi_video_backlight_notify(struct notifier_block *nb,
unsigned long val, void *bd)
{
@@ -269,9 +278,8 @@ static int acpi_video_backlight_notify(struct
notifier_block *nb,
/* A raw bl registering may change video -> native */
if (backlight->props.type == BACKLIGHT_RAW &&
- val == BACKLIGHT_REGISTERED &&
- acpi_video_get_backlight_type() != acpi_backlight_video)
- acpi_video_unregister_backlight();
+ val == BACKLIGHT_REGISTERED)
+ schedule_work(&backlight_notify_work);
return NOTIFY_OK;
}
@@ -304,6 +312,8 @@ enum acpi_backlight_type acpi_video_get_backlight_type(void)
acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
ACPI_UINT32_MAX, find_video, NULL,
&video_caps, NULL);
+ INIT_WORK(&backlight_notify_work,
+ acpi_video_backlight_notify_work);
backlight_nb.notifier_call = acpi_video_backlight_notify;
backlight_nb.priority = 0;
if (backlight_register_notifier(&backlight_nb) == 0)
--
2.4.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt] lib/igt_core: use print("%s", #expr) instead of print(#expr)
If I have a program with the following:
igt_skip_on(i % 2 == 0);
igt_skip_on_f(i % 2 == 0, "i:%d\n", i);
igt_require(i % 2 == 0);
igt_require_f(i % 2 == 0, "i:%d\n", i);
then I'll get compiler error messages complaining about format
conversions related to the '%' character used in the mod operation. So
put the whole string as a %s argument to avoid interpreting '%' and
any other possible chars.
Signed-off-by: Paulo Zanoni
---
lib/igt_core.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/igt_core.h b/lib/igt_core.h
index 1d77f45..f8bfbf0 100644
--- a/lib/igt_core.h
+++ b/lib/igt_core.h
@@ -491,7 +491,7 @@ void igt_exit(void) __attribute__((noreturn));
*/
#define igt_require(expr) do { \
if (!(expr)) igt_skip_check(#expr , NULL); \
- else igt_debug("Test requirement passed: "#expr"\n"); \
+ else igt_debug("Test requirement passed: %s\n", #expr); \
} while (0)
/**
@@ -506,7 +506,7 @@ void igt_exit(void) __attribute__((noreturn));
*/
#define igt_skip_on(expr) do { \
if ((expr)) igt_skip_check("!(" #expr ")" , NULL); \
- else igt_debug("Test requirement passed: !("#expr")\n"); \
+ else igt_debug("Test requirement passed: !(%s)\n", #expr); \
} while (0)
/**
@@ -525,7 +525,7 @@ void igt_exit(void) __attribute__((noreturn));
*/
#define igt_require_f(expr, f...) do { \
if (!(expr)) igt_skip_check(#expr , f); \
- else igt_debug("Test requirement passed: "#expr"\n"); \
+ else igt_debug("Test requirement passed: %s\n", #expr); \
} while (0)
/**
@@ -544,7 +544,7 @@ void igt_exit(void) __attribute__((noreturn));
*/
#define igt_skip_on_f(expr, f...) do { \
if ((expr)) igt_skip_check("!("#expr")", f); \
- else igt_debug("Test requirement passed: !("#expr")\n"); \
+ else igt_debug("Test requirement passed: !(%s)\n", #expr); \
} while (0)
/* fork support code */
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Assign hwmode after encoder state readout
From: Ville Syrjälä
The dotclock is often calculated in encoder .get_config(), so we
shouldn't copy the adjusted_mode to hwmode until we have read out the
dotclock.
Gets rid of some warnings like these:
[drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: Can't calculate
constants, dotclock = 0!
[drm:i915_get_vblank_timestamp] crtc 0 is disabled
Cc: Maarten Lankhorst
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 21aa745..b4229ce 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15119,7 +15119,6 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
crtc->base.state->mode.private_flags =
I915_MODE_FLAG_INHERITED;
}
- crtc->base.hwmode = crtc->config->base.adjusted_mode;
readout_plane_state(crtc,
to_intel_crtc_state(crtc->base.state));
DRM_DEBUG_KMS("[CRTC:%d] hw state readout: %s\n",
@@ -15179,6 +15178,10 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
connector->base.name,
connector->base.encoder ? "enabled" : "disabled");
}
+
+ for_each_intel_crtc(dev, crtc) {
+ crtc->base.hwmode = crtc->config->base.adjusted_mode;
+ }
}
/* Scan out the current hw modeset state,
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Fix clock readout when pipes are enabld w/o ports
From: Ville Syrjälä
The BIOS sometimes likes to enable pipes w/o any ports, at least on
older machines. Currently we fail to assign anything sensible to
crtc->hwmode.crtc_clock which leads to complaints from the vblank code.
Deal with active pipes w/o ports and assign something sensible to
crtc_clock.
Gets rid of rest of these on my gen4:
[drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 24: Can't calculate
constants, dotclock = 0!
[drm:i915_get_vblank_timestamp] crtc 1 is disabled
Cc: Maarten Lankhorst
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 31 ++-
1 file changed, 22 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b4229ce..32e9f91 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14857,13 +14857,22 @@ intel_check_plane_mapping(struct intel_crtc *crtc)
return true;
}
+static bool intel_crtc_has_encoders(struct intel_crtc *crtc)
+{
+ struct drm_device *dev = crtc->base.dev;
+ struct intel_encoder *encoder;
+
+ for_each_encoder_on_crtc(dev, &crtc->base, encoder)
+ return true;
+
+ return false;
+}
+
static void intel_sanitize_crtc(struct intel_crtc *crtc)
{
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- struct intel_encoder *encoder;
u32 reg;
- bool enable;
/* Clear any frame start delays used for debugging left by the BIOS */
reg = PIPECONF(crtc->config->cpu_transcoder);
@@ -14907,16 +14916,11 @@ static void intel_sanitize_crtc(struct intel_crtc
*crtc)
/* Adjust the state of the output pipe according to whether we
* have active connectors/encoders. */
- enable = false;
- for_each_encoder_on_crtc(dev, &crtc->base, encoder) {
- enable = true;
- break;
- }
-
- if (!enable)
+ if (!intel_crtc_has_encoders(crtc))
intel_crtc_disable_noatomic(&crtc->base);
if (crtc->active != crtc->base.state->active) {
+ struct intel_encoder *encoder;
/* This can happen either due to bugs in the get_hw_state
* functions or because of calls to intel_crtc_disable_noatomic,
@@ -15180,6 +15184,15 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
}
for_each_intel_crtc(dev, crtc) {
+ /* in case the pipe is active w/o any ports */
+ if (crtc->active && !intel_crtc_has_encoders(crtc)) {
+ crtc->config->base.adjusted_mode.crtc_clock =
+ crtc->config->port_clock;
+ if (crtc->config->pixel_multiplier)
+ crtc->config->base.adjusted_mode.crtc_clock /=
+ crtc->config->pixel_multiplier;
+ }
+
crtc->base.hwmode = crtc->config->base.adjusted_mode;
}
}
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [drm-intel:topic/drm-misc 71/71] drivers/gpu/drm/imx/imx-drm-core.c:490:2: warning: initialization from incompatible pointer type
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc head: b90180b057f77fe5c47a033aaa13a0f6578e5a01 commit: b90180b057f77fe5c47a033aaa13a0f6578e5a01 [71/71] drm/irq: More pipe/crtc consistency cleanups config: arm-imx_v6_v7_defconfig (attached as .config) reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout b90180b057f77fe5c47a033aaa13a0f6578e5a01 # save the attached .config to linux build tree make.cross ARCH=arm All warnings (new ones prefixed by >>): >> drivers/gpu/drm/imx/imx-drm-core.c:490:2: warning: initialization from >> incompatible pointer type .get_vblank_counter = drm_vblank_count, ^ >> drivers/gpu/drm/imx/imx-drm-core.c:490:2: warning: (near initialization for >> 'imx_drm_driver.get_vblank_counter') vim +490 drivers/gpu/drm/imx/imx-drm-core.c 915b4d11 drivers/staging/imx-drm/imx-drm-core.c David Herrmann 2014-08-29 474 .set_busid = drm_platform_set_busid, e692da4d drivers/staging/imx-drm/imx-drm-core.c Sascha Hauer 2012-09-21 475 .gem_free_object= drm_gem_cma_free_object, e692da4d drivers/staging/imx-drm/imx-drm-core.c Sascha Hauer 2012-09-21 476 .gem_vm_ops = &drm_gem_cma_vm_ops, e692da4d drivers/staging/imx-drm/imx-drm-core.c Sascha Hauer 2012-09-21 477 .dumb_create= drm_gem_cma_dumb_create, e692da4d drivers/staging/imx-drm/imx-drm-core.c Sascha Hauer 2012-09-21 478 .dumb_map_offset= drm_gem_cma_dumb_map_offset, 43387b37 drivers/staging/imx-drm/imx-drm-core.c Daniel Vetter 2013-07-16 479 .dumb_destroy = drm_gem_dumb_destroy, e692da4d drivers/staging/imx-drm/imx-drm-core.c Sascha Hauer 2012-09-21 480 bd3665c9 drivers/staging/imx-drm/imx-drm-core.c Philipp Zabel 2013-10-10 481 .prime_handle_to_fd = drm_gem_prime_handle_to_fd, bd3665c9 drivers/staging/imx-drm/imx-drm-core.c Philipp Zabel 2013-10-10 482 .prime_fd_to_handle = drm_gem_prime_fd_to_handle, bd3665c9 drivers/staging/imx-drm/imx-drm-core.c Philipp Zabel 2013-10-10 483 .gem_prime_import = drm_gem_prime_import, bd3665c9 drivers/staging/imx-drm/imx-drm-core.c Philipp Zabel 2013-10-10 484 .gem_prime_export = drm_gem_prime_export, bd3665c9 drivers/staging/imx-drm/imx-drm-core.c Philipp Zabel 2013-10-10 485 .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table, bd3665c9 drivers/staging/imx-drm/imx-drm-core.c Philipp Zabel 2013-10-10 486 .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table, bd3665c9 drivers/staging/imx-drm/imx-drm-core.c Philipp Zabel 2013-10-10 487 .gem_prime_vmap = drm_gem_cma_prime_vmap, bd3665c9 drivers/staging/imx-drm/imx-drm-core.c Philipp Zabel 2013-10-10 488 .gem_prime_vunmap = drm_gem_cma_prime_vunmap, bd3665c9 drivers/staging/imx-drm/imx-drm-core.c Philipp Zabel 2013-10-10 489 .gem_prime_mmap = drm_gem_cma_prime_mmap, e692da4d drivers/staging/imx-drm/imx-drm-core.c Sascha Hauer 2012-09-21 @490 .get_vblank_counter = drm_vblank_count, e692da4d drivers/staging/imx-drm/imx-drm-core.c Sascha Hauer 2012-09-21 491 .enable_vblank = imx_drm_enable_vblank, e692da4d drivers/staging/imx-drm/imx-drm-core.c Sascha Hauer 2012-09-21 492 .disable_vblank = imx_drm_disable_vblank, e692da4d drivers/staging/imx-drm/imx-drm-core.c Sascha Hauer 2012-09-21 493 .ioctls = imx_drm_ioctls, e692da4d drivers/staging/imx-drm/imx-drm-core.c Sascha Hauer 2012-09-21 494 .num_ioctls = ARRAY_SIZE(imx_drm_ioctls), e692da4d drivers/staging/imx-drm/imx-drm-core.c Sascha Hauer 2012-09-21 495 .fops = &imx_drm_driver_fops, e692da4d drivers/staging/imx-drm/imx-drm-core.c Sascha Hauer 2012-09-21 496 .name = "imx-drm", e692da4d drivers/staging/imx-drm/imx-drm-core.c Sascha Hauer 2012-09-21 497 .desc = "i.MX DRM graphics", e692da4d drivers/staging/imx-drm/imx-drm-core.c Sascha Hauer 2012-09-21 498 .date = "20120507", :: The code at line 490 was first introduced by commit :: e692da4d0e587f549ba101015e5f89903ba20b67 staging: drm/imx: Add i.MX drm core support :: TO: Sascha Hauer :: CC: Greg Kroah-Hartman --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation # # Automatically generated file; DO NOT EDIT. # Linux/arm 4.2.0-rc3 Kernel Configuration # CONFIG_ARM=y CONFIG_ARM_HAS_SG_CHAIN=y CONFIG_MIGHT_HAVE_PCI=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_HAVE_PROC_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_R
[Intel-gfx] [drm-intel:topic/drm-misc 71/71] drivers/gpu/drm/rcar-du/rcar_du_drv.c:262:2: warning: initialization from incompatible pointer type
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
head: b90180b057f77fe5c47a033aaa13a0f6578e5a01
commit: b90180b057f77fe5c47a033aaa13a0f6578e5a01 [71/71] drm/irq: More
pipe/crtc consistency cleanups
config: arm-marzen_defconfig (attached as .config)
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout b90180b057f77fe5c47a033aaa13a0f6578e5a01
# save the attached .config to linux build tree
make.cross ARCH=arm
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/rcar-du/rcar_du_drv.c:262:2: warning: initialization from
>> incompatible pointer type
.get_vblank_counter = drm_vblank_count,
^
>> drivers/gpu/drm/rcar-du/rcar_du_drv.c:262:2: warning: (near initialization
>> for 'rcar_du_driver.get_vblank_counter')
vim +262 drivers/gpu/drm/rcar-du/rcar_du_drv.c
4bf8e196 Laurent Pinchart 2013-06-19 246 .compat_ioctl =
drm_compat_ioctl,
4bf8e196 Laurent Pinchart 2013-06-19 247 #endif
4bf8e196 Laurent Pinchart 2013-06-19 248 .poll = drm_poll,
4bf8e196 Laurent Pinchart 2013-06-19 249 .read = drm_read,
4bf8e196 Laurent Pinchart 2013-06-19 250 .llseek = no_llseek,
4bf8e196 Laurent Pinchart 2013-06-19 251 .mmap =
drm_gem_cma_mmap,
4bf8e196 Laurent Pinchart 2013-06-19 252 };
4bf8e196 Laurent Pinchart 2013-06-19 253
4bf8e196 Laurent Pinchart 2013-06-19 254 static struct drm_driver
rcar_du_driver = {
6dbe686b Laurent Pinchart 2015-02-26 255 .driver_features=
DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME
6dbe686b Laurent Pinchart 2015-02-26 256 |
DRIVER_ATOMIC,
4bf8e196 Laurent Pinchart 2013-06-19 257 .load =
rcar_du_load,
4bf8e196 Laurent Pinchart 2013-06-19 258 .unload =
rcar_du_unload,
4bf8e196 Laurent Pinchart 2013-06-19 259 .preclose =
rcar_du_preclose,
3864c6f4 Laurent Pinchart 2013-03-14 260 .lastclose =
rcar_du_lastclose,
915b4d11 David Herrmann 2014-08-29 261 .set_busid =
drm_platform_set_busid,
4bf8e196 Laurent Pinchart 2013-06-19 @262 .get_vblank_counter =
drm_vblank_count,
4bf8e196 Laurent Pinchart 2013-06-19 263 .enable_vblank =
rcar_du_enable_vblank,
4bf8e196 Laurent Pinchart 2013-06-19 264 .disable_vblank =
rcar_du_disable_vblank,
4bf8e196 Laurent Pinchart 2013-06-19 265 .gem_free_object=
drm_gem_cma_free_object,
4bf8e196 Laurent Pinchart 2013-06-19 266 .gem_vm_ops =
&drm_gem_cma_vm_ops,
4bf8e196 Laurent Pinchart 2013-06-19 267 .prime_handle_to_fd =
drm_gem_prime_handle_to_fd,
4bf8e196 Laurent Pinchart 2013-06-19 268 .prime_fd_to_handle =
drm_gem_prime_fd_to_handle,
ffb40400 Laurent Pinchart 2013-07-10 269 .gem_prime_import =
drm_gem_prime_import,
ffb40400 Laurent Pinchart 2013-07-10 270 .gem_prime_export =
drm_gem_prime_export,
:: The code at line 262 was first introduced by commit
:: 4bf8e1962f91eed5dbee168d2348983dda0a518f drm: Renesas R-Car Display Unit
DRM driver
:: TO: Laurent Pinchart
:: CC: Dave Airlie
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 4.2.0-rc3 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_NO_IOPORT_MAP=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_VECTORS_BASE=0x
CONFIG_ARM_PATCH_PHYS_VIRT=y
CONFIG_GENERIC_BUG=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
CONFIG_KERNEL_LZMA=y
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
# CONFIG_FHANDLE is not set
CONFIG_USELIB=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_SHOW_LEVEL=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_HANDLE_DOMAIN_IRQ=y
CONFIG_IR
Re: [Intel-gfx] [PATCH v2 5/5] tests: make drm_read platform agnostic
Yup, in fact I see that if the console blanking kicks on, that the
drm_read test fails the first time, and then succeed on the second run.
It must wake up the console when it runs?
(Chris, I tried drm_read without the vblank api switch and it does work
just fine - I must have carried that over from some older work.)
Anyway, both core_get_client_auth and core_getversion work with nothing
more than:
- int fd = drm_open_driver(DRIVER_INTEL);
+ int fd = drm_open_driver(OPEN_ANY_GPU);
I'll just spin up a patchset with one or both of those, if that makes
sense to everyone.
-mf
On 08/12/2015 09:26 AM, Daniel Vetter wrote:
On Tue, Aug 11, 2015 at 11:59:16AM -0400, Micah Fedke wrote:
Update the drm_read test to operate on any platform to demonstrate the use of
drm_open_driver(OPEN_ANY_GPU).
To work on exynos, the event generation code is converted to use the new CRTC
selection API for vblank. The first valid crtc is selected at fixture-time.
pipe0_enabled() is updated to use the drmMode* wrapper functions instead of
direct ioctls, and the unnecessary, intel-specific pipe<->crtc mapping ioctl is
dropped.
With these updates in place, drm_read can run successfully on intel and exynos.
Tested on ivb and peach-pi, respectively.
Signed-off-by: Micah Fedke
drm_read isn't the greatest test since it implicitly relies upon fbcon
enabling the screens for us. I think that should be fixed first.
---
tests/drm_read.c | 87
1 file changed, 50 insertions(+), 37 deletions(-)
diff --git a/tests/drm_read.c b/tests/drm_read.c
index fdaf126..38fde26 100644
--- a/tests/drm_read.c
+++ b/tests/drm_read.c
@@ -45,10 +45,15 @@
#include "drm.h"
#include "ioctl_wrappers.h"
#include "drmtest.h"
+#include "igt_core.h"
#include "igt_aux.h"
+#include "igt_kms.h"
IGT_TEST_DESCRIPTION("Call read(drm) and see if it behaves.");
+static drmModeRes *resources;
+static int crtc_idx;
+
static void sighandler(int sig)
{
}
@@ -61,16 +66,19 @@ static void assert_empty(int fd)
static void generate_event(int fd)
{
- union drm_wait_vblank vbl;
+ drmVBlank wait_vbl;
+ unsigned crtc_idx_mask;
+ memset(&wait_vbl, 0, sizeof(wait_vbl));
- /* We require that pipe 0 is running */
+ crtc_idx_mask = crtc_idx << DRM_VBLANK_HIGH_CRTC_SHIFT;
+ igt_assert(!(crtc_idx_mask & ~DRM_VBLANK_HIGH_CRTC_MASK));
- vbl.request.type =
- DRM_VBLANK_RELATIVE |
- DRM_VBLANK_EVENT;
- vbl.request.sequence = 0;
+ wait_vbl.request.type = crtc_idx_mask;
+ wait_vbl.request.type |= DRM_VBLANK_RELATIVE;
+ wait_vbl.request.type |= DRM_VBLANK_EVENT;
+ wait_vbl.request.sequence = 1;
- do_ioctl(fd, DRM_IOCTL_WAIT_VBLANK, &vbl);
+ igt_assert(!drmWaitVBlank(fd, &wait_vbl));
}
static void wait_for_event(int fd)
@@ -154,44 +162,27 @@ static void test_short_buffer(int in, int nonblock)
static int pipe0_enabled(int fd)
{
- struct drm_mode_card_res res;
- uint32_t crtcs[32];
- int i;
+ drmModeRes *res;
+ drmModeCrtc *crtc;
+ int ret;
/* We assume we can generate events on pipe 0. So we have better
* make sure that is running!
*/
- memset(&res, 0, sizeof(res));
- res.count_crtcs = 32;
- res.crtc_id_ptr = (uintptr_t)crtcs;
-
- if (drmIoctl(fd, DRM_IOCTL_MODE_GETRESOURCES, &res))
- return 0;
-
- if (res.count_crtcs > 32)
+ res = drmModeGetResources(fd);
+ igt_assert(res);
+ crtc = drmModeGetCrtc(fd, res->crtcs[crtc_idx]);
+ if (!crtc){
return 0;
+ }
- for (i = 0; i < res.count_crtcs; i++) {
- struct drm_i915_get_pipe_from_crtc_id get_pipe;
- struct drm_mode_crtc mode;
-
- memset(&get_pipe, 0, sizeof(get_pipe));
- memset(&mode, 0, sizeof(mode));
-
- mode.crtc_id = crtcs[i];
-
- get_pipe.pipe = -1;
- get_pipe.crtc_id = mode.crtc_id;
- drmIoctl(fd, DRM_IOCTL_I915_GET_PIPE_FROM_CRTC_ID, &get_pipe);
- if (get_pipe.pipe)
- continue;
+ ret = crtc->mode_valid && crtc->mode.clock;
- drmIoctl(fd, DRM_IOCTL_MODE_GETCRTC, &mode);
- return mode.mode_valid && mode.mode.clock;
- }
+ drmModeFreeCrtc(crtc);
+ drmModeFreeResources(res);
- return 0;
+ return ret;
}
igt_main
@@ -202,8 +193,30 @@ igt_main
siginterrupt(SIGALRM, 1);
igt_fixture {
- fd = drm_open_driver_master(DRIVER_INTEL);
+ struct kmstest_connector_config config;
+ int i, n;
+
+ fd = drm_open_driver_master(OPEN_ANY_GPU);
+ igt_enable_connectors(fd);
+ kmstest_set_vt_graphics_mode();
Because in general we don't want fbcon to do things behind our back,
Re: [Intel-gfx] [PATCH] drm/i915: Use CONFIG_DRM_FBDEV_EMULATION
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 7131 -Summary- Platform Delta drm-intel-nightly Series Applied ILK -2 302/302 300/302 SNB 315/315 315/315 IVB 336/336 336/336 BYT -1 283/283 282/283 HSW 378/378 378/378 -Detailed- Platform Testdrm-intel-nightly Series Applied *ILK igt@kms_flip@flip-vs-dpms-interruptible PASS(1) DMESG_WARN(1) *ILK igt@kms_flip@wf_vblank-vs-modeset-interruptible PASS(1) DMESG_WARN(1) *BYT igt@gem_partial_pwrite_pread@reads-uncached PASS(1) FAIL(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/18] tests/gem_mmap: mark basic object creation tests as basic
We should be able to create small and moderate sized objects quickly and
without errors.
Signed-off-by: Jesse Barnes
---
tests/gem_mmap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/gem_mmap.c b/tests/gem_mmap.c
index 095f5b9..dd66ad6 100644
--- a/tests/gem_mmap.c
+++ b/tests/gem_mmap.c
@@ -118,7 +118,7 @@ igt_main
igt_assert(ret == -1 && errno == ENOENT);
}
- igt_subtest("new-object") {
+ igt_subtest("basic") {
arg.handle = gem_create(fd, OBJECT_SIZE);
arg.offset = 0;
arg.size = OBJECT_SIZE;
@@ -154,7 +154,7 @@ igt_main
gem_close(fd, arg.handle);
}
- igt_subtest("small-bo")
+ igt_subtest("basic-small-bo")
test_huge_bo(fd, -1);
igt_subtest("big-bo")
test_huge_bo(fd, 0);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/18] tests/gem_ctx_exec: mark lrc lite restore as basic
Need some LRC tests in the 'basic' subset, and this is a good simple
one.
Signed-off-by: Jesse Barnes
---
tests/gem_ctx_exec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/gem_ctx_exec.c b/tests/gem_ctx_exec.c
index 3df939c..ea0fb7f 100644
--- a/tests/gem_ctx_exec.c
+++ b/tests/gem_ctx_exec.c
@@ -216,7 +216,7 @@ igt_main
gem_context_destroy(fd, ctx_id);
}
- igt_subtest("lrc-lite-restore") {
+ igt_subtest("basic-lrc-lite-restore") {
int i, j;
/*
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/18] tests/drv_getparams: mark EU and subslice fetch as basic
Fundamental and simple functionality.
Signed-off-by: Jesse Barnes
---
tests/drv_getparams.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/drv_getparams.c b/tests/drv_getparams.c
index 31382e9..5a5c8bb 100644
--- a/tests/drv_getparams.c
+++ b/tests/drv_getparams.c
@@ -157,9 +157,9 @@ igt_main
init();
}
- igt_subtest("subslice-total")
+ igt_subtest("basic-subslice-total")
subslice_total();
- igt_subtest("eu-total")
+ igt_subtest("basic-eu-total")
eu_total();
}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/18] tests/drm_import_export: mark flink and prime tests as basic
They're testing basic functionality and don't involve stress or race
induction.
Signed-off-by: Jesse Barnes
---
tests/drm_import_export.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/drm_import_export.c b/tests/drm_import_export.c
index e24e0df..6a63ef9 100644
--- a/tests/drm_import_export.c
+++ b/tests/drm_import_export.c
@@ -265,7 +265,7 @@ igt_main {
test_import_close_race();
}
- igt_subtest("flink") {
+ igt_subtest("basic-flink") {
use_flink = true;
pthread_create(&test_thread_id1, NULL, test_thread, NULL);
@@ -279,7 +279,7 @@ igt_main {
pthread_join(test_thread_id4, NULL);
}
- igt_subtest("prime") {
+ igt_subtest("basic-prime") {
use_flink = false;
pthread_create(&test_thread_id1, NULL, test_thread, NULL);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/18] tests/drv_module_reload_basic: use linear_blits after module_reload for sanity check
Reduces runtime a lot... Signed-off-by: Jesse Barnes --- tests/drv_module_reload_basic | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/drv_module_reload_basic b/tests/drv_module_reload_basic index bb29a64..cf7f2b8 100755 --- a/tests/drv_module_reload_basic +++ b/tests/drv_module_reload_basic @@ -52,7 +52,7 @@ else fi # then try to run something -if ! $SOURCE_DIR/gem_exec_nop > /dev/null ; then +if ! $SOURCE_DIR/gem_linear_blits --r basic > /dev/null ; then echo "failed to execute a simple batch after reload" exit 3 fi -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/18] tests/gem_mmap_gtt: mark basic access and copy tests as basic
These ones should always pass and are fairly quick.
Signed-off-by: Jesse Barnes
---
tests/gem_mmap_gtt.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tests/gem_mmap_gtt.c b/tests/gem_mmap_gtt.c
index a95b98a..f964b39 100644
--- a/tests/gem_mmap_gtt.c
+++ b/tests/gem_mmap_gtt.c
@@ -525,7 +525,7 @@ igt_main
igt_fixture
fd = drm_open_any();
- igt_subtest("access")
+ igt_subtest("basic")
test_access(fd);
igt_subtest("short")
test_short(fd);
@@ -556,11 +556,11 @@ igt_main
igt_subtest("write-cpu-read-gtt")
test_write_cpu_read_gtt(fd);
- igt_subtest("small-bo")
+ igt_subtest("basic-small-bo")
test_huge_bo(fd, -1, I915_TILING_NONE);
- igt_subtest("small-bo-tiledX")
+ igt_subtest("basic-small-bo-tiledX")
test_huge_bo(fd, -1, I915_TILING_X);
- igt_subtest("small-bo-tiledY")
+ igt_subtest("basic-small-bo-tiledY")
test_huge_bo(fd, -1, I915_TILING_Y);
igt_subtest("big-bo")
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/18] tests/gem_pread/pwrite: mark normal tests as basic
These should always pass.
Signed-off-by: Jesse Barnes
---
tests/gem_pread.c | 2 +-
tests/gem_pwrite.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/gem_pread.c b/tests/gem_pread.c
index cc83948..3ec5fb1 100644
--- a/tests/gem_pread.c
+++ b/tests/gem_pread.c
@@ -108,7 +108,7 @@ int main(int argc, char **argv)
src = malloc(object_size);
}
- igt_subtest("normal") {
+ igt_subtest("basic") {
for (count = 1; count <= 1<<17; count <<= 1) {
struct timeval start, end;
diff --git a/tests/gem_pwrite.c b/tests/gem_pwrite.c
index 5b6a77f..1d867e7 100644
--- a/tests/gem_pwrite.c
+++ b/tests/gem_pwrite.c
@@ -169,7 +169,7 @@ int main(int argc, char **argv)
src = malloc(object_size);
}
- igt_subtest("normal") {
+ igt_subtest("basic") {
for (count = 1; count <= 1<<17; count <<= 1) {
struct timeval start, end;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/18] tests/drv_suspend: mark sysfs tests as basic
debugfs may not be mounted, but sysfs should always be restored after
suspend or hibernate.
Signed-off-by: Jesse Barnes
---
tests/drv_suspend.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/drv_suspend.c b/tests/drv_suspend.c
index d67a794..60ca8e3 100644
--- a/tests/drv_suspend.c
+++ b/tests/drv_suspend.c
@@ -193,7 +193,7 @@ igt_main
igt_subtest("debugfs-reader")
test_debugfs_reader(false);
- igt_subtest("sysfs-reader")
+ igt_subtest("basic-sysfs-reader")
test_sysfs_reader(false);
igt_subtest("forcewake")
@@ -208,7 +208,7 @@ igt_main
igt_subtest("debugfs-reader-hibernate")
test_debugfs_reader(true);
- igt_subtest("sysfs-reader-hibernate")
+ igt_subtest("basic-sysfs-reader-hibernate")
test_sysfs_reader(true);
igt_subtest("forcewake-hibernate")
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/18] tests/gem_storedw_loop: add new store_dword test to unify per-ring ones
There was a lot of duplication going on... Mark as basic while we're at
it as these should never fail.
Signed-off-by: Jesse Barnes
---
tests/Makefile.sources | 1 +
tests/gem_storedw_loop.c | 181 +++
2 files changed, 182 insertions(+)
create mode 100644 tests/gem_storedw_loop.c
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index b9a4cb4..cdcee33 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -138,6 +138,7 @@ TESTS_progs = \
gem_seqno_wrap \
gem_set_tiling_vs_gtt \
gem_set_tiling_vs_pwrite \
+ gem_storedw_loop \
gem_storedw_loop_blt \
gem_storedw_loop_bsd \
gem_storedw_loop_render \
diff --git a/tests/gem_storedw_loop.c b/tests/gem_storedw_loop.c
new file mode 100644
index 000..e4ed35d
--- /dev/null
+++ b/tests/gem_storedw_loop.c
@@ -0,0 +1,181 @@
+/*
+ * Copyright © 2009 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:
+ *Eric Anholt
+ *Jesse Barnes (based on gem_bad_blit.c)
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "drm.h"
+#include "ioctl_wrappers.h"
+#include "drmtest.h"
+#include "intel_bufmgr.h"
+#include "intel_batchbuffer.h"
+#include "intel_io.h"
+#include "intel_chipset.h"
+
+IGT_TEST_DESCRIPTION("Basic CS check using MI_STORE_DATA_IMM.");
+
+#define LOCAL_I915_EXEC_VEBOX (4<<0)
+
+static drm_intel_bufmgr *bufmgr;
+struct intel_batchbuffer *batch;
+static drm_intel_bo *target_buffer;
+static int has_ppgtt = 0;
+static int devid;
+
+/*
+ * Testcase: Basic bsd MI check using MI_STORE_DATA_IMM
+ */
+
+static void
+emit_store_dword_imm(drm_intel_bo *dest, uint32_t val)
+{
+ int cmd;
+ cmd = MI_STORE_DWORD_IMM;
+ if (!has_ppgtt)
+ cmd |= MI_MEM_VIRTUAL;
+
+ BEGIN_BATCH(4, 0);
+ OUT_BATCH(cmd);
+ if (batch->gen >= 8) {
+ OUT_RELOC(dest, I915_GEM_DOMAIN_INSTRUCTION,
+ I915_GEM_DOMAIN_INSTRUCTION, 0);
+ OUT_BATCH(val);
+ } else {
+ OUT_BATCH(0); /* reserved */
+ OUT_RELOC(dest, I915_GEM_DOMAIN_INSTRUCTION,
+ I915_GEM_DOMAIN_INSTRUCTION, 0);
+ OUT_BATCH(val);
+ }
+ ADVANCE_BATCH();
+}
+
+static void
+store_dword_loop(int ring, int count, int divider)
+{
+ int i, val = 0;
+ uint32_t *buf;
+
+ igt_info("running storedw loop on render with stall every %i batch\n",
divider);
+
+ for (i = 0; i < SLOW_QUICK(0x2000, 0x10); i++) {
+ emit_store_dword_imm(target_buffer, val);
+ intel_batchbuffer_flush_on_ring(batch, ring);
+
+ if (i % divider != 0)
+ goto cont;
+
+ drm_intel_bo_map(target_buffer, 0);
+
+ buf = target_buffer->virtual;
+ igt_assert_f(buf[0] == val,
+"value mismatch: cur 0x%08x, stored 0x%08x\n",
+buf[0], val);
+
+ drm_intel_bo_unmap(target_buffer);
+
+cont:
+ val++;
+ }
+
+ drm_intel_bo_map(target_buffer, 0);
+ buf = target_buffer->virtual;
+
+ igt_info("completed %d writes successfully, current value: 0x%08x\n", i,
+ buf[0]);
+ drm_intel_bo_unmap(target_buffer);
+}
+
+static void
+store_test(int ring, int count)
+{
+ drm_intel_bufmgr_gem_enable_reuse(bufmgr);
+
+ batch = intel_batchbuffer_alloc(bufmgr, devid);
+ igt_assert(batch);
+
+ target_buffer = drm_intel_bo_alloc(bufmgr, "target bo", 4096, 4096);
+ igt_assert(target_buffer);
+
+ store_dword_loop(ring, count, 1);
+ store_dword_loop(ring, count, 2);
+ if (!igt_run_in_simulation()) {
+ store_dword_loop(ring, count, 3);
+
[Intel-gfx] [PATCH 02/18] tests/drv_module_reload: rename drv_module_reload to include in BATs
Signed-off-by: Jesse Barnes
---
tests/Makefile.sources| 2 +-
tests/drv_module_reload | 60 ---
tests/drv_module_reload_basic | 60 +++
3 files changed, 61 insertions(+), 61 deletions(-)
delete mode 100755 tests/drv_module_reload
create mode 100755 tests/drv_module_reload_basic
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index cdcee33..4fe7d4c 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -178,7 +178,7 @@ TESTS_scripts = \
debugfs_emon_crash \
drv_debugfs_reader \
drv_missed_irq_hang \
- drv_module_reload \
+ drv_module_reload_basic \
kms_sysfs_edid_timing \
sysfs_l3_parity \
test_rte_check \
diff --git a/tests/drv_module_reload b/tests/drv_module_reload
deleted file mode 100755
index bb29a64..000
--- a/tests/drv_module_reload
+++ /dev/null
@@ -1,60 +0,0 @@
-#!/bin/bash
-#
-# Testcase: Reload the drm module
-#
-# ... we've broken this way too often :(
-#
-
-SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
-. $SOURCE_DIR/drm_lib.sh
-
-# no other drm service should be running, so we can just unbind
-
-# we must kick away fbcon (but only fbcon)
-for vtcon in /sys/class/vtconsole/vtcon*/ ; do
- if grep "frame buffer device" $vtcon/name > /dev/null ; then
- echo unbinding $vtcon: `cat $vtcon/name`
- echo 0 > $vtcon/bind
- fi
-done
-
-# The sound driver uses our power well
-pkill alsactl
-rmmod snd_hda_intel &> /dev/null
-
-#ignore errors in ips - gen5 only
-rmmod intel_ips &> /dev/null
-rmmod i915
-#ignore errors in intel-gtt, often built-in
-rmmod intel-gtt &> /dev/null
-# drm may be used by other devices (nouveau, radeon, udl, etc)
-rmmod drm_kms_helper &> /dev/null
-rmmod drm &> /dev/null
-
-if lsmod | grep i915 &> /dev/null ; then
- echo WARNING: i915.ko still loaded!
- exit 1
-else
- echo module successfully unloaded
-fi
-
-modprobe i915
-echo 1 > /sys/class/vtconsole/vtcon1/bind
-
-modprobe snd_hda_intel
-
-# does the device exist?
-if $SOURCE_DIR/gem_alive > /dev/null ; then
- echo "module successfully loaded again"
-else
- echo "failed to reload module successfully"
- exit 2
-fi
-
-# then try to run something
-if ! $SOURCE_DIR/gem_exec_nop > /dev/null ; then
- echo "failed to execute a simple batch after reload"
- exit 3
-fi
-
-exit 0
diff --git a/tests/drv_module_reload_basic b/tests/drv_module_reload_basic
new file mode 100755
index 000..bb29a64
--- /dev/null
+++ b/tests/drv_module_reload_basic
@@ -0,0 +1,60 @@
+#!/bin/bash
+#
+# Testcase: Reload the drm module
+#
+# ... we've broken this way too often :(
+#
+
+SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
+. $SOURCE_DIR/drm_lib.sh
+
+# no other drm service should be running, so we can just unbind
+
+# we must kick away fbcon (but only fbcon)
+for vtcon in /sys/class/vtconsole/vtcon*/ ; do
+ if grep "frame buffer device" $vtcon/name > /dev/null ; then
+ echo unbinding $vtcon: `cat $vtcon/name`
+ echo 0 > $vtcon/bind
+ fi
+done
+
+# The sound driver uses our power well
+pkill alsactl
+rmmod snd_hda_intel &> /dev/null
+
+#ignore errors in ips - gen5 only
+rmmod intel_ips &> /dev/null
+rmmod i915
+#ignore errors in intel-gtt, often built-in
+rmmod intel-gtt &> /dev/null
+# drm may be used by other devices (nouveau, radeon, udl, etc)
+rmmod drm_kms_helper &> /dev/null
+rmmod drm &> /dev/null
+
+if lsmod | grep i915 &> /dev/null ; then
+ echo WARNING: i915.ko still loaded!
+ exit 1
+else
+ echo module successfully unloaded
+fi
+
+modprobe i915
+echo 1 > /sys/class/vtconsole/vtcon1/bind
+
+modprobe snd_hda_intel
+
+# does the device exist?
+if $SOURCE_DIR/gem_alive > /dev/null ; then
+ echo "module successfully loaded again"
+else
+ echo "failed to reload module successfully"
+ exit 2
+fi
+
+# then try to run something
+if ! $SOURCE_DIR/gem_exec_nop > /dev/null ; then
+ echo "failed to execute a simple batch after reload"
+ exit 3
+fi
+
+exit 0
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [4.2-rc4] acpi|drm|i915: circular locking dependency: acpi_video_get_backlight_type
On Thu, Aug 13, 2015 at 4:33 PM, Hans de Goede wrote:
> Hi,
>
> On 12-08-15 21:26, Ville Syrjälä wrote:
>>
>> On Mon, Aug 10, 2015 at 08:29:00PM +0200, Sedat Dilek wrote:
>>>
>>> On Sat, Aug 1, 2015 at 2:23 PM, Sedat Dilek
>>> wrote:
On Mon, Jul 27, 2015 at 12:33 AM, Sedat Dilek
wrote:
>
> Hi,
>
> this my first build of a 4.2-rcN Linux-kernel and I see this...
>
Just FYI:
I am *not* seeing this with drm-intel-nightly from below url.
Also, I plan to test Linux v4.2-rc5.
>>>
>>> [ CC Linus ]
>>>
>>> Knock Knock Knock.
>>>
>>> This issue still remains here (with CONFIG_DRM_I915=m)...
>>>
>>> [ 18.269792] ==
>>> [ 18.269798] [ INFO: possible circular locking dependency detected ]
>>> [ 18.269805] 4.2.0-rc6-1-iniza-small #1 Not tainted
>>> [ 18.269810] ---
>>> [ 18.269816] modprobe/727 is trying to acquire lock:
>>> [ 18.269822] (init_mutex){+.+.+.}, at: []
>>> acpi_video_get_backlight_type+0x17/0x164 [video]
>>> [ 18.269840]
>>> [ 18.269840] but task is already holding lock:
>>> [ 18.269848] (&(&backlight_notifier)->rwsem){..}, at:
>>> [] __blocking_notifier_call_chain+0x39/0x70
>>> [ 18.269864]
>>> [ 18.269864] which lock already depends on the new lock.
>>> [ 18.269864]
>>> [ 18.269875]
>>> [ 18.269875] the existing dependency chain (in reverse order) is:
>>> [ 18.269884]
>>> ...
>>>
>>> Full dmesg log and kernel-config attached.
>>>
>>> Shall I add Rusty and modules/modprobe folks?
>>
>>
>> Just got back from vacation and was greeted by this same lockdep splat.
>>
>> On a hunch I reverted
>>
>> commit 93a291dfaf9c328ca5a9cea1733af1a128efe890
>> Author: Hans de Goede
>> Date: Tue Jun 16 16:27:52 2015 +0200
>>
>> ACPI / video: Move backlight notifier to video_detect.c
>>
>> and the problem seems to be gone. Hans, any thoughts?
>
>
> Looking into this atm, lockdep clearly is right.
>
> Sorry about this I have put a lot of thinking into avoiding
> these kind of issues with this patch-set, but I did not realize
> there was another lock "hiding" inside the notifier-chain.
>
> Further analysis shows that the lock inside the notifier-chain
> causes similar problems vs register_count_mutex from
> drivers/acpi/acpi_video.c. I'm working on a fix for this
> atm.
>
"[PATCH] ACPI / video: Fix circular lock dependency issue in the
video-detect code" (see [1])
...fixes the issue for me.
- sed@ -
[1] https://patchwork.kernel.org/patch/7009441/
> Regards,
>
> Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/18] tests/pm_backlight: mark simple test as basic
We should be able to adjust the backlight and observe changes in sysfs.
Signed-off-by: Jesse Barnes
---
tests/pm_backlight.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/pm_backlight.c b/tests/pm_backlight.c
index d02336d..cff2694 100644
--- a/tests/pm_backlight.c
+++ b/tests/pm_backlight.c
@@ -157,7 +157,7 @@ igt_main
igt_assert(backlight_read(&max, "max_brightness") > -1);
}
- igt_subtest("brightness")
+ igt_subtest("basic-brightness")
test_brightness(max);
igt_subtest("bad-brightness")
test_bad_brightness(max);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 16/18] tests/kms_flip: add basic tests for flip, flip vs dpms, and flip modeset
Simple variants that don't do multiple output or interruptible testing.
Signed-off-by: Jesse Barnes
---
tests/kms_flip.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index a595d9f..a0e4112 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -80,6 +80,7 @@
#define TEST_TS_CONT (1 << 27)
#define TEST_BO_TOOBIG (1 << 28)
#define TEST_HANG_ONCE (1 << 29)
+#define TEST_BASIC (1 << 30)
#define EVENT_FLIP (1 << 0)
#define EVENT_VBLANK (1 << 1)
@@ -1649,7 +1650,7 @@ int main(int argc, char **argv)
"blt-wf_vblank-vs-modeset" },
{ 60, TEST_VBLANK | TEST_MODESET | TEST_WITH_DUMMY_RCS,
"rcs-wf_vblank-vs-modeset" },
-
+ { 30, TEST_FLIP | TEST_BASIC, "basic-plain-flip" },
{ 30, TEST_FLIP , "plain-flip" },
{ 30, TEST_FLIP | TEST_EBUSY , "busy-flip" },
{ 30, TEST_FLIP | TEST_FENCE_STRESS , "flip-vs-fences" },
@@ -1657,12 +1658,14 @@ int main(int argc, char **argv)
{ 30, TEST_FLIP | TEST_CHECK_TS | TEST_FB_RECREATE,
"plain-flip-fb-recreate" },
{ 30, TEST_FLIP | TEST_RMFB | TEST_MODESET , "flip-vs-rmfb" },
+ { 60, TEST_FLIP | TEST_DPMS | TEST_EINVAL | TEST_BASIC,
"basic-flip-vs-dpms" },
{ 60, TEST_FLIP | TEST_DPMS | TEST_EINVAL, "flip-vs-dpms" },
{ 60, TEST_FLIP | TEST_DPMS | TEST_WITH_DUMMY_BCS,
"blt-flip-vs-dpms" },
{ 60, TEST_FLIP | TEST_DPMS | TEST_WITH_DUMMY_RCS,
"render-flip-vs-dpms" },
{ 30, TEST_FLIP | TEST_PAN, "flip-vs-panning" },
{ 60, TEST_FLIP | TEST_PAN | TEST_WITH_DUMMY_BCS,
"blt-flip-vs-panning" },
{ 60, TEST_FLIP | TEST_PAN | TEST_WITH_DUMMY_RCS,
"render-flip-vs-panning" },
+ { 60, TEST_FLIP | TEST_MODESET | TEST_EINVAL | TEST_BASIC,
"basic-flip-vs-modeset" },
{ 60, TEST_FLIP | TEST_MODESET | TEST_EINVAL, "flip-vs-modeset"
},
{ 60, TEST_FLIP | TEST_MODESET | TEST_WITH_DUMMY_BCS,
"blt-flip-vs-modeset" },
{ 60, TEST_FLIP | TEST_MODESET | TEST_WITH_DUMMY_RCS,
"render-flip-vs-modeset" },
@@ -1721,6 +1724,9 @@ int main(int argc, char **argv)
igt_subtest(tests[i].name)
run_test(tests[i].duration, tests[i].flags);
+ if (tests[i].flags & TEST_BASIC)
+ continue;
+
if (tests[i].flags & TEST_NO_2X_OUTPUT)
continue;
@@ -1740,6 +1746,9 @@ int main(int argc, char **argv)
!(tests[i].flags & TEST_VBLANK_ABSOLUTE))
continue;
+ if (tests[i].flags & TEST_BASIC)
+ continue;
+
igt_subtest_f( "%s-interruptible", tests[i].name)
run_test(tests[i].duration, tests[i].flags);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 15/18] tests/pm_rpm: mark RTE and D3 tests as basic
These always need to pass for basic PM functionality.
Signed-off-by: Jesse Barnes
---
tests/pm_rpm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/pm_rpm.c b/tests/pm_rpm.c
index d509fa8..7ae5806 100644
--- a/tests/pm_rpm.c
+++ b/tests/pm_rpm.c
@@ -1832,11 +1832,11 @@ int main(int argc, char *argv[])
stay_subtest();
/* Essential things */
- igt_subtest("rte")
+ igt_subtest("basic-rte")
basic_subtest();
igt_subtest("drm-resources-equal")
drm_resources_equal_subtest();
- igt_subtest("pci-d3-state")
+ igt_subtest("basic-pci-d3-state")
pci_d3_state_subtest();
/* Basic modeset */
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 18/18] gitignore: ignore more files
--- .gitignore | 3 +++ tests/.gitignore | 13 + tools/.gitignore | 8 3 files changed, 24 insertions(+) diff --git a/.gitignore b/.gitignore index a438c1c..533f6f1 100644 --- a/.gitignore +++ b/.gitignore @@ -90,3 +90,6 @@ gtk-doc.m4 piglit results + +*.orig +version.h diff --git a/tests/.gitignore b/tests/.gitignore index 31d35a5..e45cbb7 100644 --- a/tests/.gitignore +++ b/tests/.gitignore @@ -99,6 +99,7 @@ gem_set_tiling_vs_blt gem_set_tiling_vs_gtt gem_set_tiling_vs_pwrite gem_storedw_batches_loop +gem_storedw_loop gem_storedw_loop_blt gem_storedw_loop_bsd gem_storedw_loop_render @@ -169,3 +170,15 @@ prime_udl template test-list.txt testdisplay +ddi_compute_wrpll +gem_vmap_blits +gem_wait_render_timeout +igt_fork_helper +igt_list_only +igt_no_exit +igt_no_exit_list_only +igt_no_subtest +igt_simulation +pm_pc8 +pm_psr + diff --git a/tools/.gitignore b/tools/.gitignore index 49bd24f..7bf91e3 100644 --- a/tools/.gitignore +++ b/tools/.gitignore @@ -37,3 +37,11 @@ intel_vga_write intel_watermark skl_compute_wrpll skl_ddb_allocation +forcewaked +intel_dpio_read +intel_dpio_write +intel_gpu_dump +intel_nc_read +intel_nc_write +intel_punit_read +intel_punit_write -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 13/18] tests/kms_vblank: mark accuracy test as basic
Need some simple vblank coverage in the BAT list.
Signed-off-by: Jesse Barnes
---
tests/kms_vblank.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/kms_vblank.c b/tests/kms_vblank.c
index 6946177..ef2f7ca 100644
--- a/tests/kms_vblank.c
+++ b/tests/kms_vblank.c
@@ -188,7 +188,7 @@ igt_main
igt_require(crtc0_active(fd));
}
- igt_subtest("accuracy")
+ igt_subtest("basic-accuracy")
accuracy(fd);
igt_subtest("query-idle")
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/18] tests/gem_tiled_pread/pwrite: mark normal tests as basic
These simple tests should always pass.
Signed-off-by: Jesse Barnes
---
tests/gem_tiled_pread.c| 167 +
tests/gem_tiled_pread_pwrite.c | 48 ++--
2 files changed, 112 insertions(+), 103 deletions(-)
diff --git a/tests/gem_tiled_pread.c b/tests/gem_tiled_pread.c
index fdc5173..92bb649 100644
--- a/tests/gem_tiled_pread.c
+++ b/tests/gem_tiled_pread.c
@@ -112,7 +112,7 @@ calculate_expected(int offset)
return (base_y + tile_y) * WIDTH + base_x + tile_x;
}
-igt_simple_main
+igt_main
{
int fd;
int i, iter = 100;
@@ -120,96 +120,101 @@ igt_simple_main
uint32_t handle;
uint32_t devid;
- fd = drm_open_any();
+ igt_fixture {
+ fd = drm_open_any();
- handle = create_bo(fd);
- gem_get_tiling(fd, handle, &tiling, &swizzle);
+ handle = create_bo(fd);
+ gem_get_tiling(fd, handle, &tiling, &swizzle);
- devid = intel_get_drm_devid(fd);
-
- if (IS_GEN2(devid)) {
- tile_height = 16;
- tile_width = 128;
- tile_size = 2048;
- } else {
- tile_height = 8;
- tile_width = 512;
- tile_size = PAGE_SIZE;
+ devid = intel_get_drm_devid(fd);
}
- /* Read a bunch of random subsets of the data and check that they come
-* out right.
-*/
- for (i = 0; i < iter; i++) {
- int size = WIDTH * HEIGHT * 4;
- int offset = (random() % size) & ~3;
- int len = (random() % size) & ~3;
- int j;
+ igt_subtest("basic") {
- if (len == 0)
- len = 4;
+ if (IS_GEN2(devid)) {
+ tile_height = 16;
+ tile_width = 128;
+ tile_size = 2048;
+ } else {
+ tile_height = 8;
+ tile_width = 512;
+ tile_size = PAGE_SIZE;
+ }
- if (offset + len > size)
- len = size - offset;
+ /* Read a bunch of random subsets of the data and check that
they come
+* out right.
+*/
+ for (i = 0; i < iter; i++) {
+ int size = WIDTH * HEIGHT * 4;
+ int offset = (random() % size) & ~3;
+ int len = (random() % size) & ~3;
+ int j;
- if (i == 0) {
- offset = 0;
- len = size;
- }
+ if (len == 0)
+ len = 4;
- gem_read(fd, handle, offset, linear, len);
+ if (offset + len > size)
+ len = size - offset;
- /* Translate from offsets in the read buffer to the swizzled
-* address that it corresponds to. This is the opposite of
-* what Mesa does (calculate offset to be read given the linear
-* offset it's looking for).
-*/
- for (j = offset; j < offset + len; j += 4) {
- uint32_t expected_val, found_val;
- int swizzled_offset;
- const char *swizzle_str;
-
- switch (swizzle) {
- case I915_BIT_6_SWIZZLE_NONE:
- swizzled_offset = j;
- swizzle_str = "none";
- break;
- case I915_BIT_6_SWIZZLE_9:
- swizzled_offset = j ^
- swizzle_bit(9, j);
- swizzle_str = "bit9";
- break;
- case I915_BIT_6_SWIZZLE_9_10:
- swizzled_offset = j ^
- swizzle_bit(9, j) ^
- swizzle_bit(10, j);
- swizzle_str = "bit9^10";
- break;
- case I915_BIT_6_SWIZZLE_9_11:
- swizzled_offset = j ^
- swizzle_bit(9, j) ^
- swizzle_bit(11, j);
- swizzle_str = "bit9^11";
- break;
- case I915_BIT_6_SWIZZLE_9_10_11:
- swizzled_offset = j ^
- swizzle_bit(9, j) ^
- swizzle_bit(10, j) ^
- swizzle_bit(11, j);
- swizzle_str = "bit9^10^11";
- break;
-
[Intel-gfx] [PATCH 12/18] tests/kms_addfb: mark simple fb creation tests as basic
We should always be able to create simple and tiled objects.
Signed-off-by: Jesse Barnes
---
tests/kms_addfb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/kms_addfb.c b/tests/kms_addfb.c
index 42ee632..f10e12b 100644
--- a/tests/kms_addfb.c
+++ b/tests/kms_addfb.c
@@ -121,7 +121,7 @@ static void pitch_tests(int fd)
}
f.handles[0] = gem_bo;
- igt_subtest("normal") {
+ igt_subtest("basic") {
igt_assert(drmIoctl(fd, DRM_IOCTL_MODE_ADDFB2, &f) == 0);
igt_assert(drmIoctl(fd, DRM_IOCTL_MODE_RMFB, &f.fb_id) == 0);
f.fb_id = 0;
@@ -139,7 +139,7 @@ static void pitch_tests(int fd)
gem_set_tiling(fd, gem_bo, I915_TILING_X, 1024*4);
f.pitches[0] = 1024*4;
- igt_subtest("X-tiled") {
+ igt_subtest("basic-X-tiled") {
igt_assert(drmIoctl(fd, DRM_IOCTL_MODE_ADDFB2, &f) == 0);
igt_assert(drmIoctl(fd, DRM_IOCTL_MODE_RMFB, &f.fb_id) == 0);
f.fb_id = 0;
@@ -162,7 +162,7 @@ static void pitch_tests(int fd)
igt_fixture
gem_set_tiling(fd, gem_bo, I915_TILING_Y, 1024*4);
f.pitches[0] = 1024*4;
- igt_subtest("Y-tiled") {
+ igt_subtest("basic-Y-tiled") {
igt_assert(drmIoctl(fd, DRM_IOCTL_MODE_ADDFB2, &f) == -1 &&
errno == EINVAL);
}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 17/18] tests/kms_setmode: mark simple clone test as basic
Should cover simple, single CRTC mode sets.
Signed-off-by: Jesse Barnes
---
tests/kms_setmode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/kms_setmode.c b/tests/kms_setmode.c
index 82769ab..2c0fe45 100644
--- a/tests/kms_setmode.c
+++ b/tests/kms_setmode.c
@@ -685,7 +685,7 @@ int main(int argc, char **argv)
const char *name;
} tests[] = {
{ TEST_CLONE | TEST_SINGLE_CRTC_CLONE,
- "clone-single-crtc" },
+ "basic-clone-single-crtc" },
{ TEST_INVALID | TEST_CLONE | TEST_SINGLE_CRTC_CLONE,
"invalid-clone-single-crtc" },
{ TEST_INVALID | TEST_CLONE | TEST_EXCLUSIVE_CRTC_CLONE,
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bdw: Check for slice, subslice and EU count for BDW
On Thu, 2015-08-13 at 14:38 +0200, Łukasz Daniluk wrote:
> Added checks for available slices, subslices and EUs for Broadwell.
> This
> information is filled in intel_device_info and is available to user
> with
> GET_PARAM.
> Added checks for enabled slices, subslices and EU for Broadwell. This
> information is based on available counts but takes power gated slices
> into account. It can be read in debugfs.
> Introduce new register defines that contain information on slices on
> Broadwell.
>
> Cc: Jeff Mcgee
> Signed-off-by: Łukasz Daniluk
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 35 +--
> drivers/gpu/drm/i915/i915_dma.c | 89
> +
> drivers/gpu/drm/i915/i915_reg.h | 19 +++-
> 3 files changed, 138 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 23a69307..a17f912 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -4838,7 +4838,6 @@ struct sseu_dev_status {
> static void cherryview_sseu_device_status(struct drm_device *dev,
> struct sseu_dev_status *stat)
> {
> - struct drm_i915_private *dev_priv = dev->dev_private;
> const int ss_max = 2;
> int ss;
> u32 sig1[ss_max], sig2[ss_max];
> @@ -4870,7 +4869,6 @@ static void
> cherryview_sseu_device_status(struct drm_device *dev,
> static void gen9_sseu_device_status(struct drm_device *dev,
> struct sseu_dev_status *stat)
> {
> - struct drm_i915_private *dev_priv = dev->dev_private;
> int s_max = 3, ss_max = 4;
> int s, ss;
> u32 s_reg[s_max], eu_reg[2*s_max], eu_mask[2];
> @@ -4932,13 +4930,42 @@ static void gen9_sseu_device_status(struct
> drm_device *dev,
> }
> }
>
> +static void broadwell_sseu_device_status(struct drm_device *dev,
> + struct sseu_dev_status *stat)
> +{
> + int s;
> + u32 slice_info = I915_READ(GEN8_R_PWR_CLK_STATE);
> +
> + /*
> + * If first bit of slice_info is 0, there is no specific power
> + * state set. Otherwise we read the count of enabled slices
> + * from it.
> + */
> + if (slice_info & (1<<31))
> + stat->slice_total = (slice_info & GEN8_RPCS_S_CNT_MASK)
> + >> GEN8_RPCS_S_CNT_SHIFT;
> + else
> + stat->slice_total = INTEL_INFO(dev)->slice_total;
> +
> + stat->subslice_per_slice = INTEL_INFO(dev)->subslice_per_slice;
> + stat->eu_per_subslice = INTEL_INFO(dev)->eu_per_subslice;
> + stat->subslice_total = stat->slice_total * stat-
> >subslice_per_slice;
> + stat->eu_total = stat->eu_per_subslice * stat->subslice_total;
> +
> + /* subtract fused off EU(s) from enabled slice(s) */
> + for (s = 0; s < stat.slice_total; s++) {
> + u8 subslice_7eu = INTEL_INFO(dev)->subslice_7eu[s];
> + stat->eu_total -= hweight8(subslice_7eu);
> + }
> +}
> +
> static int i915_sseu_status(struct seq_file *m, void *unused)
> {
> struct drm_info_node *node = (struct drm_info_node *) m->private;
> struct drm_device *dev = node->minor->dev;
> struct sseu_dev_status stat;
>
> - if ((INTEL_INFO(dev)->gen < 8) || IS_BROADWELL(dev))
> + if ((INTEL_INFO(dev)->gen < 8))
> return -ENODEV;
>
> seq_puts(m, "SSEU Device Info\n");
> @@ -4963,6 +4990,8 @@ static int i915_sseu_status(struct seq_file
> *m, void *unused)
> memset(&stat, 0, sizeof(stat));
> if (IS_CHERRYVIEW(dev)) {
> cherryview_sseu_device_status(dev, &stat);
> + } else if (IS_BROADWELL(dev)) {
> + broadwell_sseu_device_status(dev, &stat);
> } else if (INTEL_INFO(dev)->gen >= 9) {
> gen9_sseu_device_status(dev, &stat);
> }
> diff --git a/drivers/gpu/drm/i915/i915_dma.c
> b/drivers/gpu/drm/i915/i915_dma.c
> index ab37d11..2d52b1e 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -705,6 +705,93 @@ static void gen9_sseu_info_init(struct
> drm_device *dev)
> info->has_eu_pg = (info->eu_per_subslice > 2);
> }
>
> +static void broadwell_sseu_info_init(struct drm_device *dev)
> +{
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + struct intel_device_info *info;
> + const int s_max = 3, ss_max = 3, eu_max = 8;
> + int s, ss;
> + u32 fuse2, eu_disable[s_max], s_enable, ss_disable;
> +
> + fuse2 = I915_READ(GEN8_FUSE2);
> + s_enable = (fuse2 & GEN8_F2_S_ENA_MASK) >>
> + GEN8_F2_S_ENA_SHIFT;
> + ss_disable = (fuse2 & GEN8_F2_SS_DIS_MASK) >>
> + GEN8_F2_SS_DIS_SHIFT;
> +
> + eu_disable[0] = I915_READ(GEN8_EU_DISABLE0) &
> + GEN8_EU_DIS0_S0_MASK;
> + eu_disable[1] = (I915_READ(GEN8_EU_DISABLE0) >>
> + GEN8_EU_DIS0_S1_SHIFT) |
> + ((I
Re: [Intel-gfx] [PATCH] lib/rendercopy_gen9: Setup Push constant pointer before sending BTP commands
On Thu, Aug 13, 2015 at 10:33:00AM +0300, Joonas Lahtinen wrote: > Hi, > > On ke, 2015-08-12 at 18:35 -0700, Ben Widawsky wrote: > > On Wed, Aug 12, 2015 at 03:10:18PM +0300, Joonas Lahtinen wrote: > > > On ke, 2015-08-12 at 12:26 +0100, Arun Siluvery wrote: > > > > From Gen9, by default push constant command is not committed to > > > > the > > > > shader unit > > > > untill the corresponding shader's BTP_* command is parsed. This > > > > is > > > > the > > > > behaviour when set shader is enabled. This patch updates the > > > > batch to > > > > follow > > > > this requirement otherwise it results in gpu hang. > > > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89959 > > > > > > > > Set shader need to be disabled if legacy behaviour is required. > > > > > > > > Cc: Ben Widawsky > > > > Cc: Joonas Lahtinen > > > > Cc: Mika Kuoppala > > > > Signed-off-by: Arun Siluvery > > > > > > Reviewed-by: Joonas Lahtinen > > > > > > > Repeating what I said on the mesa thread: > > Does anyone understand why this actually causes a hang on the IGT > > test? I > > certainly don't. The docs are pretty clear that the constant command > > is not > > committed until the BTP command, but I can't make any sense of how it > > related to > > a GPU hang. > > > > Changing the order makes the hang go away and come back for sure, we've > all been experiencing that. System validation said it is a programming > restriction, so I'm not sure how relevant it is what goes wrong if it's > not followed. And the legacy mode bits were added to support the old > behavior of having the order like it has been previously, so I do not > see why question it without visibility to the actual RTL. And enabling > the legacy bits makes the hang go away, too. > > If I had the RTL sources, then it would be more relevant to take > educated guesses as to why a set of hundreds of thousands of > transistors doesn't work as it should :) Without that, if it gets > stuck, it gets stuck. > > Regards, Joonas > Let me start by saying I do believe that questioning this shouldn't prevent merging the patch. I absolutely disagree with you and think we should question these kind of things and get out of the mindset of, "well, it fixes a hang, let's move on." Understanding these kind of things is critical to writing stable drivers. If the programming guide/SV team said it can lead to a hang, that's one thing, but AFAICT, we do not understand why it is hanging nor does any of the documentation we do have suggest it should hang. Without clarification, next time we have a similar hang signature we're going to be right back here where we started. It was one thing when there were a handful of us working on the stuff and we didn't have time to get to the bottom of bugs like this. I'm guilty of patches like this myself. I really do not see any excuse for this any more though. Could you send me the reference for where SV said it was a "programming restriction"? To me it all sounds very much like an implementation detail, and I'd like to try to understand what I am missing. > > [snip] > > > > --- > > Ben Widawsky, Intel Open Source Technology Center -- Ben Widawsky, 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 0/4] Add support for Hyperlinks and Markup on kernel-doc
On 07/23/2015 05:29 PM, Jonathan Corbet wrote: > On Thu, 23 Jul 2015 15:16:23 -0300 > Danilo Cesar Lemes de Paula wrote: > >> This series add supports for hyperlink cross-references on Docbooks and >> an optional markup syntax for in-source Documentation. > > I like the idea; just be warned that it's likely to be a week or two and > one more ocean crossing before I can take a serious look at this... > > Thanks, Hey, Did you find time to take a look on this? I understand that there's some discussion behind the curtains regarding the markdown support, but the cross-reference-hyperlink patch is also in the same patch series. It doesn't change any text in the docbook unless there's really a cross-reference link to it. Different from the markdown support (when people start to use markdown to write docs it will be hard to go back), the cross-link stuff doesn't require/create any change to current documentation, it is pretty safe to use. Would you mind to share your plans about this? Thanks, Danilo Cesar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 4/3] tests/gem_ctx_param_basic: Expand ctx_param tests
On 08/10/2015 07:15 AM, David Weinehall wrote: > On Thu, Aug 06, 2015 at 02:33:31PM -0700, Jesse Barnes wrote: >> On 08/06/2015 02:30 PM, Daniel Vetter wrote: >>> On Fri, May 29, 2015 at 09:52:52AM +0200, Daniel Vetter wrote: On Thu, May 28, 2015 at 05:53:17PM +0300, David Weinehall wrote: > On Wed, May 27, 2015 at 01:32:10PM +0200, Daniel Vetter wrote: >> A simple functional test here which does: >> a) an execbuf with just 1 batch. With full ppgtt you should get that one >> at offset 0. If not, skip the testcase. >> b) set the NO_ZEROMAP property. >> c) re-run the same batch, assert that now the buffer is relocated to >> something non-0. >> >> Just to make sure we have a bare minimal testcase to make sure we don't >> break this. > > Maybe this should be added to another test rather than here? This test > is described as a: > > "Basic test for context set/get param input validation." > > Somehow I feel that testing whether the *functionality* is correct > does not belong in this test, but rather in some test case that's > already related to execbufs, or even a dedicated test case. > > But that might be over-engineering. Opinions? Yeah separate testcase would fit better, agreed. >>> >>> Update version of this patch is still missing. I'll need to revert the >>> kernel side if this one doesn't show up soonish. >>> >>> Also you're breaking the invalid-flags testcase (did you bother to run >>> them all and check for regressions?) which Jesse spotted, and with the new >>> basic set this will be a P1 "I'm going to block everything" bug. >> >> We really need man pages for new ioctls as well in libdrm. > > Hmmm, this isn't a new ioctl, just a context parameter that can be > set/queried using a pre-existing ioctl, but I can modify the existing > manual page (if there is one?) to include information about the new > parameter. Yeah we don't have one for this ioctl unfortunately. There are examples of other ioctl man pages in the libdrm repo though; you could copy one of those and do one for the context get/set ioctl. If you don't have any time, can you just file a JIRA instead? We'll get to it eventually... :) Thanks, Jesse ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/4] Add support for Hyperlinks and Markup on kernel-doc
On Thu, 13 Aug 2015 20:09:35 -0300 Danilo Cesar Lemes de Paula wrote: > Did you find time to take a look on this? No. Just when I thought things couldn't get crazier, my laptop died. https://plus.google.com/+JonathanCorbet/posts/FBHp48dPb95 What spare time I had has been dedicated to recovering from that in time to give my talk next week. > I understand that there's some discussion behind the curtains regarding > the markdown support, but the cross-reference-hyperlink patch is also in > the same patch series. It doesn't change any text in the docbook unless > there's really a cross-reference link to it. Different from the markdown > support (when people start to use markdown to write docs it will be hard > to go back), the cross-link stuff doesn't require/create any change to > current documentation, it is pretty safe to use. > > Would you mind to share your plans about this? No behind-the-curtains discussions happening, or, let's say, if there are, I've not been invited either. I'd like to get back to the cross-reference stuff. Last I tried, it failed while building the media docs; have you been able to look at that? Longer term, as you may know from the kernel summit discussions, I'd really like to get rid of a lot of the XML gunk and put in something more straightforward, be it based on Markdown or something else. Doing that, however, requires that I find the time to implement something that's convincingly better. It may happen soon, but I sure can't guarantee it. Meanwhile, I think it would be a horrible mistake to delay useful work because I have a gleam in my eye to do something different one of these years, so I'll not do that. I fully expect to merge all of the stuff you've done, I just need to have a good look at it and test it out a bit. As I said before, I can't promise that for the 4.3 merge window, but I'll try. Apologies, jon ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] sna: Fix the reduction of xy reflection onto rotations.
When reducing a xy reflection to a 180 degree rotation, make sure
only one rotation bit is set. Also by rotating the bit left, we
can support cases where xy reflection happens with 90/270 degree
rotation.
Signed-off-by: Bob Paauwe
---
src/sna/sna_display.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
index 5b975c1..c8c2197 100644
--- a/src/sna/sna_display.c
+++ b/src/sna/sna_display.c
@@ -1007,6 +1007,8 @@ static unsigned
rotation_reduce(struct plane *p, unsigned rotation)
{
unsigned unsupported_rotations = rotation & ~p->rotation.supported;
+ unsigned rr_mask = (RR_Rotate_0 | RR_Rotate_90 |
+ RR_Rotate_180 | RR_Rotate_270);
if (unsupported_rotations == 0)
return rotation;
@@ -1016,7 +1018,8 @@ rotation_reduce(struct plane *p, unsigned rotation)
if ((unsupported_rotations & RR_Reflect_XY) == RR_Reflect_XY &&
p->rotation.supported& RR_Rotate_180) {
rotation &= ~RR_Reflect_XY;
- rotation ^= RR_Rotate_180;
+ rotation = ((rotation << 2 & rr_mask) |
+ (((rotation << 2) & ~rr_mask) >> 4));
}
if ((unsupported_rotations & RR_Rotate_180) &&
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix stolen bios_reserved checks
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 7138 -Summary- Platform Delta drm-intel-nightly Series Applied ILK -1 302/302 301/302 SNB 315/315 315/315 IVB 336/336 336/336 BYT 283/283 283/283 HSW 378/378 378/378 -Detailed- Platform Testdrm-intel-nightly Series Applied *ILK igt@kms_flip@wf_vblank-vs-modeset-interruptible PASS(1) DMESG_WARN(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bdw: Check for slice, subslice and EU count for BDW
On Thu, Aug 13, 2015 at 02:38:48PM +0200, Łukasz Daniluk wrote:
> Added checks for available slices, subslices and EUs for Broadwell. This
> information is filled in intel_device_info and is available to user with
> GET_PARAM.
> Added checks for enabled slices, subslices and EU for Broadwell. This
> information is based on available counts but takes power gated slices
> into account. It can be read in debugfs.
> Introduce new register defines that contain information on slices on
> Broadwell.
>
> Cc: Jeff Mcgee
> Signed-off-by: Łukasz Daniluk
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 35 +--
> drivers/gpu/drm/i915/i915_dma.c | 89
> +
> drivers/gpu/drm/i915/i915_reg.h | 19 +++-
> 3 files changed, 138 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 23a69307..a17f912 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -4838,7 +4838,6 @@ struct sseu_dev_status {
> static void cherryview_sseu_device_status(struct drm_device *dev,
> struct sseu_dev_status *stat)
> {
> - struct drm_i915_private *dev_priv = dev->dev_private;
Did you compile this? I915_READ macro requires dev_priv.
> const int ss_max = 2;
> int ss;
> u32 sig1[ss_max], sig2[ss_max];
> @@ -4870,7 +4869,6 @@ static void cherryview_sseu_device_status(struct
> drm_device *dev,
> static void gen9_sseu_device_status(struct drm_device *dev,
> struct sseu_dev_status *stat)
> {
> - struct drm_i915_private *dev_priv = dev->dev_private;
Did you compile this? I915_READ macro requires dev_priv.
> int s_max = 3, ss_max = 4;
> int s, ss;
> u32 s_reg[s_max], eu_reg[2*s_max], eu_mask[2];
> @@ -4932,13 +4930,42 @@ static void gen9_sseu_device_status(struct drm_device
> *dev,
> }
> }
>
> +static void broadwell_sseu_device_status(struct drm_device *dev,
> + struct sseu_dev_status *stat)
> +{
> + int s;
> + u32 slice_info = I915_READ(GEN8_R_PWR_CLK_STATE);
RPCS register only shows what slice state was requested, not the actual
slice state. You need to use the GEN8_GT_SLICE_INFO register that I
shared with you in my original patch for this.
> +
> + /*
> + * If first bit of slice_info is 0, there is no specific power
> + * state set. Otherwise we read the count of enabled slices
> + * from it.
> + */
> + if (slice_info & (1<<31))
> + stat->slice_total = (slice_info & GEN8_RPCS_S_CNT_MASK)
> + >> GEN8_RPCS_S_CNT_SHIFT;
> + else
> + stat->slice_total = INTEL_INFO(dev)->slice_total;
> +
> + stat->subslice_per_slice = INTEL_INFO(dev)->subslice_per_slice;
> + stat->eu_per_subslice = INTEL_INFO(dev)->eu_per_subslice;
> + stat->subslice_total = stat->slice_total * stat->subslice_per_slice;
> + stat->eu_total = stat->eu_per_subslice * stat->subslice_total;
> +
> + /* subtract fused off EU(s) from enabled slice(s) */
> + for (s = 0; s < stat.slice_total; s++) {
> + u8 subslice_7eu = INTEL_INFO(dev)->subslice_7eu[s];
> + stat->eu_total -= hweight8(subslice_7eu);
> + }
> +}
> +
> static int i915_sseu_status(struct seq_file *m, void *unused)
> {
> struct drm_info_node *node = (struct drm_info_node *) m->private;
> struct drm_device *dev = node->minor->dev;
> struct sseu_dev_status stat;
>
> - if ((INTEL_INFO(dev)->gen < 8) || IS_BROADWELL(dev))
> + if ((INTEL_INFO(dev)->gen < 8))
> return -ENODEV;
>
> seq_puts(m, "SSEU Device Info\n");
> @@ -4963,6 +4990,8 @@ static int i915_sseu_status(struct seq_file *m, void
> *unused)
> memset(&stat, 0, sizeof(stat));
> if (IS_CHERRYVIEW(dev)) {
> cherryview_sseu_device_status(dev, &stat);
> + } else if (IS_BROADWELL(dev)) {
> + broadwell_sseu_device_status(dev, &stat);
> } else if (INTEL_INFO(dev)->gen >= 9) {
> gen9_sseu_device_status(dev, &stat);
> }
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index ab37d11..2d52b1e 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -705,6 +705,93 @@ static void gen9_sseu_info_init(struct drm_device *dev)
> info->has_eu_pg = (info->eu_per_subslice > 2);
> }
>
> +static void broadwell_sseu_info_init(struct drm_device *dev)
> +{
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + struct intel_device_info *info;
> + const int s_max = 3, ss_max = 3, eu_max = 8;
> + int s, ss;
> + u32 fuse2, eu_disable[s_max], s_enable, ss_disable;
> +
> + fuse2 = I915_READ(GEN8_FUSE2);
> + s_enable = (fuse2 & GEN8_F2_S_ENA_MASK) >>
> + GEN8_F2_S_ENA_SHIFT;
> + ss_disable
[Intel-gfx] i915/kasan: out of bounds access in i915_cmd_parser_init_ring
I finally got around to playing with kasan. It didn't end well. I added some debugging to validate_cmds_sorted to print out the table sizes right before the stack traces. Dave validate_cmds_sorted: table:a1fb4220 cmd_table_count:3 validate_cmds_sorted: table:a1fb4220 table->count:12 validate_cmds_sorted: table:a1fb4230 table->count:20 validate_cmds_sorted: table:a1fb4230 table->count:20 validate_cmds_sorted: table:a1fb4240 table->count:18 validate_cmds_sorted: table:a1fb41e0 cmd_table_count:2 validate_cmds_sorted: table:a1fb41e0 table->count:12 validate_cmds_sorted: table:a1fb41f0 table->count:7 validate_cmds_sorted: table:a1fb4100 cmd_table_count:3 validate_cmds_sorted: table:a1fb4100 table->count:12 validate_cmds_sorted: table:a1fb4110 table->count:6 == BUG: KASan: out of bounds access in i915_cmd_parser_init_ring+0x66b/0x760 at addr a1fb4374 Read of size 4 by task swapper/0/1 Address belongs to variable hsw_blt_cmds+0xb4/0xe0 CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.2.0-rc6-firewall+ #4 0002 8801d6baf478 a1c0b4fb 0032 8801d6baf510 8801d6baf4f8 a123198f 8801d6baf5a8 ed003ad75e9b 0246 a1fb4110 1000 Call Trace: [] dump_stack+0x4f/0x7b [] kasan_report_error+0x3bf/0x3f0 [] kasan_report+0x3b/0x40 [] ? i915_cmd_parser_init_ring+0x66b/0x760 [] __asan_load4+0x66/0xa0 [] i915_cmd_parser_init_ring+0x66b/0x760 [] intel_init_ring_buffer+0x449/0x680 [] intel_init_blt_ring_buffer+0x38e/0x520 [] i915_gem_init_rings+0x74/0x220 [] i915_gem_init+0x1e2/0x320 [] i915_driver_load+0x1571/0x2310 [] ? debug_lockdep_rcu_enabled+0x4e/0x70 [] ? __lock_acquire+0x97e/0x2710 [] ? debug_smp_processor_id+0x17/0x20 [] ? debug_show_all_locks+0x280/0x280 [] ? __mutex_unlock_slowpath+0x11b/0x1e0 [] ? trace_hardirqs_on_caller+0x192/0x2a0 [] ? i915_getparam+0x390/0x390 [] ? mark_held_locks+0xa4/0xd0 [] ? _raw_spin_unlock_irqrestore+0x58/0x70 [] ? trace_hardirqs_on_caller+0x192/0x2a0 [] ? preempt_count_sub+0xc1/0x130 [] ? _raw_spin_unlock_irqrestore+0x43/0x70 [] drm_dev_register+0xd1/0x170 [] drm_get_pci_dev+0xf1/0x350 [] ? trace_hardirqs_on_caller+0x192/0x2a0 [] i915_pci_probe+0x83/0xb0 [] pci_device_probe+0xcf/0x130 [] driver_probe_device+0x1e1/0x410 [] ? driver_probe_device+0x410/0x410 [] ? driver_probe_device+0x410/0x410 [] __driver_attach+0xd6/0xe0 [] bus_for_each_dev+0xf5/0x160 [] ? bus_remove_file+0xa0/0xa0 [] ? do_raw_spin_unlock+0xa4/0x140 [] ? preempt_count_sub+0xc1/0x130 [] driver_attach+0x30/0x40 [] bus_add_driver+0x2b1/0x330 [] driver_register+0xde/0x1b0 [] __pci_register_driver+0xbc/0xd0 [] drm_pci_init+0x1e7/0x210 [] ? do_one_initcall+0x108/0x242 [] ? do_one_initcall+0x108/0x242 [] i915_init+0xdb/0xe3 [] ? mipi_dsi_bus_init+0x12/0x12 [] do_one_initcall+0x227/0x242 [] ? start_kernel+0x4ed/0x4ed [] ? parse_args+0x5b/0x4f0 [] kernel_init_freeable+0x290/0x321 [] ? rest_init+0x150/0x150 [] kernel_init+0x14/0x100 [] ? rest_init+0x150/0x150 [] ret_from_fork+0x3f/0x70 [] ? rest_init+0x150/0x150 Memory state around the buggy address: a1fb4200: fa fa fa fa 00 00 00 00 00 00 fa fa fa fa fa fa a1fb4280: 00 00 00 00 fa fa fa fa 00 00 00 00 00 00 00 00 >a1fb4300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa fa ^ a1fb4380: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00 a1fb4400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 == == BUG: KASan: out of bounds access in i915_cmd_parser_init_ring+0x67e/0x760 at addr a1fb4378 Read of size 4 by task swapper/0/1 Address belongs to variable hsw_blt_cmds+0xb8/0xe0 CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.2.0-rc6-firewall+ #4 0002 8801d6baf478 a1c0b4fb 0032 8801d6baf510 8801d6baf4f8 a123198f 0010 ed00 0246 fbfff43f686e 66201000 Call Trace: [] dump_stack+0x4f/0x7b [] kasan_report_error+0x3bf/0x3f0 [] kasan_report+0x3b/0x40 [] ? i915_cmd_parser_init_ring+0x67e/0x760 [] __asan_load4+0x66/0xa0 [] i915_cmd_parser_init_ring+0x67e/0x760 [] intel_init_ring_buffer+0x449/0x680 [] intel_init_blt_ring_buffer+0x38e/0x520 [] i915_gem_init_rings+0x74/0x220 [] i915_gem_init+0x1e2/0x320 [] i915_driver_load+0x1571/0x2310 [] ? debug_lockdep_rcu_enabled+0x4e/0x70 [] ? __lock_acquire+0x97e/0x2710 [] ? debug_smp_processor_id+0x17/0x20 [] ? debug_show_all_locks+0x280/0x280 [] ? __mutex_unlock_slowpath+0x11b/0x1e0 [] ? trace_hardirqs_on_caller+0x192/0x2a0 [] ? i915_getparam+0x390/0x390 [] ? mark_held_locks+0xa4/0xd0 [] ? _raw_spin_unlock_irqresto
[Intel-gfx] linux-next: manual merge of the drm-tegra tree with the drm-misc tree
Hi Thierry,
Today's linux-next merge of the drm-tegra tree got conflicts in:
drivers/gpu/drm/tegra/dsi.c
drivers/gpu/drm/tegra/hdmi.c
drivers/gpu/drm/tegra/rgb.c
drivers/gpu/drm/tegra/sor.c
between commit:
9a69a9ac20f7 ("drm: Make the connector dpms callback return a value, v2")
from the drm-misc tree and commits:
171e2e6dd912 ("drm/tegra: dsi: Restore DPMS")
29871b21c48c ("drm/tegra: hdmi: Restore DPMS")
32c3dee11e8e ("drm/tegra: rgb: Restore DPMS")
850bab448034 ("drm/tegra: sor: Restore DPMS")
from the drm-tegra tree.
I fixed it up (the latter commits removed the code updated by the former)
and can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: manual merge of the drm-misc tree with Linus' tree
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/drm_irq.c
between commit:
209e4dbc8dcd ("drm/vblank: Use u32 consistently for vblank counters")
from Linus' tree and commit:
b90180b057f7 ("drm/irq: More pipe/crtc consistency cleanups")
from the drm-misc 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/drm_irq.c
index ee14324522ce,70919d48f015..
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@@ -74,11 -74,11 +74,11 @@@ module_param_named(vblankoffdelay, drm_
module_param_named(timestamp_precision_usec, drm_timestamp_precision, int,
0600);
module_param_named(timestamp_monotonic, drm_timestamp_monotonic, int, 0600);
- static void store_vblank(struct drm_device *dev, int crtc,
+ static void store_vblank(struct drm_device *dev, unsigned int pipe,
- unsigned vblank_count_inc,
+ u32 vblank_count_inc,
struct timeval *t_vblank)
{
- struct drm_vblank_crtc *vblank = &dev->vblank[crtc];
+ struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
u32 tslot;
assert_spin_locked(&dev->vblank_time_lock);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: fix typo causing bad memory access in ring init
From: Dave Airlie
This is validating from the wrong index.
testing with KASAN found it.
Reported-by: Dave Jones
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 61ae8ff..59f85e2 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -534,7 +534,7 @@ static bool validate_cmds_sorted(struct intel_engine_cs
*ring,
for (j = 0; j < table->count; j++) {
const struct drm_i915_cmd_descriptor *desc =
- &table->table[i];
+ &table->table[j];
u32 curr = desc->cmd.value & desc->cmd.mask;
if (curr < previous) {
--
2.4.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915/kasan: out of bounds access in i915_cmd_parser_init_ring
On 14 August 2015 at 11:09, Dave Jones wrote: > I finally got around to playing with kasan. It didn't end well. > > I added some debugging to validate_cmds_sorted to print out the table > sizes right before the stack traces. oops typo, patch sent. Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [drm-intel:topic/drm-misc 71/71] drivers/gpu/drm/nouveau/nouveau_drm.c:961:31: sparse: incorrect type in initializer (incompatible argument 2 (different signedness))
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc head: b90180b057f77fe5c47a033aaa13a0f6578e5a01 commit: b90180b057f77fe5c47a033aaa13a0f6578e5a01 [71/71] drm/irq: More pipe/crtc consistency cleanups reproduce: # apt-get install sparse git checkout b90180b057f77fe5c47a033aaa13a0f6578e5a01 make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) >> drivers/gpu/drm/nouveau/nouveau_drm.c:961:31: sparse: incorrect type in >> initializer (incompatible argument 2 (different signedness)) drivers/gpu/drm/nouveau/nouveau_drm.c:961:31:expected unsigned int ( *get_vblank_counter )( ... ) drivers/gpu/drm/nouveau/nouveau_drm.c:961:31:got unsigned int ( extern [toplevel] * )( ... ) drivers/gpu/drm/nouveau/nouveau_drm.c:961:2: warning: initialization from incompatible pointer type .get_vblank_counter = drm_vblank_count, ^ drivers/gpu/drm/nouveau/nouveau_drm.c:961:2: warning: (near initialization for 'driver_stub.get_vblank_counter') vim +961 drivers/gpu/drm/nouveau/nouveau_drm.c 4cb4ea39 Daniel Vetter 2013-07-10 945 DRIVER_USE_AGP | 0e975980 Peter Antoine 2015-06-23 946 DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME | DRIVER_RENDER | 0e975980 Peter Antoine 2015-06-23 947 DRIVER_KMS_LEGACY_CONTEXT, 77145f1c Ben Skeggs 2012-07-31 948 77145f1c Ben Skeggs 2012-07-31 949 .load = nouveau_drm_load, 77145f1c Ben Skeggs 2012-07-31 950 .unload = nouveau_drm_unload, 77145f1c Ben Skeggs 2012-07-31 951 .open = nouveau_drm_open, 77145f1c Ben Skeggs 2012-07-31 952 .preclose = nouveau_drm_preclose, 77145f1c Ben Skeggs 2012-07-31 953 .postclose = nouveau_drm_postclose, 77145f1c Ben Skeggs 2012-07-31 954 .lastclose = nouveau_vga_lastclose, 77145f1c Ben Skeggs 2012-07-31 955 33b903e8 Marcin Slusarz 2013-02-08 956 #if defined(CONFIG_DEBUG_FS) 33b903e8 Marcin Slusarz 2013-02-08 957 .debugfs_init = nouveau_debugfs_init, 33b903e8 Marcin Slusarz 2013-02-08 958 .debugfs_cleanup = nouveau_debugfs_takedown, 33b903e8 Marcin Slusarz 2013-02-08 959 #endif 33b903e8 Marcin Slusarz 2013-02-08 960 77145f1c Ben Skeggs 2012-07-31 @961 .get_vblank_counter = drm_vblank_count, 51cb4b39 Ben Skeggs 2013-10-03 962 .enable_vblank = nouveau_display_vblank_enable, 51cb4b39 Ben Skeggs 2013-10-03 963 .disable_vblank = nouveau_display_vblank_disable, d83ef853 Ben Skeggs 2013-11-14 964 .get_scanout_position = nouveau_display_scanoutpos, d83ef853 Ben Skeggs 2013-11-14 965 .get_vblank_timestamp = nouveau_display_vblstamp, 77145f1c Ben Skeggs 2012-07-31 966 77145f1c Ben Skeggs 2012-07-31 967 .ioctls = nouveau_ioctls, baa70943 Rob Clark 2013-08-02 968 .num_ioctls = ARRAY_SIZE(nouveau_ioctls), 77145f1c Ben Skeggs 2012-07-31 969 .fops = &nouveau_driver_fops, :: The code at line 961 was first introduced by commit :: 77145f1cbdf8d28b46ff8070ca749bad821e0774 drm/nouveau: port remainder of drm code, and rip out compat layer :: TO: Ben Skeggs :: CC: Ben Skeggs --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation ___ 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: Adding Panel Filter function for DP
> On Mon, Aug 10, 2015 at 03:26:09PM +0800, Xiong Zhang wrote:
> > Only internal eDP, LVDS, DVI screen could set scalling mode, some
> > customers need to set scalling mode for external DP, HDMI, VGA screen.
> > Let's fulfill this.
> >
> > bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90989
> >
> > Signed-off-by: Xiong Zhang
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 63
> > -
> > 1 file changed, 44 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c index f1b9f93..2da334b 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -207,7 +207,13 @@ intel_dp_mode_valid(struct drm_connector
> *connector,
> > int target_clock = mode->clock;
> > int max_rate, mode_rate, max_lanes, max_link_clock;
> >
> > - if (is_edp(intel_dp) && fixed_mode) {
> > + if (mode->clock < 1)
> > + return MODE_CLOCK_LOW;
> > +
> > + if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> > + return MODE_H_ILLEGAL;
> > +
> > + if (!intel_panel_scale_none(&intel_connector->panel)) {
> > if (mode->hdisplay > fixed_mode->hdisplay)
> > return MODE_PANEL;
> >
> > @@ -226,12 +232,6 @@ intel_dp_mode_valid(struct drm_connector
> *connector,
> > if (mode_rate > max_rate)
> > return MODE_CLOCK_HIGH;
> >
> > - if (mode->clock < 1)
> > - return MODE_CLOCK_LOW;
> > -
> > - if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> > - return MODE_H_ILLEGAL;
> > -
> > return MODE_OK;
> > }
> >
> > @@ -1378,7 +1378,7 @@ intel_dp_compute_config(struct intel_encoder
> *encoder,
> > pipe_config->has_drrs = false;
> > pipe_config->has_audio = intel_dp->has_audio && port != PORT_A;
> >
> > - if (is_edp(intel_dp) && intel_connector->panel.fixed_mode) {
> > + if (!intel_panel_scale_none(&intel_connector->panel)) {
> > intel_fixed_panel_mode(intel_connector->panel.fixed_mode,
> >adjusted_mode);
> >
> > @@ -4592,6 +4592,23 @@ static int intel_dp_get_modes(struct
> drm_connector *connector)
> > edid = intel_connector->detect_edid;
> > if (edid) {
> > int ret = intel_connector_update_modes(connector, edid);
> > +
> > + if (ret && intel_connector->panel.fixed_mode == NULL) {
> > + /* init fixed mode as preferred mode for DP */
> > + struct drm_display_mode *fixed_mode = NULL;
> > + struct drm_display_mode *scan;
> > +
> > + list_for_each_entry(scan, &connector->probed_modes,
> > head) {
> > + if (scan->type & DRM_MODE_TYPE_PREFERRED)
> > + fixed_mode =
> > drm_mode_duplicate(connector->dev,
> > + scan);
> > + }
> > +
> > + if (fixed_mode)
> > + intel_panel_init(&intel_connector->panel,
> > +fixed_mode, NULL);
> > + }
>
> How are we supposed to get rid of a stale fixed_mode when some other
> display gets plugged in?
[Zhang, Xiong Y] Thanks so much for your good question. Yes, we should clear the
stale fitting_mode and fixed_mode when display is disconnect in
intel_dp_hpd_pulse() function.
>
> Also what would happen if the preferred mode can't be supported due to some
> source limitation?
[Zhang, Xiong Y] In this case, which mode should be selected as fixed_mode ?
As you said maybe kernel isn't the right place to do such decision.
>
> In general I'm not entirely happy with having this kind of policy in the
> kernel.
> I'd much prefer if we could get crtc size and border properties done so that
> userspace could set up the scaling any which way it chooses.
[Zhang, Xiong Y] Could you give more detail about your preference ?
thanks
___
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: Adding intel_panel_scale_none() helper function
> On Mon, Aug 10, 2015 at 06:23:19PM +, Rodrigo Vivi wrote: > > I believe this function could be added along with the next patch that > > is the first to use it... > > Or it would be good to have a good commit message explaining why this > > function is needed and what is be used for... > > Yes, please don't split up patches so much that you end up adding dead code > or dead structures - always try to have at least a minimal user for something. > > If you want to split things up really tiny then go the other way round: > First add the callers, then add the implementation. That way reviewers can > understand the big scope first and then dig into details. But this one here > really > is small enough to just be squashed in. > -Daniel > [Zhang, Xiong Y] Thanks for teaching me how to handle this. I'll follow it in the next version. thanks ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: build warnings after merge of the drm-misc tree
Hi all,
After merging the drm-misc tree, today's linux-next build (arm
multi_v7_defconfig) produced these warnings:
drivers/gpu/drm/exynos/exynos_drm_drv.c:290:2: warning: initialization from
incompatible pointer type
.get_vblank_counter = drm_vblank_count,
^
drivers/gpu/drm/exynos/exynos_drm_drv.c:290:2: warning: (near initialization
for 'exynos_drm_driver.get_vblank_counter')
drivers/gpu/drm/rcar-du/rcar_du_drv.c:262:2: warning: initialization from
incompatible pointer type
.get_vblank_counter = drm_vblank_count,
^
drivers/gpu/drm/rcar-du/rcar_du_drv.c:262:2: warning: (near initialization for
'rcar_du_driver.get_vblank_counter')
drivers/gpu/drm/msm/msm_drv.c:981:2: warning: initialization from incompatible
pointer type
.get_vblank_counter = drm_vblank_count,
^
drivers/gpu/drm/msm/msm_drv.c:981:2: warning: (near initialization for
'msm_driver.get_vblank_counter')
Introduced by commit
b90180b057f7 ("drm/irq: More pipe/crtc consistency cleanups")
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] Revert "drm/i915: Add eDP intermediate frequencies for CHV"
On Wed, 12 Aug 2015, Daniel Vetter wrote: > On Wed, Aug 12, 2015 at 04:02:17PM +0300, Ville Syrjälä wrote: >> On Wed, Aug 12, 2015 at 05:31:55PM +0530, Sivakumar Thulasimani wrote: >> > >> > >> > On 8/12/2015 5:02 PM, Ville Syrjälä wrote: >> > > On Fri, Jul 31, 2015 at 11:32:52AM +0530, Sivakumar Thulasimani wrote: >> > >> From: "Thulasimani,Sivakumar" >> > >> >> > >> This reverts >> > >> commit fe51bfb95c996733150c44d21e1c9f4b6322a326. >> > >> Author: Ville Syrjälä >> > >> Date: Thu Mar 12 17:10:38 2015 +0200 >> > >> >> > >> CHV does not support intermediate frequencies so reverting the >> > >> patch that added it in the first place >> > > My docs still say it does. Is there some undocumented problem with the >> > > PLL or is this just a marketing decision? >> > I don't think so, i too have just one document that shows the phy values >> > for each of >> > the link rates but have not found any where else to say it is supported . >> >> Display cluster HAS says they're supported. And since the spreadsheet >> has them all in green I assume someone actually figured that they ought >> to work. >> >> > Also this is not tested by anyone including us from product team so i >> > highly doubt >> > it will even work. >> >> Well if no one has tested them I guess we shouldn't try to use them. Not >> a big loss in any case I suppose. >> >> So based on that reasoning I can give an ack for this patch: >> Acked-by: Ville Syrjälä >> >> > >> > regarding HBR2, it was supposed to land on a future stepping that never >> > happened >> > so it is not supported at all. >> >> Hmm. Display Cluster HAS listed it as a stretch goal for early steppings. >> Apart >> from that there isn't much else to go by. Excepth the training pattern 3 >> support, but now that I look again the new bit for that has disappeared >> from the DP register in the spec. Or maybe I was looking at the k0 spec >> when I added it. It's still in the k0 spec but as you say that's been >> nuked. >> >> In light of this, I think dropping HBR2 is reasonable. HBR is anyway >> enough for 4k@30 with 4 lanes, so it's not like we really need HBR2. >> >> And could you also cook up a patch to kill the training pattern 3 >> support for CHV? Should be mostly a revert of my original patch that >> added it, but you probably need to adjust the use_tps3 condition a bit >> too. > > Can we please grill the people responsible for this docs mess some more? > > Patch itself is for Jani. There was some suggestions from Ville [1] to patch 1/2 that I haven't seen a reply to. BR, Jani. [1] http://mid.gmane.org/20150812131205.gw5...@intel.com > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
