summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2015-03-26drm/i915: Pass acquire ctx also to intel_release_load_detect_pipe()Ander Conselvan de Oliveira
For now this is not necessary since intel_set_mode() doesn't acquire any new locks. However, once that function is converted to atomic, that will change, since we'll pass an atomic state to it, and that needs to have the right acquire context set. Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-26drm/i915: Add intel_atomic_get_crtc_state() helper functionAnder Conselvan de Oliveira
The pattern of getting the crtc state with drm_atomic_get_crtc_state() and then converting it to intel_crtc_state will repeat quite often in the following patches, so add a helper function to save some typing. v2: Fix upcasting so that crtc_state base field could be moved. (Daniel) Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-26drm/i915: always preserve bios swizzlingDaniel Vetter
Currently we only set preserve_bios_swizzling when the initial fb is shared and totally miss the single-screen case. Fix this by consolidating all the logic for both cases. This seems to go back to when swizzle preservation was originally merged in commit d9ceb8163339134bd3ffb9fb87a0db4698283e32 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Thu Oct 9 12:57:43 2014 -0700 drm/i915: preserve swizzle settings if necessary v4 Cc: Kristian Høgsberg <hoegsberg@gmail.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-03-26drm/i915: Add initial_ prefix to bios fb takeover codeDaniel Vetter
In spirit with commit 5724dbd1678e2f573b13f0688277941fad66cb88 Author: Damien Lespiau <damien.lespiau@intel.com> Date: Tue Jan 20 12:51:52 2015 +0000 drm/i915: Rename plane_config to initial_plane_config to make it clear that this code is all special-purpose for the initial plane takeover. Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-03-26drm/i915: Remove duplicated psr.active unsetRodrigo Vivi
psr.active is being unset out of the if so this here is useless and duplicated. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-26drm/i915: Fixup legacy plane->crtc link for initial fb configDaniel Vetter
This is a very similar bug in the load detect code fixed in commit 9128b040eb774e04bc23777b005ace2b66ab2a85 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Mar 3 17:31:21 2015 +0100 drm/i915: Fix modeset state confusion in the load detect code But this time around it was the initial fb code that forgot to update the plane->crtc pointer. Otherwise it's the exact same bug, with the exact same restrains (any set_config call/ioctl that doesn't disable the pipe papers over the bug for free, so fairly hard to hit in normal testing). So if you want the full explanation just go read that one over there - it's rather long ... Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Josh Boyer <jwboyer@fedoraproject.org> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reported-and-tested-by: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-26drm/i915: kill i915.powersaveRodrigo Vivi
This flag was being mostly used as a meta flag in some cases and not covering other cases. One of the risks is that it was masking some frontbuffer trackings without disabling PSR. So, better to kill this at once and avoid umbrella parameters. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Drop unused out: label to appease gcc.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-26drm/i915: Fixup legacy plane->crtc link for initial fb configDaniel Vetter
This is a very similar bug in the load detect code fixed in commit 9128b040eb774e04bc23777b005ace2b66ab2a85 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Mar 3 17:31:21 2015 +0100 drm/i915: Fix modeset state confusion in the load detect code But this time around it was the initial fb code that forgot to update the plane->crtc pointer. Otherwise it's the exact same bug, with the exact same restrains (any set_config call/ioctl that doesn't disable the pipe papers over the bug for free, so fairly hard to hit in normal testing). So if you want the full explanation just go read that one over there - it's rather long ... Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Josh Boyer <jwboyer@fedoraproject.org> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reported-and-tested-by: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> [Jani: backported to drm-intel-fixes for v4.0-rc] Reference: http://mid.gmane.org/CA+5PVA7ChbtJrknqws1qvZcbrg1CW2pQAFkSMURWWgyASRyGXg@mail.gmail.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-03-26drm/i915: Fix atomic state when reusing the firmware fbDamien Lespiau
Right now, we get a warning when taking over the firmware fb: [drm:drm_atomic_plane_check] FB set but no CRTC with the following backtrace: [<ffffffffa010339d>] drm_atomic_check_only+0x35d/0x510 [drm] [<ffffffffa0103567>] drm_atomic_commit+0x17/0x60 [drm] [<ffffffffa00a6ccd>] drm_atomic_helper_plane_set_property+0x8d/0xd0 [drm_kms_helper] [<ffffffffa00f1fed>] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm] [<ffffffffa00a8a1b>] restore_fbdev_mode+0x6b/0xf0 [drm_kms_helper] [<ffffffffa00aa969>] drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper] [<ffffffffa00aa9e2>] drm_fb_helper_set_par+0x22/0x50 [drm_kms_helper] [<ffffffffa050a71a>] intel_fbdev_set_par+0x1a/0x60 [i915] [<ffffffff813ad444>] fbcon_init+0x4f4/0x580 That's because we update the plane state with the fb from the firmware, but we never associate the plane to that CRTC. We don't quite have the full DRM take over from HW state just yet, so fake enough of the plane atomic state to pass the checks. v2: Fix the state on which we set the CRTC in the case we're sharing the initial fb with another pipe. (Matt) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> [Jani: backported to drm-intel-fixes for v4.0-rc] Reference: http://mid.gmane.org/CA+5PVA7yXH=U757w8V=Zj2U1URG4nYNav20NpjtQ4svVueyPNw@mail.gmail.com Reference: http://lkml.kernel.org/r/CA+55aFweWR=nDzc2Y=rCtL_H8JfdprQiCimN5dwc+TgyD4Bjsg@mail.gmail.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-03-26drm/i915: Keep ring->active_list and ring->requests_list consistentChris Wilson
If we retire requests last, we may use a later seqno and so clear the requests lists without clearing the active list, leading to confusion. Hence we should retire requests first for consistency with the early return. The order used to be important as the lifecycle for the object on the active list was determined by request->seqno. However, the requests themselves are now reference counted removing the constraint from the order of retirement. Fixes regression from commit 1b5a433a4dd967b125131da42b89b5cc0d5b1f57 Author: John Harrison <John.C.Harrison@Intel.com> Date: Mon Nov 24 18:49:42 2014 +0000 drm/i915: Convert 'i915_seqno_passed' calls into 'i915_gem_request_completed ' and a WARNING: CPU: 0 PID: 1383 at drivers/gpu/drm/i915/i915_gem_evict.c:279 i915_gem_evict_vm+0x10c/0x140() WARN_ON(!list_empty(&vm->active_list)) Identified by updating WATCH_LISTS: [drm:i915_verify_lists] *ERROR* blitter ring: active list not empty, but no requests WARNING: CPU: 0 PID: 681 at drivers/gpu/drm/i915/i915_gem.c:2751 i915_gem_retire_requests_ring+0x149/0x230() WARN_ON(i915_verify_lists(ring->dev)) Note that this is only a problem in evict_vm where the following happens after a retire_request has cleaned out all requests, but not all active bo: - intel_ring_idle called from i915_gpu_idle notices that no requests are outstanding and immediately returns. - i915_gem_retire_requests_ring called from i915_gem_retire_requests also immediately returns when there's no request, still leaving the bo on the active list. - evict_vm hits the WARN_ON(!list_empty(&vm->active_list)) after evicting all active objects that there's still stuff left that shouldn't be there. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-03-25drm/i915: Add fault address to error state for gen8 and gen9Mika Kuoppala
The faulting virtual address is >32bits and has been moved to different registers. Add to error state and output upper register first, in the same line for easy reconstruction of the fault address. v2: correct gen masking (Michel) v3: s/TBL/TLB (Ville) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-25drm/i915/skl: Fix up positive error codeTvrtko Ursulin
It should have been negative since it is returned with ERR_PTR(). Introduced in new code commit: commit 50470bb011c4be278097670bea92462f4e8c8945 Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Date: Mon Mar 23 11:10:36 2015 +0000 drm/i915/skl: Support secondary (rotated) frame buffer mapping Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-25drm/i915: make unsupported fb modifier message DRM_DEBUGJesse Barnes
Or users can just spam the log all they want. Issue introduced in commit 9a8f0a1290993c86c4e35756a2624bfe461f9036 Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Date: Fri Feb 27 11:15:24 2015 +0000 drm/i915/skl: Allow Y (and Yf) frame buffer creation References: https://bugs.freedesktop.org/show_bug.cgi?id=89628 Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-25drm/amdkfd: Add multiple kgd supportXihan Zhang
The current code can only support one kgd instance. We have to support multiple kgd instances in one system. i.e two amdgpu or two radeon or one amdgpu + one radeon or more than two kgd instances. Signed-off-by: Xihan Zhang <xihan.zhang@amd.com> Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
2015-03-25drm/amdkfd: Convert timestamping to use 64bit time accessorsJohn Stultz
Convert the timestamping in the amdkfd driver to use a timespec64 and 64bit time accessors. Although the existing code is completely safe beyond y2038 because it deals with monotonic time, this patch is still needed in order to kill off all uses of struct timespec. Signed-off-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
2015-03-25drm/amdkfd: add debug prints for process teardownOded Gabbay
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2015-03-25drm/amdkfd: Remove unused field from struct qcm_process_deviceOded Gabbay
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com> Reviewed-by: Ben Goz <ben.goz@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2015-03-25drm/amdkfd: rename fence_wait_timeoutOded Gabbay
fence_wait_timeout() is an exported kernel symbol, so we should rename our local function to something different. Signed-off-by: Oded Gabbay <oded.gabbay@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2015-03-25Merge tag 'of-graph-for-4.0' of git://git.pengutronix.de/git/pza/linux into ↵Rob Herring
for-next Pull of-graph helpers from Philipp Zabel: of: Add of-graph helpers to loop over endpoints and find ports by id This series converts of_graph_get_next_endpoint to decrement the refcount of the passed prev parameter. This allows to add a for_each_endpoint_of_node helper macro to loop over all endpoints in a device tree node. The of_graph_get_port_by_id function is added to retrieve a port by its known port id (contained in the reg property) from the device tree.
2015-03-25drm/i915: Don't try to reference the fb in get_initial_plane_config()Damien Lespiau
Tvrtko noticed a new warning on boot: WARNING: CPU: 1 PID: 353 at include/linux/kref.h:47 drm_framebuffer_reference+0x6c/0x80 [drm]() Call Trace: [<ffffffff8161f10c>] dump_stack+0x4f/0x7b [<ffffffff81052caa>] warn_slowpath_common+0xaa/0xd0 [<ffffffff81052d8a>] warn_slowpath_null+0x1a/0x20 [<ffffffffa00d035c>] drm_framebuffer_reference+0x6c/0x80 [drm] [<ffffffffa01c0df7>] update_state_fb.isra.54+0x47/0x50 [i915] [<ffffffffa01ccd5c>] skylake_get_initial_plane_config+0x93c/0x950 [i915] [<ffffffffa01e8721>] intel_modeset_init+0x1551/0x17c0 [i915] [<ffffffffa02476e0>] i915_driver_load+0xed0/0x11e0 [i915] [<ffffffff81627aa1>] ? _raw_spin_unlock_irqrestore+0x51/0x70 [<ffffffffa00ca8b7>] drm_dev_register+0x77/0x110 [drm] [<ffffffffa00cda3b>] drm_get_pci_dev+0x11b/0x1f0 [drm] [<ffffffff81098e3d>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff81627aa1>] ? _raw_spin_unlock_irqrestore+0x51/0x70 [<ffffffffa0145276>] i915_pci_probe+0x56/0x60 [i915] [<ffffffff813ad59c>] pci_device_probe+0x7c/0x100 [<ffffffff81466aad>] driver_probe_device+0x16d/0x380 We cannot take a reference at this point, not before intel_framebuffer_init() and the underlying drm_framebuffer_init(). Introduced in: commit 706dc7b549175e47f23e913b7f1e52874a7d0f56 Author: Matt Roper <matthew.d.roper@intel.com> Date: Tue Feb 3 13:10:04 2015 -0800 drm/i915: Ensure plane->state->fb stays in sync with plane->fb v2: Don't move update_state_fb(). It was moved around because I originally put update_state_fb() in intel_alloc_plane_obj() before finding a better place. (Matt) Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reported-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> From drm-next: (cherry picked from commit f55548b5af87ebfc586ca75748947f1c1b1a4a52) Signed-off-by: Dave Airlie <airlied@redhat.com>
2015-03-24drm/omap: tiler: add hibernation callbackGrygorii Strashko
Setting a dev_pm_ops resume callback but not a set of hibernation handler means that pm function will not be called upon hibernation. Fix this by using SIMPLE_DEV_PM_OPS, which appropriately assigns the suspend and hibernation handlers and move omap_dmm_resume under CONFIG_PM_SLEEP to avoid build warnings. Signed-off-by: Grygorii Strashko <grygorii.strashko@linaro.org> Reviewed-by: Rob Clark <robdclark@gmail.com> [tomi valkeinen: add missing 'static'] Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-03-24drm/omap: add hibernation callbacksGrygorii Strashko
Setting a dev_pm_ops suspend/resume pair but not a set of hibernation functions means those pm functions will not be called upon hibernation. Fix this by using SIMPLE_DEV_PM_OPS, which appropriately assigns the suspend and hibernation handlers and move omap_drm_suspend/omap_drm_resume under CONFIG_PM_SLEEP to avoid build warnings. Signed-off-by: Grygorii Strashko <Grygorii.Strashko@linaro.org> [tomi.valkeinen@ti.com: fix conflict, clean up description] Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-03-24drm/omap: keep ref to old_fbTomi Valkeinen
We store the fb being page-flipped to 'old_fb' field, but we don't increase the ref count of the fb when doing that. While I am not sure if it can cause problem in practice, it's still safer to keep a ref when storing a pointer to a fb. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-03-24drm/omap: fix race conditon in DMMTomi Valkeinen
The omapdrm DMM code sometimes crashes with: WARNING: CPU: 0 PID: 1235 at lib/list_debug.c:36 __list_add+0x8c/0xbc() list_add double add: new=e9265368, prev=e90139c4, next=e9265368. This is caused by the code calling release_engine() twice for the same engine. dmm_txn_commit(wait=true) call is supposed to wait until the DMM transaction has been finished. And it does that, but it does not wait for the irq handler to finish. What happens is that the irq handler is triggered, and it either wakes up the thread that called dmm_txn_commit(), or that thread never even slept because the transaction was finished in the HW very quickly. That thread then continues executing, even if the irq handler is not yet finished, and a new transaction may be initiated. If that transaction is async (i.e. wait=false), a 'async' flag is set to true. The original irq handler, which has yet not finished, then sees the transaction as 'async', even if it was supposed to be 'sync'. When that happens, the irq handler does an extra release_engine() call because it thinks it need to release the engine, leading to the crash. This patch fixes the issue by using completion to ensure that the irq handler has finished before a dmm_txn_commit(wait=true) may continue. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-03-24drm/omap: fix race condition with dev->obj_listTomi Valkeinen
omap_gem_objects are added to dev->obj_list in omap_gem_new, and removed in omap_gem_free_object. Unfortunately there's no locking for dev->obj_list, which eventually leads to a crash: WARNING: CPU: 1 PID: 1123 at lib/list_debug.c:59 __list_del_entry+0xa4/0xe0() list_del corruption. prev->next should be e9281344, but was ea722b84 Add a spinlock to protect dev->obj_list. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-03-24drm/omap: do not use BUG_ON(!spin_is_locked(x))Tomi Valkeinen
spin_is_locked(x) returns always 0 on uniprocessor, triggering BUG() in omapdrm. Change it to use assert_spin_locked() to fix the issue. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-03-24drm/omap: only ignore DIGIT SYNC LOST for TV outputTomi Valkeinen
We need to ignore DIGIT SYNC LOST error when enabling/disabling TV output. The code does that, but it ignores the DIGI SYNC LOST when enabling any output. Normally this does no harm, but it could make us miss DIGIT SYNC LOST on some rare occasions. Fix the code to only ignore DIGIT SYNC LOST when enabling/disabling TV. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-03-24drm/omap: fix race with error_irqTomi Valkeinen
omapdrm tries to avoid error floods by unregistering the error irq when an error happens, and then registering the error irq again later. However, the code is racy, as it sometimes tries to unregister the error irq when it's already unregistered, leading to WARN(). Also, the code only registers the error irq again when something is done on that particular output, i.e. if only TV is used to flip the buffers, and LCD is showing a same buffer, an error on LCD will cause the LCD error irq to be unregistered and never registered again. To fix this, let's keep the error irqs always enabled and trust the DRM_ERROR_RATELIMITED to limit the flood. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-03-24drm/omap: use DRM_ERROR_RATELIMITED() for error irqsTomi Valkeinen
omapdrm uses normal DRM_ERROR() print when the HW reports an error. As we sometimes may get a flood of errors, let's rather use DRM_ERROR_RATELIMITED(). Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-03-24drm/omap: stop connector polling during suspendTomi Valkeinen
When not using proper hotplug detection, DRM polls periodically the connectors to find out if a cable is connected. This polling can happen at any time, even very late in the suspend process. This causes a problem with omapdrm, when the poll happens during the suspend process after GPIOs have been disabled, leading to a crash in gpio_get(). This patch fixes the issue by adding suspend and resume hooks to omapdrm, in which we disable and enable, respectively, the polling. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-03-24drm/omap: remove dummy PM functionsTomi Valkeinen
omapdrm has dummy functions for platform_device's suspend/resume/shutdown. The functions don't do anything, and those platform device functions are deprecated, so remove them from omapdrm. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-03-24drm/omap: tiler: fix race condition with engine->asyncTomi Valkeinen
The tiler irq handler uses engine->async value, but the code that sets engine->async and enables the interrupt does not have a barrier. This may cause the irq handler to see the old value of engine->async, causing memory corruption. Reported-by: Harinarayan Bhatta <harinarayan@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-03-24drm/omap: fix plane's channel selectionTomi Valkeinen
omap_plane_pre_apply() sets the plane's output channel too late, only after the plane has already been otherwise configured and enabled. This causes problems, as at the configuration stage we need to make decisions based on the output channel. This may lead to bad plane settings or failing to setup the plane. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-03-24drm/omap: fix TILER on OMAP5Tomi Valkeinen
On OMAP5 it is not possible to use TILER buffer with CPU when caching or write-combining is used. Doing so leads to errors from the memory manager. However, on OMAP4, write-combining works fine. This patch adds platform specific data for the TILER, and a function tiler_get_cpu_cache_flags() which can be used to get the caching mode to be used. Note that without write-combining the use of the TILER buffer with CPU is unusably slow. It's still good to have it operational for testing purposes. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-03-24drm/omap: handle incompatible buffer stride and pixel sizeTomi Valkeinen
omapdrm doesn't check if the pitch of the framebuffer and the color format's bits-per-pixel are compatible. omapdss requires that the stride of a buffer is an integer number of pixels For example, when using modetest with a display that has x resolution of 1280, and using packed 24 RGB mode (3 bytes per pixel), modetest allocates a buffer with a byte stride of 4 * 1280 = 5120. But 5120 / 3 = 1706.666... pixels, which causes wrong colors and a tilt on the screen. Add a check into omapdrm to return an error if the user tries to use such a combination. Note: this is not a HW requirement at least for non-rotation use cases, but a SW driver requirement. In the future we should study if also rotation use cases are fine with any stride size, and if so, change the driver to allow these strides. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-03-24drm/omap: fix error handling in omap_framebuffer_create()Tomi Valkeinen
When an error happens in omap_framebuffer_create(), omap_framebuffer_create() calls omap_framebuffer_destroy() if the fb struct has been allocated. However, that crashes, as omap_framebuffer_destroy(), which calls drm_framebuffer_cleanup(), should only be called after drm_framebuffer_init() Fix this by just calling kfree() for the allocated fb when an error happens. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-03-24drm/omap: fix operation without fbdevTomi Valkeinen
omapdrm should work fine even if fbdev is missing. The current driver crashes in that case, though, as it is missing checks for the fbdev. Add the checks so that we don't free fbdev or restore fbdev mode when there's no fbdev. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-03-24drm/omap: add a comment why locking is missingTomi Valkeinen
unpin_worker() calls omap_framebuffer_unpin() without any locks, which looks very suspicious. However, both pin and unpin are always called via the driver's private workqueue, so the access is synchronized that way. Add a comment to make this clear. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-03-24drm/omap: add pin refcounting to omap_framebufferTomi Valkeinen
omap_framebuffer_pin() and omap_framebuffer_unpin() are currently broken, as they cannot be called multiple times (i.e. pin, pin, unpin, unpin), which is what happens in certain cases. This issue causes the driver to possibly use 0 as an address for a displayed buffer, leading to OCP error from DSS. This patch fixes the issue by adding a simple pin_count, used to track the number of pins. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-03-24drm/omap: clear omap_obj->paddr in omap_gem_put_paddr()Tomi Valkeinen
Clear omap_obj's paddr when unmapping the memory, so that it's easier to catch bad use of the paddr. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-03-24drm/omap: page_flip: return -EBUSY if flip pendingTomi Valkeinen
The DRM documentation says: "If a page flip is already pending, the page_flip operation must return -EBUSY." Currently omapdrm returns -EINVAL instead. Fix omapdrm by returning -EBUSY. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-03-24drm/omap: fix encoder-crtc mappingTomi Valkeinen
OMAP DSS hardware supports changing the output port to which an overlay manager's video stream goes. For example, DPI video stream can come from any of the four overlay managers on OMAP5. However, as it's difficult to manage the change in the driver, the omapdss driver does not support that at the moment, and has a hardcoded overlay manager per output. omapdrm, on the other hand, uses the hardware features to find out which overlay manager to use for an output, which causes problems. For example, on OMAP5, omapdrm tries to use DIGIT overlay manager for DPI output, instead of the LCD3 required by the omapdss driver. This patch changes the omapdrm to use the omapdss driver's hardcoded overlay managers, which fixes the issue. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2015-03-24drm/bridge: ptn3460: Fix sparse warningsThierry Reding
The ptn3460_bridge_attach symbol is never used outside this file, so it should be static. Signed-off-by: Thierry Reding <treding@nvidia.com>
2015-03-24drm/bridge: ps8622: Fix sparse warningsThierry Reding
The ps8622_attach and ps8522_driver symbols are never used outside this file, so they should be static. Signed-off-by: Thierry Reding <treding@nvidia.com>
2015-03-24drm/bridge: Add I2C based driver for ps8622/ps8625 bridgeVincent Palatin
This patch adds drm_bridge driver for parade DisplayPort to LVDS bridge chip. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> Signed-off-by: Andrew Bresticker <abrestic@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com> Acked-by: Inki Dae <inki.dae@samsung.com> Tested-by: Rahul Sharma <rahul.sharma@samsung.com> Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Tested-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Tested-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk> [treding@nvidia.com: break cyclic dependency, add KMS helper dependency] Signed-off-by: Thierry Reding <treding@nvidia.com>
2015-03-24drm/i915: Removing the drrs capability enum initializationRamalingam C
As part of allocation of the drm_i915_private variable, drrs capability enum is initialized to DRRS_NOT_SUPPORTED. Hence need not initialize at each connector init. Moreover initializing this enum at connector init will reset the successful DRRS initialization of previous connector, as we have the DRRS support for only one panel at a time. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-24drm/i915: move clearing of RPS interrupt bits from disable to reset timeImre Deak
The logical place for clearing the RPS latched interrupt bits is when resetting the RPS interrupts, so move the corresponding part from the RPS disable function to the reset function. During resetting we already cleared the IIR bits, so the only thing missing there was clearing pm_iir. Note that we call gen6_disable_rps_interrupts() also during driver load and resume time via intel_uncore_sanitize() when i915 interrupts are still not installed. If there are any pending RPS bits at this point (which after this patch wouldn't be cleared) they will be cleared by the reset code via the interrupt preinstall hooks. Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-24drm/i915: fix race when clearing RPS IIR bitsImre Deak
When disabling RPS interrupts there is a race where we disable RPS inerrupts while the interrupt handler is running and the handler has already latched the pending RPS interrupt from the master IIR register. Afterwards the disabling path clears the PM IIR bits, making the state of pending interrupts inconsistent from the interrupt handler's point of view. This triggers the following warning: "The master control interrupt lied (PM)!". To fix this make sure that any running interrupt handler (which may have already latched the master IIR) finishes before clearing the IIR bits. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87347 Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-24drm: Fixup racy refcounting in plane_force_disableDaniel Vetter
Originally it was impossible to be dropping the last refcount in this function since there was always one around still from the idr. But in commit 83f45fc360c8e16a330474860ebda872d1384c8c Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Aug 6 09:10:18 2014 +0200 drm: Don't grab an fb reference for the idr we've switched to weak references, broke that assumption but forgot to fix it up. Since we still force-disable planes it's only possible to hit this when racing multiple rmfb with fbdev restoring or similar evil things. As long as userspace is nice it's impossible to hit the BUG_ON. But the BUG_ON would most likely be hit from fbdev code, which usually invovles the console_lock besides all modeset locks. So very likely we'd never get the bug reports if this was hit in the wild, hence better be safe than sorry and backport. Spotted by Matt Roper while reviewing other patches. [airlied: pull this back into 4.0 - the oops happens there] Cc: stable@vger.kernel.org Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2015-03-24Merge tag 'drm-intel-next-2015-03-13-merge' of ↵Dave Airlie
git://anongit.freedesktop.org/drm-intel into drm-next drm-intel-next-2015-03-13-rebased: - EU count report param for gen9+ (Jeff McGee) - piles of pll/wm/... fixes for chv, finally out of preliminary hw support (Ville, Vijay) - gen9 rps support from Akash - more work to move towards atomic from Matt, Ander and others - runtime pm support for skl (Damien) - edp1.4 intermediate link clock support (Sonika) - use frontbuffer tracking for fbc (Paulo) - remove ilk rc6 (John Harrison) - a bunch of smaller things and fixes all over Includes backmerge because git rerere couldn't keep up any more. * tag 'drm-intel-next-2015-03-13-merge' of git://anongit.freedesktop.org/drm-intel: (366 commits) drm/i915: Make sure the primary plane is enabled before reading out the fb state drm/i915: Update DRIVER_DATE to 20150313 drm/i915: Fix vmap_batch page iterator overrun drm/i915: Export total subslice and EU counts drm/i915: redefine WARN_ON_ONCE to include the condition drm/i915/skl: Implement WaDisableHBR2 drm/i915: Remove the preliminary_hw_support shackles from CHV drm/i915: Read CHV_PLL_DW8 from the correct offset drm/i915: Rewrite IVB FDI bifurcation conflict checks drm/i915: Rewrite some some of the FDI lane checks drm/i915/skl: Enable the RPS interrupts programming drm/i915/skl: Enabling processing of Turbo interrupts drm/i915/skl: Updated the i915_frequency_info debugfs function drm/i915: Simplify the way BC bifurcation state consistency is kept drm/i915/skl: Updated the act_freq_mhz_show sysfs function drm/i915/skl: Updated the gen9_enable_rps function drm/i915/skl: Updated the gen6_rps_limits function drm/i915/skl: Restructured the gen6_set_rps_thresholds function drm/i915/skl: Updated the gen6_set_rps function drm/i915/skl: Updated the gen6_init_rps_frequencies function ...
generated by cgit (git 2.34.1) at 2025-09-18 01:10:20 +0000