- 12 Jul, 2016 11 commits
-
-
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:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1467018023.20278.65.camel@kernel.crashing.org
-
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 20 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
-
git://anongit.freedesktop.org/drm-intelDave Airlie authored
- Infrastructure for GVT-g (paravirtualized gpu on gen8+), from Zhi Wang - another attemp at nonblocking atomic plane updates - bugfixes and refactoring for GuC doorbell code (Dave Gordon) - GuC command submission enabled by default, if fw available (Dave Gordon) - more bxt w/a (Arun Siluvery) - bxt phy improvements (Imre Deak) - prep work for stolen objects support (Ankitprasa Sharma & Chris Wilson) - skl/bkl w/a update from Mika Kuoppala - bunch of small improvements and fixes all over, as usual * tag 'drm-intel-next-2016-06-20' of git://anongit.freedesktop.org/drm-intel: (81 commits) drm/i915: Update DRIVER_DATE to 20160620 drm/i915: Introduce GVT context creation API drm/i915: Support LRC context single submission drm/i915: Introduce execlist context status change notification drm/i915: Make addressing mode bits in context descriptor configurable drm/i915: Make ring buffer size of a LRC context configurable drm/i915: gvt: Introduce the basic architecture of GVT-g drm/i915: Fold vGPU active check into inner functions drm/i915: Use offsetof() to calculate the offset of members in PVINFO page drm/i915: Factor out i915_pvinfo.h drm/i915: Serialise presentation with imported dmabufs drm/i915: Use atomic commits for legacy page_flips drm/i915: Move fb_bits updating later in atomic_commit drm/i915: nonblocking commit Reapply "drm/i915: Pass atomic states to fbc update, functions." drm/i915: Roll out the helper nonblock tracking drm/i915: Signal drm events for atomic drm/i915/ilk: Don't disable SSC source if it's in use drm/i915/guc: (re)initialise doorbell h/w when enabling GuC submission drm/i915/guc: replace assign_doorbell() with select_doorbell_register() ...
-
Dave Airlie authored
Merge tag 'topic/drm-misc-2016-06-22-updated' of git://anongit.freedesktop.org/drm-intel into drm-next Again a pile of things all over - Conversion to rst from docbook from Jani. Looks real pretty, and the source is now actually readable (compared to horrible, horrible docbook xml)! https://01.org/linuxgraphics/gfx-docs/drm/ - device register/unregister rework from Chris, with follow-up work from Benjamin. Allows more drivers to demidlayer load/unload and others to remove a bit of boilerplate. - master/auth related cleanup, with docs - some dma-buf polish, merged by Sumit - small stuff all over (like build fixes from Arnd) Group maintainership seems to slowly take off, with both Thierry and Sumit pushing a few things. No hiccups thus far. * tag 'topic/drm-misc-2016-06-22-updated' of git://anongit.freedesktop.org/drm-intel: (68 commits) drm/vc4: Remove unused connector drm/fb-helper: Reduce READ_ONCE(master) to lockless_dereference drm/sun4i: Remove open-coded drm_connector_register_all() drm/vc4: Remove open-coded drm_connector_register_all() drm/atmel-hlcdc: Remove redundant call to drm_connector_unregister_all() drm: document drm_auth.c drm: Clear up master tracking booleans drm: Extract drm_is_current_master drm: Refactor drop/set master code a bit drm: Lobotomize set_busid nonsense for !pci drivers drm: Nuke SET_UNIQUE ioctl drm: Don't call drm_dev_set_unique from platform drivers drm/vgem: Stop calling drm_drv_set_unique drm: Use dev->name as fallback for dev->unique drm: Clean up drm_crtc.h drm: Move master pointer from drm_minor to drm_device drm: sti: rework init sequence drm: sti: use late_register and early_unregister callbacks drm/amdkfd: Clean up inline handling drm: Add callbacks for late registering ...
-
Dave Airlie authored
Add basic support for the sii902x RGB -> HDMI bridge. * tag 'drm-sii902x' of github.com:bbrezillon/linux-at91: drm/bridge: Add sii902x DT bindings doc drm/bridge: Add sii902x driver
-
- 22 Jun, 2016 5 commits
-
-
Daniel Vetter authored
Somehow I didn't spot this when pushing :( Fixes: 398e9799 ("drm/vc4: Remove open-coded drm_connector_register_all()") Acked-by:
Daniel Vetter <daniel.vetter@intel.com>
-
Chris Wilson authored
We are only documenting that the read is outside of the lock, and do not require strict ordering on the operation. In this case the more relaxed lockless_dereference() will suffice. Signed-off-by:
-
Chris Wilson authored
drm_dev_register() will now register all known connectors, so we no longer have to do so manually. Signed-off-by:
-
Chris Wilson authored
drm_dev_register() will now register all known connectors, so we no longer have to do so manually. Signed-off-by:
-
Chris Wilson authored
drm_connector_unregister_all() is not automatically called by drm_dev_unregister() so we can drop the local call. Signed-off-by:
-
- 21 Jun, 2016 2 commits
-
-
Daniel Vetter authored
Also extract drm_auth.h for nicer grouping. v2: Nuke the other comments since they don't really explain a lot, and within the drm core we generally only document functions exported to drivers: The main audience for these docs are driver writers. v3: Limit the exposure of drm_master internals by only including drm_auth.h where it is neede (Chris). v4: Spelling polish (Emil). Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by:
-
Daniel Vetter authored
- is_master can be removed, we can compute this by checking allowed_master (which really just tracks whether a master struct has been allocated for this fpriv in either open or set_master), and whether the fpriv is the current master on the device. - that frees up is_master as a good replacement name for allowed_master. With that it's clear that it tracks whether the fpriv is a master (with possibly clients attached to it and authenticated against it), and that one of those fprivs with is_master set is the current master. v2: Fix kerneldoc for is_master (Emil). Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by:
-
