summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2015-09-02drm/amdgpu: use PT for VM sync on unmapChristian König
Instead of the array which is used for ID management. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
2015-09-02drm/amdgpu: make wait_event uninterruptible in push_jobChunming Zhou
with interruptible, the push_job maybe return -ERESTARTSYS, then result in push_job error. E.g. bug trace: [ 181.618860] *****amdgpu_copy_buffer:fence->seq:0x0000000048d8758b, contxt:1207959552, ref:683967304, r:-512 [ 181.618929] BUG: unable to handle kernel paging request at ffffffff811aa266 [ 181.625887] IP: [<ffffffff81548ffc>] reservation_object_add_excl_fence+0x3c/0x120 ... [ 181.859767] [<ffffffff811aa266>] ? unmap_mapping_range+0x66/0x110 [ 181.865928] [<ffffffffc0608ac1>] ttm_bo_move_accel_cleanup+0x41/0x3c0 [ttm] [ 181.872971] [<ffffffffc062d382>] amdgpu_move_blit.isra.18+0x122/0x150 [amdgpu] [ 181.880254] [<ffffffff811aa266>] ? unmap_mapping_range+0x66/0x110 [ 181.886420] [<ffffffffc062d709>] amdgpu_bo_move+0xa9/0x200 [amdgpu] [ 181.892753] [<ffffffffc0606e8d>] ttm_bo_handle_move_mem+0x26d/0x5c0 [ttm] Signed-off-by: Chunming Zhou <david1.zhou@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
2015-09-02drm/amdgpu: fix amdgpu_bo_unreserve order in GEM_OP IOCTL v2Christian König
No copy_(to|from)_user while BO is reserved. v2: handle default path as well Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
2015-09-02drm/amdgpu: partially revert "modify amdgpu_fence_wait_any() to ↵Christian König
amdgpu_fence_wait_multiple()" v2 That isn't used any more. v2: rebase Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-09-02Add radeon suspend/resume quirk for HP Compaq dc5750.Jeffery Miller
With the radeon driver loaded the HP Compaq dc5750 Small Form Factor machine fails to resume from suspend. Adding a quirk similar to other devices avoids the problem and the system resumes properly. Signed-off-by: Jeffery Miller <jmiller@neverware.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-09-02drm/amdgpu: re-work sync_resvChunming Zhou
sync_resv is to handle both amdgpu_fence and sched_fence. Signed-off-by: Chunming Zhou <david1.zhou@amd.com> Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com> Reviewed-by: Christian K?nig <christian.koenig@amd.com>
2015-09-02drm/amdgpu/atom: Send out the full AUX addressAlex Deucher
AUX addresses are 20 bits long. Send out the entire address instead of just the low 16 bits. Port of: drm/radeon/atom: Send out the full AUX address to amdgpu Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-09-02drm/i915: Don't call intel_get_hpd_pins() when there's no hotplug interruptVille Syrjälä
On GMCH plaforms we are now getting the following spew on aux interrupts: [drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x00000000, pins 0x00000000 [drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x00000000, pins 0x00000000 [drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x00000000, pins 0x00000000 [drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x00000000, pins 0x00000000 [drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x00000000, pins 0x00000000 [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x71450064 Prevent it by not calling intel_get_hpd_pins() unless one of the HPD interrupt bits are actually set. I already fixed similar annoyance once with 4bca26d0a6518d51a9abe64fbde4b12f04c74053 drm/i915: Use HOTPLUG_INT_STATUS_G4X on VLV/CHV but another source for it got added in fd63e2a972c670887e5e8a08440111d3812c0996 drm/i915: combine i9xx_get_hpd_pins and pch_get_hpd_pins due to pch_get_hpd_pins() being chosen over i9xx_get_hpd_pins() to serve as the new unified piece of code. pch_get_hpd_pins() had the debug print, and i9xx_get_hpd_pins() didn't. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-02drm/i915: Rewrite BXT HPD code to conform to pre-existing styleVille Syrjälä
Rewrite the BXT hpd setup to match the way we do it on other platforms: - Throw out BXT_HOTPLUG_CTL since it's the same as PCH_PORT_HOTPLUG - Enable the HPD bits in the DE port IER in gen8_de_irq_postinstall() - Update DE port IMR using bdw_update_port_irq() Also throw out port D from bxt_port_hotplug_long_detect() since BXT only goes up to C. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-02drm/i915: Refactor the hpd irq handling functionsVille Syrjälä
A lot of the hpd irq handling is duplicated code, so refactor it a bit by observing that in several places the only difference is the hpd[] array. So pull the code to a few functions and pass in the hpd[] array from the caller. Another option would be to determine the correct array to use within the functions themselves, but somehow passing it in felt nicer. Further code reduction could be achieved by passing in the hotplug register offset, and the long pulse detection function pointer. But that didn't feel as good for some reason, so I left it at the middle ground. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-02drm/i915: Rewrite bxt_hpd_handler() to look like everyone elseVille Syrjälä
bxt_hpd_handler() looks different to everyone else for no good reason. Rewrite it to use the standard variable namees etc. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-02drm/i915: Reinitialize HPD after runtime D3Ville Syrjälä
Runtime suspends disabled all interrupts, so in order to get them back fully we need to also do the HPD irq setup on runtime resume. Except on VLV/CHV where the display interrupt initialization is part of the display power well powerup. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-02drm/i915: Add port A HPD support for SPTVille Syrjälä
On SKL the port A HPD has moved to the PCH. Hook it up. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-02drm/i915: Add port A HPD support for BDWVille Syrjälä
Wire up the port A HPD for BDW. Compared to earlier platforms the interrupt setup is a bit different, but basically everything else looks the same. v2: 0 initialize pin_mask/long_mask due to intel_get_hpd_pins() changes Check for BDW before processing the HPD to not break BXT Set found=true when processing port A HPD Sort out the mess I made of the irq setup in v1 Warn about bad irq mask vs. enable bits in bdw_update_port_irq() (Paulo) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-02drm/i915: LPT:LP needs port A HPD enabled in both north and southVille Syrjälä
If the CPU and PCH are on the same package we must enabled the port A HPD also in the south hotplug register. To identify the package type we simply look at the PCH type: LPT-H means separate package, and LPT-LP means multi chip package (MCP). v2: Add comment and pimp commit message Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-02drm/i915: Add port A HPD support for IVB/HSWVille Syrjälä
As with ILK/SNB wire up the port A HPD on IVB/HSW. This might be more important on HSW with PSR. BSpec tells us that if the automagic link training performed by the hardware fails for some reason, we're going to get a short HPD and are supposed to re-train the link manyally. v2: 0 initialize pin_mask/long_mask due to intel_get_hpd_pins() changes Add a comment about the pulse duration bits being reserved on HSW+ like we have for LPT+ in ibx_hpd_irq_setup() Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-02drm/i915: Add port A HPD support for ILK/SNBVille Syrjälä
ILK/SNB support port A HPD. While HPD is optional on eDP let's at least try to wite it up so that we might notice if the link has issues. The eDP spec suggests that if HPD is not wired up, one should poll the link status instead. We don't even do that currently. v2: 0 initialize pin_mask/long_mask due to intel_get_hpd_pins() changes Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-02drm/i915: Introduce spt_irq_handler()Ville Syrjälä
Starting from SPT the only interrupts living in the south are GMBUS and HPD. What's worse some of the SPT specific new bits conflict with some other bits on earlier PCH generations. So better not use the cpt_irq_handler() for SPT+ anymore. Also kill the hand rolled port E handling with something more standardish. This also avoids accidentally confusing port B and port E long pulses since the bits occupy the same positions, just in different registers. Also add a comment noting that the short pulse duration bits are reserved on LPT+. The 2ms value we program is 0, so no issue wrt. the MBZ in the spec. v2: Call intel_hpd_irq_handler() only once (Paulo) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-02drm/i915: Move {pin, long}_mask initialization to caller from ↵Ville Syrjälä
intel_get_hpd_pins() Move the 0 initialization of pin_mask and long_mask from intel_get_hpd_pins() into each caller. This we we can call intel_get_hpd_pins() multiple times to accumulate more pins from several sources. v2: Add a comment explaining the dangers of intel_get_hpd_pins() (Paulo) Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-02drm/i915: Rename BXT PORTA HPD definesVille Syrjälä
The PORTA HPD defines are not BXT specific. They also exist on SPT, and partially already on LPT:LP. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-02drm/i915: Add HAS_PCH_LPT_LP() macroVille Syrjälä
Make LPT:LP checks look neater by wrapping the details in a new HAS_PCH_LPT_LP() macro. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-02drm/i915: Factor out ilk_update_display_irq()Ville Syrjälä
Extract the core of ironlake_{enable,disable}_display_irq() into a new function. We'll have further use for it later. v2: Warn about invalid mask vs. enable bits (Paulo) Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-02drm/i915: Extract intel_hpd_enabled_irqs()Ville Syrjälä
Eliminate a bunch of duplicated code that calculates the currently enabled HPD interrupt bits. v2: s/;/:/ in patch subject (Paulo) Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-02drm/i915: Clean up various HPD definesVille Syrjälä
Indent the PORTx_HOTPLUG_... defines appropriately, and fix some space vs. tab issues. v2: Document pre-HSW/LPT bits, and order another tab (Paulo) Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-02drm/i915: Update comments around base bppDaniel Vetter
Forgot to do that in commit d328c9d78d64ca11e744fe227096990430a88477 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Apr 10 16:22:37 2015 +0200 drm/i915: Select starting pipe bpp irrespective or the primary plane and it's confusing. Fix it. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-09-02drm/exynos: remove buf_cnt from struct exynos_drm_fbJoonyoung Shim
Looking other drm drivers, there is no the restriction that framebuffer has only one buffer in .create_handle() callback. They use just first buffer. If this limitation is removed, there is no reason keeping buffer count for framebuffer, so we can remove buf_cnt from struct exynos_drm_fb. Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-09-02drm/exynos: remove exynos_drm_fb_get_buf_cnt()Joonyoung Shim
We can get buffer count of framebuffer using drm_format_num_planes(), so keeping exynos_drm_fb_get_buf_cnt() is unnecessary. Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-09-02drm/exynos: cleanup exynos_user_fb_create()Joonyoung Shim
Using exynos_drm_framebuffer_init(), redundant codes can be removed. Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-09-02drm/exynos: update exynos_drm_framebuffer_init() for multiple buffersJoonyoung Shim
This modifies exynos_drm_framebuffer_init() to be possible to support multiple buffers. Then it can be used by exynos_user_fb_create(). Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-09-02drm/exynos: cleanup to get gem object for fbJoonyoung Shim
Current codes get first gem object and then again get remain gem objects. They can be unified to one routine. Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-09-02drm/exynos: update fb_info via only one functionJoonyoung Shim
This patch moves codes to update fb_info into exynos_drm_fbdev_update(), so fb_info is updated via only one function. Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-09-02drm/exynos: cleanup exynos_drm_fbdev_update()Joonyoung Shim
It can get exynos_gem object via function argument, so no need to call exynos_drm_fb_gem_obj() in exynos_drm_fbdev_update. It also can get struct drm_framebuffer *fb via helper->fb, so can remove a function argument for it. Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-09-02drm/exynos: s/exynos_gem_obj/obj in exynos_drm_fbdev.cJoonyoung Shim
The variable name "exynos_gem_obj" is too long, so some lines exceed 80 characters. It's simple to use "obj" instead of "exynos_gem_obj". Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-09-02drm/exynos: remove exynos_drm_fb_set_buf_cnt()Joonyoung Shim
The exynos_drm_fb_set_buf_cnt() is used to set buffer count only in exynos_drm_fbdev_update(). This patch sets directly buffer count in exynos_drm_framebuffer_init() without using exynos_drm_fb_set_buf_cnt(), so there is no any reason to keep exynos_drm_fb_set_buf_cnt(). Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-09-02drm/exynos: remove superfluous checks in g2d_check_reg_offset()Tobias Jakobi
The cases of the switch statement ensure that reg_type can never be REG_TYPE_NONE here. Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-09-02drm/exynos: fix size check in g2d_check_buf_desc_is_valid()Tobias Jakobi
The size check was incomplete. It only computed the size of area of the drawing rectangle and checked if the size still fit inside the buffer. The correct check is to compute the position of the last byte that the G2D engine is going to access and then check if that position is still contained in the buffer. In particular we need the stride information to determine this. Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-09-02drm/i915: Pass hpd_status_i915[] to intel_get_hpd_pins() in pre-g4xVille Syrjälä
Pass the correct hpd[] array to intel_get_hpd_pins() on pre-g4x platforms. This got broken in the following commit: commit fd63e2a972c670887e5e8a08440111d3812c0996 Author: Imre Deak <imre.deak@intel.com> Date: Tue Jul 21 15:32:44 2015 -0700 drm/i915: combine i9xx_get_hpd_pins and pch_get_hpd_pins Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Egbert Eich <eich@suse.de> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-09-02drm/i915: Always mark the object as dirty when used by the GPUChris Wilson
There have been many hard to track down bugs whereby userspace forgot to flag a write buffer and then cause graphics corruption or a hung GPU when that buffer was later purged under memory pressure (as the buffer appeared clean, its pages would have been evicted rather than preserved and any changes more recent than in the backing storage would be lost). In retrospect this is a rare optimisation against memory pressure, already the slow path. If we always mark the buffer as dirty when accessed by the GPU, anything not used can still be evicted cheaply (ideal behaviour for mark-and-sweep eviction) but we do not run the risk of corruption. For correct read serialisation, userspace still has to notify when the GPU writes to an object. However, there are certain situations under which userspace may wish to tell white lies to the kernel... Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Kristian Høgsberg <krh@bitplanet.net> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: "Goel, Akash" <akash.goel@intel.co> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: stable@vger.kernel.org Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-09-02drm/dp: Add dp_aux_i2c_speed_khz module param to set the assume i2c bus speedVille Syrjälä
To help with debugging i2c-over-aux issues, add a module parameter than can be used to tweak the assumed i2c bus speed, and thus the maximum number of retries we will do for each aux message. Cc: Simon Farnsworth <simon.farnsworth@onelan.com> Cc: moosotc@gmail.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Simon Farnsworth <simon.farnsworth@onelan.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-09-02drm/dp: Adjust i2c-over-aux retry count based on message size and i2c bus speedVille Syrjälä
Calculate the number of retries we should do for each i2c-over-aux message based on the time it takes to perform the i2c transfer vs. the aux transfer. We assume the shortest possible length for the aux transfer, and the longest possible (exluding clock stretching) for the i2c transfer. The DP spec has some examples on how to calculate this, but we don't calculate things quite the same way. The spec doesn't account for the retry interval (assumes immediate retry on defer), and doesn't assume the best/worst case behaviour as we do. Note that currently we assume 10 kHz speed for the i2c bus. Some real world devices (eg. some Apple DP->VGA dongle) fails with less than 16 retries. and that would correspond to something close to 15 kHz (with our method of calculating things) But let's just go for 10 kHz to be on the safe side. Ideally we should query/set the i2c bus speed via DPCD but for now this should at leaast remove the regression from the 1->16 byte trasnfer size change. And of course if the sink completes the transfer quicker this shouldn't slow things down since we don't change the interval between retries. I did a few experiments with a DP->DVI dongle I have that allows you to change the i2c bus speed. Here are the results of me changing the actual bus speed and the assumed bus speed and seeing when we start to fail the operation: actual i2c khz assumed i2c khz max retries 1 1 ok -> 2 fail 211 ok -> 106 fail 5 8 ok -> 9 fail 27 ok -> 24 fail 10 17 ok -> 18 fail 13 ok -> 12 fail 100 210 ok -> 211 fail 2 ok -> 1 fail So based on that we have a fairly decent safety margin baked into the formula to calculate the max number of retries. Fixes a regression with some DP dongles from: commit 1d002fa720738bcd0bddb9178e9ea0773288e1dd Author: Simon Farnsworth <simon.farnsworth@onelan.co.uk> Date: Tue Feb 10 18:38:08 2015 +0000 drm/dp: Use large transactions for I2C over AUX v2: Use best case for AUX and worst case for i2c (Simon Farnsworth) Add a define our AUX retry interval and account for it v3: Make everything usecs to avoid confusion about units (Daniel) Add a comment reminding people about the AUX bitrate (Daniel) Use DIV_ROUND_UP() since we're after the "worst" case for i2c Cc: Simon Farnsworth <simon.farnsworth@onelan.com> Cc: moosotc@gmail.com Tested-by: moosotc@gmail.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91451 Reviewed-by: Simon Farnsworth <simon.farnsworth@onelan.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-09-02drm/dp: Define AUX_RETRY_INTERVAL as 500 usVille Syrjälä
Currently we react to native and i2c defers by waiting either 400-500 us or 500-600 us, depending on which code path we take. Consolidate them all to one define AUX_RETRY_INTERVAL which defines the minimum interval. Since we've been using two different intervals pick the longer of them and define AUX_RETRY_INTERVAL as 500 us. For the maximum just use AUX_RETRY_INTERVAL+100 us. I want to have a define for this so that I can use it when calculating the estimated duration of i2c-over-aux transfers. Without a define it would be very easy to change the sleep duration and neglect to update the i2c-over-aux estimates. Cc: Simon Farnsworth <simon.farnsworth@onelan.com> Cc: moosotc@gmail.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Simon Farnsworth <simon.farnsworth@onelan.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-09-02Merge tag 'drm-intel-next-fixes-2015-09-02' into drm-intel-next-queuedDaniel Vetter
Backmerge -fixes since there's more DDI-E related cleanups on top of the pile of -fixes for skl that just landed for 4.3. Conflicts: drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i914/intel_dp.c drivers/gpu/drm/i915/intel_lrc.c Conflicts are all fairly harmless adjacent line stuff. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-09-02drm/i915: Also record time difference if vblank evasion fails, v2.Maarten Lankhorst
This makes the error message slightly more useful. Changes since v1: - Use ktime_get() while irqs are still disabled. (vsyrjala) Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-02drm/i915: Remove start frame argument to pipe_update_begin/end.Maarten Lankhorst
There's already a per crtc member that can be used for it. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-02drm/i915: guest i915 notification for Intel GVT-gZhiyuan Lv
When i915 drivers run inside a VM with Intel GVT-g, some explicit notifications are needed from guest to host device model through PV INFO page write. The notifications include: PPGTT create PPGTT destroy They are used for the shadow implementation of PPGTT. Intel GVT-g needs to write-protect the guest pages of PPGTT, and clear the write protection when they end their life cycle. v2: - Use lower_32_bits()/upper_32_bits() for qword operations; - Remove the notification of guest context creation/destroy; Signed-off-by: Zhiyuan Lv <zhiyuan.lv@intel.com> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-02drm/i915: Update PV INFO page definition for Intel GVT-gZhiyuan Lv
Some more definitions in the PV info page are added. They are mainly for the guest notification to Intel GVT-g device model. They are used for Broadwell enabling. The notification of PPGTT page table creation/destroy is to notify GVT-g device model the life cycle of guest page tables. Then device model will implement shadow page table for guests. The notification of context create/destroy is optional. If it is used, the device model will create/destroy shadow context corresponding to the context's life cycle. Guest driver needs to make sure that the context's LRCA and backing storage address unchanged. If it is not used, the device model will perform the context shadow work in the context scheduling time. Signed-off-by: Zhiyuan Lv <zhiyuan.lv@intel.com> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-02drm/i915: Always enable execlists on BDW for vgpuZhiyuan Lv
Broadwell hardware supports both ring buffer mode and execlist mode. When i915 runs inside a VM with Intel GVT-g, we allow execlist mode only. The main reason of EXECLIST only is that GVT-g does not support the dynamic mode switch between ring buffer mode and execlist mode when running multiple virtual machines. v2: - Adjust the position of vgpu check in sanitize function (Joonas) - Add vgpu error check in context initialization. (Joonas, Daniel) Signed-off-by: Zhiyuan Lv <zhiyuan.lv@intel.com> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-02drm/i915: preallocate pdps for 32 bit vgpuZhiyuan Lv
This is based on Mika Kuoppala's patch below: http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/61104/match=workaround+hw+preload The patch will preallocate the page directories for 32-bit PPGTT when i915 runs inside a virtual machine with Intel GVT-g. With this change, the root pointers in EXECLIST context will always keep the same. The change is needed for vGPU because Intel GVT-g will do page table shadowing, and needs to track all the page table changes from guest i915 driver. However, if guest PPGTT is modified through GPU commands like LRI, it is not possible to trap the operations in the right time, so it will be hard to make shadow PPGTT to work correctly. Shadow PPGTT could be much simpler with this change. Meanwhile hypervisor could simply prohibit any attempt of PPGTT modification through GPU command for security. The function gen8_preallocate_top_level_pdps() in the patch is from Mika, with only one change to set "used_pdpes" to avoid duplicated allocation later. Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Dave Gordon <david.s.gordon@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Zhiyuan Lv <zhiyuan.lv@intel.com> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-02drm/i915: Call audio pin/ELD notify functionDavid Henningsson
When the audio codec is enabled or disabled, notify the audio driver. This will enable the audio driver to get the notification at all times (even when audio is in different powersave states). Signed-off-by: David Henningsson <david.henningsson@canonical.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-09-02drm/i915: add yesno utility functionJani Nikula
Add a common function to return "yes" or "no" string based on the argument, and drop the local versions of it. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>