summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm (follow)
Commit message (Collapse)AuthorAgeFilesLines
* drm/plane-helper: Don't fake-implement primary plane disablingDaniel Vetter2014-04-181-28/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After thinking about this topic a bit more I've reached the conclusion that implementing this doesn't make sense: - The locking is all wrong: set_config(NULL) will also unlink encoders and connectors, but those links are protected with the mode_config mutex. In the ->disable_plane callback we only hold all modeset locks, but eventually we want to switch to just grabbing the per-crtc (and maybe per-plane) locks as needed, maybe based on ww_mutexes. Having a callback which absolutely needs all modeset locks is bad for this conversion. Note that the same isn't true for the provided ->update_plane since we've audited the crtc helpers to make sure that not encoder or connector links are changed. - There's no way to re-enable the plane with an ->update_plane: The connectors/encoder links are lost and so we can't re-enable the CRTC. Even without that issue the driver might have reassigned some shared resources (as opposed to e.g. DPMS off, where drivers are not allowed to do that to make sure the CRTC can be enabled again). - The semantics don't make much sense: Userspace asked to scan out black (or some other color if the driver supports a background color), not that the screen be disabled. - Implementing proper primary plane support (i.e. actually disabling the primary plane without disabling the CRTC) is really simple, at least if all the hw needs is flipping a bit. The big task is auditing all the interactions with other ioctls when the CRTC is on but there's no primary plane (e.g. pageflips). And some of that work still needs to be done. Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/ast: fix value check in cbr_scan2Dave Airlie2014-04-181-1/+1
| | | | | | | | | this is a typo vs the ums driver, fix to check correct value. Found initially by Coverity. Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/nouveau/bios: fix a bit shift error introduced by 457e77bSergei Antonov2014-04-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Commit 457e77b26428ab4a24998eecfb99f27fa4195397 added two checks applied to a value received from nv_rd32(bios, 0x619f04). But after this new piece of code is executed, the addr local variable does not hold the same value it used to hold before the commit. Here is what is was assigned in the original code: (u64)(nv_rd32(bios, 0x619f04) & 0xffffff00) << 8 in the committed code it ends up with this value: (u64)(nv_rd32(bios, 0x619f04) >> 8) << 8 These expressions are obviously not equivalent. My Nvidia video card does not show anything on the display when I boot a kernel containing this commit. The patch fixes the code so that the new checks are still done, but the side effect of an incorrect addr value is gone. Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Sergei Antonov <saproj@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* Merge tag 'omapdrm-fixes-3.15' of ↵Dave Airlie2014-04-187-42/+133
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-next Fixes for omapdrm, some of which were already present in 3.14, and some which appeared in 3.15-rc1: - fixes for primary-plane handling which caused crashes - fix all kinds of uninit issues which prevented from unloading the omapdrm module. - fixes for HDMI enable/disable issues * tag 'omapdrm-fixes-3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux: drm/omap: fix the handling of fb ref counts drm/omap: protect omap_crtc's event with event_lock spinlock drm/omap: Use old_fb to synchronize between successive page flips drm/omap: Fix crash when using LCD3 overlay manager drm/omap: gem sync: wait on correct events drm/omap: Fix memory leak in omap_gem_op_async drm/omap: remove warn from debugfs drm/omap: remove extra plane->destroy from crtc destroy drm/omap: print warning when rotating non-TILER fb drm/omap: fix missing unref to fb's buf object drm/omap: fix plane rotation drm/omap: fix enabling/disabling of video pipeline drm/omap: fix missing disable for unused encoder drm/omap: fix race issue when unloading omapdrm drm/omap: fix DMM driver (un)registration drm/omap: fix uninit order in pdev_remove() drm/omap: fix output enable/disable sequence
| * drm/omap: fix the handling of fb ref countsTomi Valkeinen2014-04-151-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | With the recent primary-plane changes for drm, the primary plane's framebuffer needs to be ref counted the same way as for non-primary-planes. This was not done by the omapdrm driver, which caused the ref count to drop to 0 too early, causing problems. This patch moves the fb unref and ref from omap_plane_update to omap_plane_mode_set. This way the fb refs are updated for both primary and non-primary cases, as omap_plane_update calls omap_plane_mode_set. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * drm/omap: protect omap_crtc's event with event_lock spinlockArchit Taneja2014-04-151-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | The vblank_cb callback and the page_flip ioctl can occur together in different CPU contexts. vblank_cb uses takes tje drm device's event_lock spinlock when sending the vblank event and updating omap_crtc->event and omap_crtc->od_fb. Use the same spinlock in page_flip, to make sure the above omap_crtc parameters are configured sequentially. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * drm/omap: Use old_fb to synchronize between successive page flipsArchit Taneja2014-04-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | omap_crtc->old_fb is used to check whether the previous page flip has completed or not. However, it's never initialized to anything, so it's always NULL. This results in the check to always succeed, and the page_flip to proceed. Initialize old_fb to the fb that we intend to flip to through page_flip, and therefore prevent a future page flip to proceed if the last one didn't complete. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * drm/omap: Fix crash when using LCD3 overlay managerArchit Taneja2014-04-151-0/+1
| | | | | | | | | | | | | | | | | | | | The channel_names list didn't have a string populated for LCD3 manager, this results in a crash when the display's output is connected to LCD3. Add an entry for LCD3. Reported-by: Somnath Mukherjee <somnath@ti.com> Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * drm/omap: gem sync: wait on correct eventsArchit Taneja2014-04-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A waiter of the type OMAP_GEM_READ should wait for a buffer to be completely written, and only then proceed with reading it. A similar logic applies for waiters with OMAP_GEM_WRITE flag. Currently the function is_waiting() waits on the read_complete/read_target counts in the sync object. This should be the other way round, as a reader should wait for users who are 'writing' to this buffer, and vice versa. Make readers of the buffer(OMAP_GEM_READ) wait on the write counters, and writers to the buffer(OMAP_GEM_WRITE) wait on the read counters in is_waiting() Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * drm/omap: Fix memory leak in omap_gem_op_asyncSubhajit Paul2014-04-151-0/+2
| | | | | | | | | | | | | | | | | | | | | | In omap_gem_op_async(), if a waiter is not added to the wait list, it needs to be free'd in the function itself. Make sure we free the waiter for this case. Signed-off-by: Subhajit Paul <subhajit_paul@ti.com> Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * drm/omap: remove warn from debugfsTomi Valkeinen2014-04-151-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | Patch dfe96ddcfa22b44100814b9435770f6ff1309d37 (omapdrm: simplify locking in the fb debugfs file) removed taking locks when using omapdrm's debugfs to dump fb objects. However, in omap_gem_describe we give a WARN is the lock has not been taken, so that WARN is now seen every time omapdrm debugfs is used. So, presuming the removal of locks is ok, we can also remove the WARN. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * drm/omap: remove extra plane->destroy from crtc destroyTomi Valkeinen2014-04-151-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | All the planes, including primary planes, are now destroyed by the drm framework. Thus we no longer need the explicit call to plane->destroy from the crtc's destroy function. This patch removes the call, thus fixing the crash caused by double freeing the plane. remove omap_crtc->plane->funcs->destroy(omap_crtc->plane) Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * drm/omap: print warning when rotating non-TILER fbTomi Valkeinen2014-04-151-0/+14
| | | | | | | | | | | | | | | | | | Print a warning when the user tries to rotate a non-TILER framebuffer. Also set the rotation to 0, to avoid constant flood of the warnings in case of page flipping. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * drm/omap: fix missing unref to fb's buf objectTomi Valkeinen2014-04-141-0/+3
| | | | | | | | | | | | | | | | | | | | omap_fbdev_create() takes a reference to the fb's gem object with omap_gem_get_paddr(). However, it never releases it with omap_gem_put_paddr(). This patch adds the missing omap_gem_put_paddr() to omap_fbdev_free(). Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * drm/omap: fix plane rotationGrazvydas Ignotas2014-04-141-0/+8
| | | | | | | | | | | | | | | | | | | | Plane rotation with omapdrm is currently broken. It seems omap_plane_mode_set() expects width and height in screen coordinates, so pass it like that. Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * drm/omap: fix enabling/disabling of video pipelineTomi Valkeinen2014-04-141-7/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At the moment the omap_crtc_pre_apply() handles the enabling, disabling and configuring of encoders and panels separately from the CRTC (i.e. the overlay manager). However, this doesn't work correctly. The encoder driver has to be in control of its video input (i.e. the crtc) for correct operation. This problem causes bugs with (at least) HDMI: the HDMI encoder supplies pixel clock for DISPC, and DISPC supplies video stream for HDMI. The current code first enables the HDMI encoder, and CRTC after that. However, the encoder expects the video stream to start during the encoder's enable, and if it doesn't, there will be sync lost errors. The encoder enables its video source by calling src->enable(), and this call goes to omapdrm (omap_crtc_enable), but omapdrm doesn't do anything in that function. Similarly for disable, which goes to omap_crtc_disable(). This patch moves the code to setup and enable/disable the crtc to omap_crtc_enable. and omap_crtc_disable(). Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Rob Clark <robdclark@gmail.com>
| * drm/omap: fix missing disable for unused encoderTomi Valkeinen2014-04-141-0/+6
| | | | | | | | | | | | | | | | | | | | | | When an encoder is no longer connected to a crtc, the driver will leave the encoder enabled. This patch adds code to track the encoder used for a crtc, and when the encoder changes, the old one is disabled. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Rob Clark <robdclark@gmail.com>
| * drm/omap: fix race issue when unloading omapdrmTomi Valkeinen2014-04-143-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At module unload, omap_fbdev_free() gets called which releases the framebuffers. However, the framebuffers are still used by crtcs, and will be released only later at vsync. The driver doesn't wait for this, and goes on to release the rest of the resources, which often causes a crash. This patchs adds a omap_crtc_flush() function which waits until the crtc has finished with its apply queue and page flips. The function utilizes a simple polling while-loop, as the performance is not an issue here. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Rob Clark <robdclark@gmail.com>
| * drm/omap: fix DMM driver (un)registrationTomi Valkeinen2014-04-141-4/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | At the moment the DMM driver is never unregistered, even if it's registered in the omapdrm module's init function. This means we'll get errors when reloading the omapdrm module. Fix this by unregistering the DMM driver properly, and also change the module init to fail if DMM driver cannot be registered, simplifying the unregister path as we don't need to keep the state whether we registered the DMM driver or not. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Rob Clark <robdclark@gmail.com>
| * drm/omap: fix uninit order in pdev_remove()Tomi Valkeinen2014-04-141-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | When unloading omapdrm driver, the omapdrm platform device is uninitialized last, after the displays have been disconnected omap_crtc callbacks have been removed. As the omapdrm pdev uninitialization needs the features uninitialized in earlier steps, a crash is guaranteed. This patch fixes the uninitialize order so that the omapdrm pdev is removed first. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Rob Clark <robdclark@gmail.com>
| * drm/omap: fix output enable/disable sequenceTomi Valkeinen2014-04-141-19/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At the moment it's quite easy to get the following errors when the HDMI output is enabled or disabled: [drm:omap_crtc_error_irq] *ERROR* tv: errors: 00008000 The reason for the errors is that the omapdrm driver doesn't properly handle the sync-lost irqs that happen when enabling the DIGIT crtc, which is used for HDMI and analog TV. The driver does disable the sync-lost irq properly, but it fails to wait until the output has been fully enabled (i.e. the first vsync), so the sync-lost errors are still seen occasionally. This patch makes the omapdrm act the same way as the omapfb does: - When enabling a display, we'll wait for the first vsync. - When disabling a display, we'll wait for framedone if available, or odd and even vsyncs. These changes make sure the output is fully enabled or disabled at the end of the function. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reported-by: Sanjay Singh Rawat <sanjay.rawat@linaro.org> Reviewed-by: Rob Clark <robdclark@gmail.com>
* | drm/radeon/ci: make sure mc ucode is loaded before checking the sizeAlex Deucher2014-04-171-1/+3
| | | | | | | | | | | | | | | | Avoid a possible segfault. Noticed-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
* | drm/radeon/si: make sure mc ucode is loaded before checking the sizeAlex Deucher2014-04-171-1/+3
| | | | | | | | | | | | | | | | Avoid a possible segfault. Noticed-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
* | drm/radeon: improve PLL params if we don't match exactly v2Christian König2014-04-171-6/+7
| | | | | | | | | | | | | | | | Otherwise we might be quite off on older chipsets. v2: keep ref_div minimum Signed-off-by: Christian König <christian.koenig@amd.com>
* | drm/radeon: memory leak on bo reservation failure. v2Quentin Casasnovas2014-04-171-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | On bo reservation failure, we end up leaking fpriv. v2 (chk): rebased and added missing free on vm failure as well Fixes: 5e386b574cf7e1 ("drm/radeon: fix missing bo reservation") Cc: stable@vger.kernel.org Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Quentin Casasnovas <quentin.casasnovas@oracle.com> Signed-off-by: Christian König <christian.koenig@amd.com>
* | drm/radeon: fix VCE fence commandChristoph Jaeger2014-04-171-1/+1
| | | | | | | | | | | | | | | | | | | | Due to a type mismatch that causes an implicit type conversion, the upper 32 bits of the GPU address have been zeroed out when adding to the command buffer. Picked up by Coverity - CID 1198624. Signed-off-by: Christoph Jaeger <christophjaeger@linux.com>
* | drm/radeon: re-enable mclk dpm on R7 260X asicsAlex Deucher2014-04-171-2/+6
| | | | | | | | | | | | | | If the new mc ucode is available. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
* | drm/radeon: add support for newer mc ucode on CI (v2)Alex Deucher2014-04-172-10/+20
| | | | | | | | | | | | | | | | | | | | | | | | Fixes mclk stability on certain asics. v2: print out mc firmware version used and size bug: https://bugs.freedesktop.org/show_bug.cgi?id=75992 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
* | drm/radeon: add support for newer mc ucode on SI (v2)Alex Deucher2014-04-172-13/+25
| | | | | | | | | | | | | | | | | | May fix stability issues with some newer cards. v2: print out mc firmware version used and size Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
* | drm/radeon: apply more strict limits for PLL params v2Christian König2014-04-171-0/+3
| | | | | | | | | | | | | | | | Letting post and refernce divider get to big is bad for signal stability. v2: increase the limit to 210 Signed-off-by: Christian König <christian.koenig@amd.com>
* | drm/radeon: update CI DPM powertune settingsAlex Deucher2014-04-171-12/+13
| | | | | | | | | | | | As per internal recommendations. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* | drm/radeon: fix runpm handling on APUs (v4)Alex Deucher2014-04-176-34/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Don't try and runtime suspend the APU in PX systems. We only want to power down the dGPU. v2: fix harder v3: fix stupid typo v4: consolidate runpm enablement to a single flag bugs: https://bugs.freedesktop.org/show_bug.cgi?id=75127 https://bugzilla.kernel.org/show_bug.cgi?id=72701 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
* | drm/radeon: disable mclk dpm on R7 260XAlex Deucher2014-04-171-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | Setting higher mclks seems to cause stability issues on some R7 260X boards. Disable it for now for stability until we find a proper fix. bug: https://bugs.freedesktop.org/show_bug.cgi?id=75992 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
* | Merge tag 'drm-intel-fixes-2014-04-11' of ↵Dave Airlie2014-04-169-139/+122
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-next Some fixes from Intel. * tag 'drm-intel-fixes-2014-04-11' of git://anongit.freedesktop.org/drm-intel: drm/i915: Always use kref tracking for all contexts. drm/i915: do not setup backlight if not available according to VBT drm/i915: check VBT for supported backlight type drm/i915: Disable self-refresh for untiled fbs on i915gm drm/mm: Don't WARN if drm_mm_reserve_node
| * drm/i915: Always use kref tracking for all contexts.Chris Wilson2014-04-114-137/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we always initialize kref for the context, even if we are using fake contexts for hangstats when there is no hw support, we can forgo the dance to dereference the ctx->obj and inspect whether we are permitted to use kref inside i915_gem_context_reference() and _unreference(). My ulterior motive here is to improve the debugging of a use-after-free of ctx->obj. This patch avoids the dereference here and instead forces the assertion checks associated with kref. v2: Refactor the fake contexts to being even more like the real contexts, so that there is much less duplicated and special case code. v3: Tweaks. v4: Tweaks, minor. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76671 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: lu hua <huax.lu@intel.com> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> [Jani: tiny change to backport to drm-intel-fixes.] Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: do not setup backlight if not available according to VBTJani Nikula2014-04-111-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some machines use an external EC for controlling the backlight. Info about this is present in the VBT. Do not setup native backlight control if no PWM backlight is available or supported according to VBT. The acpi_backlight interface appears to work for the EC control. In most cases there has been no harm done, but it looks like there are machines out there that have both an EC and our PWM line connected to the same wire. This, obviously, does not end well. This should fix the regression caused by commit bc0bb9fd1c7810407ab810d204bbaecb255fddde Author: Jani Nikula <jani.nikula@intel.com> Date: Thu Nov 14 12:14:29 2013 +0200 drm/i915: remove QUIRK_NO_PCH_PWM_ENABLE AFAICT the quirk removed by the above commit effectively resulted in i915 not driving the backlight PWM output, thus not messing things up. Additionally this should fix the regression caused by commit fbc9fe1b4f222a7c575e3bd8e9defe59c6190a04 Author: Aaron Lu <aaron.lu@intel.com> Date: Fri Oct 11 21:27:45 2013 +0800 ACPI / video: Do not register backlight if win8 and native interface exists which left some machines without a functioning backlight interface. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76276 Reference: https://bugzilla.kernel.org/show_bug.cgi?id=47941 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=62281 CC: Aaron Lu <aaron.lu@intel.com> CC: Eric Griffith <EGriffith92@gmail.com> CC: Kent Baxley <kent.baxley@canonical.com> Tested-by: Kamal Mostafa <kamal@canonical.com> Tested-by: Martin <bugs@mrvanes.com> Tested-by: jrg.otte@gmail.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: check VBT for supported backlight typeJani Nikula2014-04-113-0/+14
| | | | | | | | | | | | | | | | | | | | | | The only supported types are none and PWM. Other values are obsolete or reserved, don't add them. Tested-by: Kamal Mostafa <kamal@canonical.com> Tested-by: Martin <bugs@mrvanes.com> Tested-by: jrg.otte@gmail.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: Disable self-refresh for untiled fbs on i915gmDaniel Vetter2014-04-101-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Apparently it doesn't work. X-tiled self-refresh works flawlessly otoh. Apparently X still works correctly with linear framebuffers, so might just be an issue with the initial modeset. It's unclear whether this just borked wm setup from our side or a hw restriction, but just disabling gets things going. Note that this regression was only brought to light with commit 3f2dc5ac05714711fc14f2bf0ee5e42d5c08c581 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Jan 10 14:06:47 2014 +0200 drm/i915: Fix 915GM self-refresh enable/disable before that self-refresh for i915GM didn't work at all. Kudos to Ville for spotting a little bug in the original patch I've attached to the bug. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76103 Tested-by: Krzysztof Mazur <krzysiek@podlesie.net> Cc: Krzysztof Mazur <krzysiek@podlesie.net> Cc: stable@vger.kernel.org Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> [Jani: rebase on top of drm-next with primary plane support.] Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/mm: Don't WARN if drm_mm_reserve_nodeDaniel Vetter2014-04-101-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Jesse's BIOS fb reconstruction code actually relies on the -ENOSPC return value to detect overlapping framebuffers (which the bios uses always when lighting up more than one screen). All this fanciness happens in intel_alloc_plane_obj in intel_display.c. Since no one else uses this we can safely remove the WARN without repercussions. Reported-by: Ben Widawsky <benjamin.widawsky@intel.com> Tested-by: Ben Widawsky <ben@bwidawsk.net> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds2014-04-08436-15223/+38635
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull drm updates from Dave Airlie: "Highlights: - drm: Generic display port aux features, primary plane support, drm master management fixes, logging cleanups, enforced locking checks (instead of docs), documentation improvements, minor number handling cleanup, pseudofs for shared inodes. - ttm: add ability to allocate from both ends - i915: broadwell features, power domain and runtime pm, per-process address space infrastructure (not enabled) - msm: power management, hdmi audio support - nouveau: ongoing GPU fault recovery, initial maxwell support, random fixes - exynos: refactored driver to clean up a lot of abstraction, DP support moved into drm, LVDS bridge support added, parallel panel support - gma500: SGX MMU support, SGX irq handling, asle irq work fixes - radeon: video engine bringup, ring handling fixes, use dp aux helpers - vmwgfx: add rendernode support" * 'drm-next' of git://people.freedesktop.org/~airlied/linux: (849 commits) DRM: armada: fix corruption while loading cursors drm/dp_helper: don't return EPROTO for defers (v2) drm/bridge: export ptn3460_init function drm/exynos: remove MODULE_DEVICE_TABLE definitions ARM: dts: exynos4412-trats2: enable exynos/fimd node ARM: dts: exynos4210-trats: enable exynos/fimd node ARM: dts: exynos4412-trats2: add panel node ARM: dts: exynos4210-trats: add panel node ARM: dts: exynos4: add MIPI DSI Master node drm/panel: add S6E8AA0 driver ARM: dts: exynos4210-universal_c210: add proper panel node drm/panel: add ld9040 driver panel/ld9040: add DT bindings panel/s6e8aa0: add DT bindings drm/exynos: add DSIM driver exynos/dsim: add DT bindings drm/exynos: disallow fbdev initialization if no device is connected drm/mipi_dsi: create dsi devices only for nodes with reg property drm/mipi_dsi: add flags to DSI messages Skip intel_crt_init for Dell XPS 8700 ...
| * DRM: armada: fix corruption while loading cursorsRussell King2014-04-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Loading cursors to the LCD controller's SRAM can be corrupted when the configured pixel clock is relatively slow. This seems to be caused when we write back-to-back to the SRAM registers. There doesn't appear to be any status register we can read to check when an access has completed. Inserting a dummy read between the writes appears to fix the problem. Cc: <stable@vger.kernel.org> # 3.13 Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * Merge tag 'drm-intel-fixes-2014-04-04' of ↵Dave Airlie2014-04-0528-412/+608
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-next Merge window -fixes pull request as usual. Well, I did sneak in Jani's drm_i915_private_t typedef removal, need to have fun with a big sed job too ;-) Otherwise: - hdmi interlaced fixes (Jesse&Ville) - pipe error/underrun/crc tracking fixes, regression in late 3.14-rc (but not cc: stable since only really relevant for igt runs) - large cursor wm fixes (Chris) - fix gpu turbo boost/throttle again, was getting stuck due to vlv rps patches (Chris+Imre) - fix runtime pm fallout (Paulo) - bios framebuffer inherit fix (Chris) - a few smaller things * tag 'drm-intel-fixes-2014-04-04' of git://anongit.freedesktop.org/drm-intel: (196 commits) Skip intel_crt_init for Dell XPS 8700 drm/i915: vlv: fix RPS interrupt mask setting Revert "drm/i915/vlv: fixup DDR freq detection per Punit spec" drm/i915: move power domain init earlier during system resume drm/i915: Fix the computation of required fb size for pipe drm/i915: don't get/put runtime PM at the debugfs forcewake file drm/i915: fix WARNs when reading DDI state while suspended drm/i915: don't read cursor registers on powered down pipes drm/i915: get runtime PM at i915_display_info drm/i915: don't read pp_ctrl_reg if we're suspended drm/i915: get runtime PM at i915_reg_read_ioctl drm/i915: don't schedule force_wake_timer at gen6_read drm/i915: vlv: reserve the GT power context only once during driver init drm/i915: prefer struct drm_i915_private to drm_i915_private_t drm/i915/overlay: prefer struct drm_i915_private to drm_i915_private_t drm/i915/ringbuffer: prefer struct drm_i915_private to drm_i915_private_t drm/i915/display: prefer struct drm_i915_private to drm_i915_private_t drm/i915/irq: prefer struct drm_i915_private to drm_i915_private_t drm/i915/gem: prefer struct drm_i915_private to drm_i915_private_t drm/i915/dma: prefer struct drm_i915_private to drm_i915_private_t ...
| | * Skip intel_crt_init for Dell XPS 8700Giacomo Comes2014-04-041-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Dell XPS 8700 has a onboard Display port and HDMI port and no VGA port. The call intel_crt_init freeze the machine, so skip such call. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73559 Signed-off-by: Giacomo Comes <comes at naic.edu> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915: vlv: fix RPS interrupt mask settingImre Deak2014-04-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This typo may lead to missed RPS interrupts and as a result a too low or too high frequency for the current workload. The interrupt mask will be set properly at a subsequent GPU idle event, but can get corrupted again at the next RPS up/down event. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * Revert "drm/i915/vlv: fixup DDR freq detection per Punit spec"Deepak S2014-04-041-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As per the inputs provided by hardware team we still use DDR Rates as 0,1=800, 2=1066, 3=1333. With this change, Turbo freqs used on current machines matches. This reverts commit f64a28a7c5ab2fc342326de9e126acf3cc0f91d6. commit f64a28a7c5ab2fc342326de9e126acf3cc0f91d6 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Mon Nov 4 16:07:00 2013 -0800 drm/i915/vlv: fixup DDR freq detection per Punit spec v2: Add reference to previous commit which changed this. (Daniel) Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915: move power domain init earlier during system resumeImre Deak2014-04-041-14/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During resume the intel hda audio driver depends on the i915 driver reinitializing the audio power domain. Since the order of calling the i915 resume handler wrt. that of the audio driver is not guaranteed, move the power domain reinitialization step to the resume_early handler. This is guaranteed to run before the resume handler of any other driver. The power domain initialization in turn requires us to enable the i915 pci device first, so move that part earlier too. Accordingly disabling of the i915 pci device should happen after the audio suspend handler ran. So move the disabling later from the i915 resume handler to the resume_late handler. v2: - move intel_uncore_sanitize/early_sanitize earlier too, so they don't get reordered wrt. intel_power_domains_init_hw() Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76152 Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Cc: stable@vger.kernel.org [danvet: Add cc: stable and loud comments that this is just a hack.] [danvet: Fix "Should it be static?" sparse warning reported by Wu Fengguang's kbuilder.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915: Fix the computation of required fb size for pipeChris Wilson2014-04-021-8/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The computation of required framebuffer size in commit d978ef14456a38034f6c0e94a794129501f89200 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Fri Mar 7 08:57:51 2014 -0800 drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon v12 is too optimistic, and would rely on the invariant fb being reconstructed to exactly fit each pipe (and probably ignore hardware limits). Instead, we want to compute the upper bound on what the display engine will access and ensure that is within the inherited framebuffer. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915: don't get/put runtime PM at the debugfs forcewake filePaulo Zanoni2014-04-011-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | Because gen6_gt_force_wake_{get,put} should already be responsible for getting/putting runtime PM. If we keep these calls, debugfs will not be testing the get/put calls of the forcewake functions. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915: fix WARNs when reading DDI state while suspendedPaulo Zanoni2014-04-012-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If runtime PM is enabled and we unset all modes, we will runtime suspend after __intel_set_mode() , then function intel_modeset_check_state() will try to read the HW state while it is suspended and trigger lots of WARNs because it shouldn't be reading registers. So on this patch we make intel_ddi_connector_get_hw_state() return false in case the power domain is disabled, and we also make intel_display_power_enabled() return false in case the device is suspended. Notice that we can't just use intel_display_power_enabled_sw() because while the driver is being initialized the power domain refcounts are not reflecting the real state of the hardware. Just for reference, I have previously published an alternate patch for this problem, called "drm/i915: get runtime PM at intel_set_mode". Testcase: igt/pm_pc8 Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915: don't read cursor registers on powered down pipesPaulo Zanoni2014-04-011-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At i915_display_info, don't call cursor_position() for a disabled CRTC, since the CRTC may be on a powered down pipe, and this will cause "Unclaimed register before interrupt" error messages. Testcase: igt/pm_pc8/debugfs-read Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-26 18:08:47 +0100