- 12 Jul, 2016 21 commits
-
-
Gustavo Padovan authored
Remove legacy usage of drm_handle_vblank() Signed-off-by:
Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1467677092-5089-6-git-send-email-gustavo@padovan.org
-
Gustavo Padovan authored
Remove legacy usage of drm_handle_vblank() Signed-off-by:
-
Gustavo Padovan authored
Remove legacy usage of drm_handle_vblank() Signed-off-by:
-
Gustavo Padovan authored
Remove legacy usage of drm_handle_vblank() Signed-off-by:
-
Gustavo Padovan authored
Remove legacy usage of drm_handle_vblank() Signed-off-by:
-
Gustavo Padovan authored
As they are not used anywhere outside drm_irq.c make them static. Signed-off-by:
-
Dan Carpenter authored
We should be checking "phy_provider" here not "phy". Fixes: 2e54c14e ('drm/mediatek: Add DSI sub driver') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by:
-
Bhaktipriya Shridhar authored
System workqueues have been able to handle high level of concurrency for a long time now and there's no reason to use dedicated workqueues just to gain concurrency. Since the workqueue in the QXL graphics device driver is involved in freeing and processing the release ring (workitem &qdev->gc_workqxl, maps to gc_work which calls qxl_garbage_collect) and is not being used on a memory reclaim path, dedicated gc_queue has been replaced with the use of system_wq. Unlike a dedicated per-cpu workqueue created with create_workqueue(), system_wq allows multiple work items to overlap executions even on the same CPU; however, a per-cpu workqueue doesn't have any CPU locality or global ordering guarantees unless the target CPU is explicitly specified and thus the increase of local concurrency shouldn't make any difference. flush_work() has been called in qxl_device_fini() to ensure that there are no pending tasks while disconnecting the driver. Signed-off-by:
Bhaktipriya Shridhar <bhaktipriya96@gmail.com> Acked-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Xinliang Liu authored
Vblank turn on should be called in crtc's enable callback. And turn off called in crtc's disable callback. Thanks to Daniel Vetter, this bug is reported by him. Reported-by:
Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
Xinliang Liu <xinliang.liu@linaro.org> Signed-off-by:
-
Alexey Khoroshilov authored
If class_create() fails, there is no need for class_destroy(). Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by:
-
Benjamin Herrenschmidt authored
That constant isn't meant to be used outside of arch mm code Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Thierry Reding authored
Use a consistent name for the function that implements set_tear_scanline and reword and reformat the kerneldoc slightly. Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Thierry Reding authored
The QXL driver sets DRIVER_MODESET unconditionally, so testing for the absence of the feature will always fail. Signed-off-by:
-
Frank Binns authored
Use the appropriate drm minor type helper instead. Cc: Sinclair Yeh <syeh@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by:
Frank Binns <frank.binns@imgtec.com> Reviewed-by:
Sinclair Yeh <syeh@vmware.com> Signed-off-by:
-
Chris Wilson authored
Rather than manually perform our unregistration actions before shutting down the device, move them to drm_unplug_dev(). Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Alexey Brodkin <Alexey.Brodkin@synopsys.com> Cc: Amitoj Kaur Chawla <amitoj1606@gmail.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
-
Chris Wilson authored
Rather than do a partial unregister of just the minors, unregister the device (drm_dev_unregister(), and so remove all userspace interfaces, when the device is unplugged (drm_unplug_dev()). Signed-off-by:
-
Chris Wilson authored
This has now been removed from all drivers as it is performed centrally as a part of device registration for modesetting drivers. With the last user gone, we can unexport it from the DRM module. Signed-off-by:
-
Tobias Jakobi authored
Currently enabling Exynos DRM support automatically pulls in lots of fbdev dependencies. However these deps are unnecessary since DRM core already enables them when needed. Signed-off-by:
Tobias Jakobi <tjakobi@math.uni-bielefeld.de> Signed-off-by:
-
Michel Dänzer authored
Consolidate the _DRM_VBLANK_NEXTONMISS handling between drm_wait_vblank and drm_queue_vblank_event. This is a cleanup spotted while working on other changes. (The way it was previously handled could also theoretically result in drm_queue_vblank_event unnecessarily bumping vblwait->request.sequence, if the vblank counter happened to increment between the drm_vblank_count(_and_time) calls in each function, but that's unlikely) Signed-off-by:
Michel Dänzer <michel.daenzer@amd.com> Reviewed-by:
-
Chris Wilson authored
Enable the standard GEM dma-buf interface provided by the DRM core, but only for exporting the VGEM object. This allows passing around the VGEM objects created from the dumb interface and using them as sources elsewhere. Creating a VGEM object for a foriegn handle is not supported. v2: With additional completeness. v3: Need to clear the CPU cache upon exporting the dma-addresses. v4: Use drm_gem_put_pages() as well. v5: Use drm_prime_pages_to_sg() Testcase: igt/vgem_basic/dmabuf-* Testcase: igt/prime_vgem Signed-off-by:
Zach Reizner <zachr@google.com> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Signed-off-by:
-
Chris Wilson authored
The vGEM mmap code has bitrotted slightly and now immediately BUGs. Since vGEM was last updated, there are new core GEM facilities to provide more common functions, so let's use those here. v2: drm_gem_free_mmap_offset() is performed from drm_gem_object_release() so we can remove the redundant call. Testcase: igt/vgem_basic/mmap Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96603Signed-off-by:
Humberto Israel Perez Rodriguez <humberto.i.perez.rodriguez@intel.com> Reviewed-by:
-
- 30 Jun, 2016 1 commit
-
-
Masanari Iida authored
This patch fix a spelling typo found in Documentation/DocBook/gpu/API-drm-ioctl-flags.html It is because the html file was created from comments in source, I have to fix the source. Signed-off-by:
Masanari Iida <standby24x7@gmail.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160629234706.31209-1-standby24x7@gmail.com
-
- 27 Jun, 2016 1 commit
-
-
Frank Binns authored
Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
- 24 Jun, 2016 17 commits
-
-
Lukas Wunner authored
Use shiny new drm_crtc_force_disable() instead of open coding the same. No functional change intended. Cc: Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
Lukas Wunner <lukas@wunner.de> Signed-off-by:
-
Lukas Wunner authored
Use shiny new drm_crtc_force_disable() instead of open coding the same. No functional change intended. Cc: Francisco Jerez <currojerez@riseup.net> Signed-off-by:
Francisco Jerez <currojerez@riseup.net> Signed-off-by:
-
Lukas Wunner authored
Use shiny new drm_crtc_force_disable() instead of open coding the same. No functional change intended. Signed-off-by:
-
Lukas Wunner authored
amdgpu leaks a runtime pm ref if at least one CRTC is enabled on unload. The ref is taken by amdgpu_crtc_set_config() and held as long as a CRTC is in use. Fix by turning off all CRTCs on unload. Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Lukas Wunner authored
radeon leaks a runtime pm ref if at least one CRTC is enabled on unload. The ref is taken by radeon_crtc_set_config() and held as long as a CRTC is in use. Fix by turning off all CRTCs on unload. Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Lukas Wunner authored
nouveau leaks a runtime pm ref if at least one CRTC is enabled on unload. The ref is taken by nouveau_crtc_set_config() and held as long as a CRTC is in use. nv04_display_destroy() should solve this by turning off all CRTCs, but (1) nv50_display_destroy() doesn't do the same and (2) it's broken since commit d6bf2f37 ("drm/nouveau: run mode_config destructor before destroying internal display state") because the crtc structs are torn down by drm_mode_config_cleanup() before being turned off. Also, there's no locking. Move the code to turn off all CRTCs from nv04_display_destroy() to nouveau_display_destroy() so that it's called for both nv04 and nv50 and before drm_mode_config_cleanup(). Use drm_crtc_force_disable_all() helper to save on code and have proper locking. Cc: Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
Lukas Wunner authored
Turning off a single CRTC or all active CRTCs of a DRM device is a fairly common pattern. Add helpers to avoid open coding this everywhere. The name was chosen to be consistent with drm_plane_force_disable(). Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Lukas Wunner authored
The PCI core calls pm_runtime_forbid() on device probe in pci_pm_init(), making this the default state when amdgpu is loaded. amdgpu_driver_load_kms() therefore calls pm_runtime_allow(), but there's no pm_runtime_forbid() in amdgpu_driver_unload_kms() to balance it. Add it so that we leave the device in the same state that we found it. This isn't a bug, it's just good housekeeping. When amdgpu is first loaded with runpm=1, then unloaded and loaded again with runpm=0, pm_runtime_forbid() will be called from amdgpu_pmops_runtime_idle() or amdgpu_pmops_runtime_suspend(), so the behaviour is correct. If there ever is a third party driver for AMD cards, this commit avoids that it has to clean up behind amdgpu. Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Lukas Wunner authored
If an error occurs in amdgpu_device_init() after adev->rmmio has been set, its caller amdgpu_driver_load_kms() will skip runtime pm initialization and call amdgpu_driver_unload_kms(), which acquires a runtime pm ref that is leaked. Balance by releasing a runtime pm ref in the error path of amdgpu_driver_load_kms(). Fixes: d38ceaf9 ("drm/amdgpu: add core driver (v4)") Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Lukas Wunner authored
amdgpu_driver_load_kms() calls pm_runtime_put_autosuspend() if amdgpu_device_is_px(dev), but amdgpu_driver_unload_kms() calls pm_runtime_get_sync() unconditionally. We therefore leak a runtime pm ref whenever amdgpu is unloaded on a non-PX machine or if runpm=0. The GPU will subsequently never runtime suspend after loading amdgpu again. Fix by taking the runtime pm ref under the same condition that it was released on driver load. Fixes: d38ceaf9 ("drm/amdgpu: add core driver (v4)") Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Lukas Wunner authored
The PCI core calls pm_runtime_forbid() on device probe in pci_pm_init(), making this the default state when radeon is loaded. radeon_driver_load_kms() therefore calls pm_runtime_allow(), but there's no pm_runtime_forbid() in radeon_driver_unload_kms() to balance it. Add it so that we leave the device in the same state that we found it. This isn't a bug, it's just good housekeeping. When radeon is first loaded with runpm=1, then unloaded and loaded again with runpm=0, pm_runtime_forbid() will be called from radeon_pmops_runtime_idle() or radeon_pmops_runtime_suspend(), so the behaviour is correct. If there ever is a third party driver for AMD cards, this commit avoids that it has to clean up behind radeon. Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Lukas Wunner authored
radeon_device_init() returns an error if either of the two calls to radeon_init() fail. One level up in the call stack, radeon_driver_load_kms() will then skip runtime pm initialization and call radeon_driver_unload_kms(), which acquires a runtime pm ref that is leaked. Balance by releasing a runtime pm ref in the error path of radeon_device_init(). Fixes: 10ebc0bc ("drm/radeon: add runtime PM support (v2)") Cc: Dave Airlie <airlied@redhat.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Lukas Wunner authored
radeon_driver_load_kms() calls pm_runtime_put_autosuspend() if radeon_is_px(dev), but radeon_driver_unload_kms() calls pm_runtime_get_sync() unconditionally. We therefore leak a runtime pm ref whenever radeon is unloaded on a non-PX machine or if runpm=0. The GPU will subsequently never runtime suspend after loading radeon again. Fix by taking the runtime pm ref under the same condition that it was released on driver load. Fixes: 10ebc0bc ("drm/radeon: add runtime PM support (v2)") Cc: Dave Airlie <airlied@redhat.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Lukas Wunner authored
The PCI core calls pm_runtime_forbid() on device probe in pci_pm_init(), making this the default state when nouveau is loaded. nouveau_drm_load() therefore calls pm_runtime_allow(), but there's no pm_runtime_forbid() in nouveau_drm_unload() to balance it. Add it so that we leave the device in the same state that we found it. This isn't a bug, it's just good housekeeping. When nouveau is first loaded with runpm=1, then unloaded and loaded again with runpm=0, pm_runtime_forbid() will be called from nouveau_pmops_runtime_idle() or nouveau_pmops_runtime_suspend(), so the behaviour is correct. The nvidia blob doesn't use runtime pm, but if it ever does, this commit avoids that it has to clean up behind nouveau. Cc: Ben Skeggs <bskeggs@redhat.com> Tested-by:
Karol Herbst <karolherbst@gmail.com> Tested-by:
Peter Wu <peter@lekensteyn.nl> Signed-off-by:
-
Lukas Wunner authored
nouveau_drm_load() calls pm_runtime_put() if nouveau_runtime_pm != 0, but nouveau_drm_unload() calls pm_runtime_get_sync() unconditionally. We therefore leak a runtime pm ref whenever nouveau is loaded with runpm=0 and then unloaded. The GPU will subsequently never runtime suspend even if nouveau is loaded again with runpm=1. Fix by taking the runtime pm ref under the same condition that it was released on driver load. Fixes: 5addcf0a ("nouveau: add runtime PM support (v0.9)") Cc: Dave Airlie <airlied@redhat.com> Cc: Ben Skeggs <bskeggs@redhat.com> Reported-by:
-
git://git.pengutronix.de/git/pza/linuxDave Airlie authored
MT8173 HDMI support - device tree binding documentation for MT8173 HDMI encoder, CEC, DDC, and PHY - drivers for MT8173 HDMI encoder, CEC (HPD only for now), DDC, and PHY - enable HDMI output via a custom SMCCC call - add ddc-i2c-bus property to HDMI connector device tree binding * tag 'mediatek-drm-2016-06-20' of git://git.pengutronix.de/git/pza/linux: dt-bindings: hdmi-connector: add DDC I2C bus phandle documentation drm/mediatek: enable hdmi output control bit drm/mediatek: Add HDMI support dt-bindings: drm/mediatek: Add Mediatek HDMI dts binding
-
git://linuxtv.org/pinchartl/mediaDave Airlie authored
some rcar-du fixes. * 'drm/next/du' of git://linuxtv.org/pinchartl/media: drm: rcar-du: error message is not needed for EPROBE_DEFER drm: rcar-du: error message is not needed for drm_vblank_init() rcar-du: add/rename DEFR6 TCON bits
-
