- 22 Jun, 2016 4 commits
-
-
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 <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Julia Lawall <julia.lawall@lip6.fr> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1466581572-16608-1-git-send-email-chris@chris-wilson.co.uk
-
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 33 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 <daniel.vetter@intel.com>
-
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:
-
Daniel Vetter authored
Just rolling out a bit of abstraction to be able to clean up the master logic in the next step. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by:
-
Daniel Vetter authored
File open/set_maseter ioctl and file close/drop_master ioctl share the same master handling code. Extract it. Note that vmwgfx's master_set callback needs to know whether the master is a new one or has been used already, so thread this through. On the close/drop side a similar parameter existed, but wasnt used. Drop it to simplify the flow. v2: Try to make it not leak so much (Emil). v3: Send out the right version ... Cc: Emil Velikov <emil.l.velikov@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by:
-
Daniel Vetter authored
We already have a fallback in place to fill out the unique from dev->unique, which is set to something reasonable in drm_dev_alloc. Which means we only need to have a special set_busid for pci devices, to be able to care the backwards compat code for drm 1.1 around, which libdrm still needs. While developing and testing this patch things blew up in really interesting ways, and the code is rather confusing in naming things between the kernel code, ioctl #defines and libdrm. For the next brave dragon slayer, document all this madness properly in the userspace interface section of gpu.tmpl. v2: Make drm_dev_set_unique static and update kerneldoc. v3: Entire rewrite, plus document what's going on for posterity in the gpu docbook uapi section. v4: Drop accidental amdgpu hunk (Emil). v5: Drop accidental omapdrm vblank counter change (Emil). v6: Rebase on top of the sphinx conversion. Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Cc: Emil Velikov <emil.l.velikov@gmail.com> Tested-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> (virt_gpu) Reviewed-by:
-
Daniel Vetter authored
Ever since commit 2e1868b560315a8b20d688e646c489a5ad93eeae Author: Eric Anholt <anholt@freebsd.org> Date: Wed Jun 16 09:25:21 2004 +0000 DRI trunk-20040613 import the X server supports drm 1.1, thus doesn't call call libdrm's drmSetBusid - the sole user of this ioctl. When reviewing this note that for hilarity both the kernel-internal functions (set_busid) and the libdrm wrapper (drmSetBusid) have names not matching this ioctl (SET_UNIQUE). v2: Polish commit message (Emil). Cc: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: -
Daniel Vetter authored
Since commit e112e593 Author: Nicolas Iooss <nicolas.iooss_linux@m4x.org> Date: Fri Dec 11 11:20:28 2015 +0100 drm: use dev_name as default unique name in drm_dev_alloc() we're using a reasonable default which should work for everyone. Only mtk, rcar-du and sun4i are affected, and as kms-only drivers without any rendering support no one should ever care about the unique name v2: Rebase on top of mediatek. Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Daniel Vetter authored
With the previous patch this is now redudant, the core always sets a reasonable dev->unique string. Cc: Sean Paul <seanpaul@chromium.org> Reviewed-by:
-
Daniel Vetter authored
Lots of arm drivers get this wrong and for most arm boards this is the right thing actually. And anyway with most loaders you want to chase sysfs links anyway to figure out which dri device you want. This will fix dmesg noise for rockchip and sti. Also add a fallback to driver->name for entirely virtual drivers like vgem. v2: Rebase on top of commit e112e593 Author: Nicolas Iooss <nicolas.iooss_linux@m4x.org> Date: Fri Dec 11 11:20:28 2015 +0100 drm: use dev_name as default unique name in drm_dev_alloc() and simplify a bit. Plus add a comment. v3: WARN_ON(!dev->unique) as discussed with Emil. Cc: Ilia Mirkin <imirkin@alum.mit.edu> Reported-by:
Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v2) Reviewed-by:
-
Daniel Vetter authored
- Group declarations for separate files (drm_bridge.c, drm_edid.c) - Move declarations only used within drm.ko to drm_crtc_internal.h - drm_property_type_valid to drm_crtc.c, its only callsite Reviewed-by:
-
Daniel Vetter authored
There can only be one current master, and it's for the overall device. Render/control minors don't support master-based auth at all. This simplifies the master logic a lot, at least in my eyes: All these additional pointer chases are just confusing. While doing the conversion I spotted some locking fail: - drm_lock/drm_auth check dev->master without holding the master_mutex. This is fallout from commit c996fd0b Author: Thomas Hellstrom <thellstrom@vmware.com> Date: Tue Feb 25 19:57:44 2014 +0100 drm: Protect the master management with a drm_device::master_mutex v3 but I honestly don't care one bit about those old legacy drivers using this. - debugfs name info should just grab master_mutex. - And the fbdev helper looked at it to figure out whether someone is using KMS. We just need a consistent value, so READ_ONCE. Aside: We should probably check if anyone has opened a control node too, but I guess current userspace doesn't really do that yet. v2: Balance locking, reported by Julia. v3: Rebase on top of Chris' oops fixes. Cc: Julia Lawall <julia.lawall@lip6.fr> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v2) Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> (v2) Signed-off-by:
-
Benjamin Gaignard authored
Use drm_dev_alloc() and drm_dev_register() instead of .load() To simplify init sequence only create fbdev when requested in output_poll_changed(). version 2: remove call to drm_connector_unregister_all() and drm_dev_set_unique() Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@linaro.org> Signed-off-by:
-
Benjamin Gaignard authored
Make sti driver use register callback to move debugfs initialization out of sub-components creation. This will allow to convert driver .load() to drm_dev_alloc() and drm_dev_register(). sti_compositor bring up 2 crtc but only one debugfs init is needed so use drm_crtc_index to do it on the first one. This can't be done in sti_drv because only sti_compositor have access to the devices. It is almost the same for sti_encoder which handle multiple encoder while one only debugfs entry is needed so add a boolean to avoid multiple debugfs initialization Signed-off-by:
-
Daniel Vetter authored
- inline functions need to be static inline, otherwise gcc can opt to not inline and the linker gets unhappy. - no forward decls for inline functions, just include the right headers. Cc: Oded Gabbay <oded.gabbay@gmail.com> Cc: Ben Goz <ben.goz@amd.com> Reviewed-by:
Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by:
-
Benjamin Gaignard authored
Like what has been done for connectors add callbacks on encoder, crtc and plane to let driver do actions after drm device registration. Correspondingly, add callbacks called before unregister drm device. version 2: add drm_modeset_register_all() and drm_modeset_unregister_all() to centralize all calls version 3: in error case unwind registers in drm_modeset_register_all fix uninitialed return value inverse order of unregistration in drm_modeset_unregister_all version 4: move function definitions in drm_crtc_internal.h remove not needed documentation Signed-off-by:
-
Stefan Agner authored
Commit 7566e247 ("drm/fsl-dcu: handle initialization errors properly") introduced error handling during initialization, but with a wrong cleanup order. Replace the error handling with the generic cleanup function drm_mode_config_cleanup. Signed-off-by:
Stefan Agner <stefan@agner.ch> Signed-off-by:
Thierry Reding <treding@nvidia.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160619021543.23587-1-stefan@agner.ch
-
Arnd Bergmann authored
We get a harmless build warning when trying to use the mediatek DRM driver with IOMMU support disabled: warning: (DRM_MEDIATEK) selects IOMMU_DMA which has unmet direct dependencies (IOMMU_SUPPORT) However, the IOMMU_DMA symbol is not meant to be used by drivers at all, and this driver doesn't seem to have a strict dependency on it other than using the mediatek IOMMU driver that does. Since we also want to be able to do compile tests with the driver on other platforms, the IOMMU_DMA symbol should not be selected here. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
-
Jani Nikula authored
The gpu documentation has now been converted to reStructuredText files under Documentation/gpu. Remove the obsolete DocBook template. Also remove it from MAINTAINERS. Good riddance. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Jani Nikula authored
Make the documents more manageable. Signed-off-by:
-
Jani Nikula authored
Pandoc really did a bad job of converting the big KMS properties table to RST. Instead, put the properties into a separate plain text CSV file, and include it in the RST file. The generated output isn't very pretty, but at least the information is there, and it's stored in a format that's easier to process and improve upon at a later time. The CSV file was generated by copy-pasting the table from the HTML generated by the DocBook toolchain into LibreOffice Calc, and then saved as CSV, unmodified. Signed-off-by:
-
Jani Nikula authored
While splitting the document up, the headings "shifted" from what pandoc generated. Use the following order for headings for consistency: ============== Document title ============== First ===== Second ------ Third ~~~~~ Leave the lower level headings as they are; I think those are less important. Although RST doesn't mandate a specific order ("Rather than imposing a fixed number and order of section title adornment styles, the order enforced will be the order as encountered."), having the higher levels the same overall makes it easier to follow the documents. [I'm sort of kind of writing the recommendation for docs-next in the mean time, but this order seems sensible, and is what I'm proposing.] Signed-off-by: -
Jani Nikula authored
We'll want to keep an eye on what's going on in these files. Signed-off-by:
-
Jani Nikula authored
Make the gpu documentation easier to manage by splitting to separate files. Again, this is just the split, no real edits. Signed-off-by:
-
Jani Nikula authored
This is the first step towards converting the DocBook gpu.tmpl to Sphinx and reStructuredText, the new kernel documentation tool and markup. Use Jon's "cheesy conversion script" in Documentation/sphinx/tmplcvt to do the rough conversion. Do the manual edits in follow-up patches. Add a new Documentation/gpu directories for the graphics related documentation. (Hooray, now we can have directories based on topics rather than tools under Documentation.) We also won't remove the DocBook gpu.tmpl yet so it's easier to build both and compare the results for parity. Signed-off-by:
-
Daniel Vetter authored
Rockchip just blew up here on testing, because I removed some "is this crtc already disabled/enabled" state tracking from callbacks (not needed with atomic). Turns out that was needed to work around rockchip still calling legacy helper code. Since me explaining on irc/mailing-list plus kerneldoc isn't enough, be more verbose and add dmesg output. Not that anyone actually reads that, either. Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by:
-
Chris Wilson authored
Up to now, the recommendation was for drivers to call drm_dev_register() followed by drm_connector_register_all(). Now that drm_connector_register() is safe against multiple invocations, we can move drm_connector_register_all() to drm_dev_register() and not suffer from any backwards compatibility issues with drivers not following the more rigorous init ordering. Signed-off-by:
Archit Taneja <architt@codeaurora.org> Signed-off-by:
-
Chris Wilson authored
Up to now, the recommendation was for drivers to call drm_dev_register() followed by drm_connector_register_all(). Now that drm_connector_register() is safe against multiple invocations, we can move drm_connector_register_all() to drm_dev_register() and not suffer from any backwards compatibility issues with drivers not following the more rigorous init ordering. Signed-off-by:
-
Chris Wilson authored
Up to now, the recommendation was for drivers to call drm_dev_register() followed by drm_connector_register_all(). Now that drm_connector_register() is safe against multiple invocations, we can move drm_connector_register_all() to drm_dev_register() and not suffer from any backwards compatibility issues with drivers not following the more rigorous init ordering. Signed-off-by:
-
Chris Wilson authored
Up to now, the recommendation was for drivers to call drm_dev_register() followed by drm_connector_register_all(). Now that drm_connector_register() is safe against multiple invocations, we can move drm_connector_register_all() to drm_dev_register() and not suffer from any backwards compatibility issues with drivers not following the more rigorous init ordering. Signed-off-by:
Xinliang Liu <z.liuxinliang@hisilicon.com> Signed-off-by:
-
Chris Wilson authored
Up to now, the recommendation was for drivers to call drm_dev_register() followed by drm_connector_register_all(). Now that drm_connector_register() is safe against multiple invocations, we can move drm_connector_register_all() to drm_dev_register() and not suffer from any backwards compatibility issues with drivers not following the more rigorous init ordering. Signed-off-by:
-
Chris Wilson authored
Up to now, the recommendation was for drivers to call drm_dev_register() followed by drm_connector_register_all(). Now that drm_connector_register() is safe against multiple invocations, we can move drm_connector_register_all() to drm_dev_register() and not suffer from any backwards compatibility issues with drivers not following the more rigorous init ordering. Signed-off-by:
-
Tomasz Figa authored
Currently the driver calls drm_dev_register() directly after allocating the DRM device and then continues with further initialization. This is incorrect, because drm_dev_register() is supposed to be called after all initialization is done. This problem was masked by the fact that drm_dev_register() did not use to do anything special before, but recently it started to call drm_connector_register_all(), which leads to a crash if the driver is not fully initialized. This patch fixes the problem by moving the call to drm_dev_register() to the end of the initialization sequence and also removing the, now unnecessary, call to drm_connector_register_all() from driver code. Fixes: f706974a ("drm/rockchip: Drop drm_driver.load/unload callbacks") Signed-off-by:
Tomasz Figa <tfiga@chromium.org> [danvet: Fix up cleanup labels a bit.] Signed-off-by:
-
Daniel Vetter authored
It's a legacy helper function which won't do good with atomic helpers. Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
- 20 Jun, 2016 3 commits
-
-
Daniel Vetter authored
Again this is neatly protected by the dev->master_mutex now. There is a driver callback both for set and drop, but it's only used by vmwgfx. And vmwgfx has it's own solid locking for shared resources (besides dev->master_mutex), hence is all safe. Let's drop another place where the drm legacy bkl is used. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Daniel Vetter authored
All protected by dev->master_mutex. And there's no driver callbacks, which means no need to sync with old dri1 horror show drivers at all. Hence safe to drop the drm legacy BKL from these paths. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Daniel Vetter authored
Simplifies cleanup, and there's no reason drivers should ever care about authmagic at all - it's all handled in the core. And with that, Ladies and Gentlemen, it's time to pop the champagen and celebrate: dev->struct_mutex is now officially gone from modern drivers, and if a driver is using gem_free_object_unlocked and doesn't do anything else silly it's positively impossible to ever touch dev->struct_mutex at runtime, anywhere. Well except for the mutex_init on driver load ;-) v2: Rebased. Cc: Chris Wilson <chris@chris-wilson.co.uk> (v1) Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) Reviewed-by:
-
