[Intel-gfx] [PULL] topic/drm-misc
Hi Dave, First pull request for 4.3! Random things all over, most of it more atomic polish. Plus trying to reject more dri1 crap (the final bits afaik!), but this time around with nouveau whitelisted to avoid breaking old userspace. Aside: 4.2 vs 4.3 is a terrible conflict mess so I need you to roll drm-next forward first before I can send you a pull with a proposed solution. Cheers, Daniel The following changes since commit 8b72ce158cf0dba443e36fc66e0bb29c2580e0b6: drm: Always enable atomic API (2015-06-24 11:21:35 +1000) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2015-07-13 for you to fetch changes up to 1055e0687f581cf988bb2239a00d1396e18ef114: drm/fourcc: Add formats R8, RG88, GR88 (2015-07-09 15:12:41 +0200) Chad Versace (1): drm/fourcc: Add formats R8, RG88, GR88 Daniel Vetter (5): drm: Convert drm_legacy_ctxbitmap_init to void return type drm: Reject DRI1 hw lock ioctl functions for kms drivers drm/crtc-helper: Fixup error handling in drm_helper_crtc_mode_set drm: reset empty state in transitional helpers drm: Update plane->fb also for page_flip Jarkko Sakkinen (1): drm: remove redundant code form drm_ioc32.c Maarten Lankhorst (2): drm/atomic: Update old_fb after setting a property. drm/atomic: Cleanup on error properly in the atomic ioctl. Peter Antoine (1): drm: Turn off Legacy Context Functions Thierry Reding (1): drm: Remove useless blank line drivers/gpu/drm/drm_atomic.c | 76 +-- drivers/gpu/drm/drm_atomic_helper.c | 4 -- drivers/gpu/drm/drm_context.c | 51 ++- drivers/gpu/drm/drm_crtc.c| 9 + drivers/gpu/drm/drm_crtc_helper.c | 24 +-- drivers/gpu/drm/drm_drv.c | 7 +--- drivers/gpu/drm/drm_ioc32.c | 55 - drivers/gpu/drm/drm_legacy.h | 2 +- drivers/gpu/drm/drm_lock.c| 6 +++ drivers/gpu/drm/drm_plane_helper.c| 16 +--- drivers/gpu/drm/nouveau/nouveau_drm.c | 3 +- include/drm/drmP.h| 23 ++- include/uapi/drm/drm_fourcc.h | 7 13 files changed, 163 insertions(+), 120 deletions(-) -- 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] drm/i915/bxt: WA for swapped HPD pins in A stepping
On 7/13/2015 12:01 PM, Sivakumar Thulasimani wrote:
On 7/13/2015 9:47 AM, Sonika Jindal wrote:
As per bspec, on BXT A0/A1, sw needs to activate DDIA HPD logic
and interrupts to check the external panel connection.
And remove the redundant comment.
v2: Remove redundant IS_BROXTON check, Add comment about port C not
connected, and rephrase the commit message to include only what we
are doing here (Imre)
Signed-off-by: Sonika Jindal
---
drivers/gpu/drm/i915/i915_irq.c | 38
+-
1 file changed, 29 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c
b/drivers/gpu/drm/i915/i915_irq.c
index eb52a03..760539c 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -88,7 +88,11 @@ static const u32 hpd_status_i915[HPD_NUM_PINS] = {
[HPD_PORT_D] = PORTD_HOTPLUG_INT_STATUS
};
-/* BXT hpd list */
+/* Port C is not connected on bxt A0/A1 */
+static const u32 hpd_bxt_a0[HPD_NUM_PINS] = {
+[HPD_PORT_B] = BXT_DE_PORT_HP_DDIA
+};
+
static const u32 hpd_bxt[HPD_NUM_PINS] = {
[HPD_PORT_B] = BXT_DE_PORT_HP_DDIB,
[HPD_PORT_C] = BXT_DE_PORT_HP_DDIC
@@ -2257,6 +2261,7 @@ static void bxt_hpd_handler(struct drm_device
*dev, uint32_t iir_status)
struct drm_i915_private *dev_priv = dev->dev_private;
u32 hp_control, hp_trigger;
u32 pin_mask, long_mask;
+const u32 *hpd;
/* Get the status */
hp_trigger = iir_status & BXT_DE_PORT_HOTPLUG_MASK;
@@ -2271,7 +2276,12 @@ static void bxt_hpd_handler(struct drm_device
*dev, uint32_t iir_status)
/* Clear sticky bits in hpd status */
I915_WRITE(BXT_HOTPLUG_CTL, hp_control);
-pch_get_hpd_pins(&pin_mask, &long_mask, hp_trigger, hp_control,
hpd_bxt);
+if (INTEL_REVID(dev) < BXT_REVID_B0)
+hpd = hpd_bxt_a0;
+else
+hpd = hpd_bxt;
+
+pch_get_hpd_pins(&pin_mask, &long_mask, hp_trigger, hp_control,
hpd);
intel_hpd_irq_handler(dev, pin_mask, long_mask);
}
@@ -3315,8 +3325,15 @@ static void bxt_hpd_irq_setup(struct drm_device
*dev)
/* Now, enable HPD */
for_each_intel_encoder(dev, intel_encoder) {
if (dev_priv->hotplug.stats[intel_encoder->hpd_pin].state
-== HPD_ENABLED)
-hotplug_port |= hpd_bxt[intel_encoder->hpd_pin];
+== HPD_ENABLED) {
+const u32 *hpd;
+
+if (INTEL_REVID(dev) < BXT_REVID_B0)
+hpd = hpd_bxt_a0;
+else
+hpd = hpd_bxt;
+hotplug_port |= hpd[intel_encoder->hpd_pin];
+}
}
hpd initialization can be moved out so it is done once instead of being
repeated for each encoder.
Sure.
/* Mask all HPD control bits */
@@ -3324,11 +3341,14 @@ static void bxt_hpd_irq_setup(struct
drm_device *dev)
/* Enable requested port in hotplug control */
/* TODO: implement (short) HPD support on port A */
-WARN_ON_ONCE(hotplug_port & BXT_DE_PORT_HP_DDIA);
-if (hotplug_port & BXT_DE_PORT_HP_DDIB)
-hotplug_ctrl |= BXT_DDIB_HPD_ENABLE;
-if (hotplug_port & BXT_DE_PORT_HP_DDIC)
-hotplug_ctrl |= BXT_DDIC_HPD_ENABLE;
+if (INTEL_REVID(dev) < BXT_REVID_B0 && (hotplug_port &
BXT_DE_PORT_HP_DDIA))
+hotplug_ctrl |= BXT_DDIA_HPD_ENABLE;
can you add a comment here stating the swap in hpd pins ?
as i am not sure not everyone will first check the commit message for
the change here.
Ok, I'l add
+else {
+if (hotplug_port & BXT_DE_PORT_HP_DDIB)
+hotplug_ctrl |= BXT_DDIB_HPD_ENABLE;
+if (hotplug_port & BXT_DE_PORT_HP_DDIC)
+hotplug_ctrl |= BXT_DDIC_HPD_ENABLE;
+}
I915_WRITE(BXT_HOTPLUG_CTL, hotplug_ctrl);
/* Unmask DDI hotplug in IMR */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [drm-intel:topic/drm-misc 18/36] drivers/gpu/drm/cirrus/cirrus_fbdev.c:247:1: warning: label 'out_iounmap' defined but not used
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
head: 6198447760ed3c684fbcc93b5f91b4e84861e8f3
commit: fd6ab591ce1544e923c4ba0467dfb7869753830b [18/36] drm/cirrus: Use new
drm_fb_helper functions
config: x86_64-randconfig-i0-201528 (attached as .config)
reproduce:
git checkout fd6ab591ce1544e923c4ba0467dfb7869753830b
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
drivers/gpu/drm/cirrus/cirrus_fbdev.c: In function 'cirrusfb_create':
>> drivers/gpu/drm/cirrus/cirrus_fbdev.c:247:1: warning: label 'out_iounmap'
>> defined but not used [-Wunused-label]
out_iounmap:
^
vim +/out_iounmap +247 drivers/gpu/drm/cirrus/cirrus_fbdev.c
99d4a8ae Martin Koegler 2014-01-09 231 info->fix.smem_start =
cdev->dev->mode_config.fb_base;
99d4a8ae Martin Koegler 2014-01-09 232 info->fix.smem_len =
cdev->mc.vram_size;
99d4a8ae Martin Koegler 2014-01-09 233
f9aa76a8 Dave Airlie2012-04-17 234 info->screen_base = sysram;
f9aa76a8 Dave Airlie2012-04-17 235 info->screen_size = size;
f9aa76a8 Dave Airlie2012-04-17 236
f9aa76a8 Dave Airlie2012-04-17 237 info->fix.mmio_start = 0;
f9aa76a8 Dave Airlie2012-04-17 238 info->fix.mmio_len = 0;
f9aa76a8 Dave Airlie2012-04-17 239
f9aa76a8 Dave Airlie2012-04-17 240 DRM_INFO("fb mappable at
0x%lX\n", info->fix.smem_start);
f9aa76a8 Dave Airlie2012-04-17 241 DRM_INFO("vram aper at
0x%lX\n", (unsigned long)info->fix.smem_start);
f9aa76a8 Dave Airlie2012-04-17 242 DRM_INFO("size %lu\n",
(unsigned long)info->fix.smem_len);
f9aa76a8 Dave Airlie2012-04-17 243 DRM_INFO("fb depth is %d\n",
fb->depth);
f9aa76a8 Dave Airlie2012-04-17 244 DRM_INFO(" pitch is %d\n",
fb->pitches[0]);
f9aa76a8 Dave Airlie2012-04-17 245
f9aa76a8 Dave Airlie2012-04-17 246 return 0;
f9aa76a8 Dave Airlie2012-04-17 @247 out_iounmap:
f9aa76a8 Dave Airlie2012-04-17 248 return ret;
f9aa76a8 Dave Airlie2012-04-17 249 }
f9aa76a8 Dave Airlie2012-04-17 250
f9aa76a8 Dave Airlie2012-04-17 251 static int cirrus_fbdev_destroy(struct
drm_device *dev,
f9aa76a8 Dave Airlie2012-04-17 252 struct
cirrus_fbdev *gfbdev)
f9aa76a8 Dave Airlie2012-04-17 253 {
f9aa76a8 Dave Airlie2012-04-17 254 struct cirrus_framebuffer *gfb
= &gfbdev->gfb;
f9aa76a8 Dave Airlie2012-04-17 255
:: The code at line 247 was first introduced by commit
:: f9aa76a85248565ff13dc0e10633c4343a059f71 drm/kms: driver for virtual
cirrus under qemu
:: TO: Dave Airlie
:: 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/x86_64 4.1.0-rc6 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10
-fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
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_BZIP2=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_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG
Re: [Intel-gfx] [PATCH] 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: 6777 -Summary- Platform Delta drm-intel-nightly Series Applied ILK 303/303 303/303 SNB +3 309/316 312/316 IVB 343/343 343/343 BYT -1 285/285 284/285 HSW +13 367/381 380/381 -Detailed- Platform Testdrm-intel-nightly Series Applied *SNB igt@kms_mmio_vs_cs_flip@setcrtc_vs_cs_flip DMESG_WARN(1) PASS(1) *SNB igt@kms_mmio_vs_cs_flip@setplane_vs_cs_flip DMESG_WARN(1) PASS(1) *SNB igt@pm_rpm@cursor DMESG_WARN(1) PASS(1) *SNB igt@pm_rpm@cursor-dpms DMESG_FAIL(1) FAIL(1) *BYT igt@gem_tiled_partial_pwrite_pread@reads PASS(1) FAIL(1) *HSW igt@kms_mmio_vs_cs_flip@setplane_vs_cs_flip DMESG_WARN(1) PASS(1) *HSW igt@pm_lpsp@non-edp DMESG_WARN(1) PASS(1) *HSW igt@pm_rpm@debugfs-read DMESG_WARN(1) PASS(1) *HSW igt@pm_rpm@gem-idle DMESG_WARN(1) PASS(1) *HSW igt@pm_rpm@gem-mmap-gtt DMESG_WARN(1) PASS(1) *HSW igt@pm_rpm@gem-pread DMESG_WARN(1) PASS(1) *HSW igt@pm_rpm@i2c DMESG_WARN(1) PASS(1) *HSW igt@pm_rpm@modeset-non-lpsp DMESG_WARN(1) PASS(1) *HSW igt@pm_rpm@modeset-non-lpsp-stress-no-wait DMESG_WARN(1) PASS(1) *HSW igt@pm_rpm@pci-d3-state DMESG_WARN(1) PASS(1) *HSW igt@pm_rpm@reg-read-ioctl DMESG_WARN(1) PASS(1) *HSW igt@pm_rpm@rte DMESG_WARN(1) PASS(1) *HSW igt@pm_rpm@sysfs-read DMESG_WARN(1) PASS(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] [drm-intel:topic/drm-misc 21/36] drivers/gpu/drm/ast/ast_fb.c:196:17: warning: unused variable 'device'
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
head: 6198447760ed3c684fbcc93b5f91b4e84861e8f3
commit: 6f4900cd28c95db2c6975274672a5f1d06ab9a67 [21/36] drm/ast: Use new
drm_fb_helper functions
config: x86_64-randconfig-i0-201528 (attached as .config)
reproduce:
git checkout 6f4900cd28c95db2c6975274672a5f1d06ab9a67
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
drivers/gpu/drm/ast/ast_fb.c: In function 'astfb_create':
>> drivers/gpu/drm/ast/ast_fb.c:196:17: warning: unused variable 'device'
>> [-Wunused-variable]
struct device *device = &dev->pdev->dev;
^
vim +/device +196 drivers/gpu/drm/ast/ast_fb.c
312fec14 Dave Airlie 2012-02-29 180 return ret;
312fec14 Dave Airlie 2012-02-29 181
312fec14 Dave Airlie 2012-02-29 182 *gobj_p = gobj;
312fec14 Dave Airlie 2012-02-29 183 return ret;
312fec14 Dave Airlie 2012-02-29 184 }
312fec14 Dave Airlie 2012-02-29 185
cd5428a5 Daniel Vetter2013-01-21 186 static int astfb_create(struct
drm_fb_helper *helper,
312fec14 Dave Airlie 2012-02-29 187 struct
drm_fb_helper_surface_size *sizes)
312fec14 Dave Airlie 2012-02-29 188 {
0d634f6e Fabian Frederick 2014-09-14 189 struct ast_fbdev *afbdev =
0d634f6e Fabian Frederick 2014-09-14 190 container_of(helper,
struct ast_fbdev, helper);
312fec14 Dave Airlie 2012-02-29 191 struct drm_device *dev =
afbdev->helper.dev;
312fec14 Dave Airlie 2012-02-29 192 struct drm_mode_fb_cmd2
mode_cmd;
312fec14 Dave Airlie 2012-02-29 193 struct drm_framebuffer *fb;
312fec14 Dave Airlie 2012-02-29 194 struct fb_info *info;
312fec14 Dave Airlie 2012-02-29 195 int size, ret;
312fec14 Dave Airlie 2012-02-29 @196 struct device *device =
&dev->pdev->dev;
312fec14 Dave Airlie 2012-02-29 197 void *sysram;
312fec14 Dave Airlie 2012-02-29 198 struct drm_gem_object *gobj =
NULL;
312fec14 Dave Airlie 2012-02-29 199 struct ast_bo *bo = NULL;
312fec14 Dave Airlie 2012-02-29 200 mode_cmd.width =
sizes->surface_width;
312fec14 Dave Airlie 2012-02-29 201 mode_cmd.height =
sizes->surface_height;
312fec14 Dave Airlie 2012-02-29 202 mode_cmd.pitches[0] =
mode_cmd.width * ((sizes->surface_bpp + 7)/8);
312fec14 Dave Airlie 2012-02-29 203
312fec14 Dave Airlie 2012-02-29 204 mode_cmd.pixel_format =
drm_mode_legacy_fb_format(sizes->surface_bpp,
:: The code at line 196 was first introduced by commit
:: 312fec1405dd546ddb3fa6387d54e78f604dd8f8 drm: Initial KMS driver for AST
(ASpeed Technologies) 2000 series (v2)
:: TO: Dave Airlie
:: 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/x86_64 4.1.0-rc6 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10
-fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
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_BZIP2=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_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SYSVIPC is not set
#
Re: [Intel-gfx] [PATCH v2 00/10] Color Manager Implementation
On 06/15/2015 08:53 AM, Daniel Vetter wrote: > On Tue, Jun 09, 2015 at 01:50:48PM +0100, Damien Lespiau wrote: >> On Thu, Jun 04, 2015 at 07:12:31PM +0530, Kausal Malladi wrote: >>> From: Kausal Malladi >>> >>> This patch set adds color manager implementation in drm/i915 layer. >>> Color Manager is an extension in i915 driver to support color >>> correction/enhancement. Various Intel platforms support several >>> color correction capabilities. Color Manager provides abstraction >>> of these properties and allows a user space UI agent to >>> correct/enhance the display. >> >> So I did a first rough pass on the API itself. The big question that >> isn't solved at the moment is: do we want to try to do generic KMS >> properties for pre-LUT + matrix + post-LUT or not. "Generic" has 3 levels: >> >> 1/ Generic for all KMS drivers >> 2/ Generic for i915 supported platfoms >> 3/ Specific to each platform >> >> At this point, I'm quite tempted to say we should give 1/ a shot. We >> should be able to have pre-LUT + matrix + post-LUT on CRTC objects and >> guarantee that, when the drivers expose such properties, user space can >> at least give 8 bits LUT + 3x3 matrix + 8 bits LUT. >> >> It may be possible to use the "try" version of the atomic ioctl to >> explore the space of possibilities from a generic user space to use >> bigger LUTs as well. A HAL layer (which is already there in some but not >> all OSes) would still be able to use those generic properties to load >> "precision optimized" LUTs with some knowledge of the hardware. > > Yeah, imo 1/ should be doable. For the matrix we should be able to be > fully generic with a 16.16 format. For gamma one option would be to have I know I am late replying, apologies for that. I've been working on CSC support for V4L2 as well (still work in progress) and I would like to at least end up with the same low-level fixed point format as DRM so we can share matrix/vector calculations. Based on my experiences I have concerns about the 16.16 format: the precision is quite low which can be a problem when such values are used in matrix multiplications. In addition, while the precision may be sufficient for 8 bit color component values, I'm pretty sure it will be insufficient when dealing with 12 or 16 bit color components. In earlier versions of my CSC code I used a 12.20 format, but in the latest I switched to 32.32. This fits nicely in a u64 and it's easy to extract the integer and fractional parts. If this is going to be a generic and future proof API, then my suggestion would be to increase the precision of the underlying data type. Regards, Hans > an enum property listing all the supported gamma table formats, of which > 8bit 256 entry (the current standard) would be a one. This enum space > would need to be drm-wide ofc. Then the gamma blob would just contain the > table. This way we can allow funky stuff like the 1025th entry for 1.0+ > values some intel tables have, and similar things. > > Wrt pre-post and plan/crtc I guess we'd just add the properties to all the > objects where they're possible on a given platform and then the driver > must check if there's constraints (e.g. post-lut gamma only on 1 plane or > the crtc or similar stuff). > > Also there's the legacy gamma ioctl. That should forward to the crtc gamma > (and there probably pick post lut and pre-lut only if there's no post > lut). For names I'd suggest > > "pre-gamma-type", "pre-gamma-data", "post-gamma-type" and > "post-gamma-data" but I don't care terrible much about them. > -Daniel > >> >> Option 3/ is, IMHO, a no-go, we should really try hard to limit the work >> we need to do per-platform, which means defining a common format for the >> values we give to the kernel. As stated in various places, 16.16 seems >> the format of choice, even for the LUTs as we have wide gamut support in >> some of the LUTs where we can map values > 1.0 to other values > 1.0. >> >> Another thing, the documentation of the interface needs to be a bit more >> crisp. For instance, we don't currently define the order in which the >> CSC and LUT transforms of this patch set are applied: is this a de-gamma >> LUT to do the CSC in linear space? but then that means the display is >> linear, oops. So it must be a post-CSC lut, but then we don't de-gamma >> sRGB (not technically a single gamma power curve for sRGB, but details, >> details) before applying a linear transform. So with this interface, we >> have to enforce the fbs are linear, losing dynamic range. I'm sure later >> patches would expose more properties, but as a stand-alone patch set, it >> would seem we can't do anything useful? >> >> -- >> Damien >> ___ >> 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.freedesk
Re: [Intel-gfx] [PATCH 4/6] drm/i915/skl: Updated the i915_ring_freq_table debugfs function
On Mon, Jun 29, 2015 at 02:50:22PM +0530, akash.g...@intel.com wrote:
> From: Akash Goel
>
> Updated the i915_ring_freq_table debugfs function to support the read
> of ring frequency table, through Punit interface, for SKL also.
>
> Issue: VIZ-5144
> Signed-off-by: Akash Goel
> Reviewed-by: Rodrigo Vivi
Merged patches 1, 3&4 from this series, thanks.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 19 +++
> 1 file changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index e40e479..f8df5f2 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1760,6 +1760,7 @@ static int i915_ring_freq_table(struct seq_file *m,
> void *unused)
> struct drm_i915_private *dev_priv = dev->dev_private;
> int ret = 0;
> int gpu_freq, ia_freq;
> + unsigned int max_gpu_freq, min_gpu_freq;
>
> if (!(IS_GEN6(dev) || IS_GEN7(dev))) {
> seq_puts(m, "unsupported on this chipset\n");
> @@ -1774,17 +1775,27 @@ static int i915_ring_freq_table(struct seq_file *m,
> void *unused)
> if (ret)
> goto out;
>
> + if (IS_SKYLAKE(dev)) {
> + /* Convert GT frequency to 50 HZ units */
> + min_gpu_freq =
> + dev_priv->rps.min_freq_softlimit / GEN9_FREQ_SCALER;
> + max_gpu_freq =
> + dev_priv->rps.max_freq_softlimit / GEN9_FREQ_SCALER;
> + } else {
> + min_gpu_freq = dev_priv->rps.min_freq_softlimit;
> + max_gpu_freq = dev_priv->rps.max_freq_softlimit;
> + }
> +
> seq_puts(m, "GPU freq (MHz)\tEffective CPU freq (MHz)\tEffective Ring
> freq (MHz)\n");
>
> - for (gpu_freq = dev_priv->rps.min_freq_softlimit;
> - gpu_freq <= dev_priv->rps.max_freq_softlimit;
> - gpu_freq++) {
> + for (gpu_freq = min_gpu_freq; gpu_freq <= max_gpu_freq; gpu_freq++) {
> ia_freq = gpu_freq;
> sandybridge_pcode_read(dev_priv,
> GEN6_PCODE_READ_MIN_FREQ_TABLE,
> &ia_freq);
> seq_printf(m, "%d\t\t%d\t\t\t\t%d\n",
> -intel_gpu_freq(dev_priv, gpu_freq),
> +intel_gpu_freq(dev_priv, (gpu_freq *
> + (IS_SKYLAKE(dev) ? GEN9_FREQ_SCALER : 1))),
> ((ia_freq >> 0) & 0xff) * 100,
> ((ia_freq >> 8) & 0xff) * 100);
> }
> --
> 1.9.2
>
> ___
> 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
[Intel-gfx] [drm-intel:topic/drm-misc 26/36] drivers/gpu/drm//gma500/framebuffer.c:346:17: warning: unused variable 'device'
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
head: 6198447760ed3c684fbcc93b5f91b4e84861e8f3
commit: 3b9a13e85365c441dc7335d81afc0a3a344766e6 [26/36] drm/gma500: Use new
drm_fb_helper functions
config: x86_64-randconfig-i0-201528 (attached as .config)
reproduce:
git checkout 3b9a13e85365c441dc7335d81afc0a3a344766e6
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
drivers/gpu/drm//gma500/framebuffer.c: In function 'psbfb_create':
>> drivers/gpu/drm//gma500/framebuffer.c:346:17: warning: unused variable
>> 'device' [-Wunused-variable]
struct device *device = &dev->pdev->dev;
^
vim +/device +346 drivers/gpu/drm//gma500/framebuffer.c
4d8d096e Alan Cox2011-11-03 330 /**
4d8d096e Alan Cox2011-11-03 331 *psbfb_create-
create a framebuffer
4d8d096e Alan Cox2011-11-03 332 *@fbdev: the framebuffer device
4d8d096e Alan Cox2011-11-03 333 *@sizes: specification of the
layout
4d8d096e Alan Cox2011-11-03 334 *
4d8d096e Alan Cox2011-11-03 335 *Create a framebuffer to the
specifications provided
4d8d096e Alan Cox2011-11-03 336 */
4d8d096e Alan Cox2011-11-03 337 static int psbfb_create(struct psb_fbdev
*fbdev,
4d8d096e Alan Cox2011-11-03 338struct
drm_fb_helper_surface_size *sizes)
4d8d096e Alan Cox2011-11-03 339 {
4d8d096e Alan Cox2011-11-03 340struct drm_device *dev =
fbdev->psb_fb_helper.dev;
4d8d096e Alan Cox2011-11-03 341struct drm_psb_private *dev_priv =
dev->dev_private;
4d8d096e Alan Cox2011-11-03 342struct fb_info *info;
4d8d096e Alan Cox2011-11-03 343struct drm_framebuffer *fb;
4d8d096e Alan Cox2011-11-03 344struct psb_framebuffer *psbfb =
&fbdev->pfb;
a9a644ac Dave Airlie 2011-11-28 345struct drm_mode_fb_cmd2 mode_cmd;
4d8d096e Alan Cox2011-11-03 @346struct device *device = &dev->pdev->dev;
4d8d096e Alan Cox2011-11-03 347int size;
4d8d096e Alan Cox2011-11-03 348int ret;
4d8d096e Alan Cox2011-11-03 349struct gtt_range *backing;
a9a644ac Dave Airlie 2011-11-28 350u32 bpp, depth;
1b223c9e Alan Cox2011-11-29 351int gtt_roll = 0;
1b223c9e Alan Cox2011-11-29 352int pitch_lines = 0;
4d8d096e Alan Cox2011-11-03 353
4d8d096e Alan Cox2011-11-03 354mode_cmd.width = sizes->surface_width;
:: The code at line 346 was first introduced by commit
:: 4d8d096e9ae86621cc38b5417f4353305c5fd3a9 gma500: introduce the
framebuffer support code
:: TO: Alan Cox
:: 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/x86_64 4.1.0-rc6 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10
-fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
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_BZIP2=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_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CO
Re: [Intel-gfx] [PATCH 5/9] drm/i915: Clear out DPLL state from pipe config in DSI get config
On Fri, Jul 10, 2015 at 05:37:07PM +0530, Sivakumar Thulasimani wrote:
>
>
> On 7/1/2015 6:12 PM, Daniel Vetter wrote:
> >On Tue, Jun 30, 2015 at 02:50:33PM +0300, Ville Syrjälä wrote:
> >>On Tue, Jun 30, 2015 at 12:13:37PM +0200, Daniel Vetter wrote:
> >>>On Mon, Jun 29, 2015 at 08:08:27PM +0300, Ville Syrjälä wrote:
> On Mon, Jun 29, 2015 at 07:56:05PM +0300, Ville Syrjälä wrote:
> >On Mon, Jun 29, 2015 at 06:42:11PM +0200, Daniel Vetter wrote:
> >>On Mon, Jun 29, 2015 at 03:25:52PM +0300, ville.syrj...@linux.intel.com
> >>wrote:
> >>>From: Ville Syrjälä
> >>>
> >>>VLV/CHV don't use the DPLL with DSI, so just clear out the DPLL state
> >>>from the pipe_config in intel_dsi_get_config(). This avoids spurious
> >>>state checker warnings. We already did it this way for DPLL_MD, but do
> >>>it for DPLL too.
> >>>
> >>>Toss in a WARN to intel_dsi_pre_enable() to make sure the ref clocks
> >>>are enabled however. Supposedly they have some meaning to DSI too.
> >>>We now keep the ref clocks always enabled while the disp2d well is
> >>>enabled.
> >>>
> >>>Signed-off-by: Ville Syrjälä
> >>>---
> >>> drivers/gpu/drm/i915/intel_dsi.c | 15 +--
> >>> 1 file changed, 5 insertions(+), 10 deletions(-)
> >>>
> >>>diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> >>>b/drivers/gpu/drm/i915/intel_dsi.c
> >>>index 36e2148..92bb252 100644
> >>>--- a/drivers/gpu/drm/i915/intel_dsi.c
> >>>+++ b/drivers/gpu/drm/i915/intel_dsi.c
> >>>@@ -421,18 +421,12 @@ static void intel_dsi_pre_enable(struct
> >>>intel_encoder *encoder)
> >>> /* Disable DPOunit clock gating, can stall pipe
> >>>* and we need DPLL REFA always enabled */
> >>>- tmp = I915_READ(DPLL(pipe));
> >>>- tmp |= DPLL_REF_CLK_ENABLE_VLV;
> >>>- I915_WRITE(DPLL(pipe), tmp);
> >>>-
> >>>- /* update the hw state for DPLL */
> >>>- intel_crtc->config->dpll_hw_state.dpll =
> >>>DPLL_INTEGRATED_REF_CLK_VLV |
> >>>- DPLL_REF_CLK_ENABLE_VLV | DPLL_VGA_MODE_DIS;
> >>>-
> >>> tmp = I915_READ(DSPCLK_GATE_D);
> >>> tmp |= DPOUNIT_CLOCK_GATE_DISABLE;
> >>> I915_WRITE(DSPCLK_GATE_D, tmp);
> >>>+ WARN_ON((I915_READ(DPLL(pipe)) & DPLL_REF_CLK_ENABLE_VLV) == 0);
> >>>+
> >>> /* put device in ready state */
> >>> intel_dsi_device_ready(encoder);
> >>>@@ -635,9 +629,10 @@ static void intel_dsi_get_config(struct
> >>>intel_encoder *encoder,
> >>> DRM_DEBUG_KMS("\n");
> >>> /*
> >>>- * DPLL_MD is not used in case of DSI, reading will get some
> >>>default value
> >>>- * set dpll_md = 0
> >>>+ * DPLL is not used in case of DSI, reading will getsome
> >>>default value.
> >>>+ * Clear the state to keep the state checker happy.
> >>>*/
> >>>+ pipe_config->dpll_hw_state.dpll = 0;
> >>> pipe_config->dpll_hw_state.dpll_md = 0;
> >>State configs are supposed to be kzallocated. Needing this indicates a
> >>pretty serious bug - I'd vote to instead also ditch the dpll_md line and
> >>fix the offender.
> >There is no offender really. We read out the DPLL state before we know
> >which ports are active and hence can't tell at that point if the
> >information is really relevant.
> >>>So the bios leaves the DPLL enabled even when using a DSI port? Or do we
> >>>miss to check some routing bits in get_clock?
> >>Not necessarily enabled, but there are other bits in there that could be
> >>left in any state basically. The DSI port simply doesn't care.
> >If the enable bit is what's gating things here then we should just forgo
> >reading out any dpll register state if that's not set. Looking at the
> >vlv/chv state readout code that seems to be the trouble - there's nothing
> >guarding the register reads into the pipe_config at all. Didn't matter
> >pre-vlv without dsi since enable pipe should imply enabled dpll, but
> >obviously won't work correctly with dsi. Can you please spin such a patch
> >and remove the hacks here from dsi_get_config?
> >-Daniel
> Not sure i understand the point of contention here, just noticed this after
> i gave my RB :)
> so my justification on why this is proper is that DSI is not supposed to
> touch DPLL register
> any place we access dpll_hw_state.dpll is under !is_dsi check so that
> ensures that we dont
> program DPLL register for dsi panel. it was wrong to have originally modfied
> DPLL register
> inside intel_dsi_pre_enable so removal is fine. setting it to zero in
> intel_dsi_get_config
> is of no impact since any place we write back the contents of dpll_hw_state
> is past the
> !is_dsi check is never consumed by anyone as long as the CRTC uses DSI.
Ok, let's try a patch. Does the below work y/n? I've merged the patches up
to this one to dinq meanwhile, but I'd
[Intel-gfx] [PATCH] drm/i915/bxt: WA for swapped HPD pins in A stepping
As per bspec, on BXT A0/A1, sw needs to activate DDIA HPD logic
and interrupts to check the external panel connection.
And remove the redundant comment.
v2: Remove redundant IS_BROXTON check, Add comment about port C not
connected, and rephrase the commit message to include only what we
are doing here (Imre)
v3: Add comment about the WA, move 'hpd' initialization outside for
loop (Siva)
Also, remove few redundant comments from hpd handler (me)
Signed-off-by: Sonika Jindal
---
drivers/gpu/drm/i915/i915_irq.c | 46 ++-
1 file changed, 31 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a897f68..13cabca 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -88,7 +88,14 @@ static const u32 hpd_status_i915[HPD_NUM_PINS] = {
[HPD_PORT_D] = PORTD_HOTPLUG_INT_STATUS
};
-/* BXT hpd list */
+/*
+ * On BXT A0/A1, sw needs to activate DDIA HPD logic and interrupts to check
+ * the external panel connection. Port C is not connected on bxt A0/A1
+ */
+static const u32 hpd_bxt_a0[HPD_NUM_PINS] = {
+ [HPD_PORT_B] = BXT_DE_PORT_HP_DDIA
+};
+
static const u32 hpd_bxt[HPD_NUM_PINS] = {
[HPD_PORT_B] = BXT_DE_PORT_HP_DDIB,
[HPD_PORT_C] = BXT_DE_PORT_HP_DDIC
@@ -1967,6 +1974,7 @@ static void bxt_hpd_handler(struct drm_device *dev,
uint32_t iir_status)
struct drm_i915_private *dev_priv = dev->dev_private;
u32 hp_control, hp_trigger;
u32 pin_mask, long_mask;
+ const u32 *hpd;
/* Get the status */
hp_trigger = iir_status & BXT_DE_PORT_HOTPLUG_MASK;
@@ -1981,7 +1989,12 @@ static void bxt_hpd_handler(struct drm_device *dev,
uint32_t iir_status)
/* Clear sticky bits in hpd status */
I915_WRITE(BXT_HOTPLUG_CTL, hp_control);
- pch_get_hpd_pins(&pin_mask, &long_mask, hp_trigger, hp_control,
hpd_bxt);
+ if (INTEL_REVID(dev) < BXT_REVID_B0)
+ hpd = hpd_bxt_a0;
+ else
+ hpd = hpd_bxt;
+
+ pch_get_hpd_pins(&pin_mask, &long_mask, hp_trigger, hp_control, hpd);
intel_hpd_irq_handler(dev, pin_mask, long_mask);
}
@@ -3021,31 +3034,34 @@ static void bxt_hpd_irq_setup(struct drm_device *dev)
struct intel_encoder *intel_encoder;
u32 hotplug_port = 0;
u32 hotplug_ctrl;
+ const u32 *hpd;
- /* Now, enable HPD */
- for_each_intel_encoder(dev, intel_encoder) {
+ if (INTEL_REVID(dev) < BXT_REVID_B0)
+ hpd = hpd_bxt_a0;
+ else
+ hpd = hpd_bxt;
+
+ for_each_intel_encoder(dev, intel_encoder)
if (dev_priv->hotplug.stats[intel_encoder->hpd_pin].state
== HPD_ENABLED)
- hotplug_port |= hpd_bxt[intel_encoder->hpd_pin];
- }
+ hotplug_port |= hpd[intel_encoder->hpd_pin];
- /* Mask all HPD control bits */
hotplug_ctrl = I915_READ(BXT_HOTPLUG_CTL) & ~BXT_HOTPLUG_CTL_MASK;
- /* Enable requested port in hotplug control */
/* TODO: implement (short) HPD support on port A */
- WARN_ON_ONCE(hotplug_port & BXT_DE_PORT_HP_DDIA);
- if (hotplug_port & BXT_DE_PORT_HP_DDIB)
- hotplug_ctrl |= BXT_DDIB_HPD_ENABLE;
- if (hotplug_port & BXT_DE_PORT_HP_DDIC)
- hotplug_ctrl |= BXT_DDIC_HPD_ENABLE;
+ if (INTEL_REVID(dev) < BXT_REVID_B0 && (hotplug_port &
BXT_DE_PORT_HP_DDIA))
+ hotplug_ctrl |= BXT_DDIA_HPD_ENABLE;
+ else {
+ if (hotplug_port & BXT_DE_PORT_HP_DDIB)
+ hotplug_ctrl |= BXT_DDIB_HPD_ENABLE;
+ if (hotplug_port & BXT_DE_PORT_HP_DDIC)
+ hotplug_ctrl |= BXT_DDIC_HPD_ENABLE;
+ }
I915_WRITE(BXT_HOTPLUG_CTL, hotplug_ctrl);
- /* Unmask DDI hotplug in IMR */
hotplug_ctrl = I915_READ(GEN8_DE_PORT_IMR) & ~hotplug_port;
I915_WRITE(GEN8_DE_PORT_IMR, hotplug_ctrl);
- /* Enable DDI hotplug in IER */
hotplug_ctrl = I915_READ(GEN8_DE_PORT_IER) | hotplug_port;
I915_WRITE(GEN8_DE_PORT_IER, hotplug_ctrl);
POSTING_READ(GEN8_DE_PORT_IER);
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [drm-intel:topic/drm-misc 27/36] drivers/gpu/drm/mgag200/mgag200_fb.c:232:1: warning: label 'out' defined but not used
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
head: 6198447760ed3c684fbcc93b5f91b4e84861e8f3
commit: 53ebb642ccba1212b7b97a5dccb358eb791b85f6 [27/36] drm/mgag200: Use new
drm_fb_helper functions
config: x86_64-randconfig-i0-201528 (attached as .config)
reproduce:
git checkout 53ebb642ccba1212b7b97a5dccb358eb791b85f6
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
drivers/gpu/drm/mgag200/mgag200_fb.c: In function 'mgag200fb_create':
>> drivers/gpu/drm/mgag200/mgag200_fb.c:232:1: warning: label 'out' defined but
>> not used [-Wunused-label]
out:
^
>> drivers/gpu/drm/mgag200/mgag200_fb.c:169:17: warning: unused variable
>> 'device' [-Wunused-variable]
struct device *device = &dev->pdev->dev;
^
vim +/out +232 drivers/gpu/drm/mgag200/mgag200_fb.c
414c45310 Dave Airlie 2012-04-17 163 struct drm_device *dev =
mfbdev->helper.dev;
414c45310 Dave Airlie 2012-04-17 164 struct drm_mode_fb_cmd2
mode_cmd;
414c45310 Dave Airlie 2012-04-17 165 struct mga_device *mdev =
dev->dev_private;
414c45310 Dave Airlie 2012-04-17 166 struct fb_info *info;
414c45310 Dave Airlie 2012-04-17 167 struct drm_framebuffer *fb;
414c45310 Dave Airlie 2012-04-17 168 struct drm_gem_object *gobj =
NULL;
414c45310 Dave Airlie 2012-04-17 @169 struct device *device =
&dev->pdev->dev;
414c45310 Dave Airlie 2012-04-17 170 struct mgag200_bo *bo;
414c45310 Dave Airlie 2012-04-17 171 int ret;
414c45310 Dave Airlie 2012-04-17 172 void *sysram;
414c45310 Dave Airlie 2012-04-17 173 int size;
414c45310 Dave Airlie 2012-04-17 174
414c45310 Dave Airlie 2012-04-17 175 mode_cmd.width =
sizes->surface_width;
414c45310 Dave Airlie 2012-04-17 176 mode_cmd.height =
sizes->surface_height;
414c45310 Dave Airlie 2012-04-17 177 mode_cmd.pitches[0] =
mode_cmd.width * ((sizes->surface_bpp + 7) / 8);
414c45310 Dave Airlie 2012-04-17 178
414c45310 Dave Airlie 2012-04-17 179 mode_cmd.pixel_format =
drm_mode_legacy_fb_format(sizes->surface_bpp,
414c45310 Dave Airlie 2012-04-17 180
sizes->surface_depth);
414c45310 Dave Airlie 2012-04-17 181 size = mode_cmd.pitches[0] *
mode_cmd.height;
414c45310 Dave Airlie 2012-04-17 182
414c45310 Dave Airlie 2012-04-17 183 ret =
mgag200fb_create_object(mfbdev, &mode_cmd, &gobj);
414c45310 Dave Airlie 2012-04-17 184 if (ret) {
414c45310 Dave Airlie 2012-04-17 185 DRM_ERROR("failed to
create fbcon backing object %d\n", ret);
414c45310 Dave Airlie 2012-04-17 186 return ret;
414c45310 Dave Airlie 2012-04-17 187 }
414c45310 Dave Airlie 2012-04-17 188 bo = gem_to_mga_bo(gobj);
414c45310 Dave Airlie 2012-04-17 189
414c45310 Dave Airlie 2012-04-17 190 sysram = vmalloc(size);
414c45310 Dave Airlie 2012-04-17 191 if (!sysram)
414c45310 Dave Airlie 2012-04-17 192 return -ENOMEM;
414c45310 Dave Airlie 2012-04-17 193
53ebb642c Archit Taneja 2015-07-13 194 info =
drm_fb_helper_alloc_fbi(helper);
53ebb642c Archit Taneja 2015-07-13 195 if (IS_ERR(info))
53ebb642c Archit Taneja 2015-07-13 196 return PTR_ERR(info);
414c45310 Dave Airlie 2012-04-17 197
414c45310 Dave Airlie 2012-04-17 198 info->par = mfbdev;
414c45310 Dave Airlie 2012-04-17 199
414c45310 Dave Airlie 2012-04-17 200 ret =
mgag200_framebuffer_init(dev, &mfbdev->mfb, &mode_cmd, gobj);
414c45310 Dave Airlie 2012-04-17 201 if (ret)
414c45310 Dave Airlie 2012-04-17 202 return ret;
414c45310 Dave Airlie 2012-04-17 203
414c45310 Dave Airlie 2012-04-17 204 mfbdev->sysram = sysram;
414c45310 Dave Airlie 2012-04-17 205 mfbdev->size = size;
414c45310 Dave Airlie 2012-04-17 206
414c45310 Dave Airlie 2012-04-17 207 fb = &mfbdev->mfb.base;
414c45310 Dave Airlie 2012-04-17 208
414c45310 Dave Airlie 2012-04-17 209 /* setup helper */
414c45310 Dave Airlie 2012-04-17 210 mfbdev->helper.fb = fb;
414c45310 Dave Airlie 2012-04-17 211
414c45310 Dave Airlie 2012-04-17 212 strcpy(info->fix.id,
"mgadrmfb");
414c45310 Dave Airlie 2012-04-17 213
414c45310 Dave Airlie 2012-04-17 214 info->flags = FBINFO_DEFAULT |
FBINFO_CAN_FORCE_OUTPUT;
414c45310 Dave Airlie 2012-04-17 215 info->fbops = &mgag200fb_ops;
414c45310 Dave Airlie 2012-04-17 216
414c45310 Dave Airlie 2012-04-17 217 /* setup aperture base/size for
vesafb takeover */
414c45310 Dave Airlie 2012-04-17 218 info->apertures->ranges[0].base
= mdev->dev->mode_config.fb_base;
414c45310 Dave Airlie 2012-04-17 219
Re: [Intel-gfx] [PATCH v2 02/20] drm: Don't update plane properties for atomic planes if it stays the same
Op 08-07-15 om 22:12 schreef Daniel Vetter:
> On Wed, Jul 08, 2015 at 08:25:07PM +0200, Maarten Lankhorst wrote:
>> Op 08-07-15 om 19:52 schreef Daniel Vetter:
>>> On Wed, Jul 08, 2015 at 06:35:47PM +0200, Maarten Lankhorst wrote:
Op 08-07-15 om 10:55 schreef Daniel Vetter:
> On Wed, Jul 08, 2015 at 10:00:22AM +0200, Maarten Lankhorst wrote:
>> Op 07-07-15 om 18:43 schreef Daniel Vetter:
>>> On Tue, Jul 07, 2015 at 05:08:34PM +0200, Maarten Lankhorst wrote:
Op 07-07-15 om 14:10 schreef Daniel Vetter:
> On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
>> Op 07-07-15 om 11:18 schreef Daniel Vetter:
>>> On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst wrote:
This allows the first atomic call during hw init to be a real
modeset,
which is useful for forcing a recalculation.
>>> fbcon is optional, you can't rely on anything being done in any
>>> specific
>>> way. What exactly do you need this for, what's the implications?
>> In the hw readout I noticed some warnings when I wasn't setting any
>> mode property in the readout.
>> I want the first function to be the modeset, so we have a sane base
>> to commit changes on.
>> Ideally this whole function would have a atomic counterpart which
>> does it in one go. :)
> Yeah. Otoh as soon as we have atomic modeset working we can replace
> all
> the legacy entry points with atomic helpers, and then even
> plane_disable
> will be a full atomic modeset.
>
> What did fall apart with just touching properties/planes now?
Also when i915 is fully atomic it calculates in
intel_modeset_compute_config
if a modeset is needed after the first atomic call. Right now because
intel_modeset_compute_config is only called in set_config so this
works as expected.
Otherwise drm_plane_force_disable or rotate_0 will force a modeset,
and if the final mode is different this will introduce a double
modeset.
>>> For expensive properties (i.e. a no-op changes causes something that
>>> takes
>>> time like modeset or vblank wait) we need to make sure we filter them
>>> out
>>> in atomic_check. Yeah not quite there yet with pure atomic, but
>>> meanwhile
>>> the existing legacy set_prop functions should all filter out no-op
>>> changes
>>> themselves. If we don't do that for rotation then that's a bug.
>>>
>>> Same for disabling planes harder, that shouldn't take time. Especially
>>> since fbcon only force-disable non-primary plane, and for driver load
>>> that's the exact thing we already do in the driver anyway.
>> Something like this?
>> ---
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index a1d4e13f3908..2989232f4996 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -30,6 +30,7 @@
>> #include
>> #include
>> #include
>> +#include "drm_crtc_internal.h"
>> #include
>>
>> /**
>> @@ -1716,7 +1717,12 @@ drm_atomic_helper_crtc_set_property(struct
>> drm_crtc *crtc,
>> {
>> struct drm_atomic_state *state;
>> struct drm_crtc_state *crtc_state;
>> -int ret = 0;
>> +uint64_t retval;
>> +int ret;
>> +
>> +ret = drm_atomic_get_property(&crtc->base, property, &retval);
>> +if (!ret && val == retval)
>> +return 0;
>>
>> state = drm_atomic_state_alloc(crtc->dev);
>> if (!state)
>> @@ -1776,7 +1782,12 @@ drm_atomic_helper_plane_set_property(struct
>> drm_plane *plane,
>> {
>> struct drm_atomic_state *state;
>> struct drm_plane_state *plane_state;
>> -int ret = 0;
>> +uint64_t retval;
>> +int ret;
>> +
>> +ret = drm_atomic_get_property(&plane->base, property, &retval);
>> +if (!ret && val == retval)
>> +return 0;
>>
>> state = drm_atomic_state_alloc(plane->dev);
>> if (!state)
>> @@ -1836,7 +1847,12 @@ drm_atomic_helper_connector_set_property(struct
>> drm_connector *connector,
>> {
>> struct drm_atomic_state *state;
>> struct drm_connector_state *connector_state;
>> -int ret = 0;
>> +uint64_t retval;
>> +int ret;
>> +
>> +ret = drm_atomic_get_property(&connector->base, property,
>> &retval);
>> +if (!ret && val == retval)
>> +return 0;
>>
>> state = drm_atomic_state_alloc(connector->dev);
>> if (!stat
Re: [Intel-gfx] [PATCH] drm/i915: Adjust BXT HDMI port clock limits
On Fri, Jul 10, 2015 at 02:27:48PM +0100, Damien Lespiau wrote: > On Fri, Jul 10, 2015 at 04:21:27PM +0300, Ville Syrjälä wrote: > > On Fri, Jul 10, 2015 at 02:18:57PM +0100, Damien Lespiau wrote: > > > On Fri, Jul 10, 2015 at 04:09:42PM +0300, Imre Deak wrote: > > > > On ma, 2015-07-06 at 14:44 +0300, ville.syrj...@linux.intel.com wrote: > > > > > From: Ville Syrjälä > > > > > > > > > > Since > > > > > commit e62925567c7926e78bc8ca976cde5c28ea265a49 > > > > > Author: Vandana Kannan > > > > > Date: Wed Jul 1 17:02:57 2015 +0530 > > > > > > > > > > drm/i915/bxt: BUNs related to port PLL > > > > > > > > > > BXT DPLL can now generate frequencies in the 216-223 MHz range. > > > > > Adjust the HDMI port clock checks to account for the reduced range > > > > > of invalid frequencies. > > > > > > > > > > Cc: Vandana Kannan > > > > > Cc: Imre Deak > > > > > Signed-off-by: Ville Syrjälä > > > > > > > > Ville wrote a tool for CHV that calculates the valid frequencies based > > > > on the algorithm in the kernel. With the help of that I verified that > > > > this matches the list of target frequencies bxt_find_best_dpll() will > > > > accept, so: > > > > > > Could we have that tool in i-g-t? > > > > We could lift all the .find_dpll routines from the kernel into i-g-t. > > The only real concern is that we'll forget to update the i-g-t copies > > when changing the kernel. But I guess it would still be easier to just > > update them slightly when noticing that rather than having to lift them > > from the kernel all over again. > > Right, while not ideal, I think having something in i-g-t, even if it > diverges slightly (but then we can remind the patch author to update the > i-g-t tool during review) is still better than not having that code > around at all. Another way to check this would be to inject EDIDs with hand-rolled timings that increment in small steps. Then we can try modesets on all the unfiltered ones vs. just manually adding it with addmode. If any mode gets filtered inconsistently in the mode list parsing compared to modeset code that would be a bug. Unfortunately the hdmi injection stuff isn't ready yet. I'll create a jira for this idea. -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
Re: [Intel-gfx] commit dec4f799d0a4c9edae20512fa60b0a36f3299ca2 laptop reboots or hangs at boot time
Op 12-07-15 om 21:56 schreef Hans de Bruin: > Daniel, > > commit dec4f799d0a4c9edae20512fa60b0a36f3299ca2 causes my laptop to hang or > reboot at the moment the kernel swiches the vido mode at boot time. I also > noticed a warning while compiling: > > CC drivers/gpu/drm/i915/i915_gem_gtt.o > /usr/src/linux.bisect/drivers/gpu/drm/i915/i915_gem_gtt.c: In function > 'gen8_ppgtt_init': > /usr/src/linux.bisect/drivers/gpu/drm/i915/i915_gem_gtt.c:954:2: warning: > large integer implicitly truncated to unsigned type [-Woverflow] > ppgtt->base.total = 1ULL << 32; > ^ > > It might be related, or not. > http://lists.freedesktop.org/archives/dri-devel/2015-July/086263.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Adjust BXT HDMI port clock limits
On Fri, Jul 10, 2015 at 04:09:42PM +0300, Imre Deak wrote: > On ma, 2015-07-06 at 14:44 +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Since > > commit e62925567c7926e78bc8ca976cde5c28ea265a49 > > Author: Vandana Kannan > > Date: Wed Jul 1 17:02:57 2015 +0530 > > > > drm/i915/bxt: BUNs related to port PLL > > > > BXT DPLL can now generate frequencies in the 216-223 MHz range. > > Adjust the HDMI port clock checks to account for the reduced range > > of invalid frequencies. > > > > Cc: Vandana Kannan > > Cc: Imre Deak > > Signed-off-by: Ville Syrjälä > > Ville wrote a tool for CHV that calculates the valid frequencies based > on the algorithm in the kernel. With the help of that I verified that > this matches the list of target frequencies bxt_find_best_dpll() will > accept, so: > Reviewed-by: Imre Deak Queued for -next, thanks for the patch. -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
Re: [Intel-gfx] [PATCH v2] drm/i915: Don't forget to mark crtc as inactive after disable
Op 10-07-15 om 13:22 schreef Damien Lespiau: > Hi Patrik, > > Please do Cc the patch author and reviewer when finding a regression, > they are superb candidates for the review, especially when they are busy > rewriting the display code. > > On Wed, Jul 08, 2015 at 03:31:52PM +0200, Patrik Jakobsson wrote: >> Watermark calculations depend on the intel_crtc->active flag to be set >> properly. Suspend/resume is broken on SKL and we also get DDB mismatches >> without this patch. >> >> The regression was introduced in: >> >> commit eddfcbcdc27fbecb33bff098967bbdd7ca75bfa6 >> Author: Maarten Lankhorst >> Date: Mon Jun 15 12:33:53 2015 +0200 >> >> drm/i915: Update less state during modeset. >> >> No need to repeatedly call update_watermarks, or update_fbc. >> Down to a single call to update_watermarks in .crtc_enable >> >> Signed-off-by: Maarten Lankhorst >> Reviewed-by: Matt Roper >> Tested-by(IVB): Matt Roper >> Signed-off-by: Daniel Vetter >> >> v2: Don't touch disable_shared_dpll() >> >> Signed-off-by: Patrik Jakobsson > We do need to update the watermarks in disable() as well, to repartition > the DDB and update the watermarks based on the new allocation. > > Maarten, Matt, I've no clue where you want the crtc state update, where > the atomic WM work is at, could you comment? > I'd rather have we had a better way of updating watermarks, but keeping it in the .crtc_disable hook looks good to me right now. Some proper atomic solution will eventually have to be done. :) Reviewed-by: Maarten Lankhorst ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 02/20] drm: Don't update plane properties for atomic planes if it stays the same
On Mon, Jul 13, 2015 at 10:59:32AM +0200, Maarten Lankhorst wrote:
> Op 08-07-15 om 22:12 schreef Daniel Vetter:
> > On Wed, Jul 08, 2015 at 08:25:07PM +0200, Maarten Lankhorst wrote:
> >> Op 08-07-15 om 19:52 schreef Daniel Vetter:
> >>> On Wed, Jul 08, 2015 at 06:35:47PM +0200, Maarten Lankhorst wrote:
> Op 08-07-15 om 10:55 schreef Daniel Vetter:
> > On Wed, Jul 08, 2015 at 10:00:22AM +0200, Maarten Lankhorst wrote:
> >> Op 07-07-15 om 18:43 schreef Daniel Vetter:
> >>> On Tue, Jul 07, 2015 at 05:08:34PM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 14:10 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
> >> Op 07-07-15 om 11:18 schreef Daniel Vetter:
> >>> On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst wrote:
> This allows the first atomic call during hw init to be a real
> modeset,
> which is useful for forcing a recalculation.
> >>> fbcon is optional, you can't rely on anything being done in any
> >>> specific
> >>> way. What exactly do you need this for, what's the implications?
> >> In the hw readout I noticed some warnings when I wasn't setting
> >> any mode property in the readout.
> >> I want the first function to be the modeset, so we have a sane
> >> base to commit changes on.
> >> Ideally this whole function would have a atomic counterpart which
> >> does it in one go. :)
> > Yeah. Otoh as soon as we have atomic modeset working we can replace
> > all
> > the legacy entry points with atomic helpers, and then even
> > plane_disable
> > will be a full atomic modeset.
> >
> > What did fall apart with just touching properties/planes now?
> Also when i915 is fully atomic it calculates in
> intel_modeset_compute_config
> if a modeset is needed after the first atomic call. Right now because
> intel_modeset_compute_config is only called in set_config so this
> works as expected.
> Otherwise drm_plane_force_disable or rotate_0 will force a modeset,
> and if the final mode is different this will introduce a double
> modeset.
> >>> For expensive properties (i.e. a no-op changes causes something that
> >>> takes
> >>> time like modeset or vblank wait) we need to make sure we filter them
> >>> out
> >>> in atomic_check. Yeah not quite there yet with pure atomic, but
> >>> meanwhile
> >>> the existing legacy set_prop functions should all filter out no-op
> >>> changes
> >>> themselves. If we don't do that for rotation then that's a bug.
> >>>
> >>> Same for disabling planes harder, that shouldn't take time. Especially
> >>> since fbcon only force-disable non-primary plane, and for driver load
> >>> that's the exact thing we already do in the driver anyway.
> >> Something like this?
> >> ---
> >> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> >> b/drivers/gpu/drm/drm_atomic_helper.c
> >> index a1d4e13f3908..2989232f4996 100644
> >> --- a/drivers/gpu/drm/drm_atomic_helper.c
> >> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >> @@ -30,6 +30,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include "drm_crtc_internal.h"
> >> #include
> >>
> >> /**
> >> @@ -1716,7 +1717,12 @@ drm_atomic_helper_crtc_set_property(struct
> >> drm_crtc *crtc,
> >> {
> >>struct drm_atomic_state *state;
> >>struct drm_crtc_state *crtc_state;
> >> - int ret = 0;
> >> + uint64_t retval;
> >> + int ret;
> >> +
> >> + ret = drm_atomic_get_property(&crtc->base, property, &retval);
> >> + if (!ret && val == retval)
> >> + return 0;
> >>
> >>state = drm_atomic_state_alloc(crtc->dev);
> >>if (!state)
> >> @@ -1776,7 +1782,12 @@ drm_atomic_helper_plane_set_property(struct
> >> drm_plane *plane,
> >> {
> >>struct drm_atomic_state *state;
> >>struct drm_plane_state *plane_state;
> >> - int ret = 0;
> >> + uint64_t retval;
> >> + int ret;
> >> +
> >> + ret = drm_atomic_get_property(&plane->base, property, &retval);
> >> + if (!ret && val == retval)
> >> + return 0;
> >>
> >>state = drm_atomic_state_alloc(plane->dev);
> >>if (!state)
> >> @@ -1836,7 +1847,12 @@ drm_atomic_helper_connector_set_property(struct
> >> drm_connector *connector,
> >> {
> >>struct drm_atomic_state *state;
> >>struct drm_connector_state *connector_state;
> >> - int ret = 0;
> >> + uint64_t retval;
> >> + int ret;
> >> +
> >> + ret = drm_atomic_get_p
[Intel-gfx] [drm-intel:topic/drm-misc 31/36] drivers/gpu/drm//nouveau/nouveau_fbcon.c:322:18: warning: unused variable 'pdev'
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
head: 6198447760ed3c684fbcc93b5f91b4e84861e8f3
commit: 237fc6452ca562188349a9abe0f9e579fd260276 [31/36] drm/nouveau: Use new
drm_fb_helper functions
config: x86_64-randconfig-i0-201528 (attached as .config)
reproduce:
git checkout 237fc6452ca562188349a9abe0f9e579fd260276
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
drivers/gpu/drm//nouveau/nouveau_fbcon.c: In function 'nouveau_fbcon_create':
>> drivers/gpu/drm//nouveau/nouveau_fbcon.c:322:18: warning: unused variable
>> 'pdev' [-Wunused-variable]
struct pci_dev *pdev = dev->pdev;
^
vim +/pdev +322 drivers/gpu/drm//nouveau/nouveau_fbcon.c
6ee73861 Ben Skeggs 2009-12-11 306
6ee73861 Ben Skeggs 2009-12-11 307 static int
cd5428a5 Daniel Vetter2013-01-21 308 nouveau_fbcon_create(struct
drm_fb_helper *helper,
8be48d92 Dave Airlie 2010-03-30 309struct
drm_fb_helper_surface_size *sizes)
6ee73861 Ben Skeggs 2009-12-11 310 {
918b7ed4 Fabian Frederick 2014-09-14 311 struct nouveau_fbdev *fbcon =
918b7ed4 Fabian Frederick 2014-09-14 312 container_of(helper,
struct nouveau_fbdev, helper);
ebb945a9 Ben Skeggs 2012-07-20 313 struct drm_device *dev =
fbcon->dev;
77145f1c Ben Skeggs 2012-07-31 314 struct nouveau_drm *drm =
nouveau_drm(dev);
967e7bde Ben Skeggs 2014-08-10 315 struct nvif_device *device =
&drm->device;
6ee73861 Ben Skeggs 2009-12-11 316 struct fb_info *info;
6ee73861 Ben Skeggs 2009-12-11 317 struct drm_framebuffer *fb;
6ee73861 Ben Skeggs 2009-12-11 318 struct nouveau_framebuffer
*nouveau_fb;
45143cb5 Ben Skeggs 2011-06-07 319 struct nouveau_channel *chan;
6ee73861 Ben Skeggs 2009-12-11 320 struct nouveau_bo *nvbo;
308e5bcb Jesse Barnes 2011-11-14 321 struct drm_mode_fb_cmd2
mode_cmd;
1471ca9a Marcin Slusarz 2010-05-16 @322 struct pci_dev *pdev =
dev->pdev;
6ee73861 Ben Skeggs 2009-12-11 323 int size, ret;
6ee73861 Ben Skeggs 2009-12-11 324
38651674 Dave Airlie 2010-03-30 325 mode_cmd.width =
sizes->surface_width;
38651674 Dave Airlie 2010-03-30 326 mode_cmd.height =
sizes->surface_height;
6ee73861 Ben Skeggs 2009-12-11 327
308e5bcb Jesse Barnes 2011-11-14 328 mode_cmd.pitches[0] =
mode_cmd.width * (sizes->surface_bpp >> 3);
308e5bcb Jesse Barnes 2011-11-14 329 mode_cmd.pitches[0] =
roundup(mode_cmd.pitches[0], 256);
6ee73861 Ben Skeggs 2009-12-11 330
:: The code at line 322 was first introduced by commit
:: 1471ca9aa71cd37b6a7476bb6f06a3a8622ea1bd fbdev: allow passing more than
one aperture for handoff
:: TO: Marcin Slusarz
:: 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/x86_64 4.1.0-rc6 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10
-fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
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_BZIP2=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_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
C
Re: [Intel-gfx] [PATCH v2 00/10] Color Manager Implementation
On Mon, Jul 13, 2015 at 10:29:32AM +0200, Hans Verkuil wrote: > On 06/15/2015 08:53 AM, Daniel Vetter wrote: > > On Tue, Jun 09, 2015 at 01:50:48PM +0100, Damien Lespiau wrote: > >> On Thu, Jun 04, 2015 at 07:12:31PM +0530, Kausal Malladi wrote: > >>> From: Kausal Malladi > >>> > >>> This patch set adds color manager implementation in drm/i915 layer. > >>> Color Manager is an extension in i915 driver to support color > >>> correction/enhancement. Various Intel platforms support several > >>> color correction capabilities. Color Manager provides abstraction > >>> of these properties and allows a user space UI agent to > >>> correct/enhance the display. > >> > >> So I did a first rough pass on the API itself. The big question that > >> isn't solved at the moment is: do we want to try to do generic KMS > >> properties for pre-LUT + matrix + post-LUT or not. "Generic" has 3 levels: > >> > >> 1/ Generic for all KMS drivers > >> 2/ Generic for i915 supported platfoms > >> 3/ Specific to each platform > >> > >> At this point, I'm quite tempted to say we should give 1/ a shot. We > >> should be able to have pre-LUT + matrix + post-LUT on CRTC objects and > >> guarantee that, when the drivers expose such properties, user space can > >> at least give 8 bits LUT + 3x3 matrix + 8 bits LUT. > >> > >> It may be possible to use the "try" version of the atomic ioctl to > >> explore the space of possibilities from a generic user space to use > >> bigger LUTs as well. A HAL layer (which is already there in some but not > >> all OSes) would still be able to use those generic properties to load > >> "precision optimized" LUTs with some knowledge of the hardware. > > > > Yeah, imo 1/ should be doable. For the matrix we should be able to be > > fully generic with a 16.16 format. For gamma one option would be to have > > I know I am late replying, apologies for that. > > I've been working on CSC support for V4L2 as well (still work in progress) > and I would like to at least end up with the same low-level fixed point > format as DRM so we can share matrix/vector calculations. > > Based on my experiences I have concerns about the 16.16 format: the precision > is quite low which can be a problem when such values are used in matrix > multiplications. > > In addition, while the precision may be sufficient for 8 bit color component > values, I'm pretty sure it will be insufficient when dealing with 12 or 16 bit > color components. > > In earlier versions of my CSC code I used a 12.20 format, but in the latest I > switched to 32.32. This fits nicely in a u64 and it's easy to extract the > integer and fractional parts. > > If this is going to be a generic and future proof API, then my suggestion > would be to increase the precision of the underlying data type. We discussed this a bit more internally and figured it would be nice to have the same fixed point for both CSC matrix and LUT/gamma tables. Current consensus seems to be to go with 8.24 for both. Since LUTs are fairly big I think it makes sense if we try to be not too wasteful (while still future-proof ofc). But yeah agreeing on the underlying layout would be good so that we could share in-kernel code. We're aiming to not have any LUT interpolation in the kernel (just dropping samples at most if e.g. the hw table doesn't have linear sample positions). But with the LUT we might need to mutliply it with an in-kernel one (we need the CSC unit on some platforms to compress the color output range for hdmi). And maybe compress the LUTs too. -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] [drm-intel:topic/drm-misc 33/36] drivers/gpu/drm/bochs/bochs_fbdev.c:63:17: warning: unused variable 'device'
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
head: 6198447760ed3c684fbcc93b5f91b4e84861e8f3
commit: 394111a2b303c49b3a6c123320d08173588a1b37 [33/36] drm/boschs: Use new
drm_fb_helper functions
config: x86_64-randconfig-i0-201528 (attached as .config)
reproduce:
git checkout 394111a2b303c49b3a6c123320d08173588a1b37
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
drivers/gpu/drm/bochs/bochs_fbdev.c: In function 'bochsfb_create':
>> drivers/gpu/drm/bochs/bochs_fbdev.c:63:17: warning: unused variable 'device'
>> [-Wunused-variable]
struct device *device = &dev->pdev->dev;
^
vim +/device +63 drivers/gpu/drm/bochs/bochs_fbdev.c
0a6659bd Gerd Hoffmann 2013-12-17 47 if (ret)
0a6659bd Gerd Hoffmann 2013-12-17 48 return ret;
0a6659bd Gerd Hoffmann 2013-12-17 49
0a6659bd Gerd Hoffmann 2013-12-17 50 *gobj_p = gobj;
0a6659bd Gerd Hoffmann 2013-12-17 51 return ret;
0a6659bd Gerd Hoffmann 2013-12-17 52 }
0a6659bd Gerd Hoffmann 2013-12-17 53
0a6659bd Gerd Hoffmann 2013-12-17 54 static int bochsfb_create(struct
drm_fb_helper *helper,
0a6659bd Gerd Hoffmann 2013-12-17 55 struct
drm_fb_helper_surface_size *sizes)
0a6659bd Gerd Hoffmann 2013-12-17 56 {
0a6659bd Gerd Hoffmann 2013-12-17 57 struct bochs_device *bochs =
0a6659bd Gerd Hoffmann 2013-12-17 58 container_of(helper, struct
bochs_device, fb.helper);
0a6659bd Gerd Hoffmann 2013-12-17 59 struct drm_device *dev = bochs->dev;
0a6659bd Gerd Hoffmann 2013-12-17 60 struct fb_info *info;
0a6659bd Gerd Hoffmann 2013-12-17 61 struct drm_framebuffer *fb;
0a6659bd Gerd Hoffmann 2013-12-17 62 struct drm_mode_fb_cmd2 mode_cmd;
0a6659bd Gerd Hoffmann 2013-12-17 @63 struct device *device = &dev->pdev->dev;
0a6659bd Gerd Hoffmann 2013-12-17 64 struct drm_gem_object *gobj = NULL;
0a6659bd Gerd Hoffmann 2013-12-17 65 struct bochs_bo *bo = NULL;
0a6659bd Gerd Hoffmann 2013-12-17 66 int size, ret;
0a6659bd Gerd Hoffmann 2013-12-17 67
0a6659bd Gerd Hoffmann 2013-12-17 68 if (sizes->surface_bpp != 32)
0a6659bd Gerd Hoffmann 2013-12-17 69 return -EINVAL;
0a6659bd Gerd Hoffmann 2013-12-17 70
0a6659bd Gerd Hoffmann 2013-12-17 71 mode_cmd.width = sizes->surface_width;
:: The code at line 63 was first introduced by commit
:: 0a6659bdc5e8221da99eebb176fd9591435e38de drm/bochs: new driver
:: TO: Gerd Hoffmann
:: 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/x86_64 4.1.0-rc6 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10
-fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
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_BZIP2=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_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y
CONFIG_GENERIC_P
Re: [Intel-gfx] [PATCH] drm/i915: storm detection documentation update
On Fri, Jul 10, 2015 at 12:30:43PM +0530, Sivakumar Thulasimani wrote: > From: "Thulasimani,Sivakumar" > > Update the hotplug documentation to explain that hotplug storm > is not expected for Display port panels and hence is not handled > in current code. > > v2: update the statements as recommended by Daniel > > Signed-off-by: Sivakumar Thulasimani Queued for -next, thanks for the patch. -Daniel > --- > drivers/gpu/drm/i915/intel_hotplug.c |8 > 1 file changed, 8 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_hotplug.c > b/drivers/gpu/drm/i915/intel_hotplug.c > index bac91a1..3c9171f 100644 > --- a/drivers/gpu/drm/i915/intel_hotplug.c > +++ b/drivers/gpu/drm/i915/intel_hotplug.c > @@ -66,6 +66,14 @@ > * while before being re-enabled. The intention is to mitigate issues raising > * from broken hardware triggering massive amounts of interrupts and grinding > * the system to a halt. > + * > + * Current implementation expects that hotplug interrupt storm will not be > + * seen when display port sink is connected, hence on platforms whose DP > + * callback is handled by i915_digport_work_func reenabling of hpd is not > + * performed (it was never expected to be disabled in the first place ;) ) > + * this is specific to DP sinks handled by this routine and any other display > + * such as HDMI or DVI enabled on the same port will have proper logic since > + * it will use i915_hotplug_work_func where this logic is handled. > */ > > enum port intel_hpd_pin_to_port(enum hpd_pin pin) > -- > 1.7.9.5 > > ___ > 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] drm/i915: Allow parsing of variable size child device entries from VBT
On Fri, Jul 10, 2015 at 02:10:54PM +0300, Antti Koskipaa wrote:
> VBT version 196 increased the size of common_child_dev_config. The parser
> code assumed that the size of this structure would not change.
>
> So now, instead of checking for smaller size, check that the VBT entry is
> not too large and memcpy only child_dev_size amount of data, leaving any
> trailing entries as zero. If this is not good enough for the future,
> we can always sprinkle extra version checks in there.
>
> Signed-off-by: Antti Koskipaa
As I mentioned in the other threads I think with vbt it's not too paranoid
to double-check our assumptions. So for each vbt version range I'd like us
to check what size we exactly expect. Being super paranoid with vbt is imo
good practice since otherwise the hw teams will sneak in another update
without us realizing it.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_bios.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 2ff9eb0..763a636 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1022,10 +1022,15 @@ parse_device_mapping(struct drm_i915_private
> *dev_priv,
> DRM_DEBUG_KMS("No general definition block is found, no devices
> defined.\n");
> return;
> }
> - if (p_defs->child_dev_size < sizeof(*p_child)) {
> + /* Historically, child_dev_size has to be at least 33 bytes in size. */
> + if (p_defs->child_dev_size < 33) {
> DRM_ERROR("General definiton block child device size is too
> small.\n");
> return;
> }
> + if (p_defs->child_dev_size > sizeof(*p_child)) {
> + DRM_ERROR("General definiton block child device size is too
> large.\n");
> + return;
> + }
> /* get the block size of general definitions */
> block_size = get_blocksize(p_defs);
> /* get the number of child device */
> @@ -1070,7 +1075,7 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
>
> child_dev_ptr = dev_priv->vbt.child_dev + count;
> count++;
> - memcpy(child_dev_ptr, p_child, sizeof(*p_child));
> + memcpy(child_dev_ptr, p_child, p_defs->child_dev_size);
> }
> return;
> }
> --
> 2.3.6
>
> ___
> 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] [RFC] drm/i915: Add gen check for fb size
On Fri, Jul 10, 2015 at 04:45:12PM +0530, Vandana Kannan wrote:
> From gen7, the platform can support fb of size < 3x3.
> Adding this check for gen along with fb width & height.
> Note: IVB is gen7 but its not clear if it can support width < 3 and
> height < 3.
>
> This patch has been tested in Android environment.
>
> Signed-off-by: Vandana Kannan
What exactly are you usinga 3x3 framebuffer for? Imo this needs userspace
plus igt testcases and all that, but really not sure why this would be
worth it ever.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_sprite.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/drivers/gpu/drm/i915/intel_sprite.c
> index cd21525..310d0a7 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -770,8 +770,13 @@ intel_check_sprite_plane(struct drm_plane *plane,
> return -EINVAL;
> }
>
> + if (INTEL_INFO(dev)->gen < 7 && (fb->width < 3 || fb->height < 3)) {
> + DRM_DEBUG_KMS("Unsuitable framebuffer for plane\n");
> + return -EINVAL;
> + }
> +
> /* FIXME check all gen limits */
> - if (fb->width < 3 || fb->height < 3 || fb->pitches[0] > 16384) {
> + if (fb->pitches[0] > 16384) {
> DRM_DEBUG_KMS("Unsuitable framebuffer for plane\n");
> return -EINVAL;
> }
> --
> 2.0.1
>
> ___
> 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 v2 02/20] drm: Don't update plane properties for atomic planes if it stays the same
Op 13-07-15 om 11:13 schreef Daniel Vetter:
> On Mon, Jul 13, 2015 at 10:59:32AM +0200, Maarten Lankhorst wrote:
>> Op 08-07-15 om 22:12 schreef Daniel Vetter:
>>> On Wed, Jul 08, 2015 at 08:25:07PM +0200, Maarten Lankhorst wrote:
Op 08-07-15 om 19:52 schreef Daniel Vetter:
> On Wed, Jul 08, 2015 at 06:35:47PM +0200, Maarten Lankhorst wrote:
>> Op 08-07-15 om 10:55 schreef Daniel Vetter:
>>> On Wed, Jul 08, 2015 at 10:00:22AM +0200, Maarten Lankhorst wrote:
Op 07-07-15 om 18:43 schreef Daniel Vetter:
> On Tue, Jul 07, 2015 at 05:08:34PM +0200, Maarten Lankhorst wrote:
>> Op 07-07-15 om 14:10 schreef Daniel Vetter:
>>> On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
Op 07-07-15 om 11:18 schreef Daniel Vetter:
> On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst wrote:
>> This allows the first atomic call during hw init to be a real
>> modeset,
>> which is useful for forcing a recalculation.
> fbcon is optional, you can't rely on anything being done in any
> specific
> way. What exactly do you need this for, what's the implications?
In the hw readout I noticed some warnings when I wasn't setting
any mode property in the readout.
I want the first function to be the modeset, so we have a sane
base to commit changes on.
Ideally this whole function would have a atomic counterpart which
does it in one go. :)
>>> Yeah. Otoh as soon as we have atomic modeset working we can replace
>>> all
>>> the legacy entry points with atomic helpers, and then even
>>> plane_disable
>>> will be a full atomic modeset.
>>>
>>> What did fall apart with just touching properties/planes now?
>> Also when i915 is fully atomic it calculates in
>> intel_modeset_compute_config
>> if a modeset is needed after the first atomic call. Right now because
>> intel_modeset_compute_config is only called in set_config so this
>> works as expected.
>> Otherwise drm_plane_force_disable or rotate_0 will force a modeset,
>> and if the final mode is different this will introduce a double
>> modeset.
> For expensive properties (i.e. a no-op changes causes something that
> takes
> time like modeset or vblank wait) we need to make sure we filter them
> out
> in atomic_check. Yeah not quite there yet with pure atomic, but
> meanwhile
> the existing legacy set_prop functions should all filter out no-op
> changes
> themselves. If we don't do that for rotation then that's a bug.
>
> Same for disabling planes harder, that shouldn't take time. Especially
> since fbcon only force-disable non-primary plane, and for driver load
> that's the exact thing we already do in the driver anyway.
Something like this?
---
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index a1d4e13f3908..2989232f4996 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include "drm_crtc_internal.h"
#include
/**
@@ -1716,7 +1717,12 @@ drm_atomic_helper_crtc_set_property(struct
drm_crtc *crtc,
{
struct drm_atomic_state *state;
struct drm_crtc_state *crtc_state;
- int ret = 0;
+ uint64_t retval;
+ int ret;
+
+ ret = drm_atomic_get_property(&crtc->base, property, &retval);
+ if (!ret && val == retval)
+ return 0;
state = drm_atomic_state_alloc(crtc->dev);
if (!state)
@@ -1776,7 +1782,12 @@ drm_atomic_helper_plane_set_property(struct
drm_plane *plane,
{
struct drm_atomic_state *state;
struct drm_plane_state *plane_state;
- int ret = 0;
+ uint64_t retval;
+ int ret;
+
+ ret = drm_atomic_get_property(&plane->base, property, &retval);
+ if (!ret && val == retval)
+ return 0;
state = drm_atomic_state_alloc(plane->dev);
if (!state)
@@ -1836,7 +1847,12 @@ drm_atomic_helper_connector_set_property(struct
drm_connector *connector,
{
struct drm_atomic_state *state;
struct drm_connector_state *connector_state;
- int ret = 0;
+ uint64_t retval;
+ int ret;
>>
[Intel-gfx] [PATCH] drm/amdgpu: fix odd_ptr_err.cocci warnings
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c:205:5-11: inconsistent IS_ERR and
PTR_ERR, PTR_ERR on line 206
PTR_ERR should access the value just tested by IS_ERR
Semantic patch information:
There can be false positives in the patch case, where it is the call
IS_ERR that is wrong.
Generated by: scripts/coccinelle/tests/odd_ptr_err.cocci
CC: Archit Taneja
Signed-off-by: Fengguang Wu
---
amdgpu_fb.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
@@ -203,7 +203,7 @@ static int amdgpufb_create(struct drm_fb
/* okay we have an object now allocate the framebuffer */
info = drm_fb_helper_alloc_fbi(helper);
if (IS_ERR(info)) {
- ret = PTR_ERR(ret);
+ ret = PTR_ERR(info);
goto out_unref;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [drm-intel:topic/drm-misc 34/36] drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c:205:5-11: inconsistent IS_ERR and PTR_ERR, PTR_ERR on line 206
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc head: 6198447760ed3c684fbcc93b5f91b4e84861e8f3 commit: 9d70561ba3b129ae7bc052a9f73812bc3b7ad91a [34/36] drm/amdgpu: Use new drm_fb_helper functions coccinelle warnings: (new ones prefixed by >>) >> drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c:205:5-11: inconsistent IS_ERR and >> PTR_ERR, PTR_ERR on line 206 Please review and possibly fold the followup patch. --- 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] drm/i915: Update PM interrupts before updating the freq
On Sat, Jul 11, 2015 at 05:46:37PM +0100, Chris Wilson wrote: > On Fri, Jul 10, 2015 at 06:31:40PM +0530, Praveen Paneri wrote: > > From: Deepak S > > > > Currently we update the freq before masking the interrupts, which can > > allow new interrupts to occur before the frequency has changed. These > > extra interrupts might waste some cpu cycles. This patch corrects > > this by masking interrupts prior to updating the frequency. > > Well it won't waste CPU cycles as the interrupt is also masked by the > threshold limits, but there should be no harm at all in reordering the > patch so, and it does make a certain amount of sense. Added and ... > > > Signed-off-by: Deepak S > > Signed-off-by: Praveen Paneri > > Quibbling over the language in the changelog aside, > Reviewed-by: Chris Wilson queued for -next, thanks for the patch. -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
Re: [Intel-gfx] [PATCH i-g-t] lib/igt_gt.c : allow changes to stop_rings mode bits
On Fri, Jul 10, 2015 at 02:06:06PM +0100, tim.g...@intel.com wrote: > From: Tim Gore > > In function igt_set_stop_rings, the test > igt_assert_f(flags == 0 || current == 0, .. > > will fail if we are trying to force a hang but the > STOP_RINGS_ALLOW_BAN or STOP_RINGS_ALLOW_ERROR bit is set. > With the introduction of per ring resets in the driver > (in android) these bits do not get cleared to zero when > an individual ring is reset. This causes subsequent > attempt to cause a ring hang via this function to fail, > leading to several igt tests failing (ie gem_reset_stats > subtest ban-xxx etc). Fix tdr to reset these instead? -Daniel > So, modify this test to look only at the bits that are > used to hang the gpu rings. > > Signed-off-by: Tim Gore > --- > lib/igt_gt.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/lib/igt_gt.c b/lib/igt_gt.c > index 8e5e076..12c56fa 100644 > --- a/lib/igt_gt.c > +++ b/lib/igt_gt.c > @@ -345,8 +345,8 @@ void igt_set_stop_rings(enum stop_ring_flags flags) > STOP_RING_ALLOW_ERRORS)) == 0); > > current = igt_get_stop_rings(); > - igt_assert_f(flags == 0 || current == 0, > - "previous i915_ring_stop is still 0x%x\n", current); > + igt_assert_f( (flags & STOP_RING_ALL) == 0 || (current & STOP_RING_ALL) > == 0, > + "previous i915_ring_stop is still 0x%x\n", > current); > > stop_rings_write(flags); > current = igt_get_stop_rings(); > -- > 1.9.1 > > ___ > 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 v2 09/20] drm/i915: Fill in more crtc state, v2.
Op 07-07-15 om 12:28 schreef Daniel Vetter: > On Tue, Jul 07, 2015 at 09:08:20AM +0200, Maarten Lankhorst wrote: >> Perform a full readout of the state by making sure the mode is set >> up correctly atomically. >> >> Also there was a small memory leak by doing the memset, fix this >> by calling __drm_atomic_helper_crtc_destroy_state first. >> >> Changes since v1: >> - Moved after reworking primary plane and updating mode members. >> - Force a modeset calculation by changing mode->type from what the >> final mode will be. >> >> Signed-off-by: Maarten Lankhorst > tbh I don't really like mode_from_pipe_config since it goes in reverse. > With the adjust mode of config_compare we can compare different final hw > states and make a call whether they match enough for modeset avoidance or > not. mode_from_pipe_config otoh is a lie on panels where we can do > upscaling, hence I'd like to remove it to avoid confusion. What do you want the initial mode to be then? You need to fill in some mode to satisfy drm_atomic_crtc_check. ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests/gem_reset_stats.c: fix "ban" tests with scheduler
On Fri, Jul 10, 2015 at 02:26:59PM +0100, tim.g...@intel.com wrote:
> From: Tim Gore
>
> The tests for context banning fail when the gpu scheduler
> is enabled. The test causes a hang (using an infinite loop
> batch) and then queues up some work behind it on both the
> hanging context and also on a second "good" context. On
> the "good" context it queues up 2 batch buffers. After the
> hanging ring has been reset (not a full gpu reset) the
> test checks the values of batch_active and batch_pending
> returned by the i915_get_reset_stats_ioctl. For the "good"
> context it expects to see batch_pending == 2, because two
> batch buffers we queued up behind the hang on this
> context. But, with the scheduler enabled (android, gen8),
> one of these batch buffers is still waiting in the
> scheduler and has not made it as far as the
> ring->request_list, so this batch buffer is unaffected by
> the ring reset, and batch_pending is only 1.
>
> I considered putting in a test for the scheduler being
> enabled, but decided that a simpler solution is to only
> queue up 1 batch buffer on the good context. This does
> not change the test logic in any way and ensures that we
> should always have batch_pending=1, with or without the
> scheduler.
For the scheduler/tdr we probably need to split this up into two testcases
each:
- one where the 2nd batch depends upon the first (cross-context depency).
- one where the 2nd batch doesn't depend upon the first (should execute
unhampered with scheduler/tdr).
Since we don't yet have a scheduler/tdr both of these will result in the
same outcome (since there's always the temporal depency). But with your
patch you only test the 2nd case (and incompletely, we should assert that
the 2nd batch did run) and ignore the first case.
In short this failure here is telling you that your test coverage for
these features is lacking. The correct fix is not to mangle the existing,
but fix it up to correctly cover the new expectations in all cases. And
that should be done as part of the tdr/scheduler submission.
-Daniel
>
> Signed-off-by: Tim Gore
> ---
> tests/gem_reset_stats.c | 16 ++--
> 1 file changed, 6 insertions(+), 10 deletions(-)
>
> diff --git a/tests/gem_reset_stats.c b/tests/gem_reset_stats.c
> index 2bb4291..6529463 100644
> --- a/tests/gem_reset_stats.c
> +++ b/tests/gem_reset_stats.c
> @@ -468,7 +468,7 @@ static void test_rs_ctx(int num_fds, int num_ctx, int
> hang_index,
>
> static void test_ban(void)
> {
> - int h1,h2,h3,h4,h5,h6,h7;
> + int h1,h2,h3,h4,h5,h6;
> int fd_bad, fd_good;
> int retry = 10;
> int active_count = 0, pending_count = 0;
> @@ -496,7 +496,6 @@ static void test_ban(void)
> pending_count++;
>
> h6 = exec_valid(fd_good, 0);
> - h7 = exec_valid(fd_good, 0);
>
> while (retry--) {
> h3 = inject_hang_no_ban_error(fd_bad, 0);
> @@ -525,7 +524,7 @@ static void test_ban(void)
> igt_assert_eq(h4, -EIO);
> assert_reset_status(fd_bad, 0, RS_BATCH_ACTIVE);
>
> - gem_sync(fd_good, h7);
> + gem_sync(fd_good, h6);
> assert_reset_status(fd_good, 0, RS_BATCH_PENDING);
>
> igt_assert_eq(gem_reset_stats(fd_good, 0, &rs_good), 0);
> @@ -534,12 +533,11 @@ static void test_ban(void)
> igt_assert(rs_bad.batch_active == active_count);
> igt_assert(rs_bad.batch_pending == pending_count);
> igt_assert(rs_good.batch_active == 0);
> - igt_assert(rs_good.batch_pending == 2);
> + igt_assert(rs_good.batch_pending == 1);
>
> gem_close(fd_bad, h1);
> gem_close(fd_bad, h2);
> gem_close(fd_good, h6);
> - gem_close(fd_good, h7);
>
> h1 = exec_valid(fd_good, 0);
> igt_assert_lte(0, h1);
> @@ -554,7 +552,7 @@ static void test_ban(void)
>
> static void test_ban_ctx(void)
> {
> - int h1,h2,h3,h4,h5,h6,h7;
> + int h1,h2,h3,h4,h5,h6;
> int ctx_good, ctx_bad;
> int fd;
> int retry = 10;
> @@ -587,7 +585,6 @@ static void test_ban_ctx(void)
> pending_count++;
>
> h6 = exec_valid(fd, ctx_good);
> - h7 = exec_valid(fd, ctx_good);
>
> while (retry--) {
> h3 = inject_hang_no_ban_error(fd, ctx_bad);
> @@ -616,7 +613,7 @@ static void test_ban_ctx(void)
> igt_assert_eq(h4, -EIO);
> assert_reset_status(fd, ctx_bad, RS_BATCH_ACTIVE);
>
> - gem_sync(fd, h7);
> + gem_sync(fd, h6);
> assert_reset_status(fd, ctx_good, RS_BATCH_PENDING);
>
> igt_assert_eq(gem_reset_stats(fd, ctx_good, &rs_good), 0);
> @@ -625,12 +622,11 @@ static void test_ban_ctx(void)
> igt_assert(rs_bad.batch_active == active_count);
> igt_assert(rs_bad.batch_pending == pending_count);
> igt_assert(rs_good.batch_active == 0);
> - igt_assert(rs_good.batch_pending == 2);
> + igt_assert(rs_good.batch_pending == 1);
>
> gem_close(fd, h1);
> gem_close(fd, h2);
> gem_close(fd, h6);
> - gem_close(fd, h7)
Re: [Intel-gfx] [PATCH] drm/i915/bxt: WA for swapped HPD pins in A stepping
On Mon, Jul 13, 2015 at 02:10:09PM +0530, Sonika Jindal wrote:
> As per bspec, on BXT A0/A1, sw needs to activate DDIA HPD logic
> and interrupts to check the external panel connection.
> And remove the redundant comment.
>
> v2: Remove redundant IS_BROXTON check, Add comment about port C not
> connected, and rephrase the commit message to include only what we
> are doing here (Imre)
> v3: Add comment about the WA, move 'hpd' initialization outside for
> loop (Siva)
> Also, remove few redundant comments from hpd handler (me)
>
> Signed-off-by: Sonika Jindal
Can't we do this in two steps:
- Wire up port A hpd in a generic way.
- Add wa for bxt to use port A hpd in the various encoder setup functions
where we assign intel_encoder->hpd_pin.
Currently that switchover is spread all through low-level functions, which
makes this a bit confusion. Imo low-level code shouldn't treat hpd A as
anything but hpd A since that's just confusing. And we already have the
infrastructure for encoders to ask for any hpd pin they want really.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_irq.c | 46
> ++-
> 1 file changed, 31 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index a897f68..13cabca 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -88,7 +88,14 @@ static const u32 hpd_status_i915[HPD_NUM_PINS] = {
> [HPD_PORT_D] = PORTD_HOTPLUG_INT_STATUS
> };
>
> -/* BXT hpd list */
> +/*
> + * On BXT A0/A1, sw needs to activate DDIA HPD logic and interrupts to check
> + * the external panel connection. Port C is not connected on bxt A0/A1
> + */
> +static const u32 hpd_bxt_a0[HPD_NUM_PINS] = {
> + [HPD_PORT_B] = BXT_DE_PORT_HP_DDIA
> +};
> +
> static const u32 hpd_bxt[HPD_NUM_PINS] = {
> [HPD_PORT_B] = BXT_DE_PORT_HP_DDIB,
> [HPD_PORT_C] = BXT_DE_PORT_HP_DDIC
> @@ -1967,6 +1974,7 @@ static void bxt_hpd_handler(struct drm_device *dev,
> uint32_t iir_status)
> struct drm_i915_private *dev_priv = dev->dev_private;
> u32 hp_control, hp_trigger;
> u32 pin_mask, long_mask;
> + const u32 *hpd;
>
> /* Get the status */
> hp_trigger = iir_status & BXT_DE_PORT_HOTPLUG_MASK;
> @@ -1981,7 +1989,12 @@ static void bxt_hpd_handler(struct drm_device *dev,
> uint32_t iir_status)
> /* Clear sticky bits in hpd status */
> I915_WRITE(BXT_HOTPLUG_CTL, hp_control);
>
> - pch_get_hpd_pins(&pin_mask, &long_mask, hp_trigger, hp_control,
> hpd_bxt);
> + if (INTEL_REVID(dev) < BXT_REVID_B0)
> + hpd = hpd_bxt_a0;
> + else
> + hpd = hpd_bxt;
> +
> + pch_get_hpd_pins(&pin_mask, &long_mask, hp_trigger, hp_control, hpd);
> intel_hpd_irq_handler(dev, pin_mask, long_mask);
> }
>
> @@ -3021,31 +3034,34 @@ static void bxt_hpd_irq_setup(struct drm_device *dev)
> struct intel_encoder *intel_encoder;
> u32 hotplug_port = 0;
> u32 hotplug_ctrl;
> + const u32 *hpd;
>
> - /* Now, enable HPD */
> - for_each_intel_encoder(dev, intel_encoder) {
> + if (INTEL_REVID(dev) < BXT_REVID_B0)
> + hpd = hpd_bxt_a0;
> + else
> + hpd = hpd_bxt;
> +
> + for_each_intel_encoder(dev, intel_encoder)
> if (dev_priv->hotplug.stats[intel_encoder->hpd_pin].state
> == HPD_ENABLED)
> - hotplug_port |= hpd_bxt[intel_encoder->hpd_pin];
> - }
> + hotplug_port |= hpd[intel_encoder->hpd_pin];
>
> - /* Mask all HPD control bits */
> hotplug_ctrl = I915_READ(BXT_HOTPLUG_CTL) & ~BXT_HOTPLUG_CTL_MASK;
>
> - /* Enable requested port in hotplug control */
> /* TODO: implement (short) HPD support on port A */
> - WARN_ON_ONCE(hotplug_port & BXT_DE_PORT_HP_DDIA);
> - if (hotplug_port & BXT_DE_PORT_HP_DDIB)
> - hotplug_ctrl |= BXT_DDIB_HPD_ENABLE;
> - if (hotplug_port & BXT_DE_PORT_HP_DDIC)
> - hotplug_ctrl |= BXT_DDIC_HPD_ENABLE;
> + if (INTEL_REVID(dev) < BXT_REVID_B0 && (hotplug_port &
> BXT_DE_PORT_HP_DDIA))
> + hotplug_ctrl |= BXT_DDIA_HPD_ENABLE;
> + else {
> + if (hotplug_port & BXT_DE_PORT_HP_DDIB)
> + hotplug_ctrl |= BXT_DDIB_HPD_ENABLE;
> + if (hotplug_port & BXT_DE_PORT_HP_DDIC)
> + hotplug_ctrl |= BXT_DDIC_HPD_ENABLE;
> + }
> I915_WRITE(BXT_HOTPLUG_CTL, hotplug_ctrl);
>
> - /* Unmask DDI hotplug in IMR */
> hotplug_ctrl = I915_READ(GEN8_DE_PORT_IMR) & ~hotplug_port;
> I915_WRITE(GEN8_DE_PORT_IMR, hotplug_ctrl);
>
> - /* Enable DDI hotplug in IER */
> hotplug_ctrl = I915_READ(GEN8_DE_PORT_IER) | hotplug_port;
> I915_WRITE(GEN8_DE_PORT_IER, hotplug_ctrl);
> POSTING_READ(GEN8_DE_PORT_IER);
> --
> 1.7.10.4
>
> ___
> Intel-gfx mailing
Re: [Intel-gfx] [PATCH v2 02/20] drm: Don't update plane properties for atomic planes if it stays the same
On Mon, Jul 13, 2015 at 11:23:45AM +0200, Maarten Lankhorst wrote:
> Op 13-07-15 om 11:13 schreef Daniel Vetter:
> > On Mon, Jul 13, 2015 at 10:59:32AM +0200, Maarten Lankhorst wrote:
> >> Op 08-07-15 om 22:12 schreef Daniel Vetter:
> >>> On Wed, Jul 08, 2015 at 08:25:07PM +0200, Maarten Lankhorst wrote:
> Op 08-07-15 om 19:52 schreef Daniel Vetter:
> > On Wed, Jul 08, 2015 at 06:35:47PM +0200, Maarten Lankhorst wrote:
> >> Op 08-07-15 om 10:55 schreef Daniel Vetter:
> >>> On Wed, Jul 08, 2015 at 10:00:22AM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 18:43 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 05:08:34PM +0200, Maarten Lankhorst wrote:
> >> Op 07-07-15 om 14:10 schreef Daniel Vetter:
> >>> On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 11:18 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst
> > wrote:
> >> This allows the first atomic call during hw init to be a real
> >> modeset,
> >> which is useful for forcing a recalculation.
> > fbcon is optional, you can't rely on anything being done in any
> > specific
> > way. What exactly do you need this for, what's the implications?
> In the hw readout I noticed some warnings when I wasn't setting
> any mode property in the readout.
> I want the first function to be the modeset, so we have a sane
> base to commit changes on.
> Ideally this whole function would have a atomic counterpart
> which does it in one go. :)
> >>> Yeah. Otoh as soon as we have atomic modeset working we can
> >>> replace all
> >>> the legacy entry points with atomic helpers, and then even
> >>> plane_disable
> >>> will be a full atomic modeset.
> >>>
> >>> What did fall apart with just touching properties/planes now?
> >> Also when i915 is fully atomic it calculates in
> >> intel_modeset_compute_config
> >> if a modeset is needed after the first atomic call. Right now
> >> because
> >> intel_modeset_compute_config is only called in set_config so this
> >> works as expected.
> >> Otherwise drm_plane_force_disable or rotate_0 will force a modeset,
> >> and if the final mode is different this will introduce a double
> >> modeset.
> > For expensive properties (i.e. a no-op changes causes something
> > that takes
> > time like modeset or vblank wait) we need to make sure we filter
> > them out
> > in atomic_check. Yeah not quite there yet with pure atomic, but
> > meanwhile
> > the existing legacy set_prop functions should all filter out no-op
> > changes
> > themselves. If we don't do that for rotation then that's a bug.
> >
> > Same for disabling planes harder, that shouldn't take time.
> > Especially
> > since fbcon only force-disable non-primary plane, and for driver
> > load
> > that's the exact thing we already do in the driver anyway.
> Something like this?
> ---
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index a1d4e13f3908..2989232f4996 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -30,6 +30,7 @@
> #include
> #include
> #include
> +#include "drm_crtc_internal.h"
> #include
>
> /**
> @@ -1716,7 +1717,12 @@ drm_atomic_helper_crtc_set_property(struct
> drm_crtc *crtc,
> {
> struct drm_atomic_state *state;
> struct drm_crtc_state *crtc_state;
> -int ret = 0;
> +uint64_t retval;
> +int ret;
> +
> +ret = drm_atomic_get_property(&crtc->base, property, &retval);
> +if (!ret && val == retval)
> +return 0;
>
> state = drm_atomic_state_alloc(crtc->dev);
> if (!state)
> @@ -1776,7 +1782,12 @@ drm_atomic_helper_plane_set_property(struct
> drm_plane *plane,
> {
> struct drm_atomic_state *state;
> struct drm_plane_state *plane_state;
> -int ret = 0;
> +uint64_t retval;
> +int ret;
> +
> +ret = drm_atomic_get_property(&plane->base, property, &retval);
> +if (!ret && val == retval)
> +return 0;
>
> state = drm_atomic_state_alloc(plane->dev);
> if (!state)
> @@ -1836,7 +1847,12 @@
> >>>
Re: [Intel-gfx] [PATCH v2 00/10] Color Manager Implementation
On 07/13/2015 11:18 AM, Daniel Vetter wrote: > On Mon, Jul 13, 2015 at 10:29:32AM +0200, Hans Verkuil wrote: >> On 06/15/2015 08:53 AM, Daniel Vetter wrote: >>> On Tue, Jun 09, 2015 at 01:50:48PM +0100, Damien Lespiau wrote: On Thu, Jun 04, 2015 at 07:12:31PM +0530, Kausal Malladi wrote: > From: Kausal Malladi > > This patch set adds color manager implementation in drm/i915 layer. > Color Manager is an extension in i915 driver to support color > correction/enhancement. Various Intel platforms support several > color correction capabilities. Color Manager provides abstraction > of these properties and allows a user space UI agent to > correct/enhance the display. So I did a first rough pass on the API itself. The big question that isn't solved at the moment is: do we want to try to do generic KMS properties for pre-LUT + matrix + post-LUT or not. "Generic" has 3 levels: 1/ Generic for all KMS drivers 2/ Generic for i915 supported platfoms 3/ Specific to each platform At this point, I'm quite tempted to say we should give 1/ a shot. We should be able to have pre-LUT + matrix + post-LUT on CRTC objects and guarantee that, when the drivers expose such properties, user space can at least give 8 bits LUT + 3x3 matrix + 8 bits LUT. It may be possible to use the "try" version of the atomic ioctl to explore the space of possibilities from a generic user space to use bigger LUTs as well. A HAL layer (which is already there in some but not all OSes) would still be able to use those generic properties to load "precision optimized" LUTs with some knowledge of the hardware. >>> >>> Yeah, imo 1/ should be doable. For the matrix we should be able to be >>> fully generic with a 16.16 format. For gamma one option would be to have >> >> I know I am late replying, apologies for that. >> >> I've been working on CSC support for V4L2 as well (still work in progress) >> and I would like to at least end up with the same low-level fixed point >> format as DRM so we can share matrix/vector calculations. >> >> Based on my experiences I have concerns about the 16.16 format: the precision >> is quite low which can be a problem when such values are used in matrix >> multiplications. >> >> In addition, while the precision may be sufficient for 8 bit color component >> values, I'm pretty sure it will be insufficient when dealing with 12 or 16 >> bit >> color components. >> >> In earlier versions of my CSC code I used a 12.20 format, but in the latest I >> switched to 32.32. This fits nicely in a u64 and it's easy to extract the >> integer and fractional parts. >> >> If this is going to be a generic and future proof API, then my suggestion >> would be to increase the precision of the underlying data type. > > We discussed this a bit more internally and figured it would be nice to have > the same > fixed point for both CSC matrix and LUT/gamma tables. Current consensus > seems to be to go with 8.24 for both. Since LUTs are fairly big I think it > makes sense if we try to be not too wasteful (while still future-proof > ofc). The .24 should have enough precision, but I am worried about the 8: while this works for 8 bit components, you can't use it to represent values >255, which might be needed (now or in the future) for 10, 12 or 16 bit color components. It's why I ended up with 32.32: it's very generic so usable for other things besides CSC. Note that 8.24 is really 7.24 + one sign bit. So 255 can't be represented in this format. That said, all values I'm working with in my current code are small integers (say between -4 and 4 worst case), so 8.24 would work. But I am not at all confident that this is future proof. My gut feeling is that you need to be able to represent at least the max component value + a sign bit + 7 decimals precision. Which makes 17.24. Regards, Hans > > But yeah agreeing on the underlying layout would be good so that we could > share in-kernel code. We're aiming to not have any LUT interpolation in > the kernel (just dropping samples at most if e.g. the hw table doesn't > have linear sample positions). But with the LUT we might need to mutliply > it with an in-kernel one (we need the CSC unit on some platforms to > compress the color output range for hdmi). And maybe compress the LUTs > too. > -Daniel > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 09/20] drm/i915: Fill in more crtc state, v2.
On Mon, Jul 13, 2015 at 11:32:09AM +0200, Maarten Lankhorst wrote: > Op 07-07-15 om 12:28 schreef Daniel Vetter: > > On Tue, Jul 07, 2015 at 09:08:20AM +0200, Maarten Lankhorst wrote: > >> Perform a full readout of the state by making sure the mode is set > >> up correctly atomically. > >> > >> Also there was a small memory leak by doing the memset, fix this > >> by calling __drm_atomic_helper_crtc_destroy_state first. > >> > >> Changes since v1: > >> - Moved after reworking primary plane and updating mode members. > >> - Force a modeset calculation by changing mode->type from what the > >> final mode will be. > >> > >> Signed-off-by: Maarten Lankhorst > > tbh I don't really like mode_from_pipe_config since it goes in reverse. > > With the adjust mode of config_compare we can compare different final hw > > states and make a call whether they match enough for modeset avoidance or > > not. mode_from_pipe_config otoh is a lie on panels where we can do > > upscaling, hence I'd like to remove it to avoid confusion. > What do you want the initial mode to be then? > > You need to fill in some mode to satisfy drm_atomic_crtc_check. All zeros? That would make it clear that we have a mode, and that we also have no idea really what it is ... Otoh I think you've convinced me now that we indeed do need a real mode object here to avoid other troubles (i.e. the entire discussion around initial fbcon modesets). Given that I'd guess even the slightly wrong fill_in_modes here with the change to set DRIVER_MODE would be ok. As long as we can guarantee that we'll get a full modeset eventually we should be fine I hope. -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
Re: [Intel-gfx] [PATCH v2] drm/i915: Don't forget to mark crtc as inactive after disable
On Mon, Jul 13, 2015 at 11:10:51AM +0200, Maarten Lankhorst wrote: > Op 10-07-15 om 13:22 schreef Damien Lespiau: > > Hi Patrik, > > > > Please do Cc the patch author and reviewer when finding a regression, > > they are superb candidates for the review, especially when they are busy > > rewriting the display code. Yeah you need to list everyone you want to Cc: explicitly. > > On Wed, Jul 08, 2015 at 03:31:52PM +0200, Patrik Jakobsson wrote: > >> Watermark calculations depend on the intel_crtc->active flag to be set > >> properly. Suspend/resume is broken on SKL and we also get DDB mismatches > >> without this patch. > >> > >> The regression was introduced in: > >> > >> commit eddfcbcdc27fbecb33bff098967bbdd7ca75bfa6 > >> Author: Maarten Lankhorst > >> Date: Mon Jun 15 12:33:53 2015 +0200 > >> > >> drm/i915: Update less state during modeset. > >> > >> No need to repeatedly call update_watermarks, or update_fbc. > >> Down to a single call to update_watermarks in .crtc_enable > >> > >> Signed-off-by: Maarten Lankhorst > >> Reviewed-by: Matt Roper > >> Tested-by(IVB): Matt Roper > >> Signed-off-by: Daniel Vetter > >> > >> v2: Don't touch disable_shared_dpll() > >> > >> Signed-off-by: Patrik Jakobsson > > We do need to update the watermarks in disable() as well, to repartition > > the DDB and update the watermarks based on the new allocation. > > > > Maarten, Matt, I've no clue where you want the crtc state update, where > > the atomic WM work is at, could you comment? > > > I'd rather have we had a better way of updating watermarks, but keeping it in > the .crtc_disable hook looks good to me right now. Some proper atomic > solution will eventually have to be done. :) > > Reviewed-by: Maarten Lankhorst Queued for -next, thanks for the patch. -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
Re: [Intel-gfx] [PATCH v2 02/20] drm: Don't update plane properties for atomic planes if it stays the same
Op 13-07-15 om 11:45 schreef Daniel Vetter:
> On Mon, Jul 13, 2015 at 11:23:45AM +0200, Maarten Lankhorst wrote:
>> Op 13-07-15 om 11:13 schreef Daniel Vetter:
>>> On Mon, Jul 13, 2015 at 10:59:32AM +0200, Maarten Lankhorst wrote:
Op 08-07-15 om 22:12 schreef Daniel Vetter:
> On Wed, Jul 08, 2015 at 08:25:07PM +0200, Maarten Lankhorst wrote:
>> Op 08-07-15 om 19:52 schreef Daniel Vetter:
>>> On Wed, Jul 08, 2015 at 06:35:47PM +0200, Maarten Lankhorst wrote:
Op 08-07-15 om 10:55 schreef Daniel Vetter:
> On Wed, Jul 08, 2015 at 10:00:22AM +0200, Maarten Lankhorst wrote:
>> Op 07-07-15 om 18:43 schreef Daniel Vetter:
>>> On Tue, Jul 07, 2015 at 05:08:34PM +0200, Maarten Lankhorst wrote:
Op 07-07-15 om 14:10 schreef Daniel Vetter:
> On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
>> Op 07-07-15 om 11:18 schreef Daniel Vetter:
>>> On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst
>>> wrote:
This allows the first atomic call during hw init to be a real
modeset,
which is useful for forcing a recalculation.
>>> fbcon is optional, you can't rely on anything being done in any
>>> specific
>>> way. What exactly do you need this for, what's the implications?
>> In the hw readout I noticed some warnings when I wasn't setting
>> any mode property in the readout.
>> I want the first function to be the modeset, so we have a sane
>> base to commit changes on.
>> Ideally this whole function would have a atomic counterpart
>> which does it in one go. :)
> Yeah. Otoh as soon as we have atomic modeset working we can
> replace all
> the legacy entry points with atomic helpers, and then even
> plane_disable
> will be a full atomic modeset.
>
> What did fall apart with just touching properties/planes now?
Also when i915 is fully atomic it calculates in
intel_modeset_compute_config
if a modeset is needed after the first atomic call. Right now
because
intel_modeset_compute_config is only called in set_config so this
works as expected.
Otherwise drm_plane_force_disable or rotate_0 will force a modeset,
and if the final mode is different this will introduce a double
modeset.
>>> For expensive properties (i.e. a no-op changes causes something
>>> that takes
>>> time like modeset or vblank wait) we need to make sure we filter
>>> them out
>>> in atomic_check. Yeah not quite there yet with pure atomic, but
>>> meanwhile
>>> the existing legacy set_prop functions should all filter out no-op
>>> changes
>>> themselves. If we don't do that for rotation then that's a bug.
>>>
>>> Same for disabling planes harder, that shouldn't take time.
>>> Especially
>>> since fbcon only force-disable non-primary plane, and for driver
>>> load
>>> that's the exact thing we already do in the driver anyway.
>> Something like this?
>> ---
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index a1d4e13f3908..2989232f4996 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -30,6 +30,7 @@
>> #include
>> #include
>> #include
>> +#include "drm_crtc_internal.h"
>> #include
>>
>> /**
>> @@ -1716,7 +1717,12 @@ drm_atomic_helper_crtc_set_property(struct
>> drm_crtc *crtc,
>> {
>> struct drm_atomic_state *state;
>> struct drm_crtc_state *crtc_state;
>> -int ret = 0;
>> +uint64_t retval;
>> +int ret;
>> +
>> +ret = drm_atomic_get_property(&crtc->base, property, &retval);
>> +if (!ret && val == retval)
>> +return 0;
>>
>> state = drm_atomic_state_alloc(crtc->dev);
>> if (!state)
>> @@ -1776,7 +1782,12 @@ drm_atomic_helper_plane_set_property(struct
>> drm_plane *plane,
>> {
>> struct drm_atomic_state *state;
>> struct drm_plane_state *plane_state;
>> -int ret = 0;
>> +uint64_t retval;
>> +int ret;
>> +
>> +ret = drm_atomic_get_property(&plane->base, property, &retval);
>> +if (!ret && val == retval)
>> +return 0;
>>
>> state = drm_atomic_state_alloc(plane->dev);
>> if (!stat
Re: [Intel-gfx] [PATCH i-g-t] lib/igt_gt.c : allow changes to stop_rings mode bits
Tim Gore Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ > -Original Message- > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel > Vetter > Sent: Monday, July 13, 2015 10:30 AM > To: Gore, Tim > Cc: intel-gfx@lists.freedesktop.org; Wood, Thomas > Subject: Re: [Intel-gfx] [PATCH i-g-t] lib/igt_gt.c : allow changes to > stop_rings > mode bits > > On Fri, Jul 10, 2015 at 02:06:06PM +0100, tim.g...@intel.com wrote: > > From: Tim Gore > > > > In function igt_set_stop_rings, the test > > igt_assert_f(flags == 0 || current == 0, .. > > > > will fail if we are trying to force a hang but the > > STOP_RINGS_ALLOW_BAN or STOP_RINGS_ALLOW_ERROR bit is set. > > With the introduction of per ring resets in the driver (in android) > > these bits do not get cleared to zero when an individual ring is > > reset. This causes subsequent attempt to cause a ring hang via this > > function to fail, leading to several igt tests failing (ie > > gem_reset_stats subtest ban-xxx etc). > > Fix tdr to reset these instead? > -Daniel > I could change tdr, but why. When the TDR handles a ring hang and resets the ring, why would it modify the flag that defines if the driver should ban a frequently hanging context? If we get rid of the stop_rings interface, as Chris Wilson suggested, we would still need to keep the STOP_RING_ALLOW_BAN/ALLOW_ERRORS bits in debugfs, but you would not expect to have to re-write these bits each time there is a ring reset. Tim > > So, modify this test to look only at the bits that are used to hang > > the gpu rings. > > > > Signed-off-by: Tim Gore > > --- > > lib/igt_gt.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/lib/igt_gt.c b/lib/igt_gt.c index 8e5e076..12c56fa 100644 > > --- a/lib/igt_gt.c > > +++ b/lib/igt_gt.c > > @@ -345,8 +345,8 @@ void igt_set_stop_rings(enum stop_ring_flags flags) > > STOP_RING_ALLOW_ERRORS)) == 0); > > > > current = igt_get_stop_rings(); > > - igt_assert_f(flags == 0 || current == 0, > > -"previous i915_ring_stop is still 0x%x\n", current); > > + igt_assert_f( (flags & STOP_RING_ALL) == 0 || (current & > STOP_RING_ALL) == 0, > > +"previous i915_ring_stop is still 0x%x\n", > > current); > > > > stop_rings_write(flags); > > current = igt_get_stop_rings(); > > -- > > 1.9.1 > > > > ___ > > 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 v2 00/10] Color Manager Implementation
On Mon, Jul 13, 2015 at 11:43:31AM +0200, Hans Verkuil wrote: > On 07/13/2015 11:18 AM, Daniel Vetter wrote: > > On Mon, Jul 13, 2015 at 10:29:32AM +0200, Hans Verkuil wrote: > >> On 06/15/2015 08:53 AM, Daniel Vetter wrote: > >>> On Tue, Jun 09, 2015 at 01:50:48PM +0100, Damien Lespiau wrote: > On Thu, Jun 04, 2015 at 07:12:31PM +0530, Kausal Malladi wrote: > > From: Kausal Malladi > > > > This patch set adds color manager implementation in drm/i915 layer. > > Color Manager is an extension in i915 driver to support color > > correction/enhancement. Various Intel platforms support several > > color correction capabilities. Color Manager provides abstraction > > of these properties and allows a user space UI agent to > > correct/enhance the display. > > So I did a first rough pass on the API itself. The big question that > isn't solved at the moment is: do we want to try to do generic KMS > properties for pre-LUT + matrix + post-LUT or not. "Generic" has 3 > levels: > > 1/ Generic for all KMS drivers > 2/ Generic for i915 supported platfoms > 3/ Specific to each platform > > At this point, I'm quite tempted to say we should give 1/ a shot. We > should be able to have pre-LUT + matrix + post-LUT on CRTC objects and > guarantee that, when the drivers expose such properties, user space can > at least give 8 bits LUT + 3x3 matrix + 8 bits LUT. > > It may be possible to use the "try" version of the atomic ioctl to > explore the space of possibilities from a generic user space to use > bigger LUTs as well. A HAL layer (which is already there in some but not > all OSes) would still be able to use those generic properties to load > "precision optimized" LUTs with some knowledge of the hardware. > >>> > >>> Yeah, imo 1/ should be doable. For the matrix we should be able to be > >>> fully generic with a 16.16 format. For gamma one option would be to have > >> > >> I know I am late replying, apologies for that. > >> > >> I've been working on CSC support for V4L2 as well (still work in progress) > >> and I would like to at least end up with the same low-level fixed point > >> format as DRM so we can share matrix/vector calculations. > >> > >> Based on my experiences I have concerns about the 16.16 format: the > >> precision > >> is quite low which can be a problem when such values are used in matrix > >> multiplications. > >> > >> In addition, while the precision may be sufficient for 8 bit color > >> component > >> values, I'm pretty sure it will be insufficient when dealing with 12 or 16 > >> bit > >> color components. > >> > >> In earlier versions of my CSC code I used a 12.20 format, but in the > >> latest I > >> switched to 32.32. This fits nicely in a u64 and it's easy to extract the > >> integer and fractional parts. > >> > >> If this is going to be a generic and future proof API, then my suggestion > >> would be to increase the precision of the underlying data type. > > > > We discussed this a bit more internally and figured it would be nice to > > have the same > > fixed point for both CSC matrix and LUT/gamma tables. Current consensus > > seems to be to go with 8.24 for both. Since LUTs are fairly big I think it > > makes sense if we try to be not too wasteful (while still future-proof > > ofc). > > The .24 should have enough precision, but I am worried about the 8: while > this works for 8 bit components, you can't use it to represent values > >255, which might be needed (now or in the future) for 10, 12 or 16 bit > color components. > > It's why I ended up with 32.32: it's very generic so usable for other > things besides CSC. > > Note that 8.24 is really 7.24 + one sign bit. So 255 can't be represented > in this format. > > That said, all values I'm working with in my current code are small integers > (say between -4 and 4 worst case), so 8.24 would work. But I am not at all > confident that this is future proof. My gut feeling is that you need to be > able to represent at least the max component value + a sign bit + 7 decimals > precision. Which makes 17.24. The idea is to steal from GL and always normalize everything to [0.0, 1.0], irrespective of the source color format. We need that in drm since if you blend together planes with different formats it's completely undefined which one you should pick. 8 bits of precision for values out of range should be enough ;-) Oh and we might need those since for CSC and at least some LUTs you can do this. It's probably needed if your destination color space is much smaller than the source and you need to expand it. Will result in some clamping ofc. -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] drm/i915: Fix noatomic crtc disabling, v2.
This fixes the breakage caused by commit eddfcbcdc27fbecb33bff098967bbdd7ca75bfa6 Author: Maarten Lankhorst Date: Mon Jun 15 12:33:53 2015 +0200 drm/i915: Update less state during modeset. No need to repeatedly call update_watermarks, or update_fbc. Down to a single call to update_watermarks in .crtc_enable Signed-off-by: Maarten Lankhorst Reviewed-by: Matt Roper Tested-by(IVB): Matt Roper Signed-off-by: Daniel Vetter Add missing shared dpll disable to the noatomic disable function. This function will be replaced by its atomic counterpart soon. Changes since v1: - intel_crtc->active and watermarks are fixed by a patch from Patrik Jakobsson Signed-off-by: Maarten Lankhorst --- diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 80a08c701574..887ba0a54352 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -6184,6 +6184,7 @@ static void intel_crtc_disable_noatomic(struct drm_crtc *crtc) intel_crtc_disable_planes(crtc, crtc->state->plane_mask); dev_priv->display.crtc_disable(crtc); + intel_disable_shared_dpll(intel_crtc); domains = intel_crtc->enabled_power_domains; for_each_power_domain(domain, domains) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 02/20] drm: Don't update plane properties for atomic planes if it stays the same
On Mon, Jul 13, 2015 at 11:49:01AM +0200, Maarten Lankhorst wrote:
> Op 13-07-15 om 11:45 schreef Daniel Vetter:
> > On Mon, Jul 13, 2015 at 11:23:45AM +0200, Maarten Lankhorst wrote:
> >> Op 13-07-15 om 11:13 schreef Daniel Vetter:
> >>> On Mon, Jul 13, 2015 at 10:59:32AM +0200, Maarten Lankhorst wrote:
> Op 08-07-15 om 22:12 schreef Daniel Vetter:
> > On Wed, Jul 08, 2015 at 08:25:07PM +0200, Maarten Lankhorst wrote:
> >> Op 08-07-15 om 19:52 schreef Daniel Vetter:
> >>> On Wed, Jul 08, 2015 at 06:35:47PM +0200, Maarten Lankhorst wrote:
> Op 08-07-15 om 10:55 schreef Daniel Vetter:
> > On Wed, Jul 08, 2015 at 10:00:22AM +0200, Maarten Lankhorst wrote:
> >> Op 07-07-15 om 18:43 schreef Daniel Vetter:
> >>> On Tue, Jul 07, 2015 at 05:08:34PM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 14:10 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst
> > wrote:
> >> Op 07-07-15 om 11:18 schreef Daniel Vetter:
> >>> On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst
> >>> wrote:
> This allows the first atomic call during hw init to be a
> real modeset,
> which is useful for forcing a recalculation.
> >>> fbcon is optional, you can't rely on anything being done in
> >>> any specific
> >>> way. What exactly do you need this for, what's the
> >>> implications?
> >> In the hw readout I noticed some warnings when I wasn't
> >> setting any mode property in the readout.
> >> I want the first function to be the modeset, so we have a sane
> >> base to commit changes on.
> >> Ideally this whole function would have a atomic counterpart
> >> which does it in one go. :)
> > Yeah. Otoh as soon as we have atomic modeset working we can
> > replace all
> > the legacy entry points with atomic helpers, and then even
> > plane_disable
> > will be a full atomic modeset.
> >
> > What did fall apart with just touching properties/planes now?
> Also when i915 is fully atomic it calculates in
> intel_modeset_compute_config
> if a modeset is needed after the first atomic call. Right now
> because
> intel_modeset_compute_config is only called in set_config so
> this works as expected.
> Otherwise drm_plane_force_disable or rotate_0 will force a
> modeset,
> and if the final mode is different this will introduce a double
> modeset.
> >>> For expensive properties (i.e. a no-op changes causes something
> >>> that takes
> >>> time like modeset or vblank wait) we need to make sure we filter
> >>> them out
> >>> in atomic_check. Yeah not quite there yet with pure atomic, but
> >>> meanwhile
> >>> the existing legacy set_prop functions should all filter out
> >>> no-op changes
> >>> themselves. If we don't do that for rotation then that's a bug.
> >>>
> >>> Same for disabling planes harder, that shouldn't take time.
> >>> Especially
> >>> since fbcon only force-disable non-primary plane, and for driver
> >>> load
> >>> that's the exact thing we already do in the driver anyway.
> >> Something like this?
> >> ---
> >> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> >> b/drivers/gpu/drm/drm_atomic_helper.c
> >> index a1d4e13f3908..2989232f4996 100644
> >> --- a/drivers/gpu/drm/drm_atomic_helper.c
> >> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >> @@ -30,6 +30,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include "drm_crtc_internal.h"
> >> #include
> >>
> >> /**
> >> @@ -1716,7 +1717,12 @@ drm_atomic_helper_crtc_set_property(struct
> >> drm_crtc *crtc,
> >> {
> >>struct drm_atomic_state *state;
> >>struct drm_crtc_state *crtc_state;
> >> - int ret = 0;
> >> + uint64_t retval;
> >> + int ret;
> >> +
> >> + ret = drm_atomic_get_property(&crtc->base, property, &retval);
> >> + if (!ret && val == retval)
> >> + return 0;
> >>
> >>state = drm_atomic_state_alloc(crtc->dev);
> >>if (!state)
> >> @@ -1776,7 +1782,12 @@ drm_atomic_helper_plane_set_property(struct
> >> drm_plane *plane,
> >> {
> >>struct drm_atomic_state *state;
> >>struct drm_plane_state *plane_state;
> >> - int ret = 0;
> >> + uint64_t retval;
> >>
Re: [Intel-gfx] [PATCH i-g-t] tests/gem_reset_stats.c: fix "ban" tests with scheduler
Tim Gore
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Monday, July 13, 2015 10:35 AM
> To: Gore, Tim
> Cc: intel-gfx@lists.freedesktop.org; Wood, Thomas; Kuoppala, Mika
> Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/gem_reset_stats.c: fix "ban"
> tests
> with scheduler
>
> On Fri, Jul 10, 2015 at 02:26:59PM +0100, tim.g...@intel.com wrote:
> > From: Tim Gore
> >
> > The tests for context banning fail when the gpu scheduler is enabled.
> > The test causes a hang (using an infinite loop
> > batch) and then queues up some work behind it on both the hanging
> > context and also on a second "good" context. On the "good" context it
> > queues up 2 batch buffers. After the hanging ring has been reset (not
> > a full gpu reset) the test checks the values of batch_active and
> > batch_pending returned by the i915_get_reset_stats_ioctl. For the
> > "good"
> > context it expects to see batch_pending == 2, because two batch
> > buffers we queued up behind the hang on this context. But, with the
> > scheduler enabled (android, gen8), one of these batch buffers is still
> > waiting in the scheduler and has not made it as far as the
> > ring->request_list, so this batch buffer is unaffected by
> > the ring reset, and batch_pending is only 1.
> >
> > I considered putting in a test for the scheduler being enabled, but
> > decided that a simpler solution is to only queue up 1 batch buffer on
> > the good context. This does not change the test logic in any way and
> > ensures that we should always have batch_pending=1, with or without
> > the scheduler.
>
> For the scheduler/tdr we probably need to split this up into two testcases
> each:
> - one where the 2nd batch depends upon the first (cross-context depency).
> - one where the 2nd batch doesn't depend upon the first (should execute
> unhampered with scheduler/tdr).
>
> Since we don't yet have a scheduler/tdr both of these will result in the same
> outcome (since there's always the temporal depency). But with your patch
> you only test the 2nd case (and incompletely, we should assert that the 2nd
> batch did run) and ignore the first case.
>
> In short this failure here is telling you that your test coverage for these
> features is lacking. The correct fix is not to mangle the existing, but fix
> it up to
> correctly cover the new expectations in all cases. And that should be done as
> part of the tdr/scheduler submission.
> -Daniel
>
Should gem_rest_stats be testing the operation of the scheduler? I would have
thought that the scheduler operation should have its own test(s).
Gem_reset_stats
is just about the reset mechanism and the stats collected. I can add this test,
just
seems like the wrong place.
Tim
> >
> > Signed-off-by: Tim Gore
> > ---
> > tests/gem_reset_stats.c | 16 ++--
> > 1 file changed, 6 insertions(+), 10 deletions(-)
> >
> > diff --git a/tests/gem_reset_stats.c b/tests/gem_reset_stats.c index
> > 2bb4291..6529463 100644
> > --- a/tests/gem_reset_stats.c
> > +++ b/tests/gem_reset_stats.c
> > @@ -468,7 +468,7 @@ static void test_rs_ctx(int num_fds, int num_ctx,
> > int hang_index,
> >
> > static void test_ban(void)
> > {
> > - int h1,h2,h3,h4,h5,h6,h7;
> > + int h1,h2,h3,h4,h5,h6;
> > int fd_bad, fd_good;
> > int retry = 10;
> > int active_count = 0, pending_count = 0; @@ -496,7 +496,6 @@ static
> > void test_ban(void)
> > pending_count++;
> >
> > h6 = exec_valid(fd_good, 0);
> > - h7 = exec_valid(fd_good, 0);
> >
> > while (retry--) {
> > h3 = inject_hang_no_ban_error(fd_bad, 0); @@ -525,7
> > +524,7 @@ static void test_ban(void)
> > igt_assert_eq(h4, -EIO);
> > assert_reset_status(fd_bad, 0, RS_BATCH_ACTIVE);
> >
> > - gem_sync(fd_good, h7);
> > + gem_sync(fd_good, h6);
> > assert_reset_status(fd_good, 0, RS_BATCH_PENDING);
> >
> > igt_assert_eq(gem_reset_stats(fd_good, 0, &rs_good), 0); @@ -
> 534,12
> > +533,11 @@ static void test_ban(void)
> > igt_assert(rs_bad.batch_active == active_count);
> > igt_assert(rs_bad.batch_pending == pending_count);
> > igt_assert(rs_good.batch_active == 0);
> > - igt_assert(rs_good.batch_pending == 2);
> > + igt_assert(rs_good.batch_pending == 1);
> >
> > gem_close(fd_bad, h1);
> > gem_close(fd_bad, h2);
> > gem_close(fd_good, h6);
> > - gem_close(fd_good, h7);
> >
> > h1 = exec_valid(fd_good, 0);
> > igt_assert_lte(0, h1);
> > @@ -554,7 +552,7 @@ static void test_ban(void)
> >
> > static void test_ban_ctx(void)
> > {
> > - int h1,h2,h3,h4,h5,h6,h7;
> > + int h1,h2,h3,h4,h5,h6;
> > int ctx_good, ctx_bad;
> > int fd;
> > int retry = 10;
> > @@ -587,7 +585,6 @@ static void test_ban_ctx(void)
> > pending_count++;
> >
> > h6 = exec_valid(fd, ctx_good);
> > - h7 = exec_valid(fd, ctx_good);
> >
> >
Re: [Intel-gfx] [PATCH v2 00/10] Color Manager Implementation
On 07/13/2015 11:54 AM, Daniel Vetter wrote: > On Mon, Jul 13, 2015 at 11:43:31AM +0200, Hans Verkuil wrote: >> On 07/13/2015 11:18 AM, Daniel Vetter wrote: >>> On Mon, Jul 13, 2015 at 10:29:32AM +0200, Hans Verkuil wrote: On 06/15/2015 08:53 AM, Daniel Vetter wrote: > On Tue, Jun 09, 2015 at 01:50:48PM +0100, Damien Lespiau wrote: >> On Thu, Jun 04, 2015 at 07:12:31PM +0530, Kausal Malladi wrote: >>> From: Kausal Malladi >>> >>> This patch set adds color manager implementation in drm/i915 layer. >>> Color Manager is an extension in i915 driver to support color >>> correction/enhancement. Various Intel platforms support several >>> color correction capabilities. Color Manager provides abstraction >>> of these properties and allows a user space UI agent to >>> correct/enhance the display. >> >> So I did a first rough pass on the API itself. The big question that >> isn't solved at the moment is: do we want to try to do generic KMS >> properties for pre-LUT + matrix + post-LUT or not. "Generic" has 3 >> levels: >> >> 1/ Generic for all KMS drivers >> 2/ Generic for i915 supported platfoms >> 3/ Specific to each platform >> >> At this point, I'm quite tempted to say we should give 1/ a shot. We >> should be able to have pre-LUT + matrix + post-LUT on CRTC objects and >> guarantee that, when the drivers expose such properties, user space can >> at least give 8 bits LUT + 3x3 matrix + 8 bits LUT. >> >> It may be possible to use the "try" version of the atomic ioctl to >> explore the space of possibilities from a generic user space to use >> bigger LUTs as well. A HAL layer (which is already there in some but not >> all OSes) would still be able to use those generic properties to load >> "precision optimized" LUTs with some knowledge of the hardware. > > Yeah, imo 1/ should be doable. For the matrix we should be able to be > fully generic with a 16.16 format. For gamma one option would be to have I know I am late replying, apologies for that. I've been working on CSC support for V4L2 as well (still work in progress) and I would like to at least end up with the same low-level fixed point format as DRM so we can share matrix/vector calculations. Based on my experiences I have concerns about the 16.16 format: the precision is quite low which can be a problem when such values are used in matrix multiplications. In addition, while the precision may be sufficient for 8 bit color component values, I'm pretty sure it will be insufficient when dealing with 12 or 16 bit color components. In earlier versions of my CSC code I used a 12.20 format, but in the latest I switched to 32.32. This fits nicely in a u64 and it's easy to extract the integer and fractional parts. If this is going to be a generic and future proof API, then my suggestion would be to increase the precision of the underlying data type. >>> >>> We discussed this a bit more internally and figured it would be nice to >>> have the same >>> fixed point for both CSC matrix and LUT/gamma tables. Current consensus >>> seems to be to go with 8.24 for both. Since LUTs are fairly big I think it >>> makes sense if we try to be not too wasteful (while still future-proof >>> ofc). >> >> The .24 should have enough precision, but I am worried about the 8: while >> this works for 8 bit components, you can't use it to represent values >>> 255, which might be needed (now or in the future) for 10, 12 or 16 bit >> color components. >> >> It's why I ended up with 32.32: it's very generic so usable for other >> things besides CSC. >> >> Note that 8.24 is really 7.24 + one sign bit. So 255 can't be represented >> in this format. >> >> That said, all values I'm working with in my current code are small integers >> (say between -4 and 4 worst case), so 8.24 would work. But I am not at all >> confident that this is future proof. My gut feeling is that you need to be >> able to represent at least the max component value + a sign bit + 7 decimals >> precision. Which makes 17.24. > > The idea is to steal from GL and always normalize everything to [0.0, > 1.0], irrespective of the source color format. We need that in drm since > if you blend together planes with different formats it's completely > undefined which one you should pick. 8 bits of precision for values out of > range should be enough ;-) That doesn't really help much, using a [0-1] range just means that you need more precision for the fraction since the integer precision is now added to the fractional precision. So for 16-bit color components the 8.24 format will leave you with only 8 bits precision if you scale each component to the [0-1] range. That's slightly more than 2 decimals. I don't believe that is enough. If you do a gamma table lookup and
Re: [Intel-gfx] [RFC 0/2] Add Pooled EU support
Arun Siluvery writes: > These patches enabled Pooled EU support for BXT, they are implemented > by Armin Reese. I am sending these patches in its current form for comments. > > These patches modify Golden batch to have a set of modification values > where we can change the commands based on Gen. The commands to enable > Pooled EU are inserted after MI_BATCH_BUFFER_END. If the given Gen > supports this feature, modification values are used to replace > MI_BATCH_BUFFER_END so we send commands to enable Pooled EU. These > commands need to be part of this batch because they are to be > initialized only once. Userspace will have option to query the > availability of this feature, those changes are not included in > this series. > > I would like to upstream this feature and really appreciate any > comments in this regard. > Latest command stream programming guide has this to say in context initialization: "Render CS Only: Render state need not be initialized" If it is so that we get a proper render state from hw, with 'Restore Inhibit', then we can get rid of golden context for skl+. -Mika > Armin Reese (2): > drm/i915: Offsets for golden context BB modification > drm/i915/bxt: Enable pooled EUs for BXT > > drivers/gpu/drm/i915/i915_gem_render_state.c | 125 > +- > drivers/gpu/drm/i915/i915_gem_render_state.h | 7 ++ > drivers/gpu/drm/i915/intel_renderstate.h | 6 +- > drivers/gpu/drm/i915/intel_renderstate_gen6.c | 4 + > drivers/gpu/drm/i915/intel_renderstate_gen7.c | 4 + > drivers/gpu/drm/i915/intel_renderstate_gen8.c | 4 + > drivers/gpu/drm/i915/intel_renderstate_gen9.c | 18 ++-- > 7 files changed, 157 insertions(+), 11 deletions(-) > > -- > 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 5/9] drm/i915: Clear out DPLL state from pipe config in DSI get config
On 7/13/2015 2:21 PM, Daniel Vetter wrote:
On Fri, Jul 10, 2015 at 05:37:07PM +0530, Sivakumar Thulasimani wrote:
On 7/1/2015 6:12 PM, Daniel Vetter wrote:
On Tue, Jun 30, 2015 at 02:50:33PM +0300, Ville Syrjälä wrote:
On Tue, Jun 30, 2015 at 12:13:37PM +0200, Daniel Vetter wrote:
On Mon, Jun 29, 2015 at 08:08:27PM +0300, Ville Syrjälä wrote:
On Mon, Jun 29, 2015 at 07:56:05PM +0300, Ville Syrjälä wrote:
On Mon, Jun 29, 2015 at 06:42:11PM +0200, Daniel Vetter wrote:
On Mon, Jun 29, 2015 at 03:25:52PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
VLV/CHV don't use the DPLL with DSI, so just clear out the DPLL state
>from the pipe_config in intel_dsi_get_config(). This avoids spurious
state checker warnings. We already did it this way for DPLL_MD, but do
it for DPLL too.
Toss in a WARN to intel_dsi_pre_enable() to make sure the ref clocks
are enabled however. Supposedly they have some meaning to DSI too.
We now keep the ref clocks always enabled while the disp2d well is
enabled.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dsi.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 36e2148..92bb252 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -421,18 +421,12 @@ static void intel_dsi_pre_enable(struct intel_encoder
*encoder)
/* Disable DPOunit clock gating, can stall pipe
* and we need DPLL REFA always enabled */
- tmp = I915_READ(DPLL(pipe));
- tmp |= DPLL_REF_CLK_ENABLE_VLV;
- I915_WRITE(DPLL(pipe), tmp);
-
- /* update the hw state for DPLL */
- intel_crtc->config->dpll_hw_state.dpll = DPLL_INTEGRATED_REF_CLK_VLV |
- DPLL_REF_CLK_ENABLE_VLV | DPLL_VGA_MODE_DIS;
-
tmp = I915_READ(DSPCLK_GATE_D);
tmp |= DPOUNIT_CLOCK_GATE_DISABLE;
I915_WRITE(DSPCLK_GATE_D, tmp);
+ WARN_ON((I915_READ(DPLL(pipe)) & DPLL_REF_CLK_ENABLE_VLV) == 0);
+
/* put device in ready state */
intel_dsi_device_ready(encoder);
@@ -635,9 +629,10 @@ static void intel_dsi_get_config(struct intel_encoder
*encoder,
DRM_DEBUG_KMS("\n");
/*
-* DPLL_MD is not used in case of DSI, reading will get some default
value
-* set dpll_md = 0
+* DPLL is not used in case of DSI, reading will getsome default value.
+* Clear the state to keep the state checker happy.
*/
+ pipe_config->dpll_hw_state.dpll = 0;
pipe_config->dpll_hw_state.dpll_md = 0;
State configs are supposed to be kzallocated. Needing this indicates a
pretty serious bug - I'd vote to instead also ditch the dpll_md line and
fix the offender.
There is no offender really. We read out the DPLL state before we know
which ports are active and hence can't tell at that point if the
information is really relevant.
So the bios leaves the DPLL enabled even when using a DSI port? Or do we
miss to check some routing bits in get_clock?
Not necessarily enabled, but there are other bits in there that could be
left in any state basically. The DSI port simply doesn't care.
If the enable bit is what's gating things here then we should just forgo
reading out any dpll register state if that's not set. Looking at the
vlv/chv state readout code that seems to be the trouble - there's nothing
guarding the register reads into the pipe_config at all. Didn't matter
pre-vlv without dsi since enable pipe should imply enabled dpll, but
obviously won't work correctly with dsi. Can you please spin such a patch
and remove the hacks here from dsi_get_config?
-Daniel
Not sure i understand the point of contention here, just noticed this after
i gave my RB :)
so my justification on why this is proper is that DSI is not supposed to
touch DPLL register
any place we access dpll_hw_state.dpll is under !is_dsi check so that
ensures that we dont
program DPLL register for dsi panel. it was wrong to have originally modfied
DPLL register
inside intel_dsi_pre_enable so removal is fine. setting it to zero in
intel_dsi_get_config
is of no impact since any place we write back the contents of dpll_hw_state
is past the
!is_dsi check is never consumed by anyone as long as the CRTC uses DSI.
Ok, let's try a patch. Does the below work y/n? I've merged the patches up
to this one to dinq meanwhile, but I'd really like to close this first. If
it works I can rebase this patch here myself. Diff below is based on
-nightly with the above patch, so if you want to test on top of it you
also have to remove the dpll = 0; line too ofc.
Thanks, Daniel
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a7482ab140e1..c770655f5612 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8079,6 +8079,10 @@ static bool i9xx_get_pipe_config(struct intel_crtc *crtc,
i9xx_get_pfit_config(crtc, pi
Re: [Intel-gfx] [PATCH v4 14/18] drm/i915: object size needs to be u64
On 7/8/2015 6:03 PM, Chris Wilson wrote: On Wed, Jul 08, 2015 at 05:42:17PM +0100, Michel Thierry wrote: WARN_ON(vma->node.size != obj->base.size) ? Feel free to get the casting right - I suck at implicit C integer conversion rules ... -Daniel Thanks, if there's no objections, I'll change it to: if (WARN_ON(vma->node.size != (u64)vma->obj->base.size)) return -ENODEV; Are we still talking about i915_vma_bind()? Then vma->node.size != vma->obj.base.size anyway. -Chris Right, it can be either obj->base.size, fence_size or view_size... ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/4] drm/i915/gen9: Add WaFlushCoherentL3CacheLinesAtContextSwitch workaround
In Indirect context w/a batch buffer,
+WaFlushCoherentL3CacheLinesAtContextSwitch:bdw
v2: address static checker warning where unsigned value was checked for
less than zero which is never true.
Reported-by: Dan Carpenter
Cc: Imre Deak
Signed-off-by: Arun Siluvery
---
drivers/gpu/drm/i915/intel_lrc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 6a0b128..7536682 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1253,6 +1253,7 @@ static int gen9_init_indirectctx_bb(struct
intel_engine_cs *ring,
uint32_t *const batch,
uint32_t *offset)
{
+ int ret;
struct drm_device *dev = ring->dev;
uint32_t index = wa_ctx_start(wa_ctx, *offset, CACHELINE_DWORDS);
@@ -1261,6 +1262,12 @@ static int gen9_init_indirectctx_bb(struct
intel_engine_cs *ring,
(IS_BROXTON(dev) && (INTEL_REVID(dev) == BXT_REVID_A0)))
wa_ctx_emit(batch, MI_ARB_ON_OFF | MI_ARB_DISABLE);
+ /* WaFlushCoherentL3CacheLinesAtContextSwitch:skl,bxt */
+ ret = gen8_emit_flush_coherentl3_wa(ring, batch, index);
+ if (ret < 0)
+ return ret;
+ index = ret;
+
/* Pad to end of cacheline */
while (index % CACHELINE_DWORDS)
wa_ctx_emit(batch, MI_NOOP);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Don't forget to mark crtc as inactive after disable
On Mon, Jul 13, 2015 at 11:49:49AM +0200, Daniel Vetter wrote: > On Mon, Jul 13, 2015 at 11:10:51AM +0200, Maarten Lankhorst wrote: > > Op 10-07-15 om 13:22 schreef Damien Lespiau: > > > Hi Patrik, > > > > > > Please do Cc the patch author and reviewer when finding a regression, > > > they are superb candidates for the review, especially when they are busy > > > rewriting the display code. > > Yeah you need to list everyone you want to Cc: explicitly. Also need the Bugzilla reference when fixing a bug. In this case: https://bugs.freedesktop.org/show_bug.cgi?id=91203 -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bxt: WA for swapped HPD pins in A stepping
On 7/13/2015 3:10 PM, Daniel Vetter wrote:
On Mon, Jul 13, 2015 at 02:10:09PM +0530, Sonika Jindal wrote:
As per bspec, on BXT A0/A1, sw needs to activate DDIA HPD logic
and interrupts to check the external panel connection.
And remove the redundant comment.
v2: Remove redundant IS_BROXTON check, Add comment about port C not
connected, and rephrase the commit message to include only what we
are doing here (Imre)
v3: Add comment about the WA, move 'hpd' initialization outside for
loop (Siva)
Also, remove few redundant comments from hpd handler (me)
Signed-off-by: Sonika Jindal
Can't we do this in two steps:
- Wire up port A hpd in a generic way.
- Add wa for bxt to use port A hpd in the various encoder setup functions
where we assign intel_encoder->hpd_pin.
Currently that switchover is spread all through low-level functions, which
makes this a bit confusion. Imo low-level code shouldn't treat hpd A as
anything but hpd A since that's just confusing. And we already have the
infrastructure for encoders to ask for any hpd pin they want really.
-Daniel
---
drivers/gpu/drm/i915/i915_irq.c | 46 ++-
1 file changed, 31 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a897f68..13cabca 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -88,7 +88,14 @@ static const u32 hpd_status_i915[HPD_NUM_PINS] = {
[HPD_PORT_D] = PORTD_HOTPLUG_INT_STATUS
};
-/* BXT hpd list */
+/*
+ * On BXT A0/A1, sw needs to activate DDIA HPD logic and interrupts to check
+ * the external panel connection. Port C is not connected on bxt A0/A1
+ */
+static const u32 hpd_bxt_a0[HPD_NUM_PINS] = {
+ [HPD_PORT_B] = BXT_DE_PORT_HP_DDIA
+};
+
static const u32 hpd_bxt[HPD_NUM_PINS] = {
[HPD_PORT_B] = BXT_DE_PORT_HP_DDIB,
[HPD_PORT_C] = BXT_DE_PORT_HP_DDIC
@@ -1967,6 +1974,7 @@ static void bxt_hpd_handler(struct drm_device *dev,
uint32_t iir_status)
struct drm_i915_private *dev_priv = dev->dev_private;
u32 hp_control, hp_trigger;
u32 pin_mask, long_mask;
+ const u32 *hpd;
/* Get the status */
hp_trigger = iir_status & BXT_DE_PORT_HOTPLUG_MASK;
@@ -1981,7 +1989,12 @@ static void bxt_hpd_handler(struct drm_device *dev,
uint32_t iir_status)
/* Clear sticky bits in hpd status */
I915_WRITE(BXT_HOTPLUG_CTL, hp_control);
- pch_get_hpd_pins(&pin_mask, &long_mask, hp_trigger, hp_control, hpd_bxt);
+ if (INTEL_REVID(dev) < BXT_REVID_B0)
+ hpd = hpd_bxt_a0;
+ else
+ hpd = hpd_bxt;
+
+ pch_get_hpd_pins(&pin_mask, &long_mask, hp_trigger, hp_control, hpd);
intel_hpd_irq_handler(dev, pin_mask, long_mask);
}
@@ -3021,31 +3034,34 @@ static void bxt_hpd_irq_setup(struct drm_device *dev)
struct intel_encoder *intel_encoder;
u32 hotplug_port = 0;
u32 hotplug_ctrl;
+ const u32 *hpd;
- /* Now, enable HPD */
- for_each_intel_encoder(dev, intel_encoder) {
+ if (INTEL_REVID(dev) < BXT_REVID_B0)
+ hpd = hpd_bxt_a0;
+ else
+ hpd = hpd_bxt;
+
+ for_each_intel_encoder(dev, intel_encoder)
if (dev_priv->hotplug.stats[intel_encoder->hpd_pin].state
== HPD_ENABLED)
- hotplug_port |= hpd_bxt[intel_encoder->hpd_pin];
- }
+ hotplug_port |= hpd[intel_encoder->hpd_pin];
- /* Mask all HPD control bits */
hotplug_ctrl = I915_READ(BXT_HOTPLUG_CTL) & ~BXT_HOTPLUG_CTL_MASK;
- /* Enable requested port in hotplug control */
/* TODO: implement (short) HPD support on port A */
- WARN_ON_ONCE(hotplug_port & BXT_DE_PORT_HP_DDIA);
- if (hotplug_port & BXT_DE_PORT_HP_DDIB)
- hotplug_ctrl |= BXT_DDIB_HPD_ENABLE;
- if (hotplug_port & BXT_DE_PORT_HP_DDIC)
- hotplug_ctrl |= BXT_DDIC_HPD_ENABLE;
+ if (INTEL_REVID(dev) < BXT_REVID_B0 && (hotplug_port &
BXT_DE_PORT_HP_DDIA))
+ hotplug_ctrl |= BXT_DDIA_HPD_ENABLE;
+ else {
+ if (hotplug_port & BXT_DE_PORT_HP_DDIB)
+ hotplug_ctrl |= BXT_DDIB_HPD_ENABLE;
+ if (hotplug_port & BXT_DE_PORT_HP_DDIC)
+ hotplug_ctrl |= BXT_DDIC_HPD_ENABLE;
+ }
I915_WRITE(BXT_HOTPLUG_CTL, hotplug_ctrl);
- /* Unmask DDI hotplug in IMR */
hotplug_ctrl = I915_READ(GEN8_DE_PORT_IMR) & ~hotplug_port;
I915_WRITE(GEN8_DE_PORT_IMR, hotplug_ctrl);
- /* Enable DDI hotplug in IER */
hotplug_ctrl = I915_READ(GEN8_DE_PORT_IER) | hotplug_port;
I915_WRITE(GEN8_DE_PORT_IER, hotplug_ctrl);
POSTING_READ(GEN8_DE_PORT_IER);
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo
[Intel-gfx] [PATCH] drm/i915: Set edid from init and not from detect
During init_connector set the edid, then edid will be set/unset only during
hotplug. For the sake of older platforms where HPD is not stable, let edid
read happen from detect as well only if it is forced to do so.
v2: Removing the 'force' check, instead let detect call read the edid for
platforms older than gen 7 (Shashank)
Signed-off-by: Sonika Jindal
---
drivers/gpu/drm/i915/intel_hdmi.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 66af388..44e7160 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1399,6 +1399,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool
force)
enum drm_connector_status status;
struct intel_connector *intel_connector =
to_intel_connector(connector);
+ struct drm_device *dev = connector->dev;
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
connector->base.id, connector->name);
@@ -1412,7 +1413,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool
force)
* based on availability of cached EDID. This will avoid many of
* these race conditions and timing problems.
*/
- if (force)
+ if (INTEL_INFO(dev)->gen < 7)
intel_hdmi_probe(intel_connector->encoder);
if (intel_connector->detect_edid) {
@@ -2070,6 +2071,9 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
drm_connector_register(connector);
intel_hdmi->attached_connector = intel_connector;
+ /* Set edid during init */
+ intel_hdmi_probe(intel_encoder);
+
/* For G4X desktop chip, PEG_BAND_GAP_DATA 3:0 must first be written
* 0xd. Failure to do so will result in spurious interrupts being
* generated on the port when a cable is not attached.
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Check live status before reading edid
Adding this for SKL onwards.
v2: Adding checks for VLV/CHV as well. Reusing old ibx and g4x functions
to check digital port status. Adding a separate function to get bxt live
status (Daniel)
Signed-off-by: Sonika Jindal
---
drivers/gpu/drm/i915/intel_dp.c |4 ++--
drivers/gpu/drm/i915/intel_drv.h |2 ++
drivers/gpu/drm/i915/intel_hdmi.c | 42 +
3 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4ebfc3a..7b54b9d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4443,8 +4443,8 @@ ironlake_dp_detect(struct intel_dp *intel_dp)
return intel_dp_detect_dpcd(intel_dp);
}
-static int g4x_digital_port_connected(struct drm_device *dev,
- struct intel_digital_port
*intel_dig_port)
+int g4x_digital_port_connected(struct drm_device *dev,
+ struct intel_digital_port *intel_dig_port)
{
struct drm_i915_private *dev_priv = dev->dev_private;
uint32_t bit;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a47fbc3..30c8dd6 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1187,6 +1187,8 @@ void intel_edp_drrs_disable(struct intel_dp *intel_dp);
void intel_edp_drrs_invalidate(struct drm_device *dev,
unsigned frontbuffer_bits);
void intel_edp_drrs_flush(struct drm_device *dev, unsigned frontbuffer_bits);
+int g4x_digital_port_connected(struct drm_device *dev,
+ struct intel_digital_port *intel_dig_port);
/* intel_dp_mst.c */
int intel_dp_mst_encoder_init(struct intel_digital_port *intel_dig_port, int
conn_id);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 1fb6919..7eb0d0e 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1300,6 +1300,39 @@ intel_hdmi_unset_edid(struct drm_connector *connector)
to_intel_connector(connector)->detect_edid = NULL;
}
+static bool bxt_port_connected(struct drm_i915_private *dev_priv,
+ struct intel_digital_port *port)
+{
+ u32 temp = I915_READ(GEN8_DE_PORT_ISR);
+
+ switch (port->port) {
+ case PORT_B:
+ return temp & BXT_DE_PORT_HP_DDIB;
+
+ case PORT_C:
+ return temp & BXT_DE_PORT_HP_DDIC;
+
+ default:
+ return false;
+
+ }
+}
+
+static bool intel_hdmi_live_status(struct intel_digital_port *intel_dig_port)
+{
+ struct drm_device *dev = intel_dig_port->base.base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+
+ if (IS_VALLEYVIEW(dev))
+ return g4x_digital_port_connected(dev, intel_dig_port);
+ else if (IS_SKYLAKE(dev))
+ return ibx_digital_port_connected(dev_priv, intel_dig_port);
+ else if (IS_BROXTON(dev))
+ return bxt_port_connected(dev_priv, intel_dig_port);
+
+ return true;
+}
+
static bool
intel_hdmi_set_edid(struct drm_connector *connector)
{
@@ -1308,15 +1341,16 @@ intel_hdmi_set_edid(struct drm_connector *connector)
struct intel_encoder *intel_encoder =
&hdmi_to_dig_port(intel_hdmi)->base;
enum intel_display_power_domain power_domain;
- struct edid *edid;
+ struct edid *edid = NULL;
bool connected = false;
power_domain = intel_display_port_power_domain(intel_encoder);
intel_display_power_get(dev_priv, power_domain);
- edid = drm_get_edid(connector,
- intel_gmbus_get_adapter(dev_priv,
- intel_hdmi->ddc_bus));
+ if (intel_hdmi_live_status(hdmi_to_dig_port(intel_hdmi)))
+ edid = drm_get_edid(connector,
+ intel_gmbus_get_adapter(dev_priv,
+ intel_hdmi->ddc_bus));
intel_display_power_put(dev_priv, power_domain);
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Set edid from init and not from detect
On Mon, Jul 13, 2015 at 04:19:15PM +0530, Sonika Jindal wrote: > During init_connector set the edid, then edid will be set/unset only during > hotplug. For the sake of older platforms where HPD is not stable, let edid > read happen from detect as well only if it is forced to do so. > > v2: Removing the 'force' check, instead let detect call read the edid for > platforms older than gen 7 (Shashank) That's enough worse. We now have a random gen check with no rationale for why you suddenly believe all manufacturers have fixed their wiring. There is no reason to believe that gen7 suddenly works is there? If there is, why don't you mention it? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [drm-intel:topic/drm-misc 35/36] drivers/gpu/drm/virtio/virtgpu_drm_bus.c:55:2: error: implicit declaration of function 'drm_fb_helper_remove_conflicting_framebuffers'
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc head: 6198447760ed3c684fbcc93b5f91b4e84861e8f3 commit: 7bd870e7b1c8b4ff0b1624778d9ab17bfe6b903d [35/36] drm/virtio: Use new drm_fb_helper functions config: x86_64-randconfig-i0-201528 (attached as .config) reproduce: git checkout 7bd870e7b1c8b4ff0b1624778d9ab17bfe6b903d # save the attached .config to linux build tree make ARCH=x86_64 All error/warnings (new ones prefixed by >>): drivers/gpu/drm/virtio/virtgpu_drm_bus.c: In function 'virtio_pci_kick_out_firmware_fb': >> drivers/gpu/drm/virtio/virtgpu_drm_bus.c:55:2: error: implicit declaration >> of function 'drm_fb_helper_remove_conflicting_framebuffers' >> [-Werror=implicit-function-declaration] drm_fb_helper_remove_conflicting_framebuffers(ap, "virtiodrmfb", ^ cc1: some warnings being treated as errors -- drivers/gpu/drm/virtio/virtgpu_fb.c: In function 'virtio_gpufb_create': >> drivers/gpu/drm/virtio/virtgpu_fb.c:233:17: warning: unused variable >> 'device' [-Wunused-variable] struct device *device = vgdev->dev; ^ drivers/gpu/drm/virtio/virtgpu_fb.c: In function 'virtio_gpu_fbdev_destroy': >> drivers/gpu/drm/virtio/virtgpu_fb.c:365:18: warning: unused variable 'info' >> [-Wunused-variable] struct fb_info *info; ^ vim +/drm_fb_helper_remove_conflicting_framebuffers +55 drivers/gpu/drm/virtio/virtgpu_drm_bus.c 50cb941a Gerd Hoffmann 2015-03-26 49 ap->ranges[0].base = pci_resource_start(pci_dev, 0); 50cb941a Gerd Hoffmann 2015-03-26 50 ap->ranges[0].size = pci_resource_len(pci_dev, 0); 50cb941a Gerd Hoffmann 2015-03-26 51 50cb941a Gerd Hoffmann 2015-03-26 52 primary = pci_dev->resource[PCI_ROM_RESOURCE].flags 50cb941a Gerd Hoffmann 2015-03-26 53 & IORESOURCE_ROM_SHADOW; 50cb941a Gerd Hoffmann 2015-03-26 54 7bd870e7 Archit Taneja 2015-07-13 @55 drm_fb_helper_remove_conflicting_framebuffers(ap, "virtiodrmfb", 7bd870e7 Archit Taneja 2015-07-13 56 primary); 50cb941a Gerd Hoffmann 2015-03-26 57 50cb941a Gerd Hoffmann 2015-03-26 58 kfree(ap); --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation # # Automatically generated file; DO NOT EDIT. # Linux/x86_64 4.1.0-rc6 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_PERF_EVENTS_INTEL_UNCORE=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_64_SMP=y CONFIG_X86_HT=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11" CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_PGTABLE_LEVELS=4 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_BZIP2=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_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set CONFIG_KERNEL_XZ=y # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" # CONFIG_SYSVIPC is not set # CONFIG_POSIX_MQUEUE is not set CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=y CONFIG_USELIB=y CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_WATCH=y CONFIG_AUDIT_TREE=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_GENERIC_MSI_IRQ=y CONFIG_IRQ_DOMAIN_DEBUG=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONF
Re: [Intel-gfx] [PATCH] drm/i915: Set edid from init and not from detect
On 7/13/2015 5:10 PM, Chris Wilson wrote: On Mon, Jul 13, 2015 at 04:19:15PM +0530, Sonika Jindal wrote: During init_connector set the edid, then edid will be set/unset only during hotplug. For the sake of older platforms where HPD is not stable, let edid read happen from detect as well only if it is forced to do so. v2: Removing the 'force' check, instead let detect call read the edid for platforms older than gen 7 (Shashank) That's enough worse. We now have a random gen check with no rationale for why you suddenly believe all manufacturers have fixed their wiring. There is no reason to believe that gen7 suddenly works is there? If there is, why don't you mention it? -Chris This gen7 check is to be on the safer side not to affect older paltforms. For CHV/VLV, already the live status check is stable enough to determine if we can read edid or not. In VPG production branches we have this patch already available and it was tested with variety of monitors extensively. So we now read the edid only during init and during hotplug. For SKL, the "[PATCH] drm/i915: Handle HPD when it has actually occurred" patch makes HPD stable enough. So, we can rely on the edid read from init_connector instead of reading edid on every detect call. Regards, Sonika ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/2] drm/i915: avoid leaking DMA mappings
On la, 2015-07-11 at 21:54 +0100, Chris Wilson wrote:
> On Thu, Jul 09, 2015 at 12:59:05PM +0300, Imre Deak wrote:
> > +static int
> > +__i915_gem_userptr_set_pages(struct drm_i915_gem_object *obj,
> > +struct page **pvec, int num_pages)
> > +{
> > + int ret;
> > +
> > + ret = st_set_pages(&obj->pages, pvec, num_pages);
> > + if (ret)
> > + return ret;
> > +
> > + ret = i915_gem_gtt_prepare_object(obj);
> > + if (ret) {
> > + sg_free_table(obj->pages);
> > + kfree(obj->pages);
> > + obj->pages = NULL;
>
> Oh dear, we just leaked a ref one each page.
To summarize the IRC discussion on this: it would be logical that
sg_set_page() takes a ref - and in that case this would result in
leaking those refs - but this is not so. Instead we rely on the GUP refs
which we keep in case of success by setting pinned=0 (release_pages will
be a nop) and drop in case of failure by passing the original pinned
value to release_pages(). So after checking both the sync and async
userptr paths this looks ok to me.
--Imre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/4] drm/i915/gen9: Add WaDisableCtxRestoreArbitration workaround
Arun Siluvery writes:
> In Indirect and Per context w/a batch buffer,
> +WaDisableCtxRestoreArbitration
>
> v2: SKL revision id was used for BXT, copy paste error found during
> internal review (Bob Beckett).
>
> Cc: Robert Beckett
> Cc: Imre Deak
> Signed-off-by: Arun Siluvery
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 1e88b3b..e84fc52 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1274,10 +1274,13 @@ static int gen9_init_indirectctx_bb(struct
> intel_engine_cs *ring,
> uint32_t *const batch,
> uint32_t *offset)
> {
> + struct drm_device *dev = ring->dev;
> uint32_t index = wa_ctx_start(wa_ctx, *offset, CACHELINE_DWORDS);
>
> - /* FIXME: Replace me with WA */
> - wa_ctx_emit(batch, MI_NOOP);
> + /* WaDisableCtxRestoreArbitration:skl,bxt */
> + if ((IS_SKYLAKE(dev) && (INTEL_REVID(dev) <= SKL_REVID_D0)) ||
> + (IS_BROXTON(dev) && (INTEL_REVID(dev) == BXT_REVID_A0)))
> + wa_ctx_emit(batch, MI_ARB_ON_OFF | MI_ARB_DISABLE);
>
> /* Pad to end of cacheline */
> while (index % CACHELINE_DWORDS)
> @@ -1291,8 +1294,14 @@ static int gen9_init_perctx_bb(struct intel_engine_cs
> *ring,
> uint32_t *const batch,
> uint32_t *offset)
> {
> + struct drm_device *dev = ring->dev;
> uint32_t index = wa_ctx_start(wa_ctx, *offset, CACHELINE_DWORDS);
>
> + /* WaDisableCtxRestoreArbitration:skl,bxt */
> + if ((IS_SKYLAKE(dev) && (INTEL_REVID(dev) <= SKL_REVID_D0)) ||
> + (IS_BROXTON(dev) && (INTEL_REVID(dev) == BXT_REVID_A0)))
> + wa_ctx_emit(batch, MI_ARB_ON_OFF | MI_ARB_ENABLE);
> +
> wa_ctx_emit(batch, MI_BATCH_BUFFER_END);
>
> return wa_ctx_end(wa_ctx, *offset = index, 1);
> --
> 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
[Intel-gfx] [-next] WARNING at i915_gem_track_fb
4.2.0-rc2-next-20150713 [ 1239.783862] [ cut here ] [ 1239.783892] WARNING: CPU: 0 PID: 364 at drivers/gpu/drm/i915/i915_gem.c:5368 i915_gem_track_fb+0xdc/0x106 [i915]() [ 1239.783894] WARN_ON(new->frontbuffer_bits & frontbuffer_bits) [ 1239.783895] Modules linked in: [ 1239.783897] zram lz4_decompress lz4_compress lzo_compress lzo_decompress zsmalloc sha256_ssse3 sha256_generic hmac drbg ctr ccm mousedev arc4 nls_iso8859_1 nls_cp437 vfat fat coretemp hwmon iwlmvm i915 mac80211 cfbfillrect cfbimgblt intel_powerclamp i2c_algo_bit crc32c_intel iwlwifi i2c_i801 serio_raw cfbcopyarea psmouse drm_kms_helper ie31200_edac cfg80211 lpc_ich r8169 atkbd mfd_core mii thermal drm edac_core libps2 mxm_wmi wmi i8042 evdev video serio backlight processor ext4 crc16 mbcache jbd2 sd_mod ehci_pci ehci_hcd ahci libahci libata xhci_pci xhci_hcd scsi_mod usbcore usb_common [ 1239.783942] CPU: 0 PID: 364 Comm: Xorg Not tainted 4.2.0-rc2-next-20150713-dbg-00017-g16b87ed-dirty #183 [ 1239.783944] 0009 88041c5379d8 813a19ac 81077163 [ 1239.783947] 88041c537a28 88041c537a18 8103b5d9 88041c5379f8 [ 1239.783950] a0533273 0002 88041c578000 88041c578000 [ 1239.783953] Call Trace: [ 1239.783961] [] dump_stack+0x4c/0x65 [ 1239.783965] [] ? up+0x39/0x3e [ 1239.783968] [] warn_slowpath_common+0x9b/0xb5 [ 1239.783986] [] ? i915_gem_track_fb+0xdc/0x106 [i915] [ 1239.783987] [] warn_slowpath_fmt+0x46/0x48 [ 1239.784002] [] i915_gem_track_fb+0xdc/0x106 [i915] [ 1239.784026] [] intel_prepare_plane_fb+0xb1/0x101 [i915] [ 1239.784033] [] drm_atomic_helper_prepare_planes+0x5b/0xb8 [drm_kms_helper] [ 1239.784055] [] intel_atomic_commit+0x46/0xc0 [i915] [ 1239.784072] [] drm_atomic_commit+0x4d/0x52 [drm] [ 1239.784078] [] drm_atomic_helper_update_plane+0xca/0x119 [drm_kms_helper] [ 1239.784092] [] __setplane_internal+0x24e/0x2ae [drm] [ 1239.784103] [] drm_mode_cursor_universal+0x149/0x197 [drm] [ 1239.784113] [] ? drm_mode_setcrtc+0x428/0x428 [drm] [ 1239.784122] [] drm_mode_cursor_common+0xb5/0x156 [drm] [ 1239.784132] [] drm_mode_cursor_ioctl+0x37/0x39 [drm] [ 1239.784140] [] drm_ioctl+0x287/0x415 [drm] [ 1239.784143] [] ? __lock_is_held+0x3c/0x57 [ 1239.784146] [] ? __fget+0x170/0x1a1 [ 1239.784148] [] do_vfs_ioctl+0x455/0x4dd [ 1239.784151] [] ? __fget_light+0x65/0x75 [ 1239.784153] [] SyS_ioctl+0x44/0x63 [ 1239.784155] [] entry_SYSCALL_64_fastpath+0x12/0x6f [ 1239.784157] ---[ end trace 67b32b389e7fe7df ]--- -ss ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/4] drm/i915/gen9: Add WaFlushCoherentL3CacheLinesAtContextSwitch workaround
Arun Siluvery writes:
> In Indirect context w/a batch buffer,
> +WaFlushCoherentL3CacheLinesAtContextSwitch:bdw
s/bdw/skl ?
>
> v2: address static checker warning where unsigned value was checked for
> less than zero which is never true.
>
Add ^^ (Dan Carpenter)
> Reported-by: Dan Carpenter
And remove this line as this would mean the workaround/bug
in question would be reported by Dan.
> Cc: Imre Deak
> Signed-off-by: Arun Siluvery
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 6a0b128..7536682 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1253,6 +1253,7 @@ static int gen9_init_indirectctx_bb(struct
> intel_engine_cs *ring,
> uint32_t *const batch,
> uint32_t *offset)
> {
> + int ret;
> struct drm_device *dev = ring->dev;
> uint32_t index = wa_ctx_start(wa_ctx, *offset, CACHELINE_DWORDS);
>
> @@ -1261,6 +1262,12 @@ static int gen9_init_indirectctx_bb(struct
> intel_engine_cs *ring,
> (IS_BROXTON(dev) && (INTEL_REVID(dev) == BXT_REVID_A0)))
> wa_ctx_emit(batch, MI_ARB_ON_OFF | MI_ARB_DISABLE);
>
> + /* WaFlushCoherentL3CacheLinesAtContextSwitch:skl,bxt */
> + ret = gen8_emit_flush_coherentl3_wa(ring, batch, index);
Not shown in this patch but the above function assumes default
value for GEN8_L3SQCREG4 which doesn't match what we have by
default.
This is due to skl_init_clock_gating() setting up one bit
in this register.
I think the proper way to fix this would be remove the
write from skl_init_clock_gating() and setup all
the bits in this register, even the default ones with
WA_SET_BIT() in gen9_init_workarounds().
And then search the default value out from the wa list,
when you build the batch.
But if you choose to go with default skl value of
0x4840, make a comment to intel_pm.c and also
the gen8_emit_flush_coherentl3_wa() that you
have a dependency.
-Mika
> + if (ret < 0)
> + return ret;
> + index = ret;
> +
> /* Pad to end of cacheline */
> while (index % CACHELINE_DWORDS)
> wa_ctx_emit(batch, MI_NOOP);
> --
> 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 v2 4/4] drm/i915/gen9: Add WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken
Arun Siluvery writes:
> In Indirect context w/a batch buffer,
> +WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken
>
> v2: SKL revision id was used for BXT, copy paste error found during
> internal review (Bob Beckett).
>
> Cc: Robert Beckett
> Cc: Imre Deak
> Signed-off-by: Arun Siluvery
> ---
> drivers/gpu/drm/i915/intel_lrc.c| 9 +
> drivers/gpu/drm/i915/intel_ringbuffer.c | 7 +--
> 2 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 58247f0..61ed92b 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1302,6 +1302,15 @@ static int gen9_init_perctx_bb(struct intel_engine_cs
> *ring,
> struct drm_device *dev = ring->dev;
> uint32_t index = wa_ctx_start(wa_ctx, *offset, CACHELINE_DWORDS);
>
> + /* WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken:skl,bxt */
> + if ((IS_SKYLAKE(dev) && (INTEL_REVID(dev) <= SKL_REVID_B0)) ||
> + (IS_BROXTON(dev) && (INTEL_REVID(dev) == BXT_REVID_A0))) {
> + wa_ctx_emit(batch, MI_LOAD_REGISTER_IMM(1));
> + wa_ctx_emit(batch, GEN9_SLICE_COMMON_ECO_CHICKEN0);
> + wa_ctx_emit(batch,
> _MASKED_BIT_ENABLE(DISABLE_PIXEL_MASK_CAMMING));
> + wa_ctx_emit(batch, MI_NOOP);
> + }
> +
> /* WaDisableCtxRestoreArbitration:skl,bxt */
> if ((IS_SKYLAKE(dev) && (INTEL_REVID(dev) <= SKL_REVID_D0)) ||
> (IS_BROXTON(dev) && (INTEL_REVID(dev) == BXT_REVID_A0)))
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index af7c12e..66dde7f 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -946,8 +946,11 @@ static int gen9_init_workarounds(struct intel_engine_cs
> *ring)
> /*
> WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken:skl,bxt */
> WA_SET_BIT_MASKED(GEN7_COMMON_SLICE_CHICKEN1,
> GEN9_RHWO_OPTIMIZATION_DISABLE);
> - WA_SET_BIT_MASKED(GEN9_SLICE_COMMON_ECO_CHICKEN0,
> - DISABLE_PIXEL_MASK_CAMMING);
> + /*
> + * WA also requires GEN9_SLICE_COMMON_ECO_CHICKEN0[14] to be
> set,
> + * but that register is write only hence it is set
> + * in per ctx batch buffer
Why the need to move to per ctx bb? Why the write would not stick
with this? Is the rationale that we get fails with the gem_workarounds?
If so, perhaps we need a write_only marker for workaround list?
-Mika
> + */
> }
>
> if ((IS_SKYLAKE(dev) && INTEL_REVID(dev) >= SKL_REVID_C0) ||
> --
> 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 v2 00/10] Color Manager Implementation
On Mon, Jul 13, 2015 at 12:11:08PM +0200, Hans Verkuil wrote: > On 07/13/2015 11:54 AM, Daniel Vetter wrote: > > On Mon, Jul 13, 2015 at 11:43:31AM +0200, Hans Verkuil wrote: > >> On 07/13/2015 11:18 AM, Daniel Vetter wrote: > >>> On Mon, Jul 13, 2015 at 10:29:32AM +0200, Hans Verkuil wrote: > On 06/15/2015 08:53 AM, Daniel Vetter wrote: > > On Tue, Jun 09, 2015 at 01:50:48PM +0100, Damien Lespiau wrote: > >> On Thu, Jun 04, 2015 at 07:12:31PM +0530, Kausal Malladi wrote: > >>> From: Kausal Malladi > >>> > >>> This patch set adds color manager implementation in drm/i915 layer. > >>> Color Manager is an extension in i915 driver to support color > >>> correction/enhancement. Various Intel platforms support several > >>> color correction capabilities. Color Manager provides abstraction > >>> of these properties and allows a user space UI agent to > >>> correct/enhance the display. > >> > >> So I did a first rough pass on the API itself. The big question that > >> isn't solved at the moment is: do we want to try to do generic KMS > >> properties for pre-LUT + matrix + post-LUT or not. "Generic" has 3 > >> levels: > >> > >> 1/ Generic for all KMS drivers > >> 2/ Generic for i915 supported platfoms > >> 3/ Specific to each platform > >> > >> At this point, I'm quite tempted to say we should give 1/ a shot. We > >> should be able to have pre-LUT + matrix + post-LUT on CRTC objects and > >> guarantee that, when the drivers expose such properties, user space can > >> at least give 8 bits LUT + 3x3 matrix + 8 bits LUT. > >> > >> It may be possible to use the "try" version of the atomic ioctl to > >> explore the space of possibilities from a generic user space to use > >> bigger LUTs as well. A HAL layer (which is already there in some but > >> not > >> all OSes) would still be able to use those generic properties to load > >> "precision optimized" LUTs with some knowledge of the hardware. > > > > Yeah, imo 1/ should be doable. For the matrix we should be able to be > > fully generic with a 16.16 format. For gamma one option would be to have > > I know I am late replying, apologies for that. > > I've been working on CSC support for V4L2 as well (still work in > progress) > and I would like to at least end up with the same low-level fixed point > format as DRM so we can share matrix/vector calculations. > > Based on my experiences I have concerns about the 16.16 format: the > precision > is quite low which can be a problem when such values are used in matrix > multiplications. > > In addition, while the precision may be sufficient for 8 bit color > component > values, I'm pretty sure it will be insufficient when dealing with 12 or > 16 bit > color components. > > In earlier versions of my CSC code I used a 12.20 format, but in the > latest I > switched to 32.32. This fits nicely in a u64 and it's easy to extract the > integer and fractional parts. > > If this is going to be a generic and future proof API, then my suggestion > would be to increase the precision of the underlying data type. > >>> > >>> We discussed this a bit more internally and figured it would be nice to > >>> have the same > >>> fixed point for both CSC matrix and LUT/gamma tables. Current consensus > >>> seems to be to go with 8.24 for both. Since LUTs are fairly big I think it > >>> makes sense if we try to be not too wasteful (while still future-proof > >>> ofc). > >> > >> The .24 should have enough precision, but I am worried about the 8: while > >> this works for 8 bit components, you can't use it to represent values > >>> 255, which might be needed (now or in the future) for 10, 12 or 16 bit > >> color components. > >> > >> It's why I ended up with 32.32: it's very generic so usable for other > >> things besides CSC. > >> > >> Note that 8.24 is really 7.24 + one sign bit. So 255 can't be represented > >> in this format. > >> > >> That said, all values I'm working with in my current code are small > >> integers > >> (say between -4 and 4 worst case), so 8.24 would work. But I am not at all > >> confident that this is future proof. My gut feeling is that you need to be > >> able to represent at least the max component value + a sign bit + 7 > >> decimals > >> precision. Which makes 17.24. > > > > The idea is to steal from GL and always normalize everything to [0.0, > > 1.0], irrespective of the source color format. We need that in drm since > > if you blend together planes with different formats it's completely > > undefined which one you should pick. 8 bits of precision for values out of > > range should be enough ;-) > > That doesn't really help much, using a [0-1] range just means that you need > more precision for the fraction since the integer precision i
[Intel-gfx] [PATCH v3 01/20] drm/i915: Only update state on crtc's that are part of the atomic state.
This is probably hard to hit right now because in most cases all
atomic locks are taken, but after conversion to atomic this will make
it more likely to corrupt the crtc->config pointer, resulting in hard
to find bugs.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 887ba0a54352..f9b1db734502 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12314,6 +12314,7 @@ intel_modeset_update_state(struct drm_atomic_state
*state)
struct drm_crtc *crtc;
struct drm_crtc_state *crtc_state;
struct drm_connector *connector;
+ int i;
intel_shared_dpll_commit(state);
@@ -12333,7 +12334,7 @@ intel_modeset_update_state(struct drm_atomic_state
*state)
intel_modeset_update_staged_output_state(state->dev);
/* Double check state. */
- for_each_crtc(dev, crtc) {
+ for_each_crtc_in_state(state, crtc, crtc_state, i) {
WARN_ON(crtc->state->enable != intel_crtc_in_use(crtc));
to_intel_crtc(crtc)->config = to_intel_crtc_state(crtc->state);
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 08/20] drm/i915: fill in more mode members
Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 118187dc76be..d37f6a93b094 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -7754,9 +7754,14 @@ void intel_mode_from_pipe_config(struct drm_display_mode *mode, mode->vsync_end = pipe_config->base.adjusted_mode.crtc_vsync_end; mode->flags = pipe_config->base.adjusted_mode.flags; + mode->type = DRM_MODE_TYPE_DRIVER; mode->clock = pipe_config->base.adjusted_mode.crtc_clock; mode->flags |= pipe_config->base.adjusted_mode.flags; + + mode->hsync = drm_mode_hsync(mode); + mode->vrefresh = drm_mode_vrefresh(mode); + drm_mode_set_name(mode); } static void i9xx_set_pipeconf(struct intel_crtc *intel_crtc) -- 2.1.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 02/20] drm/i915: Do not update pfit state when toggling crtc enabled.
There's not much point for calculating the changes for the old
state. Instead just disable all scalers when disabling. It's
probably good enough to just disable the crtc_scaler, but just in
case there's a bug disable all scalers.
This means intel_atomic_setup_scalers is only called in the crtc
check function now, so all the transitional code can be removed.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_atomic.c | 14 ++--
drivers/gpu/drm/i915/intel_display.c | 68 +++-
drivers/gpu/drm/i915/intel_dp.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 2 +-
4 files changed, 48 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 5c79a31603af..b92b8581efc2 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -272,17 +272,12 @@ int intel_atomic_setup_scalers(struct drm_device *dev,
struct drm_plane *plane = NULL;
struct intel_plane *intel_plane;
struct intel_plane_state *plane_state = NULL;
- struct intel_crtc_scaler_state *scaler_state;
- struct drm_atomic_state *drm_state;
+ struct intel_crtc_scaler_state *scaler_state =
+ &crtc_state->scaler_state;
+ struct drm_atomic_state *drm_state = crtc_state->base.state;
int num_scalers_need;
int i, j;
- if (INTEL_INFO(dev)->gen < 9 || !intel_crtc || !crtc_state)
- return 0;
-
- scaler_state = &crtc_state->scaler_state;
- drm_state = crtc_state->base.state;
-
num_scalers_need = hweight32(scaler_state->scaler_users);
DRM_DEBUG_KMS("crtc_state = %p need = %d avail = %d scaler_users =
0x%x\n",
crtc_state, num_scalers_need, intel_crtc->num_scalers,
@@ -326,9 +321,6 @@ int intel_atomic_setup_scalers(struct drm_device *dev,
} else {
name = "PLANE";
- if (!drm_state)
- continue;
-
/* plane scaler case: assign as a plane scaler */
/* find the plane that set the bit as scaler_user */
plane = drm_state->planes[i];
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f9b1db734502..6eed925f3300 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2909,29 +2909,32 @@ unsigned long intel_plane_obj_offset(struct intel_plane
*intel_plane,
return i915_gem_obj_ggtt_offset_view(obj, view);
}
+static void skl_detach_scaler(struct intel_crtc *intel_crtc, int id)
+{
+ struct drm_device *dev = intel_crtc->base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ I915_WRITE(SKL_PS_CTRL(intel_crtc->pipe, id), 0);
+ I915_WRITE(SKL_PS_WIN_POS(intel_crtc->pipe, id), 0);
+ I915_WRITE(SKL_PS_WIN_SZ(intel_crtc->pipe, id), 0);
+ DRM_DEBUG_KMS("CRTC:%d Disabled scaler id %u.%u\n",
+ intel_crtc->base.base.id, intel_crtc->pipe, id);
+}
+
/*
* This function detaches (aka. unbinds) unused scalers in hardware
*/
static void skl_detach_scalers(struct intel_crtc *intel_crtc)
{
- struct drm_device *dev;
- struct drm_i915_private *dev_priv;
struct intel_crtc_scaler_state *scaler_state;
int i;
- dev = intel_crtc->base.dev;
- dev_priv = dev->dev_private;
scaler_state = &intel_crtc->config->scaler_state;
/* loop through and disable scalers that aren't in use */
for (i = 0; i < intel_crtc->num_scalers; i++) {
- if (!scaler_state->scalers[i].in_use) {
- I915_WRITE(SKL_PS_CTRL(intel_crtc->pipe, i), 0);
- I915_WRITE(SKL_PS_WIN_POS(intel_crtc->pipe, i), 0);
- I915_WRITE(SKL_PS_WIN_SZ(intel_crtc->pipe, i), 0);
- DRM_DEBUG_KMS("CRTC:%d Disabled scaler id %u.%u\n",
- intel_crtc->base.base.id, intel_crtc->pipe, i);
- }
+ if (!scaler_state->scalers[i].in_use)
+ skl_detach_scaler(intel_crtc, i);
}
}
@@ -4362,13 +4365,12 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
* skl_update_scaler_crtc - Stages update to scaler state for a given crtc.
*
* @state: crtc's scaler state
- * @force_detach: whether to forcibly disable scaler
*
* Return
* 0 - scaler_usage updated successfully
*error - requested scaling cannot be supported or other error condition
*/
-int skl_update_scaler_crtc(struct intel_crtc_state *state, int force_detach)
+int skl_update_scaler_crtc(struct intel_crtc_state *state)
{
struct intel_crtc *intel_crtc = to_intel_crtc(state->base.crtc);
struct drm_display_mode *adjusted_mode =
@@ -4377,7 +4379,7 @@ int skl_update_scaler_crtc(struct intel_crt
[Intel-gfx] [PATCH v3 11/20] drm/i915: Readout initial hw mode.
Atomic requires a mode blob when crtc_state->enable is true.
With a few tweaks the mode we read out from hardware could be used
as the real mode without a modeset, but this requires too much
testing, so force a modeset the first time the mode blob's updated.
This preserves the old behavior, because previously we never set
the initial mode, which always meant that a modeset happened
when the mode was first set.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 38
drivers/gpu/drm/i915/intel_fbdev.c | 11 +++
2 files changed, 20 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 80e878929bab..a4a2c3fbdc2d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13153,7 +13153,7 @@ intel_modeset_compute_config(struct drm_atomic_state
*state)
for_each_crtc_in_state(state, crtc, crtc_state, i) {
struct intel_crtc_state *pipe_config =
to_intel_crtc_state(crtc_state);
- bool modeset, recalc;
+ bool modeset, recalc = false;
if (!crtc_state->enable) {
if (needs_modeset(crtc_state))
@@ -13162,7 +13162,9 @@ intel_modeset_compute_config(struct drm_atomic_state
*state)
}
modeset = needs_modeset(crtc_state);
- recalc = pipe_config->quirks & PIPE_CONFIG_QUIRK_INHERITED_MODE;
+ if (!modeset && crtc_state->mode_blob != crtc->state->mode_blob
&&
+ pipe_config->quirks & PIPE_CONFIG_QUIRK_INHERITED_MODE)
+ recalc = true;
if (!modeset && !recalc)
continue;
@@ -13177,9 +13179,10 @@ intel_modeset_compute_config(struct drm_atomic_state
*state)
if (ret)
return ret;
- if (recalc && !intel_pipe_config_compare(state->dev,
+ if (recalc && (!i915.fastboot ||
+ !intel_pipe_config_compare(state->dev,
to_intel_crtc_state(crtc->state),
- pipe_config, true)) {
+ pipe_config, true))) {
modeset = crtc_state->mode_changed = true;
ret = drm_atomic_add_affected_planes(state, crtc);
@@ -15463,11 +15466,19 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
crtc->active = dev_priv->display.get_pipe_config(crtc,
crtc->config);
- crtc->base.state->enable = crtc->active;
crtc->base.state->active = crtc->active;
crtc->base.enabled = crtc->active;
- crtc->base.hwmode = crtc->config->base.adjusted_mode;
+ memset(&crtc->base.mode, 0, sizeof(crtc->base.mode));
+ if (crtc->base.state->active) {
+ intel_mode_from_pipe_config(&crtc->base.mode,
crtc->config);
+
intel_mode_from_pipe_config(&crtc->base.state->adjusted_mode, crtc->config);
+ WARN_ON(drm_atomic_set_mode_for_crtc(crtc->base.state,
&crtc->base.mode));
+
+ crtc->base.state->mode.type = 0;
+ }
+
+ 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",
@@ -15544,21 +1,6 @@ void intel_modeset_setup_hw_state(struct drm_device
*dev,
intel_modeset_readout_hw_state(dev);
- /*
-* Now that we have the config, copy it to each CRTC struct
-* Note that this could go away if we move to using crtc_config
-* checking everywhere.
-*/
- for_each_intel_crtc(dev, crtc) {
- if (crtc->active && i915.fastboot) {
- intel_mode_from_pipe_config(&crtc->base.mode,
- crtc->config);
- DRM_DEBUG_KMS("[CRTC:%d] found active mode: ",
- crtc->base.base.id);
- drm_mode_debug_printmodeline(&crtc->base.mode);
- }
- }
-
/* HW state is read out, now we need to sanitize this mess. */
for_each_intel_encoder(dev, encoder) {
intel_sanitize_encoder(encoder);
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index b791f2374f3b..7eff33ff84f6 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -483,18 +483,13 @@ retry:
* IMPORTANT: We want to use the adjusted mode (i.e.
* after the panel fitter
[Intel-gfx] [PATCH v3 04/20] drm/i915: Allow fuzzy matching in pipe_config_compare, v2.
Instead of doing ad-hoc checks we already have a way of checking
if the state is compatible or not. Use this to force a modeset.
Only during modesets, or with PIPE_CONFIG_QUIRK_INHERITED_MODE
we should check if a full modeset is really needed.
Fastboot will allow the adjust parameter to ignore some stuff
too, and it will fix up differences in state that are ignored
by the compare function.
Changes since v1:
- Increase the value of the lowest m/n to prevent truncation.
- Dump pipe config when fastboot's used, without a modeset.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 218 +--
1 file changed, 157 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6eed925f3300..c3a3d108 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12290,19 +12290,6 @@ encoder_retry:
DRM_DEBUG_KMS("plane bpp: %i, pipe bpp: %i, dithering: %i\n",
base_bpp, pipe_config->pipe_bpp, pipe_config->dither);
- /* Check if we need to force a modeset */
- if (pipe_config->has_audio !=
- to_intel_crtc_state(crtc->state)->has_audio) {
- pipe_config->base.mode_changed = true;
- ret = drm_atomic_add_affected_planes(state, crtc);
- }
-
- /*
-* Note we have an issue here with infoframes: current code
-* only updates them on the full mode set path per hw
-* requirements. So here we should be checking for any
-* required changes and forcing a mode set.
-*/
fail:
return ret;
}
@@ -12406,27 +12393,133 @@ static bool intel_fuzzy_clock_check(int clock1, int
clock2)
base.head) \
if (mask & (1 <<(intel_crtc)->pipe))
+
+static bool
+intel_compare_m_n(unsigned int m, unsigned int n,
+ unsigned int m2, unsigned int n2,
+ bool exact)
+{
+ if (m == m2 && n == n2)
+ return true;
+
+ if (exact || !m || !n || !m2 || !n2)
+ return false;
+
+ BUILD_BUG_ON(DATA_LINK_M_N_MASK > INT_MAX);
+
+ if (m > m2) {
+ while (m > m2) {
+ m2 <<= 1;
+ n2 <<= 1;
+ }
+ } else if (m < m2) {
+ while (m < m2) {
+ m <<= 1;
+ n <<= 1;
+ }
+ }
+
+ return m == m2 && n == n2;
+}
+
+static bool
+intel_compare_link_m_n(const struct intel_link_m_n *m_n,
+ struct intel_link_m_n *m2_n2,
+ bool adjust)
+{
+ if (m_n->tu == m2_n2->tu &&
+ intel_compare_m_n(m_n->gmch_m, m_n->gmch_n,
+ m2_n2->gmch_m, m2_n2->gmch_n, !adjust) &&
+ intel_compare_m_n(m_n->link_m, m_n->link_n,
+ m2_n2->link_m, m2_n2->link_n, !adjust)) {
+ if (adjust)
+ *m2_n2 = *m_n;
+
+ return true;
+ }
+
+ return false;
+}
+
static bool
intel_pipe_config_compare(struct drm_device *dev,
struct intel_crtc_state *current_config,
- struct intel_crtc_state *pipe_config)
+ struct intel_crtc_state *pipe_config,
+ bool adjust)
{
+ bool ret = true;
+
+#define INTEL_ERR_OR_DBG_KMS(fmt, ...) \
+ do { \
+ if (!adjust) \
+ DRM_ERROR(fmt, ##__VA_ARGS__); \
+ else \
+ DRM_DEBUG_KMS(fmt, ##__VA_ARGS__); \
+ } while (0)
+
#define PIPE_CONF_CHECK_X(name)\
if (current_config->name != pipe_config->name) { \
- DRM_ERROR("mismatch in " #name " " \
+ INTEL_ERR_OR_DBG_KMS("mismatch in " #name " " \
"(expected 0x%08x, found 0x%08x)\n", \
current_config->name, \
pipe_config->name); \
- return false; \
+ ret = false; \
}
#define PIPE_CONF_CHECK_I(name)\
if (current_config->name != pipe_config->name) { \
- DRM_ERROR("mismatch in " #name " " \
+ INTEL_ERR_OR_DBG_KMS("mismatch in " #name " " \
"(expected %i, found %i)\n", \
current_config->name, \
pipe_config->name); \
- return false; \
+ ret = false; \
+ }
+
+#define PIPE_CONF_CHECK_M_N(name) \
+ if (!intel_compare_link_m_n(¤t_config->name, \
+ &pipe_config->name,\
+ adjust)) { \
+ INTEL_ERR_OR_DBG_KMS("mismatch in " #name " " \
+ "(expected tu %i gmch %i/%i link %i/%i, " \
+ "foun
[Intel-gfx] [PATCH v3 06/20] drm/i915: Remove plane_config from struct intel_crtc.
Nothing depends on this outside initial hw readout, so keep this
struct on the stack instead.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 25 +++--
drivers/gpu/drm/i915/intel_drv.h | 1 -
2 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 037a85f1b127..e4d8acc63823 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15204,7 +15204,9 @@ void intel_modeset_init(struct drm_device *dev)
drm_modeset_unlock_all(dev);
for_each_intel_crtc(dev, crtc) {
- if (!crtc->active)
+ struct intel_initial_plane_config plane_config;
+
+ if (!crtc->base.state->active)
continue;
/*
@@ -15214,15 +15216,16 @@ void intel_modeset_init(struct drm_device *dev)
* can even allow for smooth boot transitions if the BIOS
* fb is large enough for the active pipe configuration.
*/
- if (dev_priv->display.get_initial_plane_config) {
- dev_priv->display.get_initial_plane_config(crtc,
- &crtc->plane_config);
- /*
-* If the fb is shared between multiple heads, we'll
-* just get the first one.
-*/
- intel_find_initial_plane_obj(crtc, &crtc->plane_config);
- }
+
+ plane_config.fb = NULL;
+ dev_priv->display.get_initial_plane_config(crtc,
+ &plane_config);
+
+ /*
+* If the fb is shared between multiple heads, we'll
+* just get the first one.
+*/
+ intel_find_initial_plane_obj(crtc, &plane_config);
}
}
@@ -15713,6 +15716,8 @@ void intel_modeset_gem_init(struct drm_device *dev)
if (ret) {
DRM_ERROR("failed to pin boot fb on pipe %d\n",
to_intel_crtc(c)->pipe);
+ obj->frontbuffer_bits &=
+ ~to_intel_plane(c->primary)->frontbuffer_bit;
drm_framebuffer_unreference(c->primary->fb);
c->primary->fb = NULL;
c->primary->crtc = c->primary->state->crtc = NULL;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 09a0a9222a3a..09e3581c8441 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -550,7 +550,6 @@ struct intel_crtc {
uint32_t cursor_size;
uint32_t cursor_base;
- struct intel_initial_plane_config plane_config;
struct intel_crtc_state *config;
bool new_enabled;
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 14/20] drm/i915: Update power domains on readout.
This allows us to get rid of the set_init_power in
modeset_update_crtc_domains. The state should be sanitized enough
after setup_hw_state to not need the init power.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 76
1 file changed, 50 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6bab045b389c..f6c65706cebf 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5194,6 +5194,9 @@ static unsigned long get_crtc_power_domains(struct
drm_crtc *crtc)
unsigned long mask;
enum transcoder transcoder;
+ if (!crtc->state->active)
+ return 0;
+
transcoder = intel_pipe_to_cpu_transcoder(dev->dev_private, pipe);
mask = BIT(POWER_DOMAIN_PIPE(pipe));
@@ -5208,27 +5211,46 @@ static unsigned long get_crtc_power_domains(struct
drm_crtc *crtc)
return mask;
}
-static void modeset_update_crtc_power_domains(struct drm_atomic_state *state)
+static unsigned long modeset_get_crtc_power_domains(struct drm_crtc *crtc)
{
- struct drm_device *dev = state->dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
- unsigned long pipe_domains[I915_MAX_PIPES] = { 0, };
- struct intel_crtc *crtc;
+ struct drm_i915_private *dev_priv = crtc->dev->dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ enum intel_display_power_domain domain;
+ unsigned long domains, new_domains, old_domains;
- /*
-* First get all needed power domains, then put all unneeded, to avoid
-* any unnecessary toggling of the power wells.
-*/
- for_each_intel_crtc(dev, crtc) {
- enum intel_display_power_domain domain;
+ old_domains = intel_crtc->enabled_power_domains;
+ intel_crtc->enabled_power_domains = new_domains =
get_crtc_power_domains(crtc);
- if (!crtc->base.state->enable)
- continue;
+ domains = new_domains & ~old_domains;
+
+ for_each_power_domain(domain, domains)
+ intel_display_power_get(dev_priv, domain);
+
+ return old_domains & ~new_domains;
+}
+
+static void modeset_put_power_domains(struct drm_i915_private *dev_priv,
+ unsigned long domains)
+{
+ enum intel_display_power_domain domain;
+
+ for_each_power_domain(domain, domains)
+ intel_display_power_put(dev_priv, domain);
+}
- pipe_domains[crtc->pipe] = get_crtc_power_domains(&crtc->base);
+static void modeset_update_crtc_power_domains(struct drm_atomic_state *state)
+{
+ struct drm_device *dev = state->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ unsigned long put_domains[I915_MAX_PIPES] = {};
+ struct drm_crtc_state *crtc_state;
+ struct drm_crtc *crtc;
+ int i;
- for_each_power_domain(domain, pipe_domains[crtc->pipe])
- intel_display_power_get(dev_priv, domain);
+ for_each_crtc_in_state(state, crtc, crtc_state, i) {
+ if (needs_modeset(crtc->state))
+ put_domains[to_intel_crtc(crtc)->pipe] =
+ modeset_get_crtc_power_domains(crtc);
}
if (dev_priv->display.modeset_commit_cdclk) {
@@ -5239,16 +5261,9 @@ static void modeset_update_crtc_power_domains(struct
drm_atomic_state *state)
dev_priv->display.modeset_commit_cdclk(state);
}
- for_each_intel_crtc(dev, crtc) {
- enum intel_display_power_domain domain;
-
- for_each_power_domain(domain, crtc->enabled_power_domains)
- intel_display_power_put(dev_priv, domain);
-
- crtc->enabled_power_domains = pipe_domains[crtc->pipe];
- }
-
- intel_display_set_init_power(dev_priv, false);
+ for (i = 0; i < I915_MAX_PIPES; i++)
+ if (put_domains[i])
+ modeset_put_power_domains(dev_priv, put_domains[i]);
}
static void intel_update_max_cdclk(struct drm_device *dev)
@@ -15547,6 +15562,15 @@ intel_modeset_setup_hw_state(struct drm_device *dev)
skl_wm_get_hw_state(dev);
else if (HAS_PCH_SPLIT(dev))
ilk_wm_get_hw_state(dev);
+
+ for_each_intel_crtc(dev, crtc) {
+ unsigned long put_domains;
+
+ put_domains = modeset_get_crtc_power_domains(&crtc->base);
+ if (WARN_ON(put_domains))
+ modeset_put_power_domains(dev_priv, put_domains);
+ }
+ intel_display_set_init_power(dev_priv, false);
}
void intel_display_resume(struct drm_device *dev)
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/l
[Intel-gfx] [PATCH v3 00/20] Convert to atomic, part 4.
Atomic suspend/resume, full hardware readout and atomic ioctl support. Changes from the previous version: - The fastboot changes from the previous patch have been removed, fastboot will have to be a separate patch because of the testing it needs. - I've cleaned up the changes to planes and split it into separate patches. This makes it easier to bisect. - Some commit logs have been updated. Maarten Lankhorst (20): drm/i915: Only update state on crtc's that are part of the atomic state. drm/i915: Do not update pfit state when toggling crtc enabled. drm/i915: Do not use plane_config in intel_fbdev.c drm/i915: Allow fuzzy matching in pipe_config_compare, v2. drm/i915: Update missing properties in find_initial_plane_obj drm/i915: Remove plane_config from struct intel_crtc. drm/i915: Rework plane readout. drm/i915: fill in more mode members drm/i915: Fill in more crtc state, v3. drm/i915: Set csc coefficients in intel_sanitize_crtc. drm/i915: Readout initial hw mode. drm/i915: Convert resume to atomic. drm/i915: Get rid of unused transitional members. drm/i915: Update power domains on readout. drm/i915: Always reset in intel_crtc_restore_mode drm/i915: Make intel_display_suspend atomic, try 2. drm/i915: Use full atomic modeset. drm/i915: Call plane update functions directly from intel_atomic_commit. drm/i915: always disable irqs in intel_pipe_update_start drm/i915: Remove use of runtime pm in atomic commit functions drivers/gpu/drm/i915/i915_drv.c |4 +- drivers/gpu/drm/i915/i915_drv.h |4 +- drivers/gpu/drm/i915/i915_params.c |5 - drivers/gpu/drm/i915/intel_atomic.c | 144 + drivers/gpu/drm/i915/intel_display.c | 1083 +++--- drivers/gpu/drm/i915/intel_dp.c |2 +- drivers/gpu/drm/i915/intel_drv.h | 25 +- drivers/gpu/drm/i915/intel_fbdev.c | 25 +- drivers/gpu/drm/i915/intel_lvds.c|2 +- drivers/gpu/drm/i915/intel_sprite.c | 17 +- 10 files changed, 517 insertions(+), 794 deletions(-) -- 2.1.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 10/20] drm/i915: Set csc coefficients in intel_sanitize_crtc.
This might not have been set during boot, and when we preserve the initial mode this can result in a black screen. Cc: Daniel Stone Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 819a2b551f1f..80e878929bab 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -15251,6 +15251,9 @@ static void intel_sanitize_crtc(struct intel_crtc *crtc) drm_calc_timestamping_constants(&crtc->base, &crtc->base.hwmode); update_scanline_offset(crtc); drm_crtc_vblank_on(&crtc->base); + + if (IS_HASWELL(dev) || INTEL_INFO(dev)->gen > 7) + intel_set_pipe_csc(&crtc->base); } /* We need to sanitize the plane -> pipe mapping first because this will -- 2.1.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 13/20] drm/i915: Get rid of unused transitional members.
The previous commit converted hw readout to atomic, all the new_*
members were used for restoring the old state, but with the
conversion of suspend to atomic there's no use left for them.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 80
drivers/gpu/drm/i915/intel_drv.h | 12 --
2 files changed, 18 insertions(+), 74 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b8984b4f8081..6bab045b389c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10254,7 +10254,7 @@ bool intel_get_load_detect_pipe(struct drm_connector
*connector,
retry:
ret = drm_modeset_lock(&config->connection_mutex, ctx);
if (ret)
- goto fail_unlock;
+ goto fail;
/*
* Algorithm gets a little messy:
@@ -10272,10 +10272,10 @@ retry:
ret = drm_modeset_lock(&crtc->mutex, ctx);
if (ret)
- goto fail_unlock;
+ goto fail;
ret = drm_modeset_lock(&crtc->primary->mutex, ctx);
if (ret)
- goto fail_unlock;
+ goto fail;
old->dpms_mode = connector->dpms;
old->load_detect_temp = false;
@@ -10294,9 +10294,6 @@ retry:
continue;
if (possible_crtc->state->enable)
continue;
- /* This can occur when applying the pipe A quirk on resume. */
- if (to_intel_crtc(possible_crtc)->new_enabled)
- continue;
crtc = possible_crtc;
break;
@@ -10307,20 +10304,17 @@ retry:
*/
if (!crtc) {
DRM_DEBUG_KMS("no pipe available for load-detect\n");
- goto fail_unlock;
+ goto fail;
}
ret = drm_modeset_lock(&crtc->mutex, ctx);
if (ret)
- goto fail_unlock;
+ goto fail;
ret = drm_modeset_lock(&crtc->primary->mutex, ctx);
if (ret)
- goto fail_unlock;
- intel_encoder->new_crtc = to_intel_crtc(crtc);
- to_intel_connector(connector)->new_encoder = intel_encoder;
+ goto fail;
intel_crtc = to_intel_crtc(crtc);
- intel_crtc->new_enabled = true;
old->dpms_mode = connector->dpms;
old->load_detect_temp = true;
old->release_fb = NULL;
@@ -10388,9 +10382,7 @@ retry:
intel_wait_for_vblank(dev, intel_crtc->pipe);
return true;
- fail:
- intel_crtc->new_enabled = crtc->state->enable;
-fail_unlock:
+fail:
drm_atomic_state_free(state);
state = NULL;
@@ -10436,10 +10428,6 @@ void intel_release_load_detect_pipe(struct
drm_connector *connector,
if (IS_ERR(crtc_state))
goto fail;
- to_intel_connector(connector)->new_encoder = NULL;
- intel_encoder->new_crtc = NULL;
- intel_crtc->new_enabled = false;
-
connector_state->best_encoder = NULL;
connector_state->crtc = NULL;
@@ -11843,37 +11831,6 @@ static const struct drm_crtc_helper_funcs
intel_helper_funcs = {
.atomic_check = intel_crtc_atomic_check,
};
-/**
- * intel_modeset_update_staged_output_state
- *
- * Updates the staged output configuration state, e.g. after we've read out the
- * current hw state.
- */
-static void intel_modeset_update_staged_output_state(struct drm_device *dev)
-{
- struct intel_crtc *crtc;
- struct intel_encoder *encoder;
- struct intel_connector *connector;
-
- for_each_intel_connector(dev, connector) {
- connector->new_encoder =
- to_intel_encoder(connector->base.encoder);
- }
-
- for_each_intel_encoder(dev, encoder) {
- encoder->new_crtc =
- to_intel_crtc(encoder->base.crtc);
- }
-
- for_each_intel_crtc(dev, crtc) {
- crtc->new_enabled = crtc->base.state->enable;
- }
-}
-
-/* Transitional helper to copy current connector/encoder state to
- * connector->state. This is needed so that code that is partially
- * converted to atomic does the right thing.
- */
static void intel_modeset_update_connector_atomic_state(struct drm_device *dev)
{
struct intel_connector *connector;
@@ -12314,7 +12271,6 @@ intel_modeset_update_state(struct drm_atomic_state
*state)
}
drm_atomic_helper_update_legacy_modeset_state(state->dev, state);
- intel_modeset_update_staged_output_state(state->dev);
/* Double check state. */
for_each_crtc_in_state(state, crtc, crtc_state, i) {
@@ -12714,11 +12670,14 @@ check_connector_state(struct drm_device *dev)
struct intel_connector *connector;
for_each_intel_conne
[Intel-gfx] [PATCH v3 19/20] drm/i915: always disable irqs in intel_pipe_update_start
This can only fail because of a bug in the code.
Suggested-by: Daniel Vetter
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 15 +--
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_sprite.c | 17 +++--
3 files changed, 13 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index fd41cfa92d3d..cc8ae7601884 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11248,12 +11248,11 @@ static void ilk_do_mmio_flip(struct intel_crtc
*intel_crtc)
static void intel_do_mmio_flip(struct intel_crtc *intel_crtc)
{
struct drm_device *dev = intel_crtc->base.dev;
- bool atomic_update;
u32 start_vbl_count;
intel_mark_page_flip_active(intel_crtc);
- atomic_update = intel_pipe_update_start(intel_crtc, &start_vbl_count);
+ intel_pipe_update_start(intel_crtc, &start_vbl_count);
if (INTEL_INFO(dev)->gen >= 9)
skl_do_mmio_flip(intel_crtc);
@@ -11261,8 +11260,7 @@ static void intel_do_mmio_flip(struct intel_crtc
*intel_crtc)
/* use_mmio_flip() retricts MMIO flips to ilk+ */
ilk_do_mmio_flip(intel_crtc);
- if (atomic_update)
- intel_pipe_update_end(intel_crtc, start_vbl_count);
+ intel_pipe_update_end(intel_crtc, start_vbl_count);
}
static void intel_mmio_flip_work_func(struct work_struct *work)
@@ -13649,9 +13647,7 @@ static void intel_begin_crtc_commit(struct drm_crtc
*crtc)
/* Perform vblank evasion around commit operation */
if (crtc->state->active)
- intel_crtc->atomic.evade =
- intel_pipe_update_start(intel_crtc,
-
&intel_crtc->atomic.start_vbl_count);
+ intel_pipe_update_start(intel_crtc,
&intel_crtc->atomic.start_vbl_count);
if (!needs_modeset(crtc->state) && INTEL_INFO(dev)->gen >= 9)
skl_detach_scalers(intel_crtc);
@@ -13663,9 +13659,8 @@ static void intel_finish_crtc_commit(struct drm_crtc
*crtc)
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- if (intel_crtc->atomic.evade)
- intel_pipe_update_end(intel_crtc,
- intel_crtc->atomic.start_vbl_count);
+ if (crtc->state->active)
+ intel_pipe_update_end(intel_crtc,
intel_crtc->atomic.start_vbl_count);
intel_runtime_pm_put(dev_priv);
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index cc91ea370c99..250ee28baff9 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1385,7 +1385,7 @@ bool intel_sdvo_init(struct drm_device *dev, uint32_t
sdvo_reg, bool is_sdvob);
int intel_plane_init(struct drm_device *dev, enum pipe pipe, int plane);
int intel_sprite_set_colorkey(struct drm_device *dev, void *data,
struct drm_file *file_priv);
-bool intel_pipe_update_start(struct intel_crtc *crtc,
+void intel_pipe_update_start(struct intel_crtc *crtc,
uint32_t *start_vbl_count);
void intel_pipe_update_end(struct intel_crtc *crtc, u32 start_vbl_count);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index cd21525df352..9d8af2f8a875 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -75,10 +75,8 @@ static int usecs_to_scanlines(const struct drm_display_mode
*mode, int usecs)
* until a subsequent call to intel_pipe_update_end(). That is done to
* avoid random delays. The value written to @start_vbl_count should be
* supplied to intel_pipe_update_end() for error checking.
- *
- * Return: true if the call was successful
*/
-bool intel_pipe_update_start(struct intel_crtc *crtc, uint32_t
*start_vbl_count)
+void intel_pipe_update_start(struct intel_crtc *crtc, uint32_t
*start_vbl_count)
{
struct drm_device *dev = crtc->base.dev;
const struct drm_display_mode *mode = &crtc->config->base.adjusted_mode;
@@ -96,13 +94,14 @@ bool intel_pipe_update_start(struct intel_crtc *crtc,
uint32_t *start_vbl_count)
min = vblank_start - usecs_to_scanlines(mode, 100);
max = vblank_start - 1;
+ local_irq_disable();
+ *start_vbl_count = 0;
+
if (min <= 0 || max <= 0)
- return false;
+ return;
if (WARN_ON(drm_crtc_vblank_get(&crtc->base)))
- return false;
-
- local_irq_disable();
+ return;
trace_i915_pipe_update_start(crtc, min, max);
@@ -138,8 +137,6 @@ bool intel_pipe_update_start(struct intel_crtc *crtc,
uint32_t *start_vbl_count)
*start_vbl_count = dev->driver->get_vblank_counter(dev, pipe);
trace_i915_pi
[Intel-gfx] [PATCH v3 05/20] drm/i915: Update missing properties in find_initial_plane_obj
The src and crtc rectangles were never set, resulting in the primary plane being made invisible on first atomic update. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index c3a3d108..037a85f1b127 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -2586,6 +2586,7 @@ intel_find_initial_plane_obj(struct intel_crtc *intel_crtc, struct intel_crtc *i; struct drm_i915_gem_object *obj; struct drm_plane *primary = intel_crtc->base.primary; + struct drm_plane_state *plane_state = primary->state; struct drm_framebuffer *fb; if (!plane_config->fb) @@ -2625,13 +2626,21 @@ intel_find_initial_plane_obj(struct intel_crtc *intel_crtc, return; valid_fb: + plane_state->src_x = plane_state->src_y = 0; + plane_state->src_w = fb->width << 16; + plane_state->src_h = fb->height << 16; + + plane_state->crtc_x = plane_state->src_y = 0; + plane_state->crtc_w = fb->width; + plane_state->crtc_h = fb->height; + obj = intel_fb_obj(fb); if (obj->tiling_mode != I915_TILING_NONE) dev_priv->preserve_bios_swizzle = true; - primary->fb = fb; + drm_framebuffer_reference(fb); + primary->fb = primary->state->fb = fb; primary->crtc = primary->state->crtc = &intel_crtc->base; - update_state_fb(primary); intel_crtc->base.state->plane_mask |= (1 << drm_plane_index(primary)); obj->frontbuffer_bits |= to_intel_plane(primary)->frontbuffer_bit; } -- 2.1.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 15/20] drm/i915: Always reset in intel_crtc_restore_mode
And get rid of things that are no longer true. This function is only
used for forcing a modeset when encoder properties are changed.
Because this is not yet done atomically, assume a full modeset is
needed and reset the crtc.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 58 ++--
1 file changed, 16 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f6c65706cebf..599af76d34f6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13273,63 +13273,37 @@ void intel_crtc_restore_mode(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc->dev;
struct drm_atomic_state *state;
- struct intel_encoder *encoder;
- struct intel_connector *connector;
- struct drm_connector_state *connector_state;
- struct intel_crtc_state *crtc_state;
+ struct drm_crtc_state *crtc_state;
int ret;
state = drm_atomic_state_alloc(dev);
if (!state) {
- DRM_DEBUG_KMS("[CRTC:%d] mode restore failed, out of memory",
+ DRM_DEBUG_KMS("[CRTC:%d] crtc restore failed, out of memory",
crtc->base.id);
return;
}
- state->acquire_ctx = dev->mode_config.acquire_ctx;
-
- /* The force restore path in the HW readout code relies on the staged
-* config still keeping the user requested config while the actual
-* state has been overwritten by the configuration read from HW. We
-* need to copy the staged config to the atomic state, otherwise the
-* mode set will just reapply the state the HW is already in. */
- for_each_intel_encoder(dev, encoder) {
- if (encoder->base.crtc != crtc)
- continue;
+ state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
- for_each_intel_connector(dev, connector) {
- if (connector->base.state->best_encoder !=
- &encoder->base)
- continue;
-
- connector_state = drm_atomic_get_connector_state(state,
&connector->base);
- if (IS_ERR(connector_state)) {
- DRM_DEBUG_KMS("Failed to add [CONNECTOR:%d:%s]
to state: %ld\n",
- connector->base.base.id,
- connector->base.name,
- PTR_ERR(connector_state));
- continue;
- }
+retry:
+ crtc_state = drm_atomic_get_crtc_state(state, crtc);
+ ret = PTR_ERR_OR_ZERO(crtc_state);
+ if (!ret) {
+ if (!crtc_state->active)
+ goto out;
- connector_state->crtc = crtc;
- }
+ crtc_state->mode_changed = true;
+ ret = intel_set_mode(state);
}
- crtc_state = intel_atomic_get_crtc_state(state, to_intel_crtc(crtc));
- if (IS_ERR(crtc_state)) {
- DRM_DEBUG_KMS("Failed to add [CRTC:%d] to state: %ld\n",
- crtc->base.id, PTR_ERR(crtc_state));
- drm_atomic_state_free(state);
- return;
+ if (ret == -EDEADLK) {
+ drm_atomic_state_clear(state);
+ drm_modeset_backoff(state->acquire_ctx);
+ goto retry;
}
- drm_mode_copy(&crtc_state->base.mode, &crtc->mode);
-
- intel_modeset_setup_plane_state(state, crtc, &crtc->mode,
- crtc->primary->fb, crtc->x, crtc->y);
-
- ret = intel_set_mode(state);
if (ret)
+out:
drm_atomic_state_free(state);
}
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 20/20] drm/i915: Remove use of runtime pm in atomic commit functions
We needed this originally for updating pagetables in plane commit
functions. But that's extracted into prepare/cleanup now. The other
issue was running updates when the pipe was off. That's also now
fixed.
Suggested-by: Daniel Vetter
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index cc8ae7601884..9bf67e34961c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13637,14 +13637,11 @@ intel_disable_primary_plane(struct drm_plane *plane,
static void intel_begin_crtc_commit(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc->dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
if (intel_crtc->atomic.update_wm_pre)
intel_update_watermarks(crtc);
- intel_runtime_pm_get(dev_priv);
-
/* Perform vblank evasion around commit operation */
if (crtc->state->active)
intel_pipe_update_start(intel_crtc,
&intel_crtc->atomic.start_vbl_count);
@@ -13655,14 +13652,10 @@ static void intel_begin_crtc_commit(struct drm_crtc
*crtc)
static void intel_finish_crtc_commit(struct drm_crtc *crtc)
{
- struct drm_device *dev = crtc->dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
if (crtc->state->active)
intel_pipe_update_end(intel_crtc,
intel_crtc->atomic.start_vbl_count);
-
- intel_runtime_pm_put(dev_priv);
}
/**
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 12/20] drm/i915: Convert resume to atomic.
Instead of all the ad-hoc updating, duplicate the old state first
before reading out the hw state, then restore it.
intel_display_resume is a new function that duplicates the sw state,
then reads out the hw state, and commits the old state.
intel_display_setup_hw_state now only reads out the atomic state.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90396
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 3 +-
drivers/gpu/drm/i915/intel_display.c | 77 ++--
drivers/gpu/drm/i915/intel_lvds.c| 2 +-
4 files changed, 60 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e44dc0d6656f..db48aee7f140 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -741,7 +741,7 @@ static int i915_drm_resume(struct drm_device *dev)
spin_unlock_irq(&dev_priv->irq_lock);
drm_modeset_lock_all(dev);
- intel_modeset_setup_hw_state(dev, true);
+ intel_display_resume(dev);
drm_modeset_unlock_all(dev);
intel_dp_mst_resume(dev);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 38cfd53bc262..d3e14cb43924 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3279,8 +3279,7 @@ extern void intel_modeset_gem_init(struct drm_device
*dev);
extern void intel_modeset_cleanup(struct drm_device *dev);
extern void intel_connector_unregister(struct intel_connector *);
extern int intel_modeset_vga_set_state(struct drm_device *dev, bool state);
-extern void intel_modeset_setup_hw_state(struct drm_device *dev,
-bool force_restore);
+extern void intel_display_resume(struct drm_device *dev);
extern void i915_redisable_vga(struct drm_device *dev);
extern void i915_redisable_vga_power_on(struct drm_device *dev);
extern bool ironlake_set_drps(struct drm_device *dev, u8 val);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a4a2c3fbdc2d..b8984b4f8081 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -109,6 +109,7 @@ static void skl_init_scalers(struct drm_device *dev, struct
intel_crtc *intel_cr
struct intel_crtc_state *crtc_state);
static int i9xx_get_refclk(const struct intel_crtc_state *crtc_state,
int num_connectors);
+static void intel_modeset_setup_hw_state(struct drm_device *dev);
static struct intel_encoder *intel_find_encoder(struct intel_connector
*connector, int pipe)
{
@@ -3249,7 +3250,7 @@ void intel_finish_reset(struct drm_device *dev)
dev_priv->display.hpd_irq_setup(dev);
spin_unlock_irq(&dev_priv->irq_lock);
- intel_modeset_setup_hw_state(dev, true);
+ intel_display_resume(dev);
intel_hpd_init(dev_priv);
@@ -15163,7 +15164,7 @@ void intel_modeset_init(struct drm_device *dev)
intel_fbc_disable(dev_priv);
drm_modeset_lock_all(dev);
- intel_modeset_setup_hw_state(dev, false);
+ intel_modeset_setup_hw_state(dev);
drm_modeset_unlock_all(dev);
for_each_intel_crtc(dev, crtc) {
@@ -15542,10 +15543,11 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
}
}
-/* Scan out the current hw modeset state, sanitizes it and maps it into the drm
- * and i915 state tracking structures. */
-void intel_modeset_setup_hw_state(struct drm_device *dev,
- bool force_restore)
+/* Scan out the current hw modeset state,
+ * and sanitizes it to the current state
+ */
+static void
+intel_modeset_setup_hw_state(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
enum pipe pipe;
@@ -15588,24 +15590,59 @@ void intel_modeset_setup_hw_state(struct drm_device
*dev,
else if (HAS_PCH_SPLIT(dev))
ilk_wm_get_hw_state(dev);
- if (force_restore) {
- i915_redisable_vga(dev);
+ intel_modeset_update_staged_output_state(dev);
+}
- /*
-* We need to use raw interfaces for restoring state to avoid
-* checking (bogus) intermediate states.
-*/
- for_each_pipe(dev_priv, pipe) {
- struct drm_crtc *crtc =
- dev_priv->pipe_to_crtc_mapping[pipe];
+void intel_display_resume(struct drm_device *dev)
+{
+ struct drm_atomic_state *state = drm_atomic_state_alloc(dev);
+ struct intel_connector *conn;
+ struct intel_plane *plane;
+ struct drm_crtc *crtc;
+ int ret;
- intel_crtc_restore_mode(crtc);
- }
- } else {
- intel_modeset_update_staged_output_state(dev);
+ if (!state)
+ return;
+
+ state->acqui
[Intel-gfx] [PATCH v3 09/20] drm/i915: Fill in more crtc state, v3.
There is a small memory leak in intel_modeset_readout_hw_state,
plug it.
intel_sanitize_crtc should set a null mode when disabling the crtc,
this updates crtc_state->enable too.
intel_sanitize_crtc also needs to update the vblank timestamps before
enabling vblank to make it work right.
Changes since v1:
- Moved after reworking primary plane and updating mode members.
- Force a modeset calculation by changing mode->type from what the
final mode will be.
Changes since v2:
- Do not fill out mode, this should only be done for supporting fastboot.
Signed-off-by: Maarten Lankhorst
---
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 d37f6a93b094..819a2b551f1f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15248,6 +15248,7 @@ static void intel_sanitize_crtc(struct intel_crtc *crtc)
/* restore vblank interrupts to correct state */
drm_crtc_vblank_reset(&crtc->base);
if (crtc->active) {
+ drm_calc_timestamping_constants(&crtc->base,
&crtc->base.hwmode);
update_scanline_offset(crtc);
drm_crtc_vblank_on(&crtc->base);
}
@@ -15300,7 +15301,7 @@ static void intel_sanitize_crtc(struct intel_crtc *crtc)
crtc->base.state->enable ? "enabled" : "disabled",
crtc->active ? "enabled" : "disabled");
- crtc->base.state->enable = crtc->active;
+ WARN_ON(drm_atomic_set_mode_for_crtc(crtc->base.state, NULL) <
0);
crtc->base.state->active = crtc->active;
crtc->base.enabled = crtc->active;
@@ -15450,6 +15451,7 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
int i;
for_each_intel_crtc(dev, crtc) {
+ __drm_atomic_helper_crtc_destroy_state(&crtc->base,
crtc->base.state);
memset(crtc->config, 0, sizeof(*crtc->config));
crtc->config->base.crtc = &crtc->base;
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 18/20] drm/i915: Call plane update functions directly from intel_atomic_commit.
Now that there's only a single path for all atomic updates we can call
intel_(pre/post)_plane_update from intel_atomic_commit directly. This
makes the intention more clear.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 510e31f16135..fd41cfa92d3d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13292,12 +13292,19 @@ static int intel_atomic_commit(struct drm_device *dev,
/* Now enable the clocks, plane, pipe, and connectors that we set up. */
for_each_crtc_in_state(state, crtc, crtc_state, i) {
- if (needs_modeset(crtc->state) && crtc->state->active) {
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ bool modeset = needs_modeset(crtc->state);
+
+ if (modeset && crtc->state->active) {
update_scanline_offset(to_intel_crtc(crtc));
dev_priv->display.crtc_enable(crtc);
}
+ if (!modeset)
+ intel_pre_plane_update(intel_crtc);
+
drm_atomic_helper_commit_planes_on_crtc(crtc_state);
+ intel_post_plane_update(intel_crtc);
}
/* FIXME: add subpixel order */
@@ -13635,9 +13642,6 @@ static void intel_begin_crtc_commit(struct drm_crtc
*crtc)
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- if (!needs_modeset(crtc->state))
- intel_pre_plane_update(intel_crtc);
-
if (intel_crtc->atomic.update_wm_pre)
intel_update_watermarks(crtc);
@@ -13664,8 +13668,6 @@ static void intel_finish_crtc_commit(struct drm_crtc
*crtc)
intel_crtc->atomic.start_vbl_count);
intel_runtime_pm_put(dev_priv);
-
- intel_post_plane_update(intel_crtc);
}
/**
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 16/20] drm/i915: Make intel_display_suspend atomic, try 2.
Calculate all state using a normal transition, but afterwards fudge
crtc->state->active back to its old value. This should still allow
state restore in setup_hw_state to work properly.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 52 +---
drivers/gpu/drm/i915/intel_drv.h | 2 +-
2 files changed, 50 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 599af76d34f6..6e3df10a43b9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6224,12 +6224,58 @@ static void intel_crtc_disable_noatomic(struct drm_crtc
*crtc)
* turn all crtc's off, but do not adjust state
* This has to be paired with a call to intel_modeset_setup_hw_state.
*/
-void intel_display_suspend(struct drm_device *dev)
+int intel_display_suspend(struct drm_device *dev)
{
+ struct drm_mode_config *config = &dev->mode_config;
+ struct drm_modeset_acquire_ctx *ctx = config->acquire_ctx;
+ struct drm_atomic_state *state;
struct drm_crtc *crtc;
+ unsigned crtc_mask = 0;
+ int ret = 0;
+
+ if (WARN_ON(!ctx))
+ return 0;
+
+ lockdep_assert_held(&ctx->ww_ctx);
+ state = drm_atomic_state_alloc(dev);
+ if (WARN_ON(!state))
+ return -ENOMEM;
+
+ state->acquire_ctx = ctx;
+ state->allow_modeset = true;
+
+ for_each_crtc(dev, crtc) {
+ struct drm_crtc_state *crtc_state =
+ drm_atomic_get_crtc_state(state, crtc);
- for_each_crtc(dev, crtc)
- intel_crtc_disable_noatomic(crtc);
+ ret = PTR_ERR_OR_ZERO(crtc_state);
+ if (ret)
+ goto free;
+
+ if (!crtc_state->active)
+ continue;
+
+ crtc_state->active = false;
+ crtc_mask |= 1 << drm_crtc_index(crtc);
+ }
+
+ if (crtc_mask) {
+ ret = intel_set_mode(state);
+
+ if (!ret) {
+ for_each_crtc(dev, crtc)
+ if (crtc_mask & (1 << drm_crtc_index(crtc)))
+ crtc->state->active = true;
+
+ return ret;
+ }
+ }
+
+free:
+ if (ret)
+ DRM_ERROR("Suspending crtc's failed with %i\n", ret);
+ drm_atomic_state_free(state);
+ return ret;
}
/* Master function to enable/disable CRTC and corresponding power wells */
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 217b773e0673..f4abce103221 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -988,7 +988,7 @@ int intel_pch_rawclk(struct drm_device *dev);
void intel_mark_busy(struct drm_device *dev);
void intel_mark_idle(struct drm_device *dev);
void intel_crtc_restore_mode(struct drm_crtc *crtc);
-void intel_display_suspend(struct drm_device *dev);
+int intel_display_suspend(struct drm_device *dev);
int intel_crtc_control(struct drm_crtc *crtc, bool enable);
void intel_crtc_update_dpms(struct drm_crtc *crtc);
void intel_encoder_destroy(struct drm_encoder *encoder);
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 03/20] drm/i915: Do not use plane_config in intel_fbdev.c
Use the atomic state instead, this allows removing plane_config
from the crtc after the full hw readout is completed.
The size can be found in the fb, no need for the plane_config.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_fbdev.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index 33b3c9233eac..b791f2374f3b 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -581,7 +581,6 @@ static bool intel_fbdev_init_bios(struct drm_device *dev,
struct intel_framebuffer *fb = NULL;
struct drm_crtc *crtc;
struct intel_crtc *intel_crtc;
- struct intel_initial_plane_config *plane_config = NULL;
unsigned int max_size = 0;
if (!i915.fastboot)
@@ -589,20 +588,21 @@ static bool intel_fbdev_init_bios(struct drm_device *dev,
/* Find the largest fb */
for_each_crtc(dev, crtc) {
+ struct drm_i915_gem_object *obj =
+ intel_fb_obj(crtc->primary->state->fb);
intel_crtc = to_intel_crtc(crtc);
- if (!intel_crtc->active || !crtc->primary->fb) {
+ if (!intel_crtc->active || !obj) {
DRM_DEBUG_KMS("pipe %c not active or no fb, skipping\n",
pipe_name(intel_crtc->pipe));
continue;
}
- if (intel_crtc->plane_config.size > max_size) {
+ if (obj->base.size > max_size) {
DRM_DEBUG_KMS("found possible fb from plane %c\n",
pipe_name(intel_crtc->pipe));
- plane_config = &intel_crtc->plane_config;
- fb = to_intel_framebuffer(crtc->primary->fb);
- max_size = plane_config->size;
+ fb = to_intel_framebuffer(crtc->primary->state->fb);
+ max_size = obj->base.size;
}
}
@@ -637,7 +637,6 @@ static bool intel_fbdev_init_bios(struct drm_device *dev,
DRM_DEBUG_KMS("fb not wide enough for plane %c (%d vs
%d)\n",
pipe_name(intel_crtc->pipe),
cur_size, fb->base.pitches[0]);
- plane_config = NULL;
fb = NULL;
break;
}
@@ -658,7 +657,6 @@ static bool intel_fbdev_init_bios(struct drm_device *dev,
DRM_DEBUG_KMS("fb not big enough for plane %c (%d vs
%d)\n",
pipe_name(intel_crtc->pipe),
cur_size, max_size);
- plane_config = NULL;
fb = NULL;
break;
}
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 07/20] drm/i915: Rework plane readout.
All non-primary planes get disabled during hw readout,
this reduces complexity and means not having to do some plane
visibility checks during the first commit.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_atomic.c | 7 ---
drivers/gpu/drm/i915/intel_display.c | 86
drivers/gpu/drm/i915/intel_drv.h | 1 -
3 files changed, 8 insertions(+), 86 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index b92b8581efc2..dcf4fb458649 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -98,13 +98,6 @@ int intel_atomic_check(struct drm_device *dev,
return -EINVAL;
}
- if (crtc_state &&
- crtc_state->quirks & PIPE_CONFIG_QUIRK_INITIAL_PLANES) {
- ret = drm_atomic_add_affected_planes(state,
&nuclear_crtc->base);
- if (ret)
- return ret;
- }
-
ret = drm_atomic_helper_check_planes(dev, state);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e4d8acc63823..118187dc76be 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11783,34 +11783,6 @@ static bool check_encoder_cloning(struct
drm_atomic_state *state,
return true;
}
-static void intel_crtc_check_initial_planes(struct drm_crtc *crtc,
- struct drm_crtc_state *crtc_state)
-{
- struct intel_crtc_state *pipe_config =
- to_intel_crtc_state(crtc_state);
- struct drm_plane *p;
- unsigned visible_mask = 0;
-
- drm_for_each_plane_mask(p, crtc->dev, crtc_state->plane_mask) {
- struct drm_plane_state *plane_state =
- drm_atomic_get_existing_plane_state(crtc_state->state,
p);
-
- if (WARN_ON(!plane_state))
- continue;
-
- if (!plane_state->fb)
- crtc_state->plane_mask &=
- ~(1 << drm_plane_index(p));
- else if (to_intel_plane_state(plane_state)->visible)
- visible_mask |= 1 << drm_plane_index(p);
- }
-
- if (!visible_mask)
- return;
-
- pipe_config->quirks &= ~PIPE_CONFIG_QUIRK_INITIAL_PLANES;
-}
-
static int intel_crtc_atomic_check(struct drm_crtc *crtc,
struct drm_crtc_state *crtc_state)
{
@@ -11832,10 +11804,6 @@ static int intel_crtc_atomic_check(struct drm_crtc
*crtc,
"[CRTC:%i] mismatch between state->active(%i) and
crtc->active(%i)\n",
idx, crtc->state->active, intel_crtc->active);
- /* plane mask is fixed up after all initial planes are calculated */
- if (pipe_config->quirks & PIPE_CONFIG_QUIRK_INITIAL_PLANES)
- intel_crtc_check_initial_planes(crtc, crtc_state);
-
if (mode_changed && !crtc_state->active)
intel_crtc->atomic.update_wm_post = true;
@@ -13188,19 +13156,6 @@ intel_modeset_compute_config(struct drm_atomic_state
*state)
continue;
}
- if (pipe_config->quirks & PIPE_CONFIG_QUIRK_INITIAL_PLANES) {
- ret = drm_atomic_add_affected_planes(state, crtc);
- if (ret)
- return ret;
-
- /*
-* We ought to handle i915.fastboot here.
-* If no modeset is required and the primary plane has
-* a fb, update the members of crtc_state as needed,
-* and run the necessary updates during vblank evasion.
-*/
- }
-
modeset = needs_modeset(crtc_state);
recalc = pipe_config->quirks & PIPE_CONFIG_QUIRK_INHERITED_MODE;
@@ -15460,47 +15415,22 @@ static void readout_plane_state(struct intel_crtc
*crtc,
struct intel_crtc_state *crtc_state)
{
struct intel_plane *p;
- struct drm_plane_state *drm_plane_state;
+ struct intel_plane_state *plane_state;
bool active = crtc_state->base.active;
- if (active) {
- crtc_state->quirks |= PIPE_CONFIG_QUIRK_INITIAL_PLANES;
-
- /* apply to previous sw state too */
- to_intel_crtc_state(crtc->base.state)->quirks |=
- PIPE_CONFIG_QUIRK_INITIAL_PLANES;
- }
-
for_each_intel_plane(crtc->base.dev, p) {
- bool visible = active;
-
if (crtc->pipe != p->pipe)
continue;
- drm_plane_state = p->base.state;
-
- /* Plane scaler state is not touched here. The first atomic
-* commit will restore all plane scale
Re: [Intel-gfx] [-next] WARNING at i915_gem_track_fb
On Mon, Jul 13, 2015 at 09:51:39PM +0900, Sergey Senozhatsky wrote: > 4.2.0-rc2-next-20150713 Is this also an issue in the 4.2-rc series or only in -next? -Daniel > > [ 1239.783862] [ cut here ] > [ 1239.783892] WARNING: CPU: 0 PID: 364 at > drivers/gpu/drm/i915/i915_gem.c:5368 i915_gem_track_fb+0xdc/0x106 [i915]() > [ 1239.783894] WARN_ON(new->frontbuffer_bits & frontbuffer_bits) > [ 1239.783895] Modules linked in: > [ 1239.783897] zram lz4_decompress lz4_compress lzo_compress lzo_decompress > zsmalloc sha256_ssse3 sha256_generic hmac drbg ctr ccm mousedev arc4 > nls_iso8859_1 nls_cp437 vfat fat coretemp hwmon iwlmvm i915 mac80211 > cfbfillrect cfbimgblt intel_powerclamp i2c_algo_bit crc32c_intel iwlwifi > i2c_i801 serio_raw cfbcopyarea psmouse drm_kms_helper ie31200_edac cfg80211 > lpc_ich r8169 atkbd mfd_core mii thermal drm edac_core libps2 mxm_wmi wmi > i8042 evdev video serio backlight processor ext4 crc16 mbcache jbd2 sd_mod > ehci_pci ehci_hcd ahci libahci libata xhci_pci xhci_hcd scsi_mod usbcore > usb_common > [ 1239.783942] CPU: 0 PID: 364 Comm: Xorg Not tainted > 4.2.0-rc2-next-20150713-dbg-00017-g16b87ed-dirty #183 > [ 1239.783944] 0009 88041c5379d8 813a19ac > 81077163 > [ 1239.783947] 88041c537a28 88041c537a18 8103b5d9 > 88041c5379f8 > [ 1239.783950] a0533273 0002 88041c578000 > 88041c578000 > [ 1239.783953] Call Trace: > [ 1239.783961] [] dump_stack+0x4c/0x65 > [ 1239.783965] [] ? up+0x39/0x3e > [ 1239.783968] [] warn_slowpath_common+0x9b/0xb5 > [ 1239.783986] [] ? i915_gem_track_fb+0xdc/0x106 [i915] > [ 1239.783987] [] warn_slowpath_fmt+0x46/0x48 > [ 1239.784002] [] i915_gem_track_fb+0xdc/0x106 [i915] > [ 1239.784026] [] intel_prepare_plane_fb+0xb1/0x101 [i915] > [ 1239.784033] [] > drm_atomic_helper_prepare_planes+0x5b/0xb8 [drm_kms_helper] > [ 1239.784055] [] intel_atomic_commit+0x46/0xc0 [i915] > [ 1239.784072] [] drm_atomic_commit+0x4d/0x52 [drm] > [ 1239.784078] [] > drm_atomic_helper_update_plane+0xca/0x119 [drm_kms_helper] > [ 1239.784092] [] __setplane_internal+0x24e/0x2ae [drm] > [ 1239.784103] [] drm_mode_cursor_universal+0x149/0x197 > [drm] > [ 1239.784113] [] ? drm_mode_setcrtc+0x428/0x428 [drm] > [ 1239.784122] [] drm_mode_cursor_common+0xb5/0x156 [drm] > [ 1239.784132] [] drm_mode_cursor_ioctl+0x37/0x39 [drm] > [ 1239.784140] [] drm_ioctl+0x287/0x415 [drm] > [ 1239.784143] [] ? __lock_is_held+0x3c/0x57 > [ 1239.784146] [] ? __fget+0x170/0x1a1 > [ 1239.784148] [] do_vfs_ioctl+0x455/0x4dd > [ 1239.784151] [] ? __fget_light+0x65/0x75 > [ 1239.784153] [] SyS_ioctl+0x44/0x63 > [ 1239.784155] [] entry_SYSCALL_64_fastpath+0x12/0x6f > [ 1239.784157] ---[ end trace 67b32b389e7fe7df ]--- > > -ss > ___ > 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
[Intel-gfx] [PATCH v3 17/20] drm/i915: Use full atomic modeset.
Huzzah! \o/
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_params.c | 5 -
drivers/gpu/drm/i915/intel_atomic.c | 123 ---
drivers/gpu/drm/i915/intel_display.c | 279 ++-
drivers/gpu/drm/i915/intel_drv.h | 5 -
6 files changed, 43 insertions(+), 372 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index db48aee7f140..f13ed1ef6641 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1731,7 +1731,7 @@ static int __init i915_init(void)
* to the atomic ioctl and the atomic properties. Only plane
operations on
* a single CRTC will actually work.
*/
- if (i915.nuclear_pageflip)
+ if (driver.driver_features & DRIVER_MODESET)
driver.driver_features |= DRIVER_ATOMIC;
return drm_pci_init(&driver, &i915_pci_driver);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d3e14cb43924..3d02d0094132 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2612,7 +2612,6 @@ struct i915_params {
int use_mmio_flip;
int mmio_debug;
bool verbose_state_checks;
- bool nuclear_pageflip;
int edp_vswing;
};
extern struct i915_params i915 __read_mostly;
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 7983fe48a654..5f4e7295295f 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -51,7 +51,6 @@ struct i915_params i915 __read_mostly = {
.use_mmio_flip = 0,
.mmio_debug = 0,
.verbose_state_checks = 1,
- .nuclear_pageflip = 0,
.edp_vswing = 0,
};
@@ -176,10 +175,6 @@ module_param_named(verbose_state_checks,
i915.verbose_state_checks, bool, 0600);
MODULE_PARM_DESC(verbose_state_checks,
"Enable verbose logs (ie. WARN_ON()) in case of unexpected hw state
conditions.");
-module_param_named_unsafe(nuclear_pageflip, i915.nuclear_pageflip, bool, 0600);
-MODULE_PARM_DESC(nuclear_pageflip,
-"Force atomic modeset functionality; only planes work for now
(default: false).");
-
/* WA to get away with the default setting in VBT for early platforms.Will be
removed */
module_param_named_unsafe(edp_vswing, i915.edp_vswing, int, 0400);
MODULE_PARM_DESC(edp_vswing,
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index dcf4fb458649..e2531cf59266 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -35,129 +35,6 @@
#include
#include "intel_drv.h"
-
-/**
- * intel_atomic_check - validate state object
- * @dev: drm device
- * @state: state to validate
- */
-int intel_atomic_check(struct drm_device *dev,
- struct drm_atomic_state *state)
-{
- int nplanes = dev->mode_config.num_total_plane;
- int ncrtcs = dev->mode_config.num_crtc;
- int nconnectors = dev->mode_config.num_connector;
- enum pipe nuclear_pipe = INVALID_PIPE;
- struct intel_crtc *nuclear_crtc = NULL;
- struct intel_crtc_state *crtc_state = NULL;
- int ret;
- int i;
- bool not_nuclear = false;
-
- to_intel_atomic_state(state)->cdclk = to_i915(dev)->cdclk_freq;
-
- /*
-* FIXME: At the moment, we only support "nuclear pageflip" on a
-* single CRTC. Cross-crtc updates will be added later.
-*/
- for (i = 0; i < nplanes; i++) {
- struct intel_plane *plane = to_intel_plane(state->planes[i]);
- if (!plane)
- continue;
-
- if (nuclear_pipe == INVALID_PIPE) {
- nuclear_pipe = plane->pipe;
- } else if (nuclear_pipe != plane->pipe) {
- DRM_DEBUG_KMS("i915 only support atomic plane
operations on a single CRTC at the moment\n");
- return -EINVAL;
- }
- }
-
- /*
-* FIXME: We only handle planes for now; make sure there are no CRTC's
-* or connectors involved.
-*/
- state->allow_modeset = false;
- for (i = 0; i < ncrtcs; i++) {
- struct intel_crtc *crtc = to_intel_crtc(state->crtcs[i]);
- if (crtc)
- memset(&crtc->atomic, 0, sizeof(crtc->atomic));
- if (crtc && crtc->pipe != nuclear_pipe)
- not_nuclear = true;
- if (crtc && crtc->pipe == nuclear_pipe) {
- nuclear_crtc = crtc;
- crtc_state = to_intel_crtc_state(state->crtc_states[i]);
- }
- }
- for (i = 0; i < nconnectors; i++)
- if (state->connectors[i] != NULL)
- not_nuclear = true;
-
- if (
Re: [Intel-gfx] [PATCH 5/9] drm/i915: Clear out DPLL state from pipe config in DSI get config
On Mon, Jul 13, 2015 at 03:49:44PM +0530, Sivakumar Thulasimani wrote:
>
>
> On 7/13/2015 2:21 PM, Daniel Vetter wrote:
> >On Fri, Jul 10, 2015 at 05:37:07PM +0530, Sivakumar Thulasimani wrote:
> >>
> >>On 7/1/2015 6:12 PM, Daniel Vetter wrote:
> >>>On Tue, Jun 30, 2015 at 02:50:33PM +0300, Ville Syrjälä wrote:
> On Tue, Jun 30, 2015 at 12:13:37PM +0200, Daniel Vetter wrote:
> >On Mon, Jun 29, 2015 at 08:08:27PM +0300, Ville Syrjälä wrote:
> >>On Mon, Jun 29, 2015 at 07:56:05PM +0300, Ville Syrjälä wrote:
> >>>On Mon, Jun 29, 2015 at 06:42:11PM +0200, Daniel Vetter wrote:
> On Mon, Jun 29, 2015 at 03:25:52PM +0300,
> ville.syrj...@linux.intel.com wrote:
> >From: Ville Syrjälä
> >
> >VLV/CHV don't use the DPLL with DSI, so just clear out the DPLL state
> >from the pipe_config in intel_dsi_get_config(). This avoids spurious
> >state checker warnings. We already did it this way for DPLL_MD, but
> >do
> >it for DPLL too.
> >
> >Toss in a WARN to intel_dsi_pre_enable() to make sure the ref clocks
> >are enabled however. Supposedly they have some meaning to DSI too.
> >We now keep the ref clocks always enabled while the disp2d well is
> >enabled.
> >
> >Signed-off-by: Ville Syrjälä
> >---
> > drivers/gpu/drm/i915/intel_dsi.c | 15 +--
> > 1 file changed, 5 insertions(+), 10 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> >b/drivers/gpu/drm/i915/intel_dsi.c
> >index 36e2148..92bb252 100644
> >--- a/drivers/gpu/drm/i915/intel_dsi.c
> >+++ b/drivers/gpu/drm/i915/intel_dsi.c
> >@@ -421,18 +421,12 @@ static void intel_dsi_pre_enable(struct
> >intel_encoder *encoder)
> > /* Disable DPOunit clock gating, can stall pipe
> > * and we need DPLL REFA always enabled */
> >-tmp = I915_READ(DPLL(pipe));
> >-tmp |= DPLL_REF_CLK_ENABLE_VLV;
> >-I915_WRITE(DPLL(pipe), tmp);
> >-
> >-/* update the hw state for DPLL */
> >-intel_crtc->config->dpll_hw_state.dpll =
> >DPLL_INTEGRATED_REF_CLK_VLV |
> >-DPLL_REF_CLK_ENABLE_VLV | DPLL_VGA_MODE_DIS;
> >-
> > tmp = I915_READ(DSPCLK_GATE_D);
> > tmp |= DPOUNIT_CLOCK_GATE_DISABLE;
> > I915_WRITE(DSPCLK_GATE_D, tmp);
> >+WARN_ON((I915_READ(DPLL(pipe)) & DPLL_REF_CLK_ENABLE_VLV) == 0);
> >+
> > /* put device in ready state */
> > intel_dsi_device_ready(encoder);
> >@@ -635,9 +629,10 @@ static void intel_dsi_get_config(struct
> >intel_encoder *encoder,
> > DRM_DEBUG_KMS("\n");
> > /*
> >- * DPLL_MD is not used in case of DSI, reading will get some
> >default value
> >- * set dpll_md = 0
> >+ * DPLL is not used in case of DSI, reading will getsome
> >default value.
> >+ * Clear the state to keep the state checker happy.
> > */
> >+pipe_config->dpll_hw_state.dpll = 0;
> > pipe_config->dpll_hw_state.dpll_md = 0;
> State configs are supposed to be kzallocated. Needing this indicates a
> pretty serious bug - I'd vote to instead also ditch the dpll_md line
> and
> fix the offender.
> >>>There is no offender really. We read out the DPLL state before we know
> >>>which ports are active and hence can't tell at that point if the
> >>>information is really relevant.
> >So the bios leaves the DPLL enabled even when using a DSI port? Or do we
> >miss to check some routing bits in get_clock?
> Not necessarily enabled, but there are other bits in there that could be
> left in any state basically. The DSI port simply doesn't care.
> >>>If the enable bit is what's gating things here then we should just forgo
> >>>reading out any dpll register state if that's not set. Looking at the
> >>>vlv/chv state readout code that seems to be the trouble - there's nothing
> >>>guarding the register reads into the pipe_config at all. Didn't matter
> >>>pre-vlv without dsi since enable pipe should imply enabled dpll, but
> >>>obviously won't work correctly with dsi. Can you please spin such a patch
> >>>and remove the hacks here from dsi_get_config?
> >>>-Daniel
> >>Not sure i understand the point of contention here, just noticed this after
> >>i gave my RB :)
> >>so my justification on why this is proper is that DSI is not supposed to
> >>touch DPLL register
> >>any place we access dpll_hw_state.dpll is under !is_dsi check so that
> >>ensures that we dont
> >>program DPLL register for dsi panel. it was wrong to have originally modfied
> >>DPLL register
> >>inside intel_dsi_pre_enable so removal is fine. setting it to zero in
> >>intel_dsi_get_confi
Re: [Intel-gfx] [PATCH v4 03/18] drm/i915/gen8: Add PML4 structure
On 7/11/2015 9:02 PM, Chris Wilson wrote:
On Tue, Jul 07, 2015 at 04:14:48PM +0100, Michel Thierry wrote:
Introduces the Page Map Level 4 (PML4), ie. the new top level structure
of the page tables.
To facilitate testing, 48b mode will be available on Broadwell and
GEN9+, when i915.enable_ppgtt = 3.
Cc: Akash Goel
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_drv.h | 7 ++-
drivers/gpu/drm/i915/i915_gem_gtt.c | 40 -
drivers/gpu/drm/i915/i915_gem_gtt.h | 35
3 files changed, 59 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 464b28d..de3a5d1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2497,7 +2497,12 @@ struct drm_i915_cmd_table {
#define HAS_HW_CONTEXTS(dev) (INTEL_INFO(dev)->gen >= 6)
#define HAS_LOGICAL_RING_CONTEXTS(dev)(INTEL_INFO(dev)->gen >= 8)
#define USES_PPGTT(dev) (i915.enable_ppgtt)
-#define USES_FULL_PPGTT(dev) (i915.enable_ppgtt == 2)
+#define USES_FULL_PPGTT(dev) (i915.enable_ppgtt >= 2)
+#ifdef CONFIG_X86_64
+# define USES_FULL_48BIT_PPGTT(dev)(i915.enable_ppgtt == 3)
+#else
+# define USES_FULL_48BIT_PPGTT(dev)false
+#endif
This requires an explanation.
-Chris
Actually, this is no longer necessary after Mika's changes:
commit c44ef60e437019b8ca1dab8b4d2e8761fd4ce1e9
Author: Mika Kuoppala
Date: Thu Jun 25 18:35:05 2015 +0300
drm/i915/gtt: Allow >= 4GB sizes for vm.
___
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: remove unused has_dma_mapping flag
On Wed, Jul 08, 2015 at 06:43:23PM +0100, Chris Wilson wrote: > On Wed, Jul 08, 2015 at 07:18:59PM +0300, Imre Deak wrote: > > After the previous patch this flag will check always clear, as it's > > never set for shmem backed and userptr objects, so we can remove it. > > > > Signed-off-by: Imre Deak > > Mentioned a trivial obj->get_page bugfix for > __i915_gem_userptr_set_pages(), and then went on an archaelogical dig to > understand why I didn't think of this earlier. Apparently, it just never > occurred to me that I could remove this flag introduced for > i915_gem_prime when we did the get_pages/put_pages support for it. > > Both patches (incl. the minor fix above for 1), > Reviewed-by: Chris Wilson Applied to -fixes (too lazy for a backmerge), thanks. -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
Re: [Intel-gfx] [-next] WARNING at i915_gem_track_fb
On (07/13/15 16:35), Daniel Vetter wrote: > On Mon, Jul 13, 2015 at 09:51:39PM +0900, Sergey Senozhatsky wrote: > > 4.2.0-rc2-next-20150713 > > Is this also an issue in the 4.2-rc series or only in -next? don't know how to reproduce this, but I'll check. -ss > > > > [ 1239.783862] [ cut here ] > > [ 1239.783892] WARNING: CPU: 0 PID: 364 at > > drivers/gpu/drm/i915/i915_gem.c:5368 i915_gem_track_fb+0xdc/0x106 [i915]() > > [ 1239.783894] WARN_ON(new->frontbuffer_bits & frontbuffer_bits) > > [ 1239.783895] Modules linked in: > > [ 1239.783897] zram lz4_decompress lz4_compress lzo_compress > > lzo_decompress zsmalloc sha256_ssse3 sha256_generic hmac drbg ctr ccm > > mousedev arc4 nls_iso8859_1 nls_cp437 vfat fat coretemp hwmon iwlmvm i915 > > mac80211 cfbfillrect cfbimgblt intel_powerclamp i2c_algo_bit crc32c_intel > > iwlwifi i2c_i801 serio_raw cfbcopyarea psmouse drm_kms_helper ie31200_edac > > cfg80211 lpc_ich r8169 atkbd mfd_core mii thermal drm edac_core libps2 > > mxm_wmi wmi i8042 evdev video serio backlight processor ext4 crc16 mbcache > > jbd2 sd_mod ehci_pci ehci_hcd ahci libahci libata xhci_pci xhci_hcd > > scsi_mod usbcore usb_common > > [ 1239.783942] CPU: 0 PID: 364 Comm: Xorg Not tainted > > 4.2.0-rc2-next-20150713-dbg-00017-g16b87ed-dirty #183 > > [ 1239.783944] 0009 88041c5379d8 813a19ac > > 81077163 > > [ 1239.783947] 88041c537a28 88041c537a18 8103b5d9 > > 88041c5379f8 > > [ 1239.783950] a0533273 0002 88041c578000 > > 88041c578000 > > [ 1239.783953] Call Trace: > > [ 1239.783961] [] dump_stack+0x4c/0x65 > > [ 1239.783965] [] ? up+0x39/0x3e > > [ 1239.783968] [] warn_slowpath_common+0x9b/0xb5 > > [ 1239.783986] [] ? i915_gem_track_fb+0xdc/0x106 [i915] > > [ 1239.783987] [] warn_slowpath_fmt+0x46/0x48 > > [ 1239.784002] [] i915_gem_track_fb+0xdc/0x106 [i915] > > [ 1239.784026] [] intel_prepare_plane_fb+0xb1/0x101 > > [i915] > > [ 1239.784033] [] > > drm_atomic_helper_prepare_planes+0x5b/0xb8 [drm_kms_helper] > > [ 1239.784055] [] intel_atomic_commit+0x46/0xc0 [i915] > > [ 1239.784072] [] drm_atomic_commit+0x4d/0x52 [drm] > > [ 1239.784078] [] > > drm_atomic_helper_update_plane+0xca/0x119 [drm_kms_helper] > > [ 1239.784092] [] __setplane_internal+0x24e/0x2ae [drm] > > [ 1239.784103] [] drm_mode_cursor_universal+0x149/0x197 > > [drm] > > [ 1239.784113] [] ? drm_mode_setcrtc+0x428/0x428 [drm] > > [ 1239.784122] [] drm_mode_cursor_common+0xb5/0x156 [drm] > > [ 1239.784132] [] drm_mode_cursor_ioctl+0x37/0x39 [drm] > > [ 1239.784140] [] drm_ioctl+0x287/0x415 [drm] > > [ 1239.784143] [] ? __lock_is_held+0x3c/0x57 > > [ 1239.784146] [] ? __fget+0x170/0x1a1 > > [ 1239.784148] [] do_vfs_ioctl+0x455/0x4dd > > [ 1239.784151] [] ? __fget_light+0x65/0x75 > > [ 1239.784153] [] SyS_ioctl+0x44/0x63 > > [ 1239.784155] [] entry_SYSCALL_64_fastpath+0x12/0x6f > > [ 1239.784157] ---[ end trace 67b32b389e7fe7df ]--- > > > > -ss > > ___ > > 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] [-next] WARNING at i915_gem_track_fb
Op 13-07-15 om 14:51 schreef Sergey Senozhatsky: > 4.2.0-rc2-next-20150713 > > [ 1239.783862] [ cut here ] > [ 1239.783892] WARNING: CPU: 0 PID: 364 at > drivers/gpu/drm/i915/i915_gem.c:5368 i915_gem_track_fb+0xdc/0x106 [i915]() > [ 1239.783894] WARN_ON(new->frontbuffer_bits & frontbuffer_bits) > [ 1239.783895] Modules linked in: > [ 1239.783897] zram lz4_decompress lz4_compress lzo_compress lzo_decompress > zsmalloc sha256_ssse3 sha256_generic hmac drbg ctr ccm mousedev arc4 > nls_iso8859_1 nls_cp437 vfat fat coretemp hwmon iwlmvm i915 mac80211 > cfbfillrect cfbimgblt intel_powerclamp i2c_algo_bit crc32c_intel iwlwifi > i2c_i801 serio_raw cfbcopyarea psmouse drm_kms_helper ie31200_edac cfg80211 > lpc_ich r8169 atkbd mfd_core mii thermal drm edac_core libps2 mxm_wmi wmi > i8042 evdev video serio backlight processor ext4 crc16 mbcache jbd2 sd_mod > ehci_pci ehci_hcd ahci libahci libata xhci_pci xhci_hcd scsi_mod usbcore > usb_common > [ 1239.783942] CPU: 0 PID: 364 Comm: Xorg Not tainted > -dbg-00017-g16b87ed-dirty #183 > [ 1239.783944] 0009 88041c5379d8 813a19ac > 81077163 > [ 1239.783947] 88041c537a28 88041c537a18 8103b5d9 > 88041c5379f8 > [ 1239.783950] a0533273 0002 88041c578000 > 88041c578000 > [ 1239.783953] Call Trace: > [ 1239.783961] [] dump_stack+0x4c/0x65 > [ 1239.783965] [] ? up+0x39/0x3e > [ 1239.783968] [] warn_slowpath_common+0x9b/0xb5 > [ 1239.783986] [] ? i915_gem_track_fb+0xdc/0x106 [i915] > [ 1239.783987] [] warn_slowpath_fmt+0x46/0x48 > [ 1239.784002] [] i915_gem_track_fb+0xdc/0x106 [i915] > [ 1239.784026] [] intel_prepare_plane_fb+0xb1/0x101 [i915] > [ 1239.784033] [] > drm_atomic_helper_prepare_planes+0x5b/0xb8 [drm_kms_helper] > [ 1239.784055] [] intel_atomic_commit+0x46/0xc0 [i915] > [ 1239.784072] [] drm_atomic_commit+0x4d/0x52 [drm] > [ 1239.784078] [] > drm_atomic_helper_update_plane+0xca/0x119 [drm_kms_helper] > [ 1239.784092] [] __setplane_internal+0x24e/0x2ae [drm] > [ 1239.784103] [] drm_mode_cursor_universal+0x149/0x197 > [drm] > [ 1239.784113] [] ? drm_mode_setcrtc+0x428/0x428 [drm] > [ 1239.784122] [] drm_mode_cursor_common+0xb5/0x156 [drm] > [ 1239.784132] [] drm_mode_cursor_ioctl+0x37/0x39 [drm] > [ 1239.784140] [] drm_ioctl+0x287/0x415 [drm] > [ 1239.784143] [] ? __lock_is_held+0x3c/0x57 > [ 1239.784146] [] ? __fget+0x170/0x1a1 > [ 1239.784148] [] do_vfs_ioctl+0x455/0x4dd > [ 1239.784151] [] ? __fget_light+0x65/0x75 > [ 1239.784153] [] SyS_ioctl+0x44/0x63 > [ 1239.784155] [] entry_SYSCALL_64_fastpath+0x12/0x6f > [ 1239.784157] ---[ end trace 67b32b389e7fe7df ]--- > Do you have some steps to reproduce? ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/4] drm/i915/gen9: Add WaDisableCtxRestoreArbitration workaround
On Mon, Jul 13, 2015 at 03:31:45PM +0300, Mika Kuoppala wrote:
> Arun Siluvery writes:
>
> > In Indirect and Per context w/a batch buffer,
> > +WaDisableCtxRestoreArbitration
> >
> > v2: SKL revision id was used for BXT, copy paste error found during
> > internal review (Bob Beckett).
> >
> > Cc: Robert Beckett
> > Cc: Imre Deak
> > Signed-off-by: Arun Siluvery
>
> Reviewed-by: Mika Kuoppala
Merged first two patches of this series to dinq, thanks.
-Daniel
>
> > ---
> > drivers/gpu/drm/i915/intel_lrc.c | 13 +++--
> > 1 file changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index 1e88b3b..e84fc52 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -1274,10 +1274,13 @@ static int gen9_init_indirectctx_bb(struct
> > intel_engine_cs *ring,
> > uint32_t *const batch,
> > uint32_t *offset)
> > {
> > + struct drm_device *dev = ring->dev;
> > uint32_t index = wa_ctx_start(wa_ctx, *offset, CACHELINE_DWORDS);
> >
> > - /* FIXME: Replace me with WA */
> > - wa_ctx_emit(batch, MI_NOOP);
> > + /* WaDisableCtxRestoreArbitration:skl,bxt */
> > + if ((IS_SKYLAKE(dev) && (INTEL_REVID(dev) <= SKL_REVID_D0)) ||
> > + (IS_BROXTON(dev) && (INTEL_REVID(dev) == BXT_REVID_A0)))
> > + wa_ctx_emit(batch, MI_ARB_ON_OFF | MI_ARB_DISABLE);
> >
> > /* Pad to end of cacheline */
> > while (index % CACHELINE_DWORDS)
> > @@ -1291,8 +1294,14 @@ static int gen9_init_perctx_bb(struct
> > intel_engine_cs *ring,
> >uint32_t *const batch,
> >uint32_t *offset)
> > {
> > + struct drm_device *dev = ring->dev;
> > uint32_t index = wa_ctx_start(wa_ctx, *offset, CACHELINE_DWORDS);
> >
> > + /* WaDisableCtxRestoreArbitration:skl,bxt */
> > + if ((IS_SKYLAKE(dev) && (INTEL_REVID(dev) <= SKL_REVID_D0)) ||
> > + (IS_BROXTON(dev) && (INTEL_REVID(dev) == BXT_REVID_A0)))
> > + wa_ctx_emit(batch, MI_ARB_ON_OFF | MI_ARB_ENABLE);
> > +
> > wa_ctx_emit(batch, MI_BATCH_BUFFER_END);
> >
> > return wa_ctx_end(wa_ctx, *offset = index, 1);
> > --
> > 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
--
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 v2 2/4] drm/i915/gen9: Add WaDisableCtxRestoreArbitration workaround
On Mon, Jul 13, 2015 at 04:49:37PM +0200, Daniel Vetter wrote: > On Mon, Jul 13, 2015 at 03:31:45PM +0300, Mika Kuoppala wrote: > > Arun Siluvery writes: > > > > > In Indirect and Per context w/a batch buffer, > > > +WaDisableCtxRestoreArbitration > > > > > > v2: SKL revision id was used for BXT, copy paste error found during > > > internal review (Bob Beckett). > > > > > > Cc: Robert Beckett > > > Cc: Imre Deak > > > Signed-off-by: Arun Siluvery > > > > Reviewed-by: Mika Kuoppala > > Merged first two patches of this series to dinq, thanks. Actually strike that, these all need rebasing. Dropped again. -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
Re: [Intel-gfx] [PATCH v2] drm/i915: Don't forget to mark crtc as inactive after disable
On Mon, Jul 13, 2015 at 11:42:34AM +0100, Damien Lespiau wrote: > On Mon, Jul 13, 2015 at 11:49:49AM +0200, Daniel Vetter wrote: > > On Mon, Jul 13, 2015 at 11:10:51AM +0200, Maarten Lankhorst wrote: > > > Op 10-07-15 om 13:22 schreef Damien Lespiau: > > > > Hi Patrik, > > > > > > > > Please do Cc the patch author and reviewer when finding a regression, > > > > they are superb candidates for the review, especially when they are busy > > > > rewriting the display code. > > > > Yeah you need to list everyone you want to Cc: explicitly. > > Also need the Bugzilla reference when fixing a bug. In this case: > > https://bugs.freedesktop.org/show_bug.cgi?id=91203 Added, thanks for supplying the link. -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
Re: [Intel-gfx] [PATCH] drm/i915: Check live status before reading edid
On Mon, Jul 13, 2015 at 04:35:00PM +0530, Sonika Jindal wrote:
> Adding this for SKL onwards.
>
> v2: Adding checks for VLV/CHV as well. Reusing old ibx and g4x functions
> to check digital port status. Adding a separate function to get bxt live
> status (Daniel)
>
> Signed-off-by: Sonika Jindal
> ---
> drivers/gpu/drm/i915/intel_dp.c |4 ++--
> drivers/gpu/drm/i915/intel_drv.h |2 ++
> drivers/gpu/drm/i915/intel_hdmi.c | 42
> +
> 3 files changed, 42 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 4ebfc3a..7b54b9d 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4443,8 +4443,8 @@ ironlake_dp_detect(struct intel_dp *intel_dp)
> return intel_dp_detect_dpcd(intel_dp);
> }
>
> -static int g4x_digital_port_connected(struct drm_device *dev,
> -struct intel_digital_port
> *intel_dig_port)
> +int g4x_digital_port_connected(struct drm_device *dev,
> +struct intel_digital_port *intel_dig_port)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> uint32_t bit;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index a47fbc3..30c8dd6 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1187,6 +1187,8 @@ void intel_edp_drrs_disable(struct intel_dp *intel_dp);
> void intel_edp_drrs_invalidate(struct drm_device *dev,
> unsigned frontbuffer_bits);
> void intel_edp_drrs_flush(struct drm_device *dev, unsigned frontbuffer_bits);
> +int g4x_digital_port_connected(struct drm_device *dev,
> +struct intel_digital_port *intel_dig_port);
>
> /* intel_dp_mst.c */
> int intel_dp_mst_encoder_init(struct intel_digital_port *intel_dig_port, int
> conn_id);
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 1fb6919..7eb0d0e 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1300,6 +1300,39 @@ intel_hdmi_unset_edid(struct drm_connector *connector)
> to_intel_connector(connector)->detect_edid = NULL;
> }
>
> +static bool bxt_port_connected(struct drm_i915_private *dev_priv,
> +struct intel_digital_port *port)
> +{
> + u32 temp = I915_READ(GEN8_DE_PORT_ISR);
> +
> + switch (port->port) {
> + case PORT_B:
> + return temp & BXT_DE_PORT_HP_DDIB;
> +
> + case PORT_C:
> + return temp & BXT_DE_PORT_HP_DDIC;
> +
> + default:
> + return false;
> +
> + }
> +}
> +
> +static bool intel_hdmi_live_status(struct intel_digital_port *intel_dig_port)
> +{
> + struct drm_device *dev = intel_dig_port->base.base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> +
> + if (IS_VALLEYVIEW(dev))
> + return g4x_digital_port_connected(dev, intel_dig_port);
> + else if (IS_SKYLAKE(dev))
> + return ibx_digital_port_connected(dev_priv, intel_dig_port);
> + else if (IS_BROXTON(dev))
> + return bxt_port_connected(dev_priv, intel_dig_port);
Really I want this to be rolled out for all platforms, together with the
fix for handling hpd interrupts. Together with a reference to the old
commits we had to revert because it didn't work.
I want to test this on my ivb (since that's the machine where I can
readily reproduce this bug), and if it still doesn't work there I won't
take this.
-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
Re: [Intel-gfx] [PATCH] drm/i915: Set edid from init and not from detect
On Mon, Jul 13, 2015 at 05:29:12PM +0530, Jindal, Sonika wrote: > > > On 7/13/2015 5:10 PM, Chris Wilson wrote: > >On Mon, Jul 13, 2015 at 04:19:15PM +0530, Sonika Jindal wrote: > >>During init_connector set the edid, then edid will be set/unset only during > >>hotplug. For the sake of older platforms where HPD is not stable, let edid > >>read happen from detect as well only if it is forced to do so. > >> > >>v2: Removing the 'force' check, instead let detect call read the edid for > >>platforms older than gen 7 (Shashank) > > > >That's enough worse. We now have a random gen check with no rationale > >for why you suddenly believe all manufacturers have fixed their wiring. > >There is no reason to believe that gen7 suddenly works is there? If > >there is, why don't you mention it? > >-Chris > > > This gen7 check is to be on the safer side not to affect older paltforms. > For CHV/VLV, already the live status check is stable enough to determine if > we can read edid or not. In VPG production branches we have this patch > already available and it was tested with variety of monitors extensively. So > we now read the edid only during init and during hotplug. > For SKL, the "[PATCH] drm/i915: Handle HPD when it has actually occurred" > patch makes HPD stable enough. > So, we can rely on the edid read from init_connector instead of reading edid > on every detect call. Again, not going to take this with random gen checks. I want your fix for handling hpd on other platforms, then roll this out everywhere. -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
Re: [Intel-gfx] [PATCH i-g-t] lib/igt_gt.c : allow changes to stop_rings mode bits
On Mon, Jul 13, 2015 at 09:43:11AM +, Gore, Tim wrote: > > > Tim Gore > Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ > > > -Original Message- > > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel > > Vetter > > Sent: Monday, July 13, 2015 10:30 AM > > To: Gore, Tim > > Cc: intel-gfx@lists.freedesktop.org; Wood, Thomas > > Subject: Re: [Intel-gfx] [PATCH i-g-t] lib/igt_gt.c : allow changes to > > stop_rings > > mode bits > > > > On Fri, Jul 10, 2015 at 02:06:06PM +0100, tim.g...@intel.com wrote: > > > From: Tim Gore > > > > > > In function igt_set_stop_rings, the test > > > igt_assert_f(flags == 0 || current == 0, .. > > > > > > will fail if we are trying to force a hang but the > > > STOP_RINGS_ALLOW_BAN or STOP_RINGS_ALLOW_ERROR bit is set. > > > With the introduction of per ring resets in the driver (in android) > > > these bits do not get cleared to zero when an individual ring is > > > reset. This causes subsequent attempt to cause a ring hang via this > > > function to fail, leading to several igt tests failing (ie > > > gem_reset_stats subtest ban-xxx etc). > > > > Fix tdr to reset these instead? > > -Daniel > > > I could change tdr, but why. When the TDR handles a ring hang and resets the > ring, > why would it modify the flag that defines if the driver should ban a > frequently hanging > context? If we get rid of the stop_rings interface, as Chris Wilson > suggested, we would > still need to keep the STOP_RING_ALLOW_BAN/ALLOW_ERRORS bits in debugfs, > but you would not expect to have to re-write these bits each time there is a > ring > reset. The fix current hang recover code to no reset this, add some grace period, then push this patch to igt. We don't have full-blown abi guarantees for debugfs/igt stuff, but I want at least a few months (really last released kernel&igt) of backwards/forward compatibility. And inconsistent behaviour isn't great imo. -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
Re: [Intel-gfx] [PATCH i-g-t] tests/gem_reset_stats.c: fix "ban" tests with scheduler
On Mon, Jul 13, 2015 at 10:09:59AM +, Gore, Tim wrote: > > > Tim Gore > Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ > > > > -Original Message- > > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel > > Vetter > > Sent: Monday, July 13, 2015 10:35 AM > > To: Gore, Tim > > Cc: intel-gfx@lists.freedesktop.org; Wood, Thomas; Kuoppala, Mika > > Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/gem_reset_stats.c: fix "ban" > > tests > > with scheduler > > > > On Fri, Jul 10, 2015 at 02:26:59PM +0100, tim.g...@intel.com wrote: > > > From: Tim Gore > > > > > > The tests for context banning fail when the gpu scheduler is enabled. > > > The test causes a hang (using an infinite loop > > > batch) and then queues up some work behind it on both the hanging > > > context and also on a second "good" context. On the "good" context it > > > queues up 2 batch buffers. After the hanging ring has been reset (not > > > a full gpu reset) the test checks the values of batch_active and > > > batch_pending returned by the i915_get_reset_stats_ioctl. For the > > > "good" > > > context it expects to see batch_pending == 2, because two batch > > > buffers we queued up behind the hang on this context. But, with the > > > scheduler enabled (android, gen8), one of these batch buffers is still > > > waiting in the scheduler and has not made it as far as the > > > ring->request_list, so this batch buffer is unaffected by > > > the ring reset, and batch_pending is only 1. > > > > > > I considered putting in a test for the scheduler being enabled, but > > > decided that a simpler solution is to only queue up 1 batch buffer on > > > the good context. This does not change the test logic in any way and > > > ensures that we should always have batch_pending=1, with or without > > > the scheduler. > > > > For the scheduler/tdr we probably need to split this up into two testcases > > each: > > - one where the 2nd batch depends upon the first (cross-context depency). > > - one where the 2nd batch doesn't depend upon the first (should execute > > unhampered with scheduler/tdr). > > > > Since we don't yet have a scheduler/tdr both of these will result in the > > same > > outcome (since there's always the temporal depency). But with your patch > > you only test the 2nd case (and incompletely, we should assert that the 2nd > > batch did run) and ignore the first case. > > > > In short this failure here is telling you that your test coverage for these > > features is lacking. The correct fix is not to mangle the existing, but fix > > it up to > > correctly cover the new expectations in all cases. And that should be done > > as > > part of the tdr/scheduler submission. > > -Daniel > > > Should gem_rest_stats be testing the operation of the scheduler? I would have > thought that the scheduler operation should have its own test(s). > Gem_reset_stats > is just about the reset mechanism and the stats collected. I can add this > test, just > seems like the wrong place. Well gem_reset_stats assumes that a hang will victimize all subsequent batches, irrespective of context. tdr/scheduler change that rather fundamentally (which is the entire point really, at least of tdr). So yeah we need to adjust those existing testcase. And I think it's clearer if we do that by changing the existing test-cases, that way the impact on existing features for new code is much clearer. -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
Re: [Intel-gfx] [-next] WARNING at i915_gem_track_fb
On (07/13/15 16:46), Maarten Lankhorst wrote: > > [ 1239.783961] [] dump_stack+0x4c/0x65 > > [ 1239.783965] [] ? up+0x39/0x3e > > [ 1239.783968] [] warn_slowpath_common+0x9b/0xb5 > > [ 1239.783986] [] ? i915_gem_track_fb+0xdc/0x106 [i915] > > [ 1239.783987] [] warn_slowpath_fmt+0x46/0x48 > > [ 1239.784002] [] i915_gem_track_fb+0xdc/0x106 [i915] > > [ 1239.784026] [] intel_prepare_plane_fb+0xb1/0x101 > > [i915] > > [ 1239.784033] [] > > drm_atomic_helper_prepare_planes+0x5b/0xb8 [drm_kms_helper] > > [ 1239.784055] [] intel_atomic_commit+0x46/0xc0 [i915] > > [ 1239.784072] [] drm_atomic_commit+0x4d/0x52 [drm] > > [ 1239.784078] [] > > drm_atomic_helper_update_plane+0xca/0x119 [drm_kms_helper] > > [ 1239.784092] [] __setplane_internal+0x24e/0x2ae [drm] > > [ 1239.784103] [] drm_mode_cursor_universal+0x149/0x197 > > [drm] > > [ 1239.784113] [] ? drm_mode_setcrtc+0x428/0x428 [drm] > > [ 1239.784122] [] drm_mode_cursor_common+0xb5/0x156 [drm] > > [ 1239.784132] [] drm_mode_cursor_ioctl+0x37/0x39 [drm] > > [ 1239.784140] [] drm_ioctl+0x287/0x415 [drm] > > [ 1239.784143] [] ? __lock_is_held+0x3c/0x57 > > [ 1239.784146] [] ? __fget+0x170/0x1a1 > > [ 1239.784148] [] do_vfs_ioctl+0x455/0x4dd > > [ 1239.784151] [] ? __fget_light+0x65/0x75 > > [ 1239.784153] [] SyS_ioctl+0x44/0x63 > > [ 1239.784155] [] entry_SYSCALL_64_fastpath+0x12/0x6f > > [ 1239.784157] ---[ end trace 67b32b389e7fe7df ]--- > > > Do you have some steps to reproduce? > Unfortunately no. -ss ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 0/2] Add Pooled EU support
On 11/07/2015 20:09, Chris Wilson wrote: On Sat, Jul 11, 2015 at 08:05:05PM +0100, Chris Wilson wrote: On Fri, Jul 10, 2015 at 06:35:18PM +0100, Arun Siluvery wrote: These patches enabled Pooled EU support for BXT, they are implemented by Armin Reese. I am sending these patches in its current form for comments. These patches modify Golden batch to have a set of modification values where we can change the commands based on Gen. The commands to enable Pooled EU are inserted after MI_BATCH_BUFFER_END. If the given Gen supports this feature, modification values are used to replace MI_BATCH_BUFFER_END so we send commands to enable Pooled EU. These commands need to be part of this batch because they are to be initialized only once. Userspace will have option to query the availability of this feature, those changes are not included in this series. Would it not just be simpler to execute 2 batches? First holding the basic and common state for the gen, the second using subgen. That we have a chunk of binary data is nasty, but at least we can point to the generator and be able to decipher it and recreate it as required. Doing binary patching on top, on that path lies madness. I like this idea of sending 2 batches if that is acceptable. In this case we don't have to touch the golden batch and hence the generator tool and also not worry about using the correct binary blob as header. the setup in this case would be, 1. send golden batch 2. prepare and send batch to configure pooled EU as per subslice and EU count Why we have a separate tool in the first place, is it not possible to carry all of them in code or are there any restrictions in doing so? What is the minimum instruction sequence required to be able to setup the default EU state? Is it small enough that carrying it as code in the kernel is viable (and readable)? setting up of pooled EU configuration is only few instructions, it can be added to the driver. (That actually is critical here as currently we have to juggle multiple sources and look very carefully at what is being patched - I am not confident that we will not introduce mistakes in a week's time, let alone a year or two.) The alternative is to just say that the patch table is also autogenerated and for that to be simple and clear, and far more documentated as it relies on a strict protocol. The patch table is also auto generated using intel_null_state_gen tool but it is patched based on Gen. regards Arun -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [-next] WARNING at i915_gem_track_fb
On Mon, Jul 13, 2015 at 11:44:15PM +0900, Sergey Senozhatsky wrote: > On (07/13/15 16:35), Daniel Vetter wrote: > > On Mon, Jul 13, 2015 at 09:51:39PM +0900, Sergey Senozhatsky wrote: > > > 4.2.0-rc2-next-20150713 > > > > Is this also an issue in the 4.2-rc series or only in -next? > > don't know how to reproduce this, but I'll check. It goes boom somewhere from the cursor ioctl code, which means X is probably involved. Usual suspects are vt-switching, suspend/resume or cursor vs. DPMS. You can force a DPMS off from within X with $ xset dpms force off For suspend resume it occasionally matters whether you initiate it through the gui or by closing the lid or through timeout (if you're not connected to a wallplug). I hope this helps with figuring out a repro recipe. It could also be a race somewhere, in which case you won't be able to consistently reproduce this. -Daniel > > -ss > > > > > > > [ 1239.783862] [ cut here ] > > > [ 1239.783892] WARNING: CPU: 0 PID: 364 at > > > drivers/gpu/drm/i915/i915_gem.c:5368 i915_gem_track_fb+0xdc/0x106 [i915]() > > > [ 1239.783894] WARN_ON(new->frontbuffer_bits & frontbuffer_bits) > > > [ 1239.783895] Modules linked in: > > > [ 1239.783897] zram lz4_decompress lz4_compress lzo_compress > > > lzo_decompress zsmalloc sha256_ssse3 sha256_generic hmac drbg ctr ccm > > > mousedev arc4 nls_iso8859_1 nls_cp437 vfat fat coretemp hwmon iwlmvm i915 > > > mac80211 cfbfillrect cfbimgblt intel_powerclamp i2c_algo_bit crc32c_intel > > > iwlwifi i2c_i801 serio_raw cfbcopyarea psmouse drm_kms_helper > > > ie31200_edac cfg80211 lpc_ich r8169 atkbd mfd_core mii thermal drm > > > edac_core libps2 mxm_wmi wmi i8042 evdev video serio backlight processor > > > ext4 crc16 mbcache jbd2 sd_mod ehci_pci ehci_hcd ahci libahci libata > > > xhci_pci xhci_hcd scsi_mod usbcore usb_common > > > [ 1239.783942] CPU: 0 PID: 364 Comm: Xorg Not tainted > > > 4.2.0-rc2-next-20150713-dbg-00017-g16b87ed-dirty #183 > > > [ 1239.783944] 0009 88041c5379d8 813a19ac > > > 81077163 > > > [ 1239.783947] 88041c537a28 88041c537a18 8103b5d9 > > > 88041c5379f8 > > > [ 1239.783950] a0533273 0002 88041c578000 > > > 88041c578000 > > > [ 1239.783953] Call Trace: > > > [ 1239.783961] [] dump_stack+0x4c/0x65 > > > [ 1239.783965] [] ? up+0x39/0x3e > > > [ 1239.783968] [] warn_slowpath_common+0x9b/0xb5 > > > [ 1239.783986] [] ? i915_gem_track_fb+0xdc/0x106 [i915] > > > [ 1239.783987] [] warn_slowpath_fmt+0x46/0x48 > > > [ 1239.784002] [] i915_gem_track_fb+0xdc/0x106 [i915] > > > [ 1239.784026] [] intel_prepare_plane_fb+0xb1/0x101 > > > [i915] > > > [ 1239.784033] [] > > > drm_atomic_helper_prepare_planes+0x5b/0xb8 [drm_kms_helper] > > > [ 1239.784055] [] intel_atomic_commit+0x46/0xc0 [i915] > > > [ 1239.784072] [] drm_atomic_commit+0x4d/0x52 [drm] > > > [ 1239.784078] [] > > > drm_atomic_helper_update_plane+0xca/0x119 [drm_kms_helper] > > > [ 1239.784092] [] __setplane_internal+0x24e/0x2ae [drm] > > > [ 1239.784103] [] > > > drm_mode_cursor_universal+0x149/0x197 [drm] > > > [ 1239.784113] [] ? drm_mode_setcrtc+0x428/0x428 [drm] > > > [ 1239.784122] [] drm_mode_cursor_common+0xb5/0x156 > > > [drm] > > > [ 1239.784132] [] drm_mode_cursor_ioctl+0x37/0x39 [drm] > > > [ 1239.784140] [] drm_ioctl+0x287/0x415 [drm] > > > [ 1239.784143] [] ? __lock_is_held+0x3c/0x57 > > > [ 1239.784146] [] ? __fget+0x170/0x1a1 > > > [ 1239.784148] [] do_vfs_ioctl+0x455/0x4dd > > > [ 1239.784151] [] ? __fget_light+0x65/0x75 > > > [ 1239.784153] [] SyS_ioctl+0x44/0x63 > > > [ 1239.784155] [] entry_SYSCALL_64_fastpath+0x12/0x6f > > > [ 1239.784157] ---[ end trace 67b32b389e7fe7df ]--- > > > > > > -ss > > > ___ > > > 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 > > -- 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 04/13 v4] drm/i915: GuC-specific firmware loader
On Thu, Jul 09, 2015 at 07:29:05PM +0100, Dave Gordon wrote: > From: Alex Dai > > This fetches the required firmware image from the filesystem, > then loads it into the GuC's memory via a dedicated DMA engine. > > This patch is derived from GuC loading work originally done by > Vinit Azad and Ben Widawsky. > > v2: > Various improvements per review comments by Chris Wilson > > v3: > Removed 'wait' parameter to intel_guc_ucode_load() as firmware > prefetch is no longer supported in the common firmware loader, > per Daniel Vetter's request. > Firmware checker callback fn now returns errno rather than bool. > > v4: > Squash uC-independent code into GuC-specifc loader [Daniel Vetter] > Don't keep the driver working (by falling back to execlist mode) > if GuC firmware loading fails [Daniel Vetter] > > Issue: VIZ-4884 > Signed-off-by: Alex Dai > Signed-off-by: Dave Gordon I think this is it, one comment below. > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index dbbb649..e020309 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -5074,6 +5074,19 @@ i915_gem_init_hw(struct drm_device *dev) > goto out; > } > > + /* We can't enable contexts until all firmware is loaded */ > + ret = intel_guc_ucode_load(dev); To stay in line with the current flow I think the request_firmware + create fw bo object code should be move into gem_init so that gem_init_hw is only responsible for loading the fw in the bo into hw. That will take care of not trying to re-request the firmware from userspace in resume/gpu reset code, which should simplify the status handling a lot. Also with just declaring the gpu wedged we could instead move the check below into the init_hw part of the guc load process. That would nicely encapsulate that decision and I'd expect take care of the other status codes - in the end callers really only care about -EIO or not here. But imo we can polish that after merging. All my other higher-level concerns with this have been addressed, so I think this is good to go in after detailed code review. Thanks, 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] drm/i915: Forward all core DRM ioctls to core compat handling
From: Tvrtko Ursulin Previously only core DRM ioctls under the DRM_COMMAND_BASE were being forwarded, but the drm.h header suggests (and reality confirms) ones after (and including) DRM_COMMAND_END should be forwarded as well. Signed-off-by: Tvrtko Ursulin Cc: Daniel Vetter --- drivers/gpu/drm/i915/i915_ioc32.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_ioc32.c b/drivers/gpu/drm/i915/i915_ioc32.c index 176de6322e4d..23aa04cded6b 100644 --- a/drivers/gpu/drm/i915/i915_ioc32.c +++ b/drivers/gpu/drm/i915/i915_ioc32.c @@ -204,7 +204,7 @@ long i915_compat_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) drm_ioctl_compat_t *fn = NULL; int ret; - if (nr < DRM_COMMAND_BASE) + if (nr < DRM_COMMAND_BASE || nr >= DRM_COMMAND_END) return drm_compat_ioctl(filp, cmd, arg); if (nr < DRM_COMMAND_BASE + ARRAY_SIZE(i915_compat_ioctls)) -- 2.4.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: Provide compat ioctl for addfb2.1
From: Tvrtko Ursulin
Frame buffer modifiers extensions provided in;
commit e3eb3250d84ef97b766312345774367b6a310db8
Author: Rob Clark
Date: Thu Feb 5 14:41:52 2015 +
drm: add support for tiled/compressed/etc modifier in addfb2
Missed the structure packing/alignment problem where 64-bit
members were added after the odd number of 32-bit ones. This
makes the compiler produce structures of different sizes under
32- and 64-bit x86 targets and makes the ioctl need explicit
compat handling.
Signed-off-by: Tvrtko Ursulin
Cc: dri-de...@lists.freedesktop.org
Cc: Rob Clark
Cc: Daniel Stone
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_ioc32.c | 60 +
1 file changed, 60 insertions(+)
diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c
index aa8bbb460c57..2bea11bfb3ae 100644
--- a/drivers/gpu/drm/drm_ioc32.c
+++ b/drivers/gpu/drm/drm_ioc32.c
@@ -70,6 +70,8 @@
#define DRM_IOCTL_WAIT_VBLANK32DRM_IOWR(0x3a,
drm_wait_vblank32_t)
+#define DRM_IOCTL_MODE_ADDFB232DRM_IOWR(0xb8,
drm_mode_fb_cmd232_t)
+
typedef struct drm_version_32 {
int version_major;/**< Major version */
int version_minor;/**< Minor version */
@@ -1016,6 +1018,63 @@ static int compat_drm_wait_vblank(struct file *file,
unsigned int cmd,
return 0;
}
+typedef struct drm_mode_fb_cmd232 {
+ u32 fb_id;
+ u32 width;
+ u32 height;
+ u32 pixel_format;
+ u32 flags;
+ u32 handles[4];
+ u32 pitches[4];
+ u32 offsets[4];
+ u64 modifier[4];
+} __attribute__((packed)) drm_mode_fb_cmd232_t;
+
+static int compat_drm_mode_addfb2(struct file *file, unsigned int cmd,
+ unsigned long arg)
+{
+ drm_mode_fb_cmd232_t __user *argp = (void __user *)arg;
+ struct drm_mode_fb_cmd232 req32;
+ struct drm_mode_fb_cmd2 __user *req64;
+ int i;
+ int err;
+
+ if (copy_from_user(&req32, argp, sizeof(req32)))
+ return -EFAULT;
+
+ req64 = compat_alloc_user_space(sizeof(*req64));
+
+ if (!access_ok(VERIFY_WRITE, req64, sizeof(*req64))
+ || __put_user(req32.width, &req64->width)
+ || __put_user(req32.height, &req64->height)
+ || __put_user(req32.pixel_format, &req64->pixel_format)
+ || __put_user(req32.flags, &req64->flags))
+ return -EFAULT;
+
+ for (i = 0; i < 4; i++) {
+ if (__put_user(req32.handles[i], &req64->handles[i]))
+ return -EFAULT;
+ if (__put_user(req32.pitches[i], &req64->pitches[i]))
+ return -EFAULT;
+ if (__put_user(req32.offsets[i], &req64->offsets[i]))
+ return -EFAULT;
+ if (__put_user(req32.modifier[i], &req64->modifier[i]))
+ return -EFAULT;
+ }
+
+ err = drm_ioctl(file, DRM_IOCTL_MODE_ADDFB2, (unsigned long)req64);
+ if (err)
+ return err;
+
+ if (__get_user(req32.fb_id, &req64->fb_id))
+ return -EFAULT;
+
+ if (copy_to_user(argp, &req32, sizeof(req32)))
+ return -EFAULT;
+
+ return 0;
+}
+
static drm_ioctl_compat_t *drm_compat_ioctls[] = {
[DRM_IOCTL_NR(DRM_IOCTL_VERSION32)] = compat_drm_version,
[DRM_IOCTL_NR(DRM_IOCTL_GET_UNIQUE32)] = compat_drm_getunique,
@@ -1048,6 +1107,7 @@ static drm_ioctl_compat_t *drm_compat_ioctls[] = {
[DRM_IOCTL_NR(DRM_IOCTL_UPDATE_DRAW32)] = compat_drm_update_draw,
#endif
[DRM_IOCTL_NR(DRM_IOCTL_WAIT_VBLANK32)] = compat_drm_wait_vblank,
+ [DRM_IOCTL_NR(DRM_IOCTL_MODE_ADDFB232)] = compat_drm_mode_addfb2,
};
/**
--
2.4.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] lib/igt_gt.c : allow changes to stop_rings mode bits
Tim Gore Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ > -Original Message- > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel > Vetter > Sent: Monday, July 13, 2015 3:59 PM > To: Gore, Tim > Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org; Wood, Thomas > Subject: Re: [Intel-gfx] [PATCH i-g-t] lib/igt_gt.c : allow changes to > stop_rings > mode bits > > On Mon, Jul 13, 2015 at 09:43:11AM +, Gore, Tim wrote: > > > > > > Tim Gore > > Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon > > SN3 1RJ > > > > > -Original Message- > > > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of > > > Daniel Vetter > > > Sent: Monday, July 13, 2015 10:30 AM > > > To: Gore, Tim > > > Cc: intel-gfx@lists.freedesktop.org; Wood, Thomas > > > Subject: Re: [Intel-gfx] [PATCH i-g-t] lib/igt_gt.c : allow changes > > > to stop_rings mode bits > > > > > > On Fri, Jul 10, 2015 at 02:06:06PM +0100, tim.g...@intel.com wrote: > > > > From: Tim Gore > > > > > > > > In function igt_set_stop_rings, the test > > > > igt_assert_f(flags == 0 || current == 0, .. > > > > > > > > will fail if we are trying to force a hang but the > > > > STOP_RINGS_ALLOW_BAN or STOP_RINGS_ALLOW_ERROR bit is set. > > > > With the introduction of per ring resets in the driver (in > > > > android) these bits do not get cleared to zero when an individual > > > > ring is reset. This causes subsequent attempt to cause a ring hang > > > > via this function to fail, leading to several igt tests failing > > > > (ie gem_reset_stats subtest ban-xxx etc). > > > > > > Fix tdr to reset these instead? > > > -Daniel > > > > > I could change tdr, but why. When the TDR handles a ring hang and > > resets the ring, why would it modify the flag that defines if the > > driver should ban a frequently hanging context? If we get rid of the > > stop_rings interface, as Chris Wilson suggested, we would still need > > to keep the STOP_RING_ALLOW_BAN/ALLOW_ERRORS bits in debugfs, but > you > > would not expect to have to re-write these bits each time there is a ring > reset. > > The fix current hang recover code to no reset this, add some grace period, > then push this patch to igt. We don't have full-blown abi guarantees for > debugfs/igt stuff, but I want at least a few months (really last released > kernel&igt) of backwards/forward compatibility. And inconsistent behaviour > isn't great imo. > -Daniel Sorry Daniel, I didn't really follow that. I didn't want a gpu reset to clear the ALLOW_BAN bit, since this will defeat the point of this bit, except perhaps in test situations where you can keep setting it each time you deliberately cause a hang. It seems like the ALLOW_BAN bit has uses in real world situations, although I don't know it anyone uses it. Would you be more comfortable with Igt_assert_f ( ( flags ==0 ) || (( current & STOP_RING_ALL) ==0) && ((current ^ flags) & ~ STOP_RING_ALL == 0 ) ) So the either the new flags must be 0 (currently allowed) or the existing flags must indicate that all hangs are cleared (0 except possibly the mode bits) AND the mode bits you are writing are the same as the current values. ?? Tim > -- > 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
