summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)Author
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-01i915: Set ddi_pll_sel in DP MST pathAnder Conselvan de Oliveira
The DP MST encoder config function never sets ddi_pll_sel, even though its value is programmed in its ->pre_enable() hook. That used to work because a new pipe_config was kzalloc'ed at every modeset, and the value of zero selects the highest clock for the PLL. Starting with the commit below, the value of ddi_pll_sel is preserved through modesets, and since the correct value wasn't properly setup by the MST code, it could lead to warnings and blank screens. commit 8504c74c7ae48b4b8ed1f1c0acf67482a7f45c93 Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Date: Fri May 15 11:51:50 2015 +0300 drm/i915: Preserve ddi_pll_sel when allocating new pipe_config Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91628 Cc: stable@vger.kernel.org # 7e6313a2516d drm/i915: Don't use link_bw for PLL setup Cc: stable@vger.kernel.org Cc: Timo Aaltonen <tjaalton@ubuntu.com> Cc: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-09-01drm/i915: Don't use link_bw for PLL setupVille Syrjälä
Use port_clock instead of link_bw when picking the PLL parameters for DP. link_bw may be zero with an eDP 1.4 sink that supports DP_LINK_RATE_SET so we shouldn't use it for anything other than feed it to the sink appropriately. v2: Fix typo in commit message (Sivakumar) Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> [Jani: cherry-picked from future.] Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-09-01drm/vmwgfx: Allow dropped masters render-node like access on legacy nodes v2Thomas Hellstrom
Applications like gnome-shell may try to render after dropping master privileges. Since the driver should now be safe against this scenario, allow those applications to use their legacy node like a render node. v2: Add missing return statement. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
2015-09-01drm/atomic: Fix bookkeeping with TEST_ONLY, v3.Maarten Lankhorst
Commit ec9f932ed41622d120de52a5b525e4d77b9ef17e "drm/atomic: Cleanup on error properly in the atomic ioctl." cleaned up some error paths, but didn't fix the TEST_ONLY path. In the check only case plane->fb shouldn't be updated, and the vblank events should be cleared as on failure. Changes since v1: - Fix -EDEADLK handling of vblank events too. - Free state last with CHECK_ONLY. Changes since v2: - Add comment about freeing crtc_state->event with TEST_ONLY. (Daniel Stone) Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-09-01drm/i915: Preserve SSC earlierLukas Wunner
Commit 92122789b2d6 ("drm/i915: preserve SSC if previously set v3") added code to intel_modeset_gem_init to override the SSC status read from VBT with the SSC status set by BIOS. However, intel_modeset_gem_init is invoked *after* intel_modeset_init, which calls intel_setup_outputs, which *modifies* SSC status by way of intel_init_pch_refclk. So unlike advertised, intel_modeset_gem_init doesn't preserve the SSC status set by BIOS but whatever intel_init_pch_refclk decided on. This is a problem on dual gpu laptops such as the MacBook Pro which require either a handler to switch DDC lines, or the discrete gpu to proxy DDC/AUX communication: Both the handler and the discrete gpu may initialize after the i915 driver, and consequently, an LVDS connector may initially seem disconnected and the SSC therefore is disabled by intel_init_pch_refclk, but on reprobe the connector may turn out to be connected and the SSC must then be enabled. Due to 92122789b2d6 however, the SSC is not enabled on reprobe since it is assumed BIOS disabled it while in fact it was disabled by intel_init_pch_refclk. Also, because the SSC status is preserved so late, the preserved value only ever gets used on resume but not on panel initialization: intel_modeset_init calls intel_init_display which indirectly calls intel_panel_use_ssc via multiple subroutines, *before* the BIOS value overrides the VBT value in intel_modeset_gem_init (intel_panel_use_ssc is the sole user of dev_priv->vbt.lvds_use_ssc). Fix this by moving the code introduced by 92122789b2d6 from intel_modeset_gem_init to intel_modeset_init before the invocation of intel_setup_outputs and intel_init_display. Add a DRM_DEBUG_KMS as suggested way back by Jani: http://lists.freedesktop.org/archives/intel-gfx/2014-June/046666.html Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115 Tested-by: Paul Hordiienko <pvt.gord@gmail.com> [MBP 6,2 2010 intel ILK + nvidia GT216 pre-retina] Tested-by: William Brown <william@blackhats.net.au> [MBP 8,2 2011 intel SNB + amd turks pre-retina] Tested-by: Lukas Wunner <lukas@wunner.de> [MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina] Tested-by: Bruno Bierbaumer <bruno@bierbaumer.net> [MBP 11,3 2013 intel HSW + nvidia GK107 retina -- work in progress] Fixes: 92122789b2d6 ("drm/i915: preserve SSC if previously set v3") Signed-off-by: Lukas Wunner <lukas@wunner.de> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-08-31drm/i915/skl: Adding DDI_E power well domainXiong Zhang
From B spec, DDI_E port belong to PowerWell 2, but DDI_E share the powerwell_req/staus register bit with DDI_A which belong to DDI_A_E_POWER_WELL. In order to communicate with the connector on DDI-E, both DDI_A_E_POWER_WELL and POWER_WELL_2 must be enabled. Currently intel_dp_power_get(DDI_E) only enable DDI_A_E_POWER_WELL, this patch will not only enable DDI_a_E_POWER_WELL but also enable POWER_WELL_2. This patch also fix the DDI-E hotplug function. Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-08-31drm/radeon/native: 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 radeon non-atom aux path Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-08-31drm/radeon/atom: Send out the full AUX addressVille Syrjälä
AUX addresses are 20 bits long. Send out the entire address instead of just the low 16 bits. Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-08-31drm/i915: eDP can be present on DDI-ERodrigo Vivi
Enable eDP on DDI-E. Also let's remove duplicated definitions to avoid later confusion. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Xiong Zhang <xiong.y.zhang@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-08-31drm/i915/skl: Enable DDI-ERodrigo Vivi
There are OEMs using DDI-E out there, so let's enable it. Unfortunately there is no detection bit for DDI-E So we need to rely on VBT for that. I also need to give credits to Xiong since before seing his approach to check info->support_* I was creating an ugly vbt->ddie_sfuse_strap in order to propagate the ddi presence info v2: Rebased as last patch in the series. since all other patches in this series are needed for anything working propperly on DDI-E. Credits-to: "Zhang, Xiong Y" <xiong.y.zhang@intel.com> Cc: "Zhang, Xiong Y" <xiong.y.zhang@intel.com> Reviewed-by: Xiong Zhang <xiong.y.zhang@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-08-31drm/i915: Enable HDMI on DDI-EXiong Zhang
DDI-E doesn't have the correspondent GMBUS pin. We rely on VBT to tell us which one it being used instead. The DVI/HDMI on shared port couldn't exist. This patch isn't tested without hardware wchich has HDMI on DDI-E. v2: fix trailing whitespace v3: MISSING_CASE take place of BUG() Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-08-31drm/i915: apply the PCI_D0/D3 hibernation workaround everywhere on pre GEN6Imre Deak
commit da2bc1b9db3351addd293e5b82757efe1f77ed1d Author: Imre Deak <imre.deak@intel.com> Date: Thu Oct 23 19:23:26 2014 +0300 drm/i915: add poweroff_late handler introduced a regression on old platforms during hibernation. A workaround was added in commit ab3be73fa7b43f4c3648ce29b5fd649ea54d3adb Author: Imre Deak <imre.deak@intel.com> Date: Mon Mar 2 13:04:41 2015 +0200 drm/i915: gen4: work around hang during hibernation using an explicit blacklist for the GENs/BIOS vendors where the issue was reported. Later there we had reports of the same failure on platforms not on this list. To my best knowledge the correct thing to do is still to put the device to PCI D3 state during hibernation, see [1] and [2] for the reasons. This also aligns with our future plans to unify more the runtime and system suspend/resume paths. Since an exact blacklist seems to be impractical (multiple GENs and BIOS vendors are affected) apply the workaround on everything pre GEN6. [1] http://lists.freedesktop.org/archives/intel-gfx/2015-February/060710.html [2] https://lkml.org/lkml/2015/6/22/274 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=95061 Reported-by: Ilya Tumaykin <itumaykin@gmail.com> Reported-by: Dirk Griesbach <spamthis@freenet.de> Reported-by: Pavel Machek <pavel@ucw.cz> Reported-by: Mikko Rapeli <mikko.rapeli@iki.fi> Tested-by: Mikko Rapeli <mikko.rapeli@iki.fi> Reported-by: Paul Bolle <pebolle@tiscali.nl> CC: stable@vger.kernel.org Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-08-31drm/i915: Check DP link status on long hpd tooVille Syrjälä
We are no longer checkling the DP link status on long hpd. We used to do that from the .hot_plug() handler, but it was removed when MST got introduced. If there's no userspace we now fail to retrain the link if the sink power is toggled (or cable yanked and replugged), meaning the user is left staring at a blank screen. With the retraining put back that should be fixed. Also remove the leftover comment that referred to the old retraining from .hot_plug(). Fixes a regression introduced in: commit 0e32b39ceed665bfa4a77a4bc307b6652b991632 Author: Dave Airlie <airlied@redhat.com> Date: Fri May 2 14:02:48 2014 +1000 drm/i915: add DP 1.2 MST support (v0.7) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89453 Tested-by: Palmer Dabbelt <palmer@dabbelt.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91407 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89461 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89594 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85641 Cc: Dave Airlie <airlied@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-08-31Merge branch 'exynos-drm-next' of ↵Dave Airlie
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next This is a second pull-request which adds last part of atomic modeset/pageflip support, render node support, clean-up, and fix-up. * 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: drm/exynos: fix build warning to exynos_drm_gem.c drm/exynos: Properly report supported formats for each device drm/exynos: add render node support drm/exynos: implement atomic_{begin/flush} of DECON drm/exynos: remove legacy ->suspend()/resume() drm/exynos: Enable atomic modesetting feature drm/exynos: remove wait queue for pending page flip drm/exynos: wait all planes updates to finish drm/exynos: add atomic asynchronous commit drm/exynos: fimd: only finish update if START == START_S drm/exynos: add macro to get the address of START_S reg drm/exynos: check for pending fb before finish update drm/exynos: fimd: move window protect code to prepare/cleanup_plane drm/exynos: add prepare and cleanup phases for planes drm/exynos: fimd: unify call to exynos_drm_crtc_finish_pageflip() drm/exynos: don't track enabled state at exynos_crtc
2015-08-31Merge tag 'drm-intel-next-fixes-2015-08-28' of ↵Dave Airlie
git://anongit.freedesktop.org/drm-intel into drm-next Some i915 fixes headed for v4.3. SKL DDI-E is a wip, but here's the first in a series. * tag 'drm-intel-next-fixes-2015-08-28' of git://anongit.freedesktop.org/drm-intel: drm/i915/skl: enable DDI-E hotplug drm/i915: Fix build warning on 32-bit drm/i915/skl: Update DDI buffer translation programming. drm/i915: Allow parsing of variable size child device entries from VBT drm/i915: fix link rates reported for SKL drm/i915: fix VBT parsing for SDVO child device mapping
2015-08-31drm/exynos: fix build warning to exynos_drm_gem.cInki Dae
Signed-off-by: Inki Dae <daeinki@gmail.com>
2015-08-31drm/exynos: Properly report supported formats for each deviceMarek Szyprowski
Exynos DRM reported that all planes for all supported sub-devices supports only three pixel formats: XRGB24, ARGB24 and NV12. This patch lets each Exynos DRM sub-drivers to provide the list of supported pixel formats and registers this list to DRM core. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-08-31drm/exynos: add render node supportJoonyoung Shim
This patch allows clients who want to use render node to access rendering relevant ioctls - g2d, post processor and gem allocation. Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-08-31drm/exynos: implement atomic_{begin/flush} of DECONHyungwon Hwang
Each CRTC's atomic_{begin/flush} must stop/start the update of shadow registers to active register in the functions. This patch achieves these purpose by moving the setting of protection bits to those functions from decon_update_plane. v2: rebased to the branch exynos-drm-next Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-08-31drm/exynos: remove legacy ->suspend()/resume()Gustavo Padovan
These legacy helpers should only be used by shadow-attaching drivers. KMS drivers has its own way to handle suspend/resume and don't need to use these two helpers. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <daeinki@gmail.com>
2015-08-31drm/exynos: Enable atomic modesetting featureGustavo Padovan
From: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Now that atomic modesetting is implemented for exynos enable the DRIVER_ATOMIC flag on the driver's features. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-08-31drm/exynos: remove wait queue for pending page flipGustavo Padovan
Exynos atomic commit procedures already does this job of waiting for pending updates to finish, that means using pending_flip_queue is pointless now because the disable CRTC procedure will never happen during a page_flip. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-08-31drm/exynos: wait all planes updates to finishGustavo Padovan
Add infrastructure to wait for all planes updates to finish by using an atomic_t variable to track how many pending updates we are waiting plus a wait_queue for the wait part. It also changes vblank behaviour and keeps it enabled for all types of updates Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-08-31drm/exynos: add atomic asynchronous commitGustavo Padovan
The atomic modesetting interfaces supports async commits that should be implemented by the drivers. If drm core requests an async commit exynos_atomic_commit() will now schedule a work task to run the update later. It also serializes commits that needs to run on the same crtc, putting the following commit to wait until the current one is finished. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-08-31drm/exynos: fimd: only finish update if START == START_SGustavo Padovan
fimd_update_plane() programs BUF_START[win] and during the update BUF_START[win] is copied to BUF_START_S[win] (its shadow register) and starts scanning out, then it raises a irq. The fimd_irq_handler, in the case we have a pending_fb, will check the fb value was copied to START_S register and finish the update in case of success. Based on patch from Daniel Kurtz <djkurtz@chromium.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-08-31drm/exynos: check for pending fb before finish updateGustavo Padovan
The current code was ignoring the end of update for all overlay planes, caring only for the primary plane update in case of pageflip. This change adds a change to start to check for pending updates for all planes through exynos_plane->pending_fb. At the start of plane update the pending_fb is set with the fb to be shown on the screen. Then only when to fb is already presented in the screen we set pending_fb to NULL to signal that the update was finished. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com> fixup! drm/exynos: check for pending fb before finish update
2015-08-31drm/exynos: fimd: move window protect code to prepare/cleanup_planeGustavo Padovan
Only set/clear the update bit in the CRTC's .atomic_begin()/flush() so all planes are really committed at the same time. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-08-31drm/exynos: add prepare and cleanup phases for planesGustavo Padovan
From: Gustavo Padovan <gustavo.padovan@collabora.co.uk> .prepare_plane() and .cleanup_plane() allows to perform extra operations before and after the update of planes. For FIMD for example this will be used to enable disable the shadow protection bit. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-08-31drm/exynos: fimd: unify call to exynos_drm_crtc_finish_pageflip()Gustavo Padovan
Unify handling of finished plane update to prepare for a following patch that will check for the START and START_S regs to really make sure that the plane was updated. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-08-31drm/exynos: don't track enabled state at exynos_crtcGustavo Padovan
struct drm_crtc already stores the enabled state of the crtc thus we don't need to replicate enabled in exynos_drm_crtc. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2015-08-30amdkfd: use <linux/mman.h> instead of <uapi/asm-generic/mman-common.h>Christoph Hellwig
The latter is a default version of <asm/mman.h> and not for driver use. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
2015-08-28drm/amdgpu: use IB for fill_buffer instead of direct commandChunming Zhou
Signed-off-by: Chunming Zhou <david1.zhou@amd.com> Reviewed-by: Christian K?nig <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2015-08-28drm/amdgpu: stop trying to suspend UVD sessions v2Christian König
Saving the current UVD state on suspend and restoring it on resume just doesn't work reliable. Just close cleanup all sessions on suspend. Ported from radeon commit "12e49feadff6d7b7ebbe852b36943a71524d8d34". v2: rebased Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1)
2015-08-28drm/amdgpu: add scheduler dependency callback v2Christian König
This way the scheduler doesn't wait in it's work thread any more. v2: fix race conditions Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
2015-08-28drm/amdgpu: let the scheduler work more with jobs v2Christian König
v2: fix another race condition Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
2015-08-28drm/radeon: fix HDMI quantization_range for pre-DCE5 asicsAlex Deucher
Support for output_csc is only available on DCE5 and newer so don't mess with the HDMI quantization_range on pre-DCE5 asics. bug: https://bugs.freedesktop.org/show_bug.cgi?id=83226 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
generated by cgit (git 2.34.1) at 2025-06-03 05:29:08 +0000