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: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
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 c996fd0b95
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: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466499262-18717-1-git-send-email-daniel.vetter@ffwll.ch
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: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466514580-15194-3-git-send-email-benjamin.gaignard@linaro.org
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: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466519829-4000-1-git-send-email-benjamin.gaignard@linaro.org
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: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1462997501-982363-1-git-send-email-arnd@arndb.de
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 <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/17053ff08caf5cfac4f478437ef796f83a31d772.1466506505.git.jani.nikula@intel.com
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 <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/126f42734defac6cbb8496a481d58db7b38461dd.1466506505.git.jani.nikula@intel.com
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: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/bc7b4f9ac037632e0c8469c079d21fad5eaa39a0.1466506505.git.jani.nikula@intel.com
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: f706974a69 ("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 <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466483254-35373-1-git-send-email-tfiga@chromium.org
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: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466148814-8194-4-git-send-email-daniel.vetter@ffwll.ch
It's related, and soon authmagic will also use the master_mutex.
There is an ever-so-slightly semantic change here:
- authmagic will only be cleaned up for primary_client drm_minors. But
it's impossible to create authmagic on render/control nodes, so this
is fine.
- The cleanup is moved down a bit in the release processing. Doesn't
matter at all since authmagic is purely internal logic used by the
core ioctl access checks, and when we're in a file's release
callback no one can do ioctls any more.
v2: Rebased.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466148814-8194-3-git-send-email-daniel.vetter@ffwll.ch
Change the error handling in dma_buf_init_debugfs() to remove the
"dma_buf" directory if creating the "bufinfo" file fails. No need to
have an empty debugfs directory around.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
The callback function dma_buf_describe() returns an int not void so the
function pointer cast in dma_buf_show() is wrong. dma_buf_describe() can
also fail when acquiring the mutex gets interrupted so always returning
0 in dma_buf_show() is wrong, too.
Fix both issues by avoiding the indirection via dma_buf_show() and call
dma_buf_describe() directly. Rename it to dma_buf_debug_show() to get it
in line with the other functions.
This type mismatch was caught by the PaX RAP plugin.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Brad Spengler <spender@grsecurity.net>
Cc: PaX Team <pageexec@freemail.hu>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
The drm_dp_aux is associated with the intel_dp encoder and not the
connector. Since the encoder is destroyed before the connector,
attempting to free the drm_dp_aux from inside the connector cleanup
causes a use-after-free.
This was applied to the patch that CI was happy with, but in the
confusion of so many series trying to make CI happy, the unready
patch was plucked.
Fixes: c191eca110 ("drm/i915: Move intel_connector->unregister to connector->early_unregister")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466411357-730-1-git-send-email-chris@chris-wilson.co.uk
