- 27 Feb, 2017 7 commits
-
-
Daniel Vetter authored
Backmerge the main pull request to sync up with all the newly landed drivers. Otherwise we'll have chaos even before 4.12 started in earnest. Signed-off-by:Daniel Vetter <daniel.vetter@intel.com>
-
Ander Conselvan de Oliveira authored
According to bspec, the DDI IO power domains should be enabled after enabling the DPLL and mapping it to the DDI. The current order doesn't seem to create problems with Skylake and Kabylake, but causes enable timeouts in Geminilake. v2: Rebase. - Take power domain references before sanitizing encoders. (Imre) - Add comment to get_encoder_power_domains() defition. (Ander) v3: Don't put the domain if called with HSW/BDW's analog encoder. (CI) v4: Put IO power domain before unmapping DPLL. (Imre) - Change return type of intel_ddi_get_power_domains() to u64. (Imre) Cc: David Weinehall <david.weinehall@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: David Weinehall <david.weinehall@linux.intel.com> # v1 Reviewed-by:
Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170224141959.5955-1-ander.conselvan.de.oliveira@intel.com
-
Ander Conselvan de Oliveira authored
In Geminilake, the DDI IO power domains can't be enabled before a DPLL is running and mapped to the appropriate DDI. At least on Geminilake, attempting to enable those during init will lead to a timeout. The failure to enable the power domain also causes issues with the state verifier during resume from suspend. After all the init power domains are enabled, the call to intel_power_domains_sync_hw() from the resume path will cause the hw_enabled field on the respective power wells to be false while the usage count remains above zero. Further attempts to enable the power domain caused by a modeset will simply update the usage count without doing anything else. When the state verifier attempts to read the state of a DDI encoder, intel_display_power_get_if_enabled() returns false, leading to the following WARN: WARNING: CPU: 3 PID: 1743 at drivers/gpu/drm/i915/intel_display.c:7001 verify_connector_state.isra.80+0x26c/0x2b0 [i915] attached crtc is active, but connector isn't Modules linked in: i915(E) tun ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_broute bridge stp llc ebtable_nat ip6table_mangle ip6table_security ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_raw iptable_mangle iptable_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables x86_pkg_temp_thermal coretemp kvm_intel kvm i2c_algo_bit drm_kms_helper irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel drm shpchp tpm_tis tpm_tis_core tpm nfsd auth_rpcgss nfs_acl lockd grace sunrpc crc32c_intel serio_raw [last unloaded: i915] CPU: 3 PID: 1743 Comm: kworker/u8:22 Tainted: G W E 4.10.0-rc3ander+ #300 Hardware name: Intel Corp. Geminilake/GLK RVP1 DDR4 (05), BIOS GELKRVPA.X64.0023.B40.1611302145 11/30/2016 Workqueue: events_unbound async_run_entry_fn Call Trace: dump_stack+0x86/0xc3 __warn+0xcb/0xf0 warn_slowpath_fmt+0x5f/0x80 verify_connector_state.isra.80+0x26c/0x2b0 [i915] intel_atomic_commit_tail+0x520/0x1000 [i915] ? remove_wait_queue+0x70/0x70 intel_atomic_commit+0x3f8/0x520 [i915] ? intel_runtime_pm_put+0x6e/0xa0 [i915] drm_atomic_commit+0x4b/0x50 [drm] __intel_display_resume+0x72/0xc0 [i915] intel_display_resume+0x107/0x150 [i915] i915_drm_resume+0xe0/0x180 [i915] i915_pm_restore+0x1e/0x30 [i915] i915_pm_resume+0xe/0x10 [i915] pci_pm_resume+0x64/0xa0 dpm_run_callback+0xa1/0x2a0 ? pci_pm_thaw+0x90/0x90 device_resume+0xe3/0x200 async_resume+0x1d/0x50 async_run_entry_fn+0x39/0x170 process_one_work+0x212/0x670 ? process_one_work+0x197/0x670 worker_thread+0x4e/0x490 kthread+0x101/0x140 ? process_one_work+0x670/0x670 ? kthread_create_on_node+0x60/0x60 ret_from_fork+0x2a/0x40 Cc: David Weinehall <david.weinehall@linux.intel.com> Signed-off-by:
David Weinehall <david.weinehall@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170222063431.10060-6-ander.conselvan.de.oliveira@intel.com
-
Ander Conselvan de Oliveira authored
Implement WaDDIIOTimeout to avoid a timeout when enabling the DDI IO power domains. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Don't allow conversion from arbitraty encoder types to a digital port. Calling enc_to_dig_port() with the wrong encoder may seem far fetched, but certain paths of the ddi code may be called with hasell's analog encoder and the conversion is wrong for DP mst encoders too, so safe guard against it. v2: Warn if encoder type is unknown and device is not DDI. (Imre) v3: Remove stray hunk from rebase error. (Ander) Signed-off-by:
-
Ander Conselvan de Oliveira authored
The encoder power domain is obviously tied to the encoder, so store it in struct intel_encoder. This avoids some indirection. v2: Rebase Signed-off-by:
-
Ander Conselvan de Oliveira authored
The aux power domain only makes sense in the DP code. Storing it in struct intel_dp avoids some indirection. v2: Rebase Signed-off-by:
-
- 25 Feb, 2017 4 commits
-
-
Chris Wilson authored
When advancing onto the next 4th level page table entry, we need to reset our indices to 0. Currently we restart from the original address which means we start with an offset into the next PML table. Fixes: 894ccebe ("drm/i915: Micro-optimise gen8_ppgtt_insert_entries()") Reported-by:
Matthew Auld <matthew.william.auld@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99948 Testcase: igt/drv_selftest/live_gtt Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.william.auld@gmail.com> Tested-by:
-
Chris Wilson authored
We rely on the VMA being allocated inside the drm_mm and for its allotted node being large enough to accommodate all the vma->pages. Signed-off-by:
-
Chris Wilson authored
Before looking up the page directory entry, check we are still within bounds. Signed-off-by:
-
Chris Wilson authored
Double check that we allocated the right amount of scatterlist elements for our obj->size. Signed-off-by:
-
- 24 Feb, 2017 12 commits
-
-
Chris Wilson authored
Check for a timeout in the lowlevel_hole GTT before we allocate state for that pass, as our cleanup phase stops on the iteration before the timeout. References: https://bugs.freedesktop.org/show_bug.cgi?id=99947Signed-off-by:
-
Kenneth Graunke authored
This patch makes the I915_PARAM_HAS_EXEC_CONSTANTS getparam return 0 (indicating the optional feature is not supported), and makes execbuf always return -EINVAL if the flags are used. Apparently, no userspace ever shipped which used this optional feature: I checked the git history of Mesa, xf86-video-intel, libva, and Beignet, and there were zero commits showing a use of these flags. Kernel commit 72bfa19c apparently introduced the feature prematurely. According to Chris, the intention was to use this in cairo-drm, but "the use was broken for gen6", so I don't think it ever happened. 'relative_constants_mode' has always been tracked per-device, but this has actually been wrong ever since hardware contexts were introduced, as the INSTPM register is saved (and automatically restored) as part of the render ring context. The software per-device value could therefore get out of sync with the hardware per-context value. This meant that using them is actually unsafe: a client which tried to use them could damage the state of other clients, causing the GPU to interpret their BO offsets as absolute pointers, leading to bogus memory reads. These flags were also never ported to execlist mode, making them no-ops on Gen9+ (which requires execlists), and Gen8 in the default mode. On Gen8+, userspace can write these registers directly, achieving the same effect. On Gen6-7.5, it likely makes sense to extend the command parser to support them. I don't think anyone wants this on Gen4-5. Based on a patch by Dave Gordon. v3: Return -ENODEV for the getparam, as this is what we do for other obsolete features. Suggested by Chris Wilson. Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92448Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Imre Deak authored
At least a ParadTech PS175 LSPCON chip/firmware uses long instead of short pulses to signal output unplug/plug events. This is contrary to how branch devices normally work which use short HPD signaling. This chip will also switch to LS mode after an unplug event, which could be the consequence of the long HPD signaling semantics and an effort to save power automatically. Because of this we'll fail to do AUX and detect the output after a replug event. To fix this make sure we are in PCON mode during connector detection. v2: - Switch the mode in the proper spot. Cc: raptorteak@gmail.com Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98912 Reported-and-tested-by: raptorteak@gmail.com Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1487776252-6288-1-git-send-email-imre.deak@intel.com
-
Chris Wilson authored
We require that the request is completed before the context is switched away. Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com>
-
Ville Syrjälä authored
Rather than sprinkling ideas of how big the DDI buf translation tables are somewhere in intel_dp.c, let's concentrate it all in intel_ddi.c where the actual tables are defined. To that end we introduce intel_ddi_dp_voltage_max() which will actually look at the proper translation table to determine what is the maximum voltage swing level supported. v2: Mask out the preemphasis bits from the return value of intel_ddi_dp_voltage_max() Signed-off-by: -
Ville Syrjälä authored
Convert the big switch statement in translate_signal_level() into a neat table. The table also serves as documentation for the translation tables. We'll also have other uses for this table later on. v2: Remove superfluous space (David) Signed-off-by:
-
Ville Syrjälä authored
Split the code to select the correct translation table into DP, eDP and FDI specific helpers. This reduces the clutter in intel_prepare_dp_ddi_buffers(), and we'll have other uses for some of these new helper functions later on. v2: Fix typo in commit message (David) Signed-off-by:
-
Chris Wilson authored
If we cease making progress in finding matching outputs for a tiled configuration, stop looping over the remaining unconfigured outputs. v2: Use conn_seq (instead of pass) to only apply tile configuration on first pass. Fixes: b0ee9e7f ("drm/fb: add support for tiled monitor configurations. (v2)") Signed-off-by:
Tomasz Lis <tomasz.lis@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170224114306.4400-1-chris@chris-wilson.co.uk
-
Dave Airlie authored
Linus doesn't like it user selectable, so kill it until someone needs it for something else. Signed-off-by:Dave Airlie <airlied@redhat.com>
-
Noralf Trønnes authored
BACKLIGHT_CLASS_DEVICE was selected in the last version of the tinydrm patchset to fix the backlight dependency, but the ifdef CONFIG_BACKLIGHT_CLASS_DEVICE was forgotten. Fix that. Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
-
Noralf Trønnes authored
This warning is seen on 64-bit builds in functions: 'mipi_dbi_typec1_command': 'mipi_dbi_typec3_command_read': 'mipi_dbi_typec3_command': >> drivers/gpu/drm/tinydrm/mipi-dbi.c:65:20: warning: field width specifier '*' expects argument of type 'int', but argument 5 has type 'size_t {aka long unsigned int}' [-Wformat=] DRM_DEBUG_DRIVER("cmd=%02x, par=%*ph\n", cmd, len, data); \ ^ include/drm/drmP.h:228:40: note: in definition of macro 'DRM_DEBUG_DRIVER' drm_printk(KERN_DEBUG, DRM_UT_DRIVER, fmt, ##__VA_ARGS__) ^~~ >> drivers/gpu/drm/tinydrm/mipi-dbi.c:671:2: note: in expansion of macro 'MIPI_DBI_DEBUG_COMMAND' MIPI_DBI_DEBUG_COMMAND(cmd, parameters, num); ^~~~~~~~~~~~~~~~~~~~~~ Fix by casting 'len' to int in the macro MIPI_DBI_DEBUG_COMMAND(). There is no chance of overflow. Signed-off-by: -
Noralf Trønnes authored
Fix this warning: drivers/gpu/drm/tinydrm/mipi-dbi.c: In function ‘mipi_dbi_debugfs_command_write’: drivers/gpu/drm/tinydrm/mipi-dbi.c:905:8: warning: ‘cmd’ may be used uninitialized in this function [-Wmaybe-uninitialized] ret = mipi_dbi_command_buf(mipi, cmd, parameters, i); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cmd can't be used uninitialized, but to satisfy the compiler, initialize it to zero. Signed-off-by:
-
- 23 Feb, 2017 17 commits
-
-
Chris Wilson authored
If the reserved region of memory has not been setup (most probably because it has been limited by hardware or virtualisation), don't tell the user to try and increase the amount of memory reserved for graphics. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
Some ttm/amd fixes. * 'drm-next-4.11' of git://people.freedesktop.org/~agd5f/linux: drm/amd/powerplay: fix PSI feature on Polars12. drm/amdgpu: refuse to reserve io mem for split VRAM buffers drm/ttm: fix use-after-free races in vm fault handling drm/amd/amdgpu: post card if there is real hw resetting performed
-
git://anongit.freedesktop.org/tegra/linuxDave Airlie authored
drm/panel: Changes for v4.11-rc1 This set contains a couple of cleanups as well as support for a few more simple panels. * tag 'drm/panel/for-4.11-rc1' of git://anongit.freedesktop.org/tegra/linux: drm/panel: simple: Specify bus width and flags for EDT displays drm/panel: simple: Add Netron DY E231732 of: Add vendor prefix for Netron DY drm/panel: simple: Add support for Tianma TM070JDHG30 of: Add vendor prefix for Tianma Micro-electronics drm/panel: simple: Add support BOE NV101WXMN51 dt-bindings: display: Add BOE NV101WXMN51 panel binding drm/panel: Constify device node argument to of_drm_find_panel()
-
git://anongit.freedesktop.org/tegra/linuxDave Airlie authored
drm/tegra: Changes for v4.11-rc1 Just a single change that hooks up the Tegra DRM parent device to the correct device tree node. * tag 'drm/tegra/for-4.11-rc1' of git://anongit.freedesktop.org/tegra/linux: gpu: host1x: Set OF node for new host1x devices
-
Chris Wilson authored
Now that the code is getting simpler, we can reduce the indentation when waiting for the global_seqno. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170223074422.4125-17-chris@chris-wilson.co.uk
-
Chris Wilson authored
As we handoff the GPU reset to the waiter, we need to check we don't miss a wakeup if it has already been sent prior to us starting the wait. v2: Tweak checking for reset to be clear to the need before sleeping after changing the task state. Signed-off-by:
-
Chris Wilson authored
Combine the common code for the pair of waiters into a single function. v2: Rename reset_request to wait_request_check_and_reset Signed-off-by:
-
Chris Wilson authored
If we change the wait_queue_t from using the autoremove_wake_function to the default_wake_function, we no longer have to restore the wait_queue_t entry on the wait_queue_head_t list after being woken up by it, as we are unusual in sleeping multiple times on the same wait_queue_t. Signed-off-by:
-
Chris Wilson authored
Add a mock selftest to preempt a request and check that we cancel it, requeue the request and then complete its execution. v2: Error leaks no more. Signed-off-by:
-
Chris Wilson authored
After the request is cancelled, we then need to remove it from the global execution timeline and return it to the context timeline, the inverse of submit_request(). v2: Move manipulation of struct intel_wait to helpers Signed-off-by:
-
Chris Wilson authored
If we preempt a request and remove it from the execution queue, we need to undo its global seqno and restart any waiters. Signed-off-by:
-
Chris Wilson authored
The plan in the near-future is to allow requests to be removed from the signaler. We can no longer then rely on holding a reference to the request for the duration it is in the signaling tree, and instead must obtain a reference to the request for the current operation using RCU. Signed-off-by:
-
Chris Wilson authored
A request is assigned a global seqno only when it is on the hardware execution queue. The global seqno can be used to maintain a list of requests on the same engine in retirement order, for example for constructing a priority queue for waiting. Prior to its execution, or if it is subsequently removed in the event of preemption, its global seqno is zero. As both insertion and removal from the execution queue may operate in IRQ context, it is not guarded by the usual struct_mutex BKL. Instead those relying on the global seqno must be prepared for its value to change between reads. Only when the request is complete can the global seqno be stable (due to the memory barriers on submitting the commands to the hardware to write the breadcrumb, if the HWS shows that it has passed the global seqno and the global seqno is unchanged after the read, it is indeed complete). Signed-off-by:
-
Chris Wilson authored
On reflection, we are only using the execute fence as a waitqueue on the global_seqno and not using it for dependency tracking between fences (unlike the submit and dma fences). By only treating it as a waitqueue, we can then treat it similar to the other waitqueues during submit, making the code simpler. Signed-off-by:
-
Chris Wilson authored
It had only one callsite and existed to keep the code clearer. Now having shared the wait-on-error between phases and with plans to change the wait-for-execute in the next few patches, remove the out of line wait loop and move it into the main body of i915_wait_request. Signed-off-by:
-
Chris Wilson authored
Add ourselves to the gpu error waitqueue earlier on, even before we determine we have to wait on the seqno. This is so that we can then share the waitqueue between stages in subsequent patches. Signed-off-by:
-
Chris Wilson authored
Use a local variable to avoid having to type out the full name of the gpu_error wait_queue. Signed-off-by:
-
