We're not super-consistent about these, but I think it's worth to
document at least the commmon patterns.
v2:
- Add a not about ENOTTY (it's just a confusing name, but used
exactly what it's meant for in DRM) (Chris).
- Unconfuse the text for ENODEV (Daniel)
- Move text undert the IOCTL heading (Chris).
- typos
Cc: Daniel Stone <daniel@fooishbar.org>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: "Zhang, Tina" <tina.zhang@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170818174328.6386-1-daniel.vetter@ffwll.ch
I spotted a markup issue, plus adding the descriptions in drm_driver.
Plus a few more links while at it.
I'm still mildly unhappy with the split between fops and ioctls, but I
still think having the ioctls in the uapi chapter makes more sense. Oh
well ...
v2: Rebase.
v3: Move misplace hunk to the right patch.
Cc: Stefan Agner <stefan@agner.ch>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170531092045.3950-1-daniel.vetter@ffwll.ch
Also unify/merge with the existing stuff.
I was a bit torn where to put this, but in the end I decided to put
all the ioctl/sysfs/debugfs stuff into drm-uapi.rst. That means we
have a bit a split with the other uapi related stuff used internally,
like drm_file.[hc], but I think overall this makes more sense.
If it's too confusing we can always add more cross-links to make it
more discoverable. But the auto-sprinkling of links kernel-doc already
does seems sufficient.
Also for prettier docs and more cross-links, switch the internal
defines over to an enum, as usual.
v2: Update kerneldoc fro drm_compat_ioctl too (caught by 0day), plus a
bit more drive-by polish.
v3: Fix typo, spotted by xerpi on irc (Sergi).
v4: Add missing space in comment (Neil).
Cc: Sergi Granell <xerpi.g.12@gmail.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170404095304.17599-4-daniel.vetter@ffwll.ch
- remove docs for internal func, doesn't add value
- add short overview snippet instead explaining that drivers don't
have to bother themselves with reg/unreg concerns
- drop the ttm comment about drmP.h, drmP.h is disappearing ...
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170404095304.17599-2-daniel.vetter@ffwll.ch
I've decided to not document drm_debugfs_remove_files, it's on the way
out.
The biggest part is a huge todo.rst entry with what all should be
improved.
v2: Nits from Gabriel.
Cc: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Reviewed-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170322205401.24897-1-daniel.vetter@ffwll.ch
This was missed in Tomeu's patch. Also remove the kerneldoc for the
internal function, we don't document that in general.
While at it word-smith the docs slightly for more clarity.
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170322083617.13361-4-daniel.vetter@ffwll.ch
Well, mostly drm_file.h, and clean up all related things:
- I didnt' figure out the difference between preclose and postclose.
The existing explanation in drm-internals.rst didn't convince me,
since it's also really outdated - we clean up pending DRM events in
the core nowadays. I put a FIXME in for the future.
- Another FIXME is to have a macro for default fops.
- Lots of links all around, main areas are to tie the overview in
drm_file.c more into the callbacks in struct drm_device, and the
other is to link render/primary node code to the right sections in
drm-uapi.rst.
- Also moved the open/close stuff to drm_drv.h from drm-internals.rst,
seems like the better place for that information. Since that section
was rather outdated this amounted to full-on rewrite.
A big missing piece here is some overview graph, but I think better to
wait with that one until drm_device and drm_driver are also fully
documented.
v2: Nits from Sean.
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Liviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-12-daniel.vetter@ffwll.ch
- Remove the outdated hunk about driver documentation which somehow
got misplaced here in the split-up.
- Collect all the testing&validation stuff together and give the CRC
section a heading for prettier output.
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1483044517-5770-1-git-send-email-daniel.vetter@ffwll.ch
Adds files and directories to debugfs for controlling and reading frame
CRCs, per CRTC:
dri/0/crtc-0/crc
dri/0/crtc-0/crc/control
dri/0/crtc-0/crc/data
Drivers can implement the set_crc_source callback() in drm_crtc_funcs to
start and stop generating frame CRCs and can add entries to the output
by calling drm_crtc_add_crc_entry.
v2:
- Lots of good fixes suggested by Thierry.
- Added documentation.
- Changed the debugfs layout.
- Moved to allocate the entries circular queue once when frame
generation gets enabled for the first time.
v3:
- Use the control file just to select the source, and start and stop
capture when the data file is opened and closed, respectively.
- Make variable the number of CRC values per entry, per source.
- Allocate entries queue each time we start capturing as now there
isn't a fixed number of CRC values per entry.
- Store the frame counter in the data file as a 8-digit hex number.
- For sources that cannot provide useful frame numbers, place
XXXXXXXX in the frame field.
v4:
- Build only if CONFIG_DEBUG_FS is enabled.
- Use memdup_user_nul.
- Consolidate calculation of the size of an entry in a helper.
- Add 0x prefix to hex numbers in the data file.
- Remove unnecessary snprintf and strlen usage in read callback.
v5:
- Made the crcs array in drm_crtc_crc_entry fixed-size
- Lots of other smaller improvements suggested by Emil Velikov
v7:
- Move definition of drm_debugfs_crtc_crc_add to drm_internal.h
v8:
- Call debugfs_remove_recursive when we fail to create the minor
device
v9:
- Register the debugfs directory for a crtc from
drm_crtc_register_all()
v10:
- Don't let debugfs failures interrupt CRTC registration (Emil
Velikov)
v11:
- Remove extra brace that broke compilation. Sorry!
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Acked-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1475767268-14379-3-git-send-email-tomeu.vizoso@collabora.com
Everyone knows them, except all the new folks joining from the ARM
side haven't lived through all the pain of the past years and are
entirely surprised when I raise this. Definitely time to document
this.
Last time this was a big discussion was about 6 years ago, when qcom
tried to land a kernel driver without userspace. Dave Airlie made the
rules really clear:
http://airlied.livejournal.com/73115.html
This write-up here is essentially what I've put into a presentation a
while ago, which was also reviewed by Dave:
http://blog.ffwll.ch/2015/05/gfx-kernel-upstreaming-requirements.html
v2: Fix typos Eric&Rob spotted.
v3: Nitpick from Jani.
Cc: Dave Airlie <airlied@gmail.com>
Cc: Oded Gabbay <oded.gabbay@gmail.com>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Sinclair Yeh <syeh@vmware.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Mark Yao <mark.yao@rock-chips.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: CK Hu <ck.hu@mediatek.com>
Cc: Xinliang Liu <z.liuxinliang@hisilicon.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Stefan Agner <stefan@agner.ch>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Brian Starkey <brian.starkey@arm.com>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
- Move the common vtable stuff to the top
- Move "Tile Group" to a more appropriate heading level
- Throw away the old intro for the crtc helpers (it's entirely stale,
e.g. helpers have become modular years ago), and replace it with a
general intro about the motivation behind helpers.
- Reorder helpers to group them together a bit better, and explain
that grouping in the intro.
- Make sure the introductory DOC section is always first.
v2:
- Remove bogus files accidentally added (Sean).
- Spelling fixes (Sean).
Cc: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1471034937-651-2-git-send-email-daniel.vetter@ffwll.ch
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: 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>
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>
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
