[PATCH 00/10] Documentation/Sphinx

[PATCH 00/10] Documentation/Sphinx

[Jani Nikula]

Hi Jon, all -

I've had a few moments of spare time to look into Sphinx. This is a sort
of status report on the progress.

I suppose we all thought it would be easiest to use docproc for the
Sphinx toolchain, for starters. I tried it, hard, and even sent a bunch
of docproc prep patches. However I ran into some problems. Out-of-tree
builds were a nightmare, as Sphinx has trouble to pick up some of the
files from $(srctree) and some from $(objtree). Having dependencies on
the source files work without rebuilding everything was getting tricky
too.

I decided to look into writing a Sphinx extension for kernel-doc, and it
turns out to be a really nice solution. We can keep all the .rst files
in $(srctree), we don't have to explicitly specify the .rst files to
process, there are no intermediate files, and Sphinx runs the kernel-doc
script using the extension based on the directives in the .rst
files. The extension tells Sphinx about the dependencies on the source
files, and Sphinx handles rebuilding as needed. Out-of-tree builds just
work. Sites like https://readthedocs.org/ can build the documentation,
including kernel-doc, without extra tweaks. As a whole, the build
becomes much simpler.

There are a few tradeoffs, of course. First, this requires that the
EXPORT_SYMBOL markers are placed immediately after the function being
exported, as kernel-doc will only look at one file at a time. This is
the recommendation anyway. See the corresponding patch for further
details ("kernel-doc: support printing exported and non-exported
symbols"). Second, we lose support for the !C docproc directive to check
that all kernel-doc comments in a file are used. This is probably
something we'd like to have back in the future, but at this time I think
it's an acceptable tradeoff wrt the gains.

With this, we can put any .rst files (including ones that have
kernel-doc directives) anywhere under Documentation, add a link to them
in Documentation/index.rst table of contents, and it will just work. It
can't get much simpler than that.

At this time I've put most effort into the configuration and build side
of things, solving the problems described above, and handling missing
tools and packages gracefully. There are still issues to be ironed out
in a) the kernel-doc script rst output and b) the xml template to rst
conversion. These are somewhat orthogonal from each other and the build,
and I expect some hand-editing will be required in the end.

The patches are available in the "sphinx" branch of [1], and I've set up
a project at Read the Docs to build that into documentation [2] (mostly
to test this approach also works and so I don't have to host this
anywhere).

Any comments are welcome, but please do remember that I've focused on
polishing the toolchain and build, not the output quality, with release
early, release often in mind.

BR,
Jani.


[1] git://people.freedesktop.org/~jani/drm
[2] https://kernel.readthedocs.io/



Jani Nikula (9):
  kernel-doc: fix use of uninitialized value
  kernel-doc: support printing exported and non-exported symbols
  Documentation/sphinx: add basic working Sphinx configuration and build
  Documentation: add .gitignore
  Documentation/sphinx: add Sphinx kernel-doc directive extension
  Documentation/sphinx: configure the kernel-doc extension
  Documentation: add kernel hacking rst
  Documentation: add kernel api rst
  Documentation: moar files

Jonathan Corbet (1):
  sphinx: cheesy script to convert .tmpl files

 Documentation/.gitignore                  |    1 +
 Documentation/DocBook/Makefile            |    7 +-
 Documentation/Makefile.sphinx             |   63 +
 Documentation/conf.py                     |  384 +++++
 Documentation/crypto-API.rst              | 1870 +++++++++++++++++++++
 Documentation/filesystems.rst             |  314 ++++
 Documentation/gpu.rst                     | 2556 +++++++++++++++++++++++++++++
 Documentation/index.rst                   |   30 +
 Documentation/kernel-api.rst              |  419 +++++
 Documentation/kernel-hacking.rst          |  795 +++++++++
 Documentation/sphinx/convert_template.sed |   14 +
 Documentation/sphinx/kernel-doc.py        |   99 ++
 Documentation/sphinx/post_convert.sed     |   19 +
 Documentation/sphinx/tmplcvt              |   19 +
 Makefile                                  |    5 +-
 scripts/kernel-doc                        |   32 +-
 16 files changed, 6619 insertions(+), 8 deletions(-)
 create mode 100644 Documentation/.gitignore
 create mode 100644 Documentation/Makefile.sphinx
 create mode 100644 Documentation/conf.py
 create mode 100644 Documentation/crypto-API.rst
 create mode 100644 Documentation/filesystems.rst
 create mode 100644 Documentation/gpu.rst
 create mode 100644 Documentation/index.rst
 create mode 100644 Documentation/kernel-api.rst
 create mode 100644 Documentation/kernel-hacking.rst
 create mode 100644 Documentation/sphinx/convert_template.sed
 create mode 100644 Documentation/sphinx/kernel-doc.py
 create mode 100644 Documentation/sphinx/post_convert.sed
 create mode 100755 Documentation/sphinx/tmplcvt

-- 
2.1.4

[PATCH 01/10] kernel-doc: fix use of uninitialized value

[Jani Nikula]

I'm not quite sure why the errors below are happening, but this fixes
them.

Use of uninitialized value in string ne at ./scripts/kernel-doc line 1819, <IN> line 6494.
Use of uninitialized value $_[0] in join or string at ./scripts/kernel-doc line 1759, <IN> line 6494.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
 scripts/kernel-doc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 2fc8fad5195e..babb374c043d 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -1803,7 +1803,8 @@ sub output_function_rst(%) {
 	} else {
 	    print "      ``$parameter``\n";
 	}
-	if ($args{'parameterdescs'}{$parameter_name} ne $undescribed) {
+	if (defined($args{'parameterdescs'}{$parameter_name}) &&
+	    $args{'parameterdescs'}{$parameter_name} ne $undescribed) {
 	    my $oldprefix = $lineprefix;
 	    $lineprefix = "        ";
 	    output_highlight_rst($args{'parameterdescs'}{$parameter_name});
-- 
2.1.4

[PATCH 02/10] kernel-doc: support printing exported and non-exported symbols

[Jani Nikula]

Currently we use docproc to figure out which symbols are exported, and
then docproc calls kernel-doc on specific functions, to get
documentation on exported functions. According to git blame and docproc
comments, this is due to historical reasons, as functions and their
corresponding EXPORT_SYMBOL* may have been in different files. However
for more than ten years the recommendation in CodingStyle has been to
place the EXPORT_SYMBOL* immediately after the closing function brace
line.

Additionally, the kernel-doc comments for functions are generally placed
above the function definition in the .c files (i.e. where the
EXPORT_SYMBOL* is) rather than above the declaration in the .h
files. There are some exceptions to this, but AFAICT none of these are
included in DocBook documentation using the "!E" docproc directive.

Therefore, assuming the EXPORT_SYMBOL* and kernel-doc are with the
function definition, kernel-doc can extract the exported vs. not
information by making two passes on the input file. Add support for that
via the new -export and -internal parameters.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
 scripts/kernel-doc | 29 +++++++++++++++++++++++++++--
 1 file changed, 27 insertions(+), 2 deletions(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index babb374c043d..0e4109bcaa41 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -59,6 +59,12 @@ Output format selection (mutually exclusive):
   -text			Output plain text format.
 
 Output selection (mutually exclusive):
+  -export		Only output documentation for symbols that have been
+			exported using EXPORT_SYMBOL() or EXPORT_SYMBOL_GPL()
+			in the same FILE.
+  -internal		Only output documentation for symbols that have NOT been
+			exported using EXPORT_SYMBOL() or EXPORT_SYMBOL_GPL()
+			in the same FILE.
   -function NAME	Only output documentation for the given function(s)
 			or DOC: section title(s). All other functions and DOC:
 			sections are ignored. May be specified multiple times.
@@ -380,6 +386,7 @@ my $doc_block = $doc_com . 'DOC:\s*(.*)?';
 my $doc_split_start = '^\s*/\*\*\s*$';
 my $doc_split_sect = '\s*\*\s*(@[\w\s]+):(.*)';
 my $doc_split_end = '^\s*\*/\s*$';
+my $export_symbol = '^\s*EXPORT_SYMBOL(_GPL)?\s*\(\s*(\w+)\s*\)\s*;';
 
 my %constants;
 my %parameterdescs;
@@ -444,6 +451,12 @@ while ($ARGV[0] =~ m/^-(.*)/) {
 	$function_only = 2;
 	$function = shift @ARGV;
 	$function_table{$function} = 1;
+    } elsif ($cmd eq "-export") { # only exported symbols
+	$function_only = 3;
+	%function_table = ()
+    } elsif ($cmd eq "-internal") { # only non-exported symbols
+	$function_only = 4;
+	%function_table = ()
     } elsif ($cmd eq "-v") {
 	$verbose = 1;
     } elsif (($cmd eq "-h") || ($cmd eq "--help")) {
@@ -1971,8 +1984,10 @@ sub output_declaration {
     my $functype = shift;
     my $func = "output_${functype}_$output_mode";
     if (($function_only==0) ||
-	( $function_only == 1 && defined($function_table{$name})) ||
-	( $function_only == 2 && !($functype eq "function" && defined($function_table{$name}))))
+	( ($function_only == 1 || $function_only == 3) &&
+	  defined($function_table{$name})) ||
+	( ($function_only == 2 || $function_only == 4) &&
+	  !($functype eq "function" && defined($function_table{$name}))))
     {
 	&$func(@_);
 	$section_counter++;
@@ -2677,6 +2692,16 @@ sub process_file($) {
 
     $. = 1;
 
+    # two passes for -export and -internal
+    if ($function_only == 3 || $function_only == 4) {
+	while (<IN>) {
+	    if (/$export_symbol/o) {
+		$function_table{$2} = 1;
+	    }
+	}
+	seek(IN, 0, 0);
+    }
+
     $section_counter = 0;
     while (<IN>) {
 	while (s/\\\s*$//) {
-- 
2.1.4

[PATCH 03/10] Documentation/sphinx: add basic working Sphinx configuration and build

[Jani Nikula]

Add basic configuration and makefile to build documentation from any
.rst files under Documentation using Sphinx. For starters, there's just
the placeholder index.rst.

At the top level Makefile, hook Sphinx documentation targets alongside
(but independent of) the DocBook toolchain, having both be run on the
various 'make *docs' targets.

All Sphinx processing is placed into Documentation/Makefile.sphinx. Both
that and the Documentation/DocBook/Makefile are now expected to handle
all the documentation targets, explicitly ignoring them if they're not
relevant for that particular toolchain. The changes to the existing
DocBook Makefile are kept minimal.

There is graceful handling of missing Sphinx and rst2pdf (which is
needed for pdf output) by checking for the tool and python module,
respectively, with informative messages to the user.

If the Read the Docs theme (sphinx_rtd_theme) is available, use it, but
otherwise gracefully fall back to the Sphinx default theme, with an
informative message to the user, and slightly less pretty HTML output.

Sphinx can now handle htmldocs, pdfdocs (if rst2pdf is available),
epubdocs and xmldocs targets. The output documents are written into per
output type subdirectories under Documentation/output.

Finally, you can pass options to sphinx-build using the SPHINXBUILD make
variable. For example, 'make SPHINXOPTS=-v htmldocs' for more verbose
output from Sphinx.

This is based on the original work by Jonathan Corbet, but he probably
wouldn't recognize this as his own anymore.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
 Documentation/DocBook/Makefile |   7 +-
 Documentation/Makefile.sphinx  |  61 +++++++
 Documentation/conf.py          | 378 +++++++++++++++++++++++++++++++++++++++++
 Documentation/index.rst        |  23 +++
 Makefile                       |   5 +-
 5 files changed, 469 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/Makefile.sphinx
 create mode 100644 Documentation/conf.py
 create mode 100644 Documentation/index.rst

diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index d70f9b68174e..e0c7e1e0590b 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -33,10 +33,6 @@ PDF_METHOD	= $(prefer-db2x)
 PS_METHOD	= $(prefer-db2x)
 
 
-###
-# The targets that may be used.
-PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs cleandocs
-
 targets += $(DOCBOOKS)
 BOOKS := $(addprefix $(obj)/,$(DOCBOOKS))
 xmldocs: $(BOOKS)
@@ -63,6 +59,9 @@ installmandocs: mandocs
 		sort -k 2 -k 1 | uniq -f 1 | sed -e 's: :/:' | \
 		xargs install -m 644 -t /usr/local/man/man9/
 
+# no-op for the DocBook toolchain
+epubdocs:
+
 ###
 #External programs used
 KERNELDOCXMLREF = $(srctree)/scripts/kernel-doc-xml-ref
diff --git a/Documentation/Makefile.sphinx b/Documentation/Makefile.sphinx
new file mode 100644
index 000000000000..25a7970bfe5c
--- /dev/null
+++ b/Documentation/Makefile.sphinx
@@ -0,0 +1,61 @@
+# -*- makefile -*-
+# Makefile for Sphinx documentation
+#
+
+# You can set these variables from the command line.
+SPHINXBUILD   = sphinx-build
+SPHINXOPTS    =
+PAPER         =
+BUILDDIR      = $(obj)/output
+
+# User-friendly check for sphinx-build
+HAVE_SPHINX := $(shell if which $(SPHINXBUILD) >/dev/null 2>&1; then echo 1; else echo 0; fi)
+
+ifeq ($(HAVE_SPHINX),0)
+
+.DEFAULT:
+	$(warning The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed and in PATH, or set the SPHINXBUILD make variable to point to the full path of the '$(SPHINXBUILD)' executable.)
+	@echo "  SKIP    Sphinx $@ target."
+
+else # HAVE_SPHINX
+
+# User-friendly check for rst2pdf
+HAVE_RST2PDF := $(shell if python -c "import rst2pdf" >/dev/null 2>&1; then echo 1; else echo 0; fi)
+
+# Internal variables.
+PAPEROPT_a4     = -D latex_paper_size=a4
+PAPEROPT_letter = -D latex_paper_size=letter
+ALLSPHINXOPTS   = -d $(BUILDDIR)/.doctrees $(PAPEROPT_$(PAPER)) -c $(srctree)/$(src) $(SPHINXOPTS) $(srctree)/$(src)
+# the i18n builder cannot share the environment and doctrees with the others
+I18NSPHINXOPTS  = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
+
+quiet_cmd_sphinx = SPHINX  $@
+      cmd_sphinx = $(SPHINXBUILD) -b $2 $(ALLSPHINXOPTS) $(BUILDDIR)/$2
+
+htmldocs:
+	$(call cmd,sphinx,html)
+
+pdfdocs:
+ifeq ($(HAVE_RST2PDF),0)
+	$(warning The Python 'rst2pdf' module was not found. Make sure you have the module installed to produce PDF output.)
+	@echo "  SKIP    Sphinx $@ target."
+else # HAVE_RST2PDF
+	$(call cmd,sphinx,pdf)
+endif # HAVE_RST2PDF
+
+epubdocs:
+	$(call cmd,sphinx,epub)
+
+xmldocs:
+	$(call cmd,sphinx,xml)
+
+# no-ops for the Sphinx toolchain
+sgmldocs:
+psdocs:
+mandocs:
+installmandocs:
+
+cleandocs:
+	$(Q)rm -rf $(BUILDDIR)
+
+endif # HAVE_SPHINX
diff --git a/Documentation/conf.py b/Documentation/conf.py
new file mode 100644
index 000000000000..ff86f5e88049
--- /dev/null
+++ b/Documentation/conf.py
@@ -0,0 +1,378 @@
+# -*- coding: utf-8 -*-
+#
+# The Linux Kernel documentation build configuration file, created by
+# sphinx-quickstart on Fri Feb 12 13:51:46 2016.
+#
+# This file is execfile()d with the current directory set to its
+# containing dir.
+#
+# Note that not all possible configuration values are present in this
+# autogenerated file.
+#
+# All configuration values have a default; values that are commented out
+# serve to show the default.
+
+import sys
+import os
+
+# If extensions (or modules to document with autodoc) are in another directory,
+# add these directories to sys.path here. If the directory is relative to the
+# documentation root, use os.path.abspath to make it absolute, like shown here.
+#sys.path.insert(0, os.path.abspath('.'))
+
+# -- General configuration ------------------------------------------------
+
+# If your documentation needs a minimal Sphinx version, state it here.
+#needs_sphinx = '1.0'
+
+# Add any Sphinx extension module names here, as strings. They can be
+# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
+# ones.
+extensions = []
+
+# Gracefully handle missing rst2pdf.
+try:
+    import rst2pdf
+    extensions += ['rst2pdf.pdfbuilder']
+except ImportError:
+    pass
+
+# Add any paths that contain templates here, relative to this directory.
+templates_path = ['_templates']
+
+# The suffix(es) of source filenames.
+# You can specify multiple suffix as a list of string:
+# source_suffix = ['.rst', '.md']
+source_suffix = '.rst'
+
+# The encoding of source files.
+#source_encoding = 'utf-8-sig'
+
+# The master toctree document.
+master_doc = 'index'
+
+# General information about the project.
+project = 'The Linux Kernel'
+copyright = '2016, The kernel development community'
+author = 'The kernel development community'
+
+# The version info for the project you're documenting, acts as replacement for
+# |version| and |release|, also used in various other places throughout the
+# built documents.
+#
+# The short X.Y version.
+version = '4.5'
+# The full version, including alpha/beta/rc tags.
+release = '4.5'
+
+# The language for content autogenerated by Sphinx. Refer to documentation
+# for a list of supported languages.
+#
+# This is also used if you do content translation via gettext catalogs.
+# Usually you set "language" from the command line for these cases.
+language = None
+
+# There are two options for replacing |today|: either, you set today to some
+# non-false value, then it is used:
+#today = ''
+# Else, today_fmt is used as the format for a strftime call.
+#today_fmt = '%B %d, %Y'
+
+# List of patterns, relative to source directory, that match files and
+# directories to ignore when looking for source files.
+exclude_patterns = ['output']
+
+# The reST default role (used for this markup: `text`) to use for all
+# documents.
+#default_role = None
+
+# If true, '()' will be appended to :func: etc. cross-reference text.
+#add_function_parentheses = True
+
+# If true, the current module name will be prepended to all description
+# unit titles (such as .. function::).
+#add_module_names = True
+
+# If true, sectionauthor and moduleauthor directives will be shown in the
+# output. They are ignored by default.
+#show_authors = False
+
+# The name of the Pygments (syntax highlighting) style to use.
+pygments_style = 'sphinx'
+
+# A list of ignored prefixes for module index sorting.
+#modindex_common_prefix = []
+
+# If true, keep warnings as "system message" paragraphs in the built documents.
+#keep_warnings = False
+
+# If true, `todo` and `todoList` produce output, else they produce nothing.
+todo_include_todos = False
+
+primary_domain = 'C'
+highlight_language = 'C'
+
+# -- Options for HTML output ----------------------------------------------
+
+# The theme to use for HTML and HTML Help pages.  See the documentation for
+# a list of builtin themes.
+
+# The Read the Docs theme is available from
+# - https://github.com/snide/sphinx_rtd_theme
+# - https://pypi.python.org/pypi/sphinx_rtd_theme
+# - python-sphinx-rtd-theme package (on Debian)
+try:
+    import sphinx_rtd_theme
+    html_theme = 'sphinx_rtd_theme'
+    html_theme_path = [sphinx_rtd_theme.get_html_theme_path()]
+except ImportError:
+    sys.stderr.write('Warning: The Sphinx \'sphinx_rtd_theme\' HTML theme was not found. Make sure you have the theme installed to produce pretty HTML output. Falling back to the default theme.\n')
+
+# Theme options are theme-specific and customize the look and feel of a theme
+# further.  For a list of options available for each theme, see the
+# documentation.
+#html_theme_options = {}
+
+# Add any paths that contain custom themes here, relative to this directory.
+#html_theme_path = []
+
+# The name for this set of Sphinx documents.  If None, it defaults to
+# "<project> v<release> documentation".
+#html_title = None
+
+# A shorter title for the navigation bar.  Default is the same as html_title.
+#html_short_title = None
+
+# The name of an image file (relative to this directory) to place at the top
+# of the sidebar.
+#html_logo = None
+
+# The name of an image file (within the static path) to use as favicon of the
+# docs.  This file should be a Windows icon file (.ico) being 16x16 or 32x32
+# pixels large.
+#html_favicon = None
+
+# Add any paths that contain custom static files (such as style sheets) here,
+# relative to this directory. They are copied after the builtin static files,
+# so a file named "default.css" will overwrite the builtin "default.css".
+#html_static_path = ['_static']
+
+# Add any extra paths that contain custom files (such as robots.txt or
+# .htaccess) here, relative to this directory. These files are copied
+# directly to the root of the documentation.
+#html_extra_path = []
+
+# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
+# using the given strftime format.
+#html_last_updated_fmt = '%b %d, %Y'
+
+# If true, SmartyPants will be used to convert quotes and dashes to
+# typographically correct entities.
+#html_use_smartypants = True
+
+# Custom sidebar templates, maps document names to template names.
+#html_sidebars = {}
+
+# Additional templates that should be rendered to pages, maps page names to
+# template names.
+#html_additional_pages = {}
+
+# If false, no module index is generated.
+#html_domain_indices = True
+
+# If false, no index is generated.
+#html_use_index = True
+
+# If true, the index is split into individual pages for each letter.
+#html_split_index = False
+
+# If true, links to the reST sources are added to the pages.
+#html_show_sourcelink = True
+
+# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
+#html_show_sphinx = True
+
+# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
+#html_show_copyright = True
+
+# If true, an OpenSearch description file will be output, and all pages will
+# contain a <link> tag referring to it.  The value of this option must be the
+# base URL from which the finished HTML is served.
+#html_use_opensearch = ''
+
+# This is the file name suffix for HTML files (e.g. ".xhtml").
+#html_file_suffix = None
+
+# Language to be used for generating the HTML full-text search index.
+# Sphinx supports the following languages:
+#   'da', 'de', 'en', 'es', 'fi', 'fr', 'h', 'it', 'ja'
+#   'nl', 'no', 'pt', 'ro', 'r', 'sv', 'tr'
+#html_search_language = 'en'
+
+# A dictionary with options for the search language support, empty by default.
+# Now only 'ja' uses this config value
+#html_search_options = {'type': 'default'}
+
+# The name of a javascript file (relative to the configuration directory) that
+# implements a search results scorer. If empty, the default will be used.
+#html_search_scorer = 'scorer.js'
+
+# Output file base name for HTML help builder.
+htmlhelp_basename = 'TheLinuxKerneldoc'
+
+# -- Options for LaTeX output ---------------------------------------------
+
+latex_elements = {
+# The paper size ('letterpaper' or 'a4paper').
+#'papersize': 'letterpaper',
+
+# The font size ('10pt', '11pt' or '12pt').
+#'pointsize': '10pt',
+
+# Additional stuff for the LaTeX preamble.
+#'preamble': '',
+
+# Latex figure (float) alignment
+#'figure_align': 'htbp',
+}
+
+# Grouping the document tree into LaTeX files. List of tuples
+# (source start file, target name, title,
+#  author, documentclass [howto, manual, or own class]).
+latex_documents = [
+    (master_doc, 'TheLinuxKernel.tex', 'The Linux Kernel Documentation',
+     'The kernel development community', 'manual'),
+]
+
+# The name of an image file (relative to this directory) to place at the top of
+# the title page.
+#latex_logo = None
+
+# For "manual" documents, if this is true, then toplevel headings are parts,
+# not chapters.
+#latex_use_parts = False
+
+# If true, show page references after internal links.
+#latex_show_pagerefs = False
+
+# If true, show URL addresses after external links.
+#latex_show_urls = False
+
+# Documents to append as an appendix to all manuals.
+#latex_appendices = []
+
+# If false, no module index is generated.
+#latex_domain_indices = True
+
+
+# -- Options for manual page output ---------------------------------------
+
+# One entry per manual page. List of tuples
+# (source start file, name, description, authors, manual section).
+man_pages = [
+    (master_doc, 'thelinuxkernel', 'The Linux Kernel Documentation',
+     [author], 1)
+]
+
+# If true, show URL addresses after external links.
+#man_show_urls = False
+
+
+# -- Options for Texinfo output -------------------------------------------
+
+# Grouping the document tree into Texinfo files. List of tuples
+# (source start file, target name, title, author,
+#  dir menu entry, description, category)
+texinfo_documents = [
+    (master_doc, 'TheLinuxKernel', 'The Linux Kernel Documentation',
+     author, 'TheLinuxKernel', 'One line description of project.',
+     'Miscellaneous'),
+]
+
+# Documents to append as an appendix to all manuals.
+#texinfo_appendices = []
+
+# If false, no module index is generated.
+#texinfo_domain_indices = True
+
+# How to display URL addresses: 'footnote', 'no', or 'inline'.
+#texinfo_show_urls = 'footnote'
+
+# If true, do not generate a @detailmenu in the "Top" node's menu.
+#texinfo_no_detailmenu = False
+
+
+# -- Options for Epub output ----------------------------------------------
+
+# Bibliographic Dublin Core info.
+epub_title = project
+epub_author = author
+epub_publisher = author
+epub_copyright = copyright
+
+# The basename for the epub file. It defaults to the project name.
+#epub_basename = project
+
+# The HTML theme for the epub output. Since the default themes are not
+# optimized for small screen space, using the same theme for HTML and epub
+# output is usually not wise. This defaults to 'epub', a theme designed to save
+# visual space.
+#epub_theme = 'epub'
+
+# The language of the text. It defaults to the language option
+# or 'en' if the language is not set.
+#epub_language = ''
+
+# The scheme of the identifier. Typical schemes are ISBN or URL.
+#epub_scheme = ''
+
+# The unique identifier of the text. This can be a ISBN number
+# or the project homepage.
+#epub_identifier = ''
+
+# A unique identification for the text.
+#epub_uid = ''
+
+# A tuple containing the cover image and cover page html template filenames.
+#epub_cover = ()
+
+# A sequence of (type, uri, title) tuples for the guide element of content.opf.
+#epub_guide = ()
+
+# HTML files that should be inserted before the pages created by sphinx.
+# The format is a list of tuples containing the path and title.
+#epub_pre_files = []
+
+# HTML files that should be inserted after the pages created by sphinx.
+# The format is a list of tuples containing the path and title.
+#epub_post_files = []
+
+# A list of files that should not be packed into the epub file.
+epub_exclude_files = ['search.html']
+
+# The depth of the table of contents in toc.ncx.
+#epub_tocdepth = 3
+
+# Allow duplicate toc entries.
+#epub_tocdup = True
+
+# Choose between 'default' and 'includehidden'.
+#epub_tocscope = 'default'
+
+# Fix unsupported image types using the Pillow.
+#epub_fix_images = False
+
+# Scale large images.
+#epub_max_image_width = 0
+
+# How to display URL addresses: 'footnote', 'no', or 'inline'.
+#epub_show_urls = 'inline'
+
+# If false, no index is generated.
+#epub_use_index = True
+
+#=======
+# rst2pdf
+pdf_documents = [
+    ('index', u'Kernel', u'Kernel', u'J. Random Bozo'),
+]
diff --git a/Documentation/index.rst b/Documentation/index.rst
new file mode 100644
index 000000000000..71a276f34c7f
--- /dev/null
+++ b/Documentation/index.rst
@@ -0,0 +1,23 @@
+.. The Linux Kernel documentation master file, created by
+   sphinx-quickstart on Fri Feb 12 13:51:46 2016.
+   You can adapt this file completely to your liking, but it should at least
+   contain the root `toctree` directive.
+
+Welcome to The Linux Kernel's documentation!
+============================================
+
+Nothing for you to see here *yet*. Please move along.
+
+Contents:
+
+.. toctree::
+   :maxdepth: 2
+
+
+Indices and tables
+==================
+
+* :ref:`genindex`
+* :ref:`modindex`
+* :ref:`search`
+
diff --git a/Makefile b/Makefile
index 0f9cb36d45c2..85b3d1049054 100644
--- a/Makefile
+++ b/Makefile
@@ -1385,8 +1385,11 @@ $(help-board-dirs): help-%:
 
 # Documentation targets
 # ---------------------------------------------------------------------------
-%docs: scripts_basic FORCE
+DOC_TARGETS := xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs epubdocs cleandocs
+PHONY += $(DOC_TARGETS)
+$(DOC_TARGETS): scripts_basic FORCE
 	$(Q)$(MAKE) $(build)=scripts build_docproc build_check-lc_ctype
+	$(Q)$(MAKE) $(build)=Documentation -f $(srctree)/Documentation/Makefile.sphinx $@
 	$(Q)$(MAKE) $(build)=Documentation/DocBook $@
 
 else # KBUILD_EXTMOD
-- 
2.1.4

[PATCH 04/10] Documentation: add .gitignore

[Jani Nikula]

The Sphinx output directory is generated.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
 Documentation/.gitignore | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 Documentation/.gitignore

diff --git a/Documentation/.gitignore b/Documentation/.gitignore
new file mode 100644
index 000000000000..53752db253e3
--- /dev/null
+++ b/Documentation/.gitignore
@@ -0,0 +1 @@
+output
-- 
2.1.4

[PATCH 05/10] Documentation/sphinx: add Sphinx kernel-doc directive extension

[Jani Nikula]

Add an extension to handle kernel-doc directives, to call kernel-doc
according to the arguments and parameters given to the reStructuredText
directive.

The syntax for the kernel-doc directive is:

.. kernel-doc:: FILENAME
   :export:
   :internal:
   :functions: FUNCTION [FUNCTION ...]
   :doc: SECTION TITLE

Of the directive options export, internal, functions, and doc, currently
only one option may be given at a time.

The FILENAME is relative from the kernel source tree root.

The extension notifies Sphinx about the document dependency on FILENAME,
causing the document to be rebuilt when the file has been changed.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
 Documentation/sphinx/kernel-doc.py | 99 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 99 insertions(+)
 create mode 100644 Documentation/sphinx/kernel-doc.py

diff --git a/Documentation/sphinx/kernel-doc.py b/Documentation/sphinx/kernel-doc.py
new file mode 100644
index 000000000000..21f61373daf0
--- /dev/null
+++ b/Documentation/sphinx/kernel-doc.py
@@ -0,0 +1,99 @@
+# coding=utf-8
+#
+# Copyright © 2016 Intel Corporation
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice (including the next
+# paragraph) shall be included in all copies or substantial portions of the
+# Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+# IN THE SOFTWARE.
+#
+# Authors:
+#    Jani Nikula <jani.nikula@intel.com>
+
+import os
+import subprocess
+import sys
+
+from docutils import nodes, statemachine
+from docutils.parsers.rst import directives
+from sphinx.util.compat import Directive
+
+class KernelDocDirective(Directive):
+    """Extract kernel-doc comments from the specified file"""
+    required_argument = 1
+    optional_arguments = 4
+    option_spec = {
+        'doc': directives.unchanged_required,
+        'functions': directives.unchanged_required,
+        'export': directives.flag,
+        'internal': directives.flag,
+    }
+    has_content = False
+
+    def run(self):
+        env = self.state.document.settings.env
+        cmd = [env.config.kerneldoc_bin, '-rst']
+
+        filename = env.config.kerneldoc_srctree + '/' + self.arguments[0]
+
+        # Tell sphinx of the dependency
+        env.note_dependency(os.path.abspath(filename))
+
+        tab_width = self.options.get('tab-width', self.state.document.settings.tab_width)
+        source = self.state_machine.input_lines.source(self.lineno - self.state_machine.input_offset - 1)
+
+        # FIXME: make this nicer and more robust against errors
+        if 'export' in self.options:
+            cmd += ['-export']
+        elif 'internal' in self.options:
+            cmd += ['-internal']
+        elif 'doc' in self.options:
+            cmd += ['-function', str(self.options.get('doc'))]
+        elif 'functions' in self.options:
+            for f in str(self.options.get('functions')).split(' '):
+                cmd += ['-function', f]
+
+        cmd += [filename]
+
+        try:
+            env.app.verbose('calling kernel-doc \'%s\'' % (" ".join(cmd)))
+
+            p = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
+            out, err = p.communicate()
+
+            if p.returncode != 0:
+                sys.stderr.write(err)
+
+                env.app.warn('kernel-doc \'%s\' failed with return code %d' % (" ".join(cmd), p.returncode))
+                return [nodes.error(None, nodes.paragraph(text = "kernel-doc missing"))]
+            elif env.config.kerneldoc_verbosity > 0:
+                sys.stderr.write(err)
+
+            lines = statemachine.string2lines(out, tab_width, convert_whitespace=True)
+            self.state_machine.insert_input(lines, source)
+            return []
+        except Exception as e:
+            env.app.warn('kernel-doc \'%s\' processing failed with: %s' %
+                         (" ".join(cmd), str(e)))
+            return [nodes.error(None, nodes.paragraph(text = "kernel-doc missing"))]
+
+def setup(app):
+    app.add_config_value('kerneldoc_bin', None, 'env')
+    app.add_config_value('kerneldoc_srctree', None, 'env')
+    app.add_config_value('kerneldoc_verbosity', 1, 'env')
+
+    app.add_directive('kernel-doc', KernelDocDirective)
-- 
2.1.4

[PATCH 06/10] Documentation/sphinx: configure the kernel-doc extension

[Jani Nikula]

Tell Sphinx where to find the extension, and pass on the kernel src tree
and kernel-doc paths to the extension.

With this, any .rst files under Documentation may contain the kernel-doc
rst directive to include kernel-doc documentation from any source file.

While building, it may be handy to pass kernel-doc extension
configuration on the command line. For example, 'make SPHINXOPTS="-D
kerneldoc_verbosity=0" htmldocs' silences all stderr output from
kernel-doc when the kernel-doc exit code is 0. (The stderr will be
logged unconditionally when the exit code is non-zero.)

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
 Documentation/Makefile.sphinx |  4 +++-
 Documentation/conf.py         | 10 ++++++++--
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/Documentation/Makefile.sphinx b/Documentation/Makefile.sphinx
index 25a7970bfe5c..8a662be9bd87 100644
--- a/Documentation/Makefile.sphinx
+++ b/Documentation/Makefile.sphinx
@@ -25,7 +25,9 @@ HAVE_RST2PDF := $(shell if python -c "import rst2pdf" >/dev/null 2>&1; then echo
 # Internal variables.
 PAPEROPT_a4     = -D latex_paper_size=a4
 PAPEROPT_letter = -D latex_paper_size=letter
-ALLSPHINXOPTS   = -d $(BUILDDIR)/.doctrees $(PAPEROPT_$(PAPER)) -c $(srctree)/$(src) $(SPHINXOPTS) $(srctree)/$(src)
+KERNELDOC       = $(srctree)/scripts/kernel-doc
+KERNELDOC_CONF  = -D kerneldoc_srctree=$(srctree) -D kerneldoc_bin=$(KERNELDOC)
+ALLSPHINXOPTS   = -d $(BUILDDIR)/.doctrees $(KERNELDOC_CONF) $(PAPEROPT_$(PAPER)) -c $(srctree)/$(src) $(SPHINXOPTS) $(srctree)/$(src)
 # the i18n builder cannot share the environment and doctrees with the others
 I18NSPHINXOPTS  = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
 
diff --git a/Documentation/conf.py b/Documentation/conf.py
index ff86f5e88049..0d33cb157716 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -18,7 +18,7 @@ import os
 # If extensions (or modules to document with autodoc) are in another directory,
 # add these directories to sys.path here. If the directory is relative to the
 # documentation root, use os.path.abspath to make it absolute, like shown here.
-#sys.path.insert(0, os.path.abspath('.'))
+sys.path.insert(0, os.path.abspath('sphinx'))
 
 # -- General configuration ------------------------------------------------
 
@@ -28,7 +28,7 @@ import os
 # Add any Sphinx extension module names here, as strings. They can be
 # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
 # ones.
-extensions = []
+extensions = ['kernel-doc']
 
 # Gracefully handle missing rst2pdf.
 try:
@@ -376,3 +376,9 @@ epub_exclude_files = ['search.html']
 pdf_documents = [
     ('index', u'Kernel', u'Kernel', u'J. Random Bozo'),
 ]
+
+# kernel-doc extension configuration for running Sphinx directly (e.g. by Read
+# the Docs). In a normal build, these are supplied from the Makefile via command
+# line arguments.
+kerneldoc_bin = '../scripts/kernel-doc'
+kerneldoc_srctree = '..'
-- 
2.1.4

[PATCH 07/10] sphinx: cheesy script to convert .tmpl files

[Jani Nikula]

From: Jonathan Corbet <corbet@lwn.net>

This script uses pandoc to convert existing DocBook template files to RST
templates.  A couple of sed scripts are need to massage things both before
and after the conversion, but the result is then usable with no hand
editing.

[Jani: Change usage to tmplcvt <in> <out>. Fix escaping for docproc
directives. Add support the new kernel-doc extension.]

Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
 Documentation/sphinx/convert_template.sed | 14 ++++++++++++++
 Documentation/sphinx/post_convert.sed     | 19 +++++++++++++++++++
 Documentation/sphinx/tmplcvt              | 19 +++++++++++++++++++
 3 files changed, 52 insertions(+)
 create mode 100644 Documentation/sphinx/convert_template.sed
 create mode 100644 Documentation/sphinx/post_convert.sed
 create mode 100755 Documentation/sphinx/tmplcvt

diff --git a/Documentation/sphinx/convert_template.sed b/Documentation/sphinx/convert_template.sed
new file mode 100644
index 000000000000..d53bb8220a26
--- /dev/null
+++ b/Documentation/sphinx/convert_template.sed
@@ -0,0 +1,14 @@
+#
+# Pandoc doesn't grok <function> or <structname>, so convert them
+# ahead of time.
+#
+# Use "$bq" instead of "`" so that pandoc won't mess with it.
+#
+s%<function>\([^<(]\+\)()</function>%:c:func:$bq\1$bq%g
+s%<function>\([^<(]\+\)</function>%:c:func:$bq\1$bq%g
+s%<structname>struct *\([^<]\+\)</structname>%:ref:$bqstruct \1$bq%g
+s%<structname>\([^<]\+\)</structname>%:ref:$bqstruct \1$bq%g
+#
+# Wrap docproc directives in para and code blocks.
+#
+s%^\(!.*\)$%<para><code>DOCPROC: \1</code></para>%
diff --git a/Documentation/sphinx/post_convert.sed b/Documentation/sphinx/post_convert.sed
new file mode 100644
index 000000000000..ce17049f6a8e
--- /dev/null
+++ b/Documentation/sphinx/post_convert.sed
@@ -0,0 +1,19 @@
+#
+# pandoc thinks that both "_" needs to be escaped.  Remove the extra
+# backslashes.  Also put in proper backquotes now that pandoc won't quote
+# them.
+#
+s/$bq/`/g
+s/\\_/_/g
+#
+# Unwrap docproc directives.
+#
+s/^``DOCPROC: !E\(.*\)``$/.. kernel-doc:: \1\n   :export:/
+s/^``DOCPROC: !I\(.*\)``$/.. kernel-doc:: \1\n   :internal:/
+s/^``DOCPROC: !F\([^ ]*\) \(.*\)``$/.. kernel-doc:: \1\n   :functions: \2/
+s/^``DOCPROC: !P\([^ ]*\) \(.*\)``$/.. kernel-doc:: \1\n   :doc: \2/
+s/^``DOCPROC: \(!.*\)``$/.. WARNING: DOCPROC directive not supported: \1/
+#
+# Trim trailing whitespace.
+#
+s/[[:space:]]*$//
diff --git a/Documentation/sphinx/tmplcvt b/Documentation/sphinx/tmplcvt
new file mode 100755
index 000000000000..909a73065e0a
--- /dev/null
+++ b/Documentation/sphinx/tmplcvt
@@ -0,0 +1,19 @@
+#!/bin/bash
+#
+# Convert a template file into something like RST
+#
+# fix <function>
+# feed to pandoc
+# fix \_
+# title line?
+#
+
+in=$1
+rst=$2
+tmp=$rst.tmp
+
+cp $in $tmp
+sed --in-place -f convert_template.sed $tmp
+pandoc -s -S -f docbook -t rst -o $rst $tmp
+sed --in-place -f post_convert.sed $rst
+rm $tmp
-- 
2.1.4

[PATCH 08/10] Documentation: add kernel hacking rst

[Jani Nikula]

Crude conversion. This one doesn't use kernel-doc.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
 Documentation/index.rst          |   5 +-
 Documentation/kernel-hacking.rst | 795 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 799 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/kernel-hacking.rst

diff --git a/Documentation/index.rst b/Documentation/index.rst
index 71a276f34c7f..1ed1c4e91c27 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -6,13 +6,16 @@
 Welcome to The Linux Kernel's documentation!
 ============================================
 
-Nothing for you to see here *yet*. Please move along.
+This is a hacked together set of pages generated from the kernel .tmpl files
+using sphinx.  There's lots of glitches and such still - lots of details to work
+out, but at least it's a start.
 
 Contents:
 
 .. toctree::
    :maxdepth: 2
 
+   kernel-hacking
 
 Indices and tables
 ==================
diff --git a/Documentation/kernel-hacking.rst b/Documentation/kernel-hacking.rst
new file mode 100644
index 000000000000..1b539677db20
--- /dev/null
+++ b/Documentation/kernel-hacking.rst
@@ -0,0 +1,795 @@
+============================================
+Unreliable Guide To Hacking The Linux Kernel
+============================================
+
+:Author: Rusty Russell
+
+Introduction
+============
+
+Welcome, gentle reader, to Rusty's Remarkably Unreliable Guide to Linux
+Kernel Hacking. This document describes the common routines and general
+requirements for kernel code: its goal is to serve as a primer for Linux
+kernel development for experienced C programmers. I avoid implementation
+details: that's what the code is for, and I ignore whole tracts of
+useful routines.
+
+Before you read this, please understand that I never wanted to write
+this document, being grossly under-qualified, but I always wanted to
+read it, and this was the only way. I hope it will grow into a
+compendium of best practice, common starting points and random
+information.
+
+The Players
+===========
+
+At any time each of the CPUs in a system can be:
+
+-  not associated with any process, serving a hardware interrupt;
+
+-  not associated with any process, serving a softirq or tasklet;
+
+-  running in kernel space, associated with a process (user context);
+
+-  running a process in user space.
+
+There is an ordering between these. The bottom two can preempt each
+other, but above that is a strict hierarchy: each can only be preempted
+by the ones above it. For example, while a softirq is running on a CPU,
+no other softirq will preempt it, but a hardware interrupt can. However,
+any other CPUs in the system execute independently.
+
+We'll see a number of ways that the user context can block interrupts,
+to become truly non-preemptable.
+
+User Context
+------------
+
+User context is when you are coming in from a system call or other trap:
+like userspace, you can be preempted by more important tasks and by
+interrupts. You can sleep, by calling :c:func:`schedule`.
+
+    **Note**
+
+    You are always in user context on module load and unload, and on
+    operations on the block device layer.
+
+In user context, the ``current`` pointer (indicating the task we are
+currently executing) is valid, and :c:func:`in_interrupt`
+(``include/linux/interrupt.h``) is false.
+
+    **Caution**
+
+    Beware that if you have preemption or softirqs disabled (see below),
+    :c:func:`in_interrupt` will return a false positive.
+
+Hardware Interrupts (Hard IRQs)
+-------------------------------
+
+Timer ticks, network cards and keyboard are examples of real hardware
+which produce interrupts at any time. The kernel runs interrupt
+handlers, which services the hardware. The kernel guarantees that this
+handler is never re-entered: if the same interrupt arrives, it is queued
+(or dropped). Because it disables interrupts, this handler has to be
+fast: frequently it simply acknowledges the interrupt, marks a 'software
+interrupt' for execution and exits.
+
+You can tell you are in a hardware interrupt, because
+:c:func:`in_irq` returns true.
+
+    **Caution**
+
+    Beware that this will return a false positive if interrupts are
+    disabled (see below).
+
+Software Interrupt Context: Softirqs and Tasklets
+-------------------------------------------------
+
+Whenever a system call is about to return to userspace, or a hardware
+interrupt handler exits, any 'software interrupts' which are marked
+pending (usually by hardware interrupts) are run (``kernel/softirq.c``).
+
+Much of the real interrupt handling work is done here. Early in the
+transition to SMP, there were only 'bottom halves' (BHs), which didn't
+take advantage of multiple CPUs. Shortly after we switched from wind-up
+computers made of match-sticks and snot, we abandoned this limitation
+and switched to 'softirqs'.
+
+``include/linux/interrupt.h`` lists the different softirqs. A very
+important softirq is the timer softirq (``include/linux/timer.h``): you
+can register to have it call functions for you in a given length of
+time.
+
+Softirqs are often a pain to deal with, since the same softirq will run
+simultaneously on more than one CPU. For this reason, tasklets
+(``include/linux/interrupt.h``) are more often used: they are
+dynamically-registrable (meaning you can have as many as you want), and
+they also guarantee that any tasklet will only run on one CPU at any
+time, although different tasklets can run simultaneously.
+
+    **Caution**
+
+    The name 'tasklet' is misleading: they have nothing to do with
+    'tasks', and probably more to do with some bad vodka Alexey
+    Kuznetsov had at the time.
+
+You can tell you are in a softirq (or tasklet) using the
+:c:func:`in_softirq` macro (``include/linux/interrupt.h``).
+
+    **Caution**
+
+    Beware that this will return a false positive if a bh lock (see
+    below) is held.
+
+Some Basic Rules
+================
+
+No memory protection
+    If you corrupt memory, whether in user context or interrupt context,
+    the whole machine will crash. Are you sure you can't do what you
+    want in userspace?
+
+No floating point or MMX
+    The FPU context is not saved; even in user context the FPU state
+    probably won't correspond with the current process: you would mess
+    with some user process' FPU state. If you really want to do this,
+    you would have to explicitly save/restore the full FPU state (and
+    avoid context switches). It is generally a bad idea; use fixed point
+    arithmetic first.
+
+A rigid stack limit
+    Depending on configuration options the kernel stack is about 3K to
+    6K for most 32-bit architectures: it's about 14K on most 64-bit
+    archs, and often shared with interrupts so you can't use it all.
+    Avoid deep recursion and huge local arrays on the stack (allocate
+    them dynamically instead).
+
+The Linux kernel is portable
+    Let's keep it that way. Your code should be 64-bit clean, and
+    endian-independent. You should also minimize CPU specific stuff,
+    e.g. inline assembly should be cleanly encapsulated and minimized to
+    ease porting. Generally it should be restricted to the
+    architecture-dependent part of the kernel tree.
+
+ioctls: Not writing a new system call
+=====================================
+
+A system call generally looks like this
+
+::
+
+    asmlinkage long sys_mycall(int arg)
+    {
+            return 0;
+    }
+
+
+First, in most cases you don't want to create a new system call. You
+create a character device and implement an appropriate ioctl for it.
+This is much more flexible than system calls, doesn't have to be entered
+in every architecture's ``include/asm/unistd.h`` and
+``arch/kernel/entry.S`` file, and is much more likely to be accepted by
+Linus.
+
+If all your routine does is read or write some parameter, consider
+implementing a :c:func:`sysfs` interface instead.
+
+Inside the ioctl you're in user context to a process. When a error
+occurs you return a negated errno (see ``include/linux/errno.h``),
+otherwise you return 0.
+
+After you slept you should check if a signal occurred: the Unix/Linux
+way of handling signals is to temporarily exit the system call with the
+``-ERESTARTSYS`` error. The system call entry code will switch back to
+user context, process the signal handler and then your system call will
+be restarted (unless the user disabled that). So you should be prepared
+to process the restart, e.g. if you're in the middle of manipulating
+some data structure.
+
+::
+
+    if (signal_pending(current))
+            return -ERESTARTSYS;
+
+
+If you're doing longer computations: first think userspace. If you
+*really* want to do it in kernel you should regularly check if you need
+to give up the CPU (remember there is cooperative multitasking per CPU).
+Idiom:
+
+::
+
+    cond_resched(); /* Will sleep */
+
+
+A short note on interface design: the UNIX system call motto is "Provide
+mechanism not policy".
+
+Recipes for Deadlock
+====================
+
+You cannot call any routines which may sleep, unless:
+
+-  You are in user context.
+
+-  You do not own any spinlocks.
+
+-  You have interrupts enabled (actually, Andi Kleen says that the
+   scheduling code will enable them for you, but that's probably not
+   what you wanted).
+
+Note that some functions may sleep implicitly: common ones are the user
+space access functions (\*_user) and memory allocation functions
+without ``GFP_ATOMIC``.
+
+You should always compile your kernel ``CONFIG_DEBUG_ATOMIC_SLEEP`` on,
+and it will warn you if you break these rules. If you *do* break the
+rules, you will eventually lock up your box.
+
+Really.
+
+Common Routines
+===============
+
+:c:func:`printk` ``include/linux/kernel.h``
+-----------------------------------------------
+
+:c:func:`printk` feeds kernel messages to the console, dmesg, and
+the syslog daemon. It is useful for debugging and reporting errors, and
+can be used inside interrupt context, but use with caution: a machine
+which has its console flooded with printk messages is unusable. It uses
+a format string mostly compatible with ANSI C printf, and C string
+concatenation to give it a first "priority" argument:
+
+::
+
+    printk(KERN_INFO "i = %u\n", i);
+
+
+See ``include/linux/kernel.h``; for other KERN_ values; these are
+interpreted by syslog as the level. Special case: for printing an IP
+address use
+
+::
+
+    __be32 ipaddress;
+    printk(KERN_INFO "my ip: %pI4\n", &ipaddress);
+
+
+:c:func:`printk` internally uses a 1K buffer and does not catch
+overruns. Make sure that will be enough.
+
+    **Note**
+
+    You will know when you are a real kernel hacker when you start
+    typoing printf as printk in your user programs :)
+
+    **Note**
+
+    Another sidenote: the original Unix Version 6 sources had a comment
+    on top of its printf function: "Printf should not be used for
+    chit-chat". You should follow that advice.
+
+:c:func:`copy_[to/from]_user` / :c:func:`get_user` / :c:func:`put_user` ``include/asm/uaccess.h``
+-----------------------------------------------------------------------------------------------------------------
+
+*[SLEEPS]*
+
+:c:func:`put_user` and :c:func:`get_user` are used to get and
+put single values (such as an int, char, or long) from and to userspace.
+A pointer into userspace should never be simply dereferenced: data
+should be copied using these routines. Both return ``-EFAULT`` or 0.
+
+:c:func:`copy_to_user` and :c:func:`copy_from_user` are more
+general: they copy an arbitrary amount of data to and from userspace.
+
+    **Caution**
+
+    Unlike :c:func:`put_user` and :c:func:`get_user`, they
+    return the amount of uncopied data (ie. 0 still means success).
+
+[Yes, this moronic interface makes me cringe. The flamewar comes up
+every year or so. --RR.]
+
+The functions may sleep implicitly. This should never be called outside
+user context (it makes no sense), with interrupts disabled, or a
+spinlock held.
+
+:c:func:`kmalloc`/:c:func:`kfree` ``include/linux/slab.h``
+------------------------------------------------------------------
+
+*[MAY SLEEP: SEE BELOW]*
+
+These routines are used to dynamically request pointer-aligned chunks of
+memory, like malloc and free do in userspace, but :c:func:`kmalloc`
+takes an extra flag word. Important values:
+
+``
+       GFP_KERNEL
+      ``
+    May sleep and swap to free memory. Only allowed in user context, but
+    is the most reliable way to allocate memory.
+
+``
+       GFP_ATOMIC
+      ``
+    Don't sleep. Less reliable than ``GFP_KERNEL``, but may be called
+    from interrupt context. You should *really* have a good
+    out-of-memory error-handling strategy.
+
+``
+       GFP_DMA
+      ``
+    Allocate ISA DMA lower than 16MB. If you don't know what that is you
+    don't need it. Very unreliable.
+
+If you see a sleeping function called from invalid context warning
+message, then maybe you called a sleeping allocation function from
+interrupt context without ``GFP_ATOMIC``. You should really fix that.
+Run, don't walk.
+
+If you are allocating at least ``PAGE_SIZE`` (``include/asm/page.h``)
+bytes, consider using :c:func:`__get_free_pages`
+(``include/linux/mm.h``). It takes an order argument (0 for page sized,
+1 for double page, 2 for four pages etc.) and the same memory priority
+flag word as above.
+
+If you are allocating more than a page worth of bytes you can use
+:c:func:`vmalloc`. It'll allocate virtual memory in the kernel map.
+This block is not contiguous in physical memory, but the MMU makes it
+look like it is for you (so it'll only look contiguous to the CPUs, not
+to external device drivers). If you really need large physically
+contiguous memory for some weird device, you have a problem: it is
+poorly supported in Linux because after some time memory fragmentation
+in a running kernel makes it hard. The best way is to allocate the block
+early in the boot process via the :c:func:`alloc_bootmem` routine.
+
+Before inventing your own cache of often-used objects consider using a
+slab cache in ``include/linux/slab.h``
+
+:c:func:`current` ``include/asm/current.h``
+-----------------------------------------------
+
+This global variable (really a macro) contains a pointer to the current
+task structure, so is only valid in user context. For example, when a
+process makes a system call, this will point to the task structure of
+the calling process. It is *not NULL* in interrupt context.
+
+:c:func:`mdelay`/:c:func:`udelay` ``include/asm/delay.h`` ``include/linux/delay.h``
+-------------------------------------------------------------------------------------------
+
+The :c:func:`udelay` and :c:func:`ndelay` functions can be used
+for small pauses. Do not use large values with them as you risk overflow
+- the helper function :c:func:`mdelay` is useful here, or consider
+:c:func:`msleep`.
+
+:c:func:`cpu_to_be32`/:c:func:`be32_to_cpu`/:c:func:`cpu_to_le32`/:c:func:`le32_to_cpu` ``include/asm/byteorder.h``
+-------------------------------------------------------------------------------------------------------------------------------------------
+
+The :c:func:`cpu_to_be32` family (where the "32" can be replaced
+by 64 or 16, and the "be" can be replaced by "le") are the general way
+to do endian conversions in the kernel: they return the converted value.
+All variations supply the reverse as well: :c:func:`be32_to_cpu`,
+etc.
+
+There are two major variations of these functions: the pointer
+variation, such as :c:func:`cpu_to_be32p`, which take a pointer to
+the given type, and return the converted value. The other variation is
+the "in-situ" family, such as :c:func:`cpu_to_be32s`, which
+convert value referred to by the pointer, and return void.
+
+:c:func:`local_irq_save`/:c:func:`local_irq_restore` ``include/linux/irqflags.h``
+---------------------------------------------------------------------------------------------
+
+These routines disable hard interrupts on the local CPU, and restore
+them. They are reentrant; saving the previous state in their one
+``unsigned long flags`` argument. If you know that interrupts are
+enabled, you can simply use :c:func:`local_irq_disable` and
+:c:func:`local_irq_enable`.
+
+:c:func:`local_bh_disable`/:c:func:`local_bh_enable` ``include/linux/interrupt.h``
+----------------------------------------------------------------------------------------------
+
+These routines disable soft interrupts on the local CPU, and restore
+them. They are reentrant; if soft interrupts were disabled before, they
+will still be disabled after this pair of functions has been called.
+They prevent softirqs and tasklets from running on the current CPU.
+
+:c:func:`smp_processor_id`() ``include/asm/smp.h``
+--------------------------------------------------------
+
+:c:func:`get_cpu` disables preemption (so you won't suddenly get
+moved to another CPU) and returns the current processor number, between
+0 and ``NR_CPUS``. Note that the CPU numbers are not necessarily
+continuous. You return it again with :c:func:`put_cpu` when you are
+done.
+
+If you know you cannot be preempted by another task (ie. you are in
+interrupt context, or have preemption disabled) you can use
+smp_processor_id().
+
+``__init``/``__exit``/``__initdata`` ``include/linux/init.h``
+-------------------------------------------------------------
+
+After boot, the kernel frees up a special section; functions marked with
+``__init`` and data structures marked with ``__initdata`` are dropped
+after boot is complete: similarly modules discard this memory after
+initialization. ``__exit`` is used to declare a function which is only
+required on exit: the function will be dropped if this file is not
+compiled as a module. See the header file for use. Note that it makes no
+sense for a function marked with ``__init`` to be exported to modules
+with :c:func:`EXPORT_SYMBOL` - this will break.
+
+:c:func:`__initcall`/:c:func:`module_init` ``include/linux/init.h``
+------------------------------------------------------------------------------
+
+Many parts of the kernel are well served as a module
+(dynamically-loadable parts of the kernel). Using the
+:c:func:`module_init` and :c:func:`module_exit` macros it is
+easy to write code without #ifdefs which can operate both as a module or
+built into the kernel.
+
+The :c:func:`module_init` macro defines which function is to be
+called at module insertion time (if the file is compiled as a module),
+or at boot time: if the file is not compiled as a module the
+:c:func:`module_init` macro becomes equivalent to
+:c:func:`__initcall`, which through linker magic ensures that the
+function is called on boot.
+
+The function can return a negative error number to cause module loading
+to fail (unfortunately, this has no effect if the module is compiled
+into the kernel). This function is called in user context with
+interrupts enabled, so it can sleep.
+
+:c:func:`module_exit` ``include/linux/init.h``
+---------------------------------------------------
+
+This macro defines the function to be called at module removal time (or
+never, in the case of the file compiled into the kernel). It will only
+be called if the module usage count has reached zero. This function can
+also sleep, but cannot fail: everything must be cleaned up by the time
+it returns.
+
+Note that this macro is optional: if it is not present, your module will
+not be removable (except for 'rmmod -f').
+
+:c:func:`try_module_get`/:c:func:`module_put` ``include/linux/module.h``
+-----------------------------------------------------------------------------------
+
+These manipulate the module usage count, to protect against removal (a
+module also can't be removed if another module uses one of its exported
+symbols: see below). Before calling into module code, you should call
+:c:func:`try_module_get` on that module: if it fails, then the
+module is being removed and you should act as if it wasn't there.
+Otherwise, you can safely enter the module, and call
+:c:func:`module_put` when you're finished.
+
+Most registerable structures have an owner field, such as in the
+:ref:`struct file_operations` structure. Set this field to the
+macro ``THIS_MODULE``.
+
+Wait Queues ``include/linux/wait.h``
+====================================
+
+*[SLEEPS]*
+
+A wait queue is used to wait for someone to wake you up when a certain
+condition is true. They must be used carefully to ensure there is no
+race condition. You declare a ``wait_queue_head_t``, and then processes
+which want to wait for that condition declare a ``wait_queue_t``
+referring to themselves, and place that in the queue.
+
+Declaring
+---------
+
+You declare a ``wait_queue_head_t`` using the
+:c:func:`DECLARE_WAIT_QUEUE_HEAD` macro, or using the
+:c:func:`init_waitqueue_head` routine in your initialization code.
+
+Queuing
+-------
+
+Placing yourself in the waitqueue is fairly complex, because you must
+put yourself in the queue before checking the condition. There is a
+macro to do this: :c:func:`wait_event_interruptible`
+``include/linux/wait.h`` The first argument is the wait queue head, and
+the second is an expression which is evaluated; the macro returns 0 when
+this expression is true, or -ERESTARTSYS if a signal is received. The
+:c:func:`wait_event` version ignores signals.
+
+Waking Up Queued Tasks
+----------------------
+
+Call :c:func:`wake_up` ``include/linux/wait.h``;, which will wake
+up every process in the queue. The exception is if one has
+``TASK_EXCLUSIVE`` set, in which case the remainder of the queue will
+not be woken. There are other variants of this basic function available
+in the same header.
+
+Atomic Operations
+=================
+
+Certain operations are guaranteed atomic on all platforms. The first
+class of operations work on ``atomic_t`` ``include/asm/atomic.h``; this
+contains a signed integer (at least 32 bits long), and you must use
+these functions to manipulate or read atomic_t variables.
+:c:func:`atomic_read` and :c:func:`atomic_set` get and set the
+counter, :c:func:`atomic_add`, :c:func:`atomic_sub`,
+:c:func:`atomic_inc`, :c:func:`atomic_dec`, and
+:c:func:`atomic_dec_and_test` (returns true if it was decremented
+to zero).
+
+Yes. It returns true (i.e. != 0) if the atomic variable is zero.
+
+Note that these functions are slower than normal arithmetic, and so
+should not be used unnecessarily.
+
+The second class of atomic operations is atomic bit operations on an
+``unsigned long``, defined in ``include/linux/bitops.h``. These
+operations generally take a pointer to the bit pattern, and a bit
+number: 0 is the least significant bit. :c:func:`set_bit`,
+:c:func:`clear_bit` and :c:func:`change_bit` set, clear, and
+flip the given bit. :c:func:`test_and_set_bit`,
+:c:func:`test_and_clear_bit` and
+:c:func:`test_and_change_bit` do the same thing, except return
+true if the bit was previously set; these are particularly useful for
+atomically setting flags.
+
+It is possible to call these operations with bit indices greater than
+BITS_PER_LONG. The resulting behavior is strange on big-endian
+platforms though so it is a good idea not to do this.
+
+Symbols
+=======
+
+Within the kernel proper, the normal linking rules apply (ie. unless a
+symbol is declared to be file scope with the ``static`` keyword, it can
+be used anywhere in the kernel). However, for modules, a special
+exported symbol table is kept which limits the entry points to the
+kernel proper. Modules can also export symbols.
+
+:c:func:`EXPORT_SYMBOL` ``include/linux/export.h``
+-------------------------------------------------------
+
+This is the classic method of exporting a symbol: dynamically loaded
+modules will be able to use the symbol as normal.
+
+:c:func:`EXPORT_SYMBOL_GPL` ``include/linux/export.h``
+------------------------------------------------------------
+
+Similar to :c:func:`EXPORT_SYMBOL` except that the symbols exported
+by :c:func:`EXPORT_SYMBOL_GPL` can only be seen by modules with a
+:c:func:`MODULE_LICENSE` that specifies a GPL compatible license.
+It implies that the function is considered an internal implementation
+issue, and not really an interface. Some maintainers and developers may
+however require EXPORT_SYMBOL_GPL() when adding any new APIs or
+functionality.
+
+Routines and Conventions
+========================
+
+Double-linked lists ``include/linux/list.h``
+--------------------------------------------
+
+There used to be three sets of linked-list routines in the kernel
+headers, but this one is the winner. If you don't have some particular
+pressing need for a single list, it's a good choice.
+
+In particular, :c:func:`list_for_each_entry` is useful.
+
+Return Conventions
+------------------
+
+For code called in user context, it's very common to defy C convention,
+and return 0 for success, and a negative error number (eg. -EFAULT) for
+failure. This can be unintuitive at first, but it's fairly widespread in
+the kernel.
+
+Using :c:func:`ERR_PTR` ``include/linux/err.h``; to encode a
+negative error number into a pointer, and :c:func:`IS_ERR` and
+:c:func:`PTR_ERR` to get it back out again: avoids a separate
+pointer parameter for the error number. Icky, but in a good way.
+
+Breaking Compilation
+--------------------
+
+Linus and the other developers sometimes change function or structure
+names in development kernels; this is not done just to keep everyone on
+their toes: it reflects a fundamental change (eg. can no longer be
+called with interrupts on, or does extra checks, or doesn't do checks
+which were caught before). Usually this is accompanied by a fairly
+complete note to the linux-kernel mailing list; search the archive.
+Simply doing a global replace on the file usually makes things *worse*.
+
+Initializing structure members
+------------------------------
+
+The preferred method of initializing structures is to use designated
+initialisers, as defined by ISO C99, eg:
+
+::
+
+    static struct block_device_operations opt_fops = {
+            .open               = opt_open,
+            .release            = opt_release,
+            .ioctl              = opt_ioctl,
+            .check_media_change = opt_media_change,
+    };
+
+
+This makes it easy to grep for, and makes it clear which structure
+fields are set. You should do this because it looks cool.
+
+GNU Extensions
+--------------
+
+GNU Extensions are explicitly allowed in the Linux kernel. Note that
+some of the more complex ones are not very well supported, due to lack
+of general use, but the following are considered standard (see the GCC
+info page section "C Extensions" for more details - Yes, really the info
+page, the man page is only a short summary of the stuff in info).
+
+-  Inline functions
+
+-  Statement expressions (ie. the ({ and }) constructs).
+
+-  Declaring attributes of a function / variable / type
+   (__attribute__)
+
+-  typeof
+
+-  Zero length arrays
+
+-  Macro varargs
+
+-  Arithmetic on void pointers
+
+-  Non-Constant initializers
+
+-  Assembler Instructions (not outside arch/ and include/asm/)
+
+-  Function names as strings (__func__).
+
+-  __builtin_constant_p()
+
+Be wary when using long long in the kernel, the code gcc generates for
+it is horrible and worse: division and multiplication does not work on
+i386 because the GCC runtime functions for it are missing from the
+kernel environment.
+
+C++
+---
+
+Using C++ in the kernel is usually a bad idea, because the kernel does
+not provide the necessary runtime environment and the include files are
+not tested for it. It is still possible, but not recommended. If you
+really want to do this, forget about exceptions at least.
+
+#if
+---
+
+It is generally considered cleaner to use macros in header files (or at
+the top of .c files) to abstract away functions rather than using \`#if'
+pre-processor statements throughout the source code.
+
+Putting Your Stuff in the Kernel
+================================
+
+In order to get your stuff into shape for official inclusion, or even to
+make a neat patch, there's administrative work to be done:
+
+-  Figure out whose pond you've been pissing in. Look at the top of the
+   source files, inside the ``MAINTAINERS`` file, and last of all in the
+   ``CREDITS`` file. You should coordinate with this person to make sure
+   you're not duplicating effort, or trying something that's already
+   been rejected.
+
+   Make sure you put your name and EMail address at the top of any files
+   you create or mangle significantly. This is the first place people
+   will look when they find a bug, or when *they* want to make a change.
+
+-  Usually you want a configuration option for your kernel hack. Edit
+   ``Kconfig`` in the appropriate directory. The Config language is
+   simple to use by cut and paste, and there's complete documentation in
+   ``Documentation/kbuild/kconfig-language.txt``.
+
+   In your description of the option, make sure you address both the
+   expert user and the user who knows nothing about your feature.
+   Mention incompatibilities and issues here. *Definitely* end your
+   description with “if in doubt, say N” (or, occasionally, \`Y'); this
+   is for people who have no idea what you are talking about.
+
+-  Edit the ``Makefile``: the CONFIG variables are exported here so you
+   can usually just add a "obj-$(CONFIG_xxx) += xxx.o" line. The syntax
+   is documented in ``Documentation/kbuild/makefiles.txt``.
+
+-  Put yourself in ``CREDITS`` if you've done something noteworthy,
+   usually beyond a single file (your name should be at the top of the
+   source files anyway). ``MAINTAINERS`` means you want to be consulted
+   when changes are made to a subsystem, and hear about bugs; it implies
+   a more-than-passing commitment to some part of the code.
+
+-  Finally, don't forget to read ``Documentation/SubmittingPatches`` and
+   possibly ``Documentation/SubmittingDrivers``.
+
+Kernel Cantrips
+===============
+
+Some favorites from browsing the source. Feel free to add to this list.
+
+``arch/x86/include/asm/delay.h:``
+
+::
+
+    #define ndelay(n) (__builtin_constant_p(n) ? \
+            ((n) > 20000 ? __bad_ndelay() : __const_udelay((n) * 5ul)) : \
+            __ndelay(n))
+
+
+``include/linux/fs.h``:
+
+::
+
+    /*
+     * Kernel pointers have redundant information, so we can use a
+     * scheme where we can return either an error code or a dentry
+     * pointer with the same return value.
+     *
+     * This should be a per-architecture thing, to allow different
+     * error and pointer decisions.
+     */
+     #define ERR_PTR(err)    ((void *)((long)(err)))
+     #define PTR_ERR(ptr)    ((long)(ptr))
+     #define IS_ERR(ptr)     ((unsigned long)(ptr) > (unsigned long)(-1000))
+
+``arch/x86/include/asm/uaccess_32.h:``
+
+::
+
+    #define copy_to_user(to,from,n)                         \
+            (__builtin_constant_p(n) ?                      \
+             __constant_copy_to_user((to),(from),(n)) :     \
+             __generic_copy_to_user((to),(from),(n)))
+
+
+``arch/sparc/kernel/head.S:``
+
+::
+
+    /*
+     * Sun people can't spell worth damn. "compatability" indeed.
+     * At least we *know* we can't spell, and use a spell-checker.
+     */
+
+    /* Uh, actually Linus it is I who cannot spell. Too much murky
+     * Sparc assembly will do this to ya.
+     */
+    C_LABEL(cputypvar):
+            .asciz "compatibility"
+
+    /* Tested on SS-5, SS-10. Probably someone at Sun applied a spell-checker. */
+            .align 4
+    C_LABEL(cputypvar_sun4m):
+            .asciz "compatible"
+
+
+``arch/sparc/lib/checksum.S:``
+
+::
+
+            /* Sun, you just can't beat me, you just can't.  Stop trying,
+             * give up.  I'm serious, I am going to kick the living shit
+             * out of you, game over, lights out.
+             */
+
+
+Thanks
+======
+
+Thanks to Andi Kleen for the idea, answering my questions, fixing my
+mistakes, filling content, etc. Philipp Rumpf for more spelling and
+clarity fixes, and some excellent non-obvious points. Werner Almesberger
+for giving me a great summary of :c:func:`disable_irq`, and Jes
+Sorensen and Andrea Arcangeli added caveats. Michael Elizabeth Chastain
+for checking and adding to the Configure section. Telsa Gwynne for
+teaching me DocBook.
-- 
2.1.4

[PATCH 09/10] Documentation: add kernel api rst

[Jani Nikula]

Crude conversion. This one uses kernel-doc.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
 Documentation/index.rst      |   1 +
 Documentation/kernel-api.rst | 419 +++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 420 insertions(+)
 create mode 100644 Documentation/kernel-api.rst

diff --git a/Documentation/index.rst b/Documentation/index.rst
index 1ed1c4e91c27..6ca68ef5c89a 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -16,6 +16,7 @@ Contents:
    :maxdepth: 2
 
    kernel-hacking
+   kernel-api
 
 Indices and tables
 ==================
diff --git a/Documentation/kernel-api.rst b/Documentation/kernel-api.rst
new file mode 100644
index 000000000000..ac24d8c2461f
--- /dev/null
+++ b/Documentation/kernel-api.rst
@@ -0,0 +1,419 @@
+====================
+The Linux Kernel API
+====================
+
+Data Types
+==========
+
+Doubly Linked Lists
+-------------------
+
+.. kernel-doc:: include/linux/list.h
+   :internal:
+
+Basic C Library Functions
+=========================
+
+When writing drivers, you cannot in general use routines which are from
+the C Library. Some of the functions have been found generally useful
+and they are listed below. The behaviour of these functions may vary
+slightly from those defined by ANSI, and these deviations are noted in
+the text.
+
+String Conversions
+------------------
+
+.. kernel-doc:: lib/vsprintf.c
+   :export:
+
+.. kernel-doc:: include/linux/kernel.h
+   :functions: kstrtol
+
+.. kernel-doc:: include/linux/kernel.h
+   :functions: kstrtoul
+
+.. kernel-doc:: lib/kstrtox.c
+   :export:
+
+String Manipulation
+-------------------
+
+.. kernel-doc:: lib/string.c
+   :export:
+
+Bit Operations
+--------------
+
+.. kernel-doc:: arch/x86/include/asm/bitops.h
+   :internal:
+
+Basic Kernel Library Functions
+==============================
+
+The Linux kernel provides more basic utility functions.
+
+Bitmap Operations
+-----------------
+
+.. kernel-doc:: lib/bitmap.c
+   :export:
+
+.. kernel-doc:: lib/bitmap.c
+   :internal:
+
+Command-line Parsing
+--------------------
+
+.. kernel-doc:: lib/cmdline.c
+   :export:
+
+CRC Functions
+-------------
+
+.. kernel-doc:: lib/crc7.c
+   :export:
+
+.. kernel-doc:: lib/crc16.c
+   :export:
+
+.. kernel-doc:: lib/crc-itu-t.c
+   :export:
+
+.. kernel-doc:: lib/crc32.c
+   :export:
+
+.. kernel-doc:: lib/crc-ccitt.c
+   :export:
+
+idr/ida Functions
+-----------------
+
+.. kernel-doc:: include/linux/idr.h
+   :doc: idr sync
+
+.. kernel-doc:: lib/idr.c
+   :doc: IDA description
+
+.. kernel-doc:: lib/idr.c
+   :export:
+
+Memory Management in Linux
+==========================
+
+The Slab Cache
+--------------
+
+.. kernel-doc:: include/linux/slab.h
+   :internal:
+
+.. kernel-doc:: mm/slab.c
+   :export:
+
+.. kernel-doc:: mm/util.c
+   :export:
+
+User Space Memory Access
+------------------------
+
+.. kernel-doc:: arch/x86/include/asm/uaccess_32.h
+   :internal:
+
+.. kernel-doc:: arch/x86/lib/usercopy_32.c
+   :export:
+
+More Memory Management Functions
+--------------------------------
+
+.. kernel-doc:: mm/readahead.c
+   :export:
+
+.. kernel-doc:: mm/filemap.c
+   :export:
+
+.. kernel-doc:: mm/memory.c
+   :export:
+
+.. kernel-doc:: mm/vmalloc.c
+   :export:
+
+.. kernel-doc:: mm/page_alloc.c
+   :internal:
+
+.. kernel-doc:: mm/mempool.c
+   :export:
+
+.. kernel-doc:: mm/dmapool.c
+   :export:
+
+.. kernel-doc:: mm/page-writeback.c
+   :export:
+
+.. kernel-doc:: mm/truncate.c
+   :export:
+
+Kernel IPC facilities
+=====================
+
+IPC utilities
+-------------
+
+.. kernel-doc:: ipc/util.c
+   :internal:
+
+FIFO Buffer
+===========
+
+kfifo interface
+---------------
+
+.. kernel-doc:: include/linux/kfifo.h
+   :internal:
+
+relay interface support
+=======================
+
+Relay interface support is designed to provide an efficient mechanism
+for tools and facilities to relay large amounts of data from kernel
+space to user space.
+
+relay interface
+---------------
+
+.. kernel-doc:: kernel/relay.c
+   :export:
+
+.. kernel-doc:: kernel/relay.c
+   :internal:
+
+Module Support
+==============
+
+Module Loading
+--------------
+
+.. kernel-doc:: kernel/kmod.c
+   :export:
+
+Inter Module support
+--------------------
+
+Refer to the file kernel/module.c for more information.
+
+Hardware Interfaces
+===================
+
+Interrupt Handling
+------------------
+
+.. kernel-doc:: kernel/irq/manage.c
+   :export:
+
+DMA Channels
+------------
+
+.. kernel-doc:: kernel/dma.c
+   :export:
+
+Resources Management
+--------------------
+
+.. kernel-doc:: kernel/resource.c
+   :internal:
+
+.. kernel-doc:: kernel/resource.c
+   :export:
+
+MTRR Handling
+-------------
+
+.. kernel-doc:: arch/x86/kernel/cpu/mtrr/main.c
+   :export:
+
+PCI Support Library
+-------------------
+
+.. kernel-doc:: drivers/pci/pci.c
+   :export:
+
+.. kernel-doc:: drivers/pci/pci-driver.c
+   :export:
+
+.. kernel-doc:: drivers/pci/remove.c
+   :export:
+
+.. kernel-doc:: drivers/pci/search.c
+   :export:
+
+.. kernel-doc:: drivers/pci/msi.c
+   :export:
+
+.. kernel-doc:: drivers/pci/bus.c
+   :export:
+
+.. kernel-doc:: drivers/pci/access.c
+   :export:
+
+.. kernel-doc:: drivers/pci/irq.c
+   :export:
+
+.. kernel-doc:: drivers/pci/htirq.c
+   :export:
+
+.. kernel-doc:: drivers/pci/probe.c
+   :export:
+
+.. kernel-doc:: drivers/pci/slot.c
+   :export:
+
+.. kernel-doc:: drivers/pci/rom.c
+   :export:
+
+.. kernel-doc:: drivers/pci/iov.c
+   :export:
+
+.. kernel-doc:: drivers/pci/pci-sysfs.c
+   :internal:
+
+PCI Hotplug Support Library
+---------------------------
+
+.. kernel-doc:: drivers/pci/hotplug/pci_hotplug_core.c
+   :export:
+
+Firmware Interfaces
+===================
+
+DMI Interfaces
+--------------
+
+.. kernel-doc:: drivers/firmware/dmi_scan.c
+   :export:
+
+EDD Interfaces
+--------------
+
+.. kernel-doc:: drivers/firmware/edd.c
+   :internal:
+
+Security Framework
+==================
+
+.. kernel-doc:: security/security.c
+   :internal:
+
+.. kernel-doc:: security/inode.c
+   :export:
+
+Audit Interfaces
+================
+
+.. kernel-doc:: kernel/audit.c
+   :export:
+
+.. kernel-doc:: kernel/auditsc.c
+   :internal:
+
+.. kernel-doc:: kernel/auditfilter.c
+   :internal:
+
+Accounting Framework
+====================
+
+.. kernel-doc:: kernel/acct.c
+   :internal:
+
+Block Devices
+=============
+
+.. kernel-doc:: block/blk-core.c
+   :export:
+
+.. kernel-doc:: block/blk-core.c
+   :internal:
+
+.. kernel-doc:: block/blk-map.c
+   :export:
+
+.. kernel-doc:: block/blk-sysfs.c
+   :internal:
+
+.. kernel-doc:: block/blk-settings.c
+   :export:
+
+.. kernel-doc:: block/blk-exec.c
+   :export:
+
+.. kernel-doc:: block/blk-flush.c
+   :export:
+
+.. kernel-doc:: block/blk-lib.c
+   :export:
+
+.. kernel-doc:: block/blk-tag.c
+   :export:
+
+.. kernel-doc:: block/blk-tag.c
+   :internal:
+
+.. kernel-doc:: block/blk-integrity.c
+   :export:
+
+.. kernel-doc:: kernel/trace/blktrace.c
+   :internal:
+
+.. kernel-doc:: block/genhd.c
+   :internal:
+
+.. kernel-doc:: block/genhd.c
+   :export:
+
+Char devices
+============
+
+.. kernel-doc:: fs/char_dev.c
+   :export:
+
+Miscellaneous Devices
+=====================
+
+.. kernel-doc:: drivers/char/misc.c
+   :export:
+
+Clock Framework
+===============
+
+The clock framework defines programming interfaces to support software
+management of the system clock tree. This framework is widely used with
+System-On-Chip (SOC) platforms to support power management and various
+devices which may need custom clock rates. Note that these "clocks"
+don't relate to timekeeping or real time clocks (RTCs), each of which
+have separate frameworks. These :ref:`struct clk` instances may be
+used to manage for example a 96 MHz signal that is used to shift bits
+into and out of peripherals or busses, or otherwise trigger synchronous
+state machine transitions in system hardware.
+
+Power management is supported by explicit software clock gating: unused
+clocks are disabled, so the system doesn't waste power changing the
+state of transistors that aren't in active use. On some systems this may
+be backed by hardware clock gating, where clocks are gated without being
+disabled in software. Sections of chips that are powered but not clocked
+may be able to retain their last state. This low power state is often
+called a *retention mode*. This mode still incurs leakage currents,
+especially with finer circuit geometries, but for CMOS circuits power is
+mostly used by clocked state changes.
+
+Power-aware drivers only enable their clocks when the device they manage
+is in active use. Also, system sleep states often differ according to
+which clock domains are active: while a "standby" state may allow wakeup
+from several active domains, a "mem" (suspend-to-RAM) state may require
+a more wholesale shutdown of clocks derived from higher speed PLLs and
+oscillators, limiting the number of possible wakeup event sources. A
+driver's suspend method may need to be aware of system-specific clock
+constraints on the target sleep state.
+
+Some platforms support programmable clock generators. These can be used
+by external chips of various kinds, such as other CPUs, multimedia
+codecs, and devices with strict requirements for interface clocking.
+
+.. kernel-doc:: include/linux/clk.h
+   :internal:
-- 
2.1.4

[PATCH 10/10] Documentation: moar files

[Jani Nikula]

Crude conversion. This has enough errors to break the pdf build.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
 Documentation/crypto-API.rst  | 1870 ++++++++++++++++++++++++++++++
 Documentation/filesystems.rst |  314 +++++
 Documentation/gpu.rst         | 2556 +++++++++++++++++++++++++++++++++++++++++
 Documentation/index.rst       |    3 +
 4 files changed, 4743 insertions(+)
 create mode 100644 Documentation/crypto-API.rst
 create mode 100644 Documentation/filesystems.rst
 create mode 100644 Documentation/gpu.rst

diff --git a/Documentation/crypto-API.rst b/Documentation/crypto-API.rst
new file mode 100644
index 000000000000..11853b0e6b41
--- /dev/null
+++ b/Documentation/crypto-API.rst
@@ -0,0 +1,1870 @@
+=======================
+Linux Kernel Crypto API
+=======================
+
+:Author: Stephan Mueller
+:Author: Marek Vasut
+
+Kernel Crypto API Interface Specification
+=========================================
+
+Introduction
+------------
+
+The kernel crypto API offers a rich set of cryptographic ciphers as well
+as other data transformation mechanisms and methods to invoke these.
+This document contains a description of the API and provides example
+code.
+
+To understand and properly use the kernel crypto API a brief explanation
+of its structure is given. Based on the architecture, the API can be
+separated into different components. Following the architecture
+specification, hints to developers of ciphers are provided. Pointers to
+the API function call documentation are given at the end.
+
+The kernel crypto API refers to all algorithms as "transformations".
+Therefore, a cipher handle variable usually has the name "tfm". Besides
+cryptographic operations, the kernel crypto API also knows compression
+transformations and handles them the same way as ciphers.
+
+The kernel crypto API serves the following entity types:
+
+-  consumers requesting cryptographic services
+
+-  data transformation implementations (typically ciphers) that can be
+   called by consumers using the kernel crypto API
+
+This specification is intended for consumers of the kernel crypto API as
+well as for developers implementing ciphers. This API specification,
+however, does not discuss all API calls available to data transformation
+implementations (i.e. implementations of ciphers and other
+transformations (such as CRC or even compression algorithms) that can
+register with the kernel crypto API).
+
+Note: The terms "transformation" and cipher algorithm are used
+interchangeably.
+
+Terminology
+-----------
+
+The transformation implementation is an actual code or interface to
+hardware which implements a certain transformation with precisely
+defined behavior.
+
+The transformation object (TFM) is an instance of a transformation
+implementation. There can be multiple transformation objects associated
+with a single transformation implementation. Each of those
+transformation objects is held by a crypto API consumer or another
+transformation. Transformation object is allocated when a crypto API
+consumer requests a transformation implementation. The consumer is then
+provided with a structure, which contains a transformation object (TFM).
+
+The structure that contains transformation objects may also be referred
+to as a "cipher handle". Such a cipher handle is always subject to the
+following phases that are reflected in the API calls applicable to such
+a cipher handle:
+
+1. Initialization of a cipher handle.
+
+2. Execution of all intended cipher operations applicable for the handle
+   where the cipher handle must be furnished to every API call.
+
+3. Destruction of a cipher handle.
+
+When using the initialization API calls, a cipher handle is created and
+returned to the consumer. Therefore, please refer to all initialization
+API calls that refer to the data structure type a consumer is expected
+to receive and subsequently to use. The initialization API calls have
+all the same naming conventions of crypto_alloc_\*.
+
+The transformation context is private data associated with the
+transformation object.
+
+Kernel Crypto API Architecture
+==============================
+
+Cipher algorithm types
+----------------------
+
+The kernel crypto API provides different API calls for the following
+cipher types:
+
+-  Symmetric ciphers
+
+-  AEAD ciphers
+
+-  Message digest, including keyed message digest
+
+-  Random number generation
+
+-  User space interface
+
+Ciphers And Templates
+---------------------
+
+The kernel crypto API provides implementations of single block ciphers
+and message digests. In addition, the kernel crypto API provides
+numerous "templates" that can be used in conjunction with the single
+block ciphers and message digests. Templates include all types of block
+chaining mode, the HMAC mechanism, etc.
+
+Single block ciphers and message digests can either be directly used by
+a caller or invoked together with a template to form multi-block ciphers
+or keyed message digests.
+
+A single block cipher may even be called with multiple templates.
+However, templates cannot be used without a single cipher.
+
+See /proc/crypto and search for "name". For example:
+
+-  aes
+
+-  ecb(aes)
+
+-  cmac(aes)
+
+-  ccm(aes)
+
+-  rfc4106(gcm(aes))
+
+-  sha1
+
+-  hmac(sha1)
+
+-  authenc(hmac(sha1),cbc(aes))
+
+In these examples, "aes" and "sha1" are the ciphers and all others are
+the templates.
+
+Synchronous And Asynchronous Operation
+--------------------------------------
+
+The kernel crypto API provides synchronous and asynchronous API
+operations.
+
+When using the synchronous API operation, the caller invokes a cipher
+operation which is performed synchronously by the kernel crypto API.
+That means, the caller waits until the cipher operation completes.
+Therefore, the kernel crypto API calls work like regular function calls.
+For synchronous operation, the set of API calls is small and
+conceptually similar to any other crypto library.
+
+Asynchronous operation is provided by the kernel crypto API which
+implies that the invocation of a cipher operation will complete almost
+instantly. That invocation triggers the cipher operation but it does not
+signal its completion. Before invoking a cipher operation, the caller
+must provide a callback function the kernel crypto API can invoke to
+signal the completion of the cipher operation. Furthermore, the caller
+must ensure it can handle such asynchronous events by applying
+appropriate locking around its data. The kernel crypto API does not
+perform any special serialization operation to protect the caller's data
+integrity.
+
+Crypto API Cipher References And Priority
+-----------------------------------------
+
+A cipher is referenced by the caller with a string. That string has the
+following semantics:
+
+::
+
+        template(single block cipher)
+
+
+where "template" and "single block cipher" is the aforementioned
+template and single block cipher, respectively. If applicable,
+additional templates may enclose other templates, such as
+
+::
+
+        template1(template2(single block cipher)))
+
+
+The kernel crypto API may provide multiple implementations of a template
+or a single block cipher. For example, AES on newer Intel hardware has
+the following implementations: AES-NI, assembler implementation, or
+straight C. Now, when using the string "aes" with the kernel crypto API,
+which cipher implementation is used? The answer to that question is the
+priority number assigned to each cipher implementation by the kernel
+crypto API. When a caller uses the string to refer to a cipher during
+initialization of a cipher handle, the kernel crypto API looks up all
+implementations providing an implementation with that name and selects
+the implementation with the highest priority.
+
+Now, a caller may have the need to refer to a specific cipher
+implementation and thus does not want to rely on the priority-based
+selection. To accommodate this scenario, the kernel crypto API allows
+the cipher implementation to register a unique name in addition to
+common names. When using that unique name, a caller is therefore always
+sure to refer to the intended cipher implementation.
+
+The list of available ciphers is given in /proc/crypto. However, that
+list does not specify all possible permutations of templates and
+ciphers. Each block listed in /proc/crypto may contain the following
+information -- if one of the components listed as follows are not
+applicable to a cipher, it is not displayed:
+
+-  name: the generic name of the cipher that is subject to the
+   priority-based selection -- this name can be used by the cipher
+   allocation API calls (all names listed above are examples for such
+   generic names)
+
+-  driver: the unique name of the cipher -- this name can be used by the
+   cipher allocation API calls
+
+-  module: the kernel module providing the cipher implementation (or
+   "kernel" for statically linked ciphers)
+
+-  priority: the priority value of the cipher implementation
+
+-  refcnt: the reference count of the respective cipher (i.e. the number
+   of current consumers of this cipher)
+
+-  selftest: specification whether the self test for the cipher passed
+
+-  type:
+
+   -  skcipher for symmetric key ciphers
+
+   -  cipher for single block ciphers that may be used with an
+      additional template
+
+   -  shash for synchronous message digest
+
+   -  ahash for asynchronous message digest
+
+   -  aead for AEAD cipher type
+
+   -  compression for compression type transformations
+
+   -  rng for random number generator
+
+   -  givcipher for cipher with associated IV generator (see the geniv
+      entry below for the specification of the IV generator type used by
+      the cipher implementation)
+
+-  blocksize: blocksize of cipher in bytes
+
+-  keysize: key size in bytes
+
+-  ivsize: IV size in bytes
+
+-  seedsize: required size of seed data for random number generator
+
+-  digestsize: output size of the message digest
+
+-  geniv: IV generation type:
+
+   -  eseqiv for encrypted sequence number based IV generation
+
+   -  seqiv for sequence number based IV generation
+
+   -  chainiv for chain iv generation
+
+   -  <builtin> is a marker that the cipher implements IV generation and
+      handling as it is specific to the given cipher
+
+Key Sizes
+---------
+
+When allocating a cipher handle, the caller only specifies the cipher
+type. Symmetric ciphers, however, typically support multiple key sizes
+(e.g. AES-128 vs. AES-192 vs. AES-256). These key sizes are determined
+with the length of the provided key. Thus, the kernel crypto API does
+not provide a separate way to select the particular symmetric cipher key
+size.
+
+Cipher Allocation Type And Masks
+--------------------------------
+
+The different cipher handle allocation functions allow the specification
+of a type and mask flag. Both parameters have the following meaning (and
+are therefore not covered in the subsequent sections).
+
+The type flag specifies the type of the cipher algorithm. The caller
+usually provides a 0 when the caller wants the default handling.
+Otherwise, the caller may provide the following selections which match
+the the aforementioned cipher types:
+
+-  CRYPTO_ALG_TYPE_CIPHER Single block cipher
+
+-  CRYPTO_ALG_TYPE_COMPRESS Compression
+
+-  CRYPTO_ALG_TYPE_AEAD Authenticated Encryption with Associated Data
+   (MAC)
+
+-  CRYPTO_ALG_TYPE_BLKCIPHER Synchronous multi-block cipher
+
+-  CRYPTO_ALG_TYPE_ABLKCIPHER Asynchronous multi-block cipher
+
+-  CRYPTO_ALG_TYPE_GIVCIPHER Asynchronous multi-block cipher packed
+   together with an IV generator (see geniv field in the /proc/crypto
+   listing for the known IV generators)
+
+-  CRYPTO_ALG_TYPE_DIGEST Raw message digest
+
+-  CRYPTO_ALG_TYPE_HASH Alias for CRYPTO_ALG_TYPE_DIGEST
+
+-  CRYPTO_ALG_TYPE_SHASH Synchronous multi-block hash
+
+-  CRYPTO_ALG_TYPE_AHASH Asynchronous multi-block hash
+
+-  CRYPTO_ALG_TYPE_RNG Random Number Generation
+
+-  CRYPTO_ALG_TYPE_AKCIPHER Asymmetric cipher
+
+-  CRYPTO_ALG_TYPE_PCOMPRESS Enhanced version of
+   CRYPTO_ALG_TYPE_COMPRESS allowing for segmented compression /
+   decompression instead of performing the operation on one segment
+   only. CRYPTO_ALG_TYPE_PCOMPRESS is intended to replace
+   CRYPTO_ALG_TYPE_COMPRESS once existing consumers are converted.
+
+The mask flag restricts the type of cipher. The only allowed flag is
+CRYPTO_ALG_ASYNC to restrict the cipher lookup function to
+asynchronous ciphers. Usually, a caller provides a 0 for the mask flag.
+
+When the caller provides a mask and type specification, the caller
+limits the search the kernel crypto API can perform for a suitable
+cipher implementation for the given cipher name. That means, even when a
+caller uses a cipher name that exists during its initialization call,
+the kernel crypto API may not select it due to the used type and mask
+field.
+
+Internal Structure of Kernel Crypto API
+---------------------------------------
+
+The kernel crypto API has an internal structure where a cipher
+implementation may use many layers and indirections. This section shall
+help to clarify how the kernel crypto API uses various components to
+implement the complete cipher.
+
+The following subsections explain the internal structure based on
+existing cipher implementations. The first section addresses the most
+complex scenario where all other scenarios form a logical subset.
+
+Generic AEAD Cipher Structure
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The following ASCII art decomposes the kernel crypto API layers when
+using the AEAD cipher with the automated IV generation. The shown
+example is used by the IPSEC layer.
+
+For other use cases of AEAD ciphers, the ASCII art applies as well, but
+the caller may not use the AEAD cipher with a separate IV generator. In
+this case, the caller must generate the IV.
+
+The depicted example decomposes the AEAD cipher of GCM(AES) based on the
+generic C implementations (gcm.c, aes-generic.c, ctr.c, ghash-generic.c,
+seqiv.c). The generic implementation serves as an example showing the
+complete logic of the kernel crypto API.
+
+It is possible that some streamlined cipher implementations (like
+AES-NI) provide implementations merging aspects which in the view of the
+kernel crypto API cannot be decomposed into layers any more. In case of
+the AES-NI implementation, the CTR mode, the GHASH implementation and
+the AES cipher are all merged into one cipher implementation registered
+with the kernel crypto API. In this case, the concept described by the
+following ASCII art applies too. However, the decomposition of GCM into
+the individual sub-components by the kernel crypto API is not done any
+more.
+
+Each block in the following ASCII art is an independent cipher instance
+obtained from the kernel crypto API. Each block is accessed by the
+caller or by other blocks using the API functions defined by the kernel
+crypto API for the cipher implementation type.
+
+The blocks below indicate the cipher type as well as the specific logic
+implemented in the cipher.
+
+The ASCII art picture also indicates the call structure, i.e. who calls
+which component. The arrows point to the invoked block where the caller
+uses the API applicable to the cipher type specified for the block.
+
+::
+
+
+    kernel crypto API                                |   IPSEC Layer
+                                                     |
+    +-----------+                                    |
+    |           |            (1)
+    |   aead    | <-----------------------------------  esp_output
+    |  (seqiv)  | ---+
+    +-----------+    |
+                     | (2)
+    +-----------+    |
+    |           | <--+                (2)
+    |   aead    | <-----------------------------------  esp_input
+    |   (gcm)   | ------------+
+    +-----------+             |
+          | (3)               | (5)
+          v                   v
+    +-----------+       +-----------+
+    |           |       |           |
+    |  skcipher |       |   ahash   |
+    |   (ctr)   | ---+  |  (ghash)  |
+    +-----------+    |  +-----------+
+                     |
+    +-----------+    | (4)
+    |           | <--+
+    |   cipher  |
+    |   (aes)   |
+    +-----------+
+
+
+
+The following call sequence is applicable when the IPSEC layer triggers
+an encryption operation with the esp_output function. During
+configuration, the administrator set up the use of rfc4106(gcm(aes)) as
+the cipher for ESP. The following call sequence is now depicted in the
+ASCII art above:
+
+1. esp_output() invokes crypto_aead_encrypt() to trigger an
+   encryption operation of the AEAD cipher with IV generator.
+
+   In case of GCM, the SEQIV implementation is registered as GIVCIPHER
+   in crypto_rfc4106_alloc().
+
+   The SEQIV performs its operation to generate an IV where the core
+   function is seqiv_geniv().
+
+2. Now, SEQIV uses the AEAD API function calls to invoke the associated
+   AEAD cipher. In our case, during the instantiation of SEQIV, the
+   cipher handle for GCM is provided to SEQIV. This means that SEQIV
+   invokes AEAD cipher operations with the GCM cipher handle.
+
+   During instantiation of the GCM handle, the CTR(AES) and GHASH
+   ciphers are instantiated. The cipher handles for CTR(AES) and GHASH
+   are retained for later use.
+
+   The GCM implementation is responsible to invoke the CTR mode AES and
+   the GHASH cipher in the right manner to implement the GCM
+   specification.
+
+3. The GCM AEAD cipher type implementation now invokes the SKCIPHER API
+   with the instantiated CTR(AES) cipher handle.
+
+   During instantiation of the CTR(AES) cipher, the CIPHER type
+   implementation of AES is instantiated. The cipher handle for AES is
+   retained.
+
+   That means that the SKCIPHER implementation of CTR(AES) only
+   implements the CTR block chaining mode. After performing the block
+   chaining operation, the CIPHER implementation of AES is invoked.
+
+4. The SKCIPHER of CTR(AES) now invokes the CIPHER API with the AES
+   cipher handle to encrypt one block.
+
+5. The GCM AEAD implementation also invokes the GHASH cipher
+   implementation via the AHASH API.
+
+When the IPSEC layer triggers the esp_input() function, the same call
+sequence is followed with the only difference that the operation starts
+with step (2).
+
+Generic Block Cipher Structure
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Generic block ciphers follow the same concept as depicted with the ASCII
+art picture above.
+
+For example, CBC(AES) is implemented with cbc.c, and aes-generic.c. The
+ASCII art picture above applies as well with the difference that only
+step (4) is used and the SKCIPHER block chaining mode is CBC.
+
+Generic Keyed Message Digest Structure
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Keyed message digest implementations again follow the same concept as
+depicted in the ASCII art picture above.
+
+For example, HMAC(SHA256) is implemented with hmac.c and
+sha256_generic.c. The following ASCII art illustrates the
+implementation:
+
+::
+
+
+    kernel crypto API            |       Caller
+                                 |
+    +-----------+         (1)    |
+    |           | <------------------  some_function
+    |   ahash   |
+    |   (hmac)  | ---+
+    +-----------+    |
+                     | (2)
+    +-----------+    |
+    |           | <--+
+    |   shash   |
+    |  (sha256) |
+    +-----------+
+
+
+
+The following call sequence is applicable when a caller triggers an HMAC
+operation:
+
+1. The AHASH API functions are invoked by the caller. The HMAC
+   implementation performs its operation as needed.
+
+   During initialization of the HMAC cipher, the SHASH cipher type of
+   SHA256 is instantiated. The cipher handle for the SHA256 instance is
+   retained.
+
+   At one time, the HMAC implementation requires a SHA256 operation
+   where the SHA256 cipher handle is used.
+
+2. The HMAC instance now invokes the SHASH API with the SHA256 cipher
+   handle to calculate the message digest.
+
+Developing Cipher Algorithms
+============================
+
+Registering And Unregistering Transformation
+--------------------------------------------
+
+There are three distinct types of registration functions in the Crypto
+API. One is used to register a generic cryptographic transformation,
+while the other two are specific to HASH transformations and
+COMPRESSion. We will discuss the latter two in a separate chapter, here
+we will only look at the generic ones.
+
+Before discussing the register functions, the data structure to be
+filled with each, struct crypto_alg, must be considered -- see below
+for a description of this data structure.
+
+The generic registration functions can be found in
+include/linux/crypto.h and their definition can be seen below. The
+former function registers a single transformation, while the latter
+works on an array of transformation descriptions. The latter is useful
+when registering transformations in bulk.
+
+::
+
+       int crypto_register_alg(struct crypto_alg *alg);
+       int crypto_register_algs(struct crypto_alg *algs, int count);
+
+
+The counterparts to those functions are listed below.
+
+::
+
+       int crypto_unregister_alg(struct crypto_alg *alg);
+       int crypto_unregister_algs(struct crypto_alg *algs, int count);
+
+
+Notice that both registration and unregistration functions do return a
+value, so make sure to handle errors. A return code of zero implies
+success. Any return code < 0 implies an error.
+
+The bulk registration / unregistration functions require that struct
+crypto_alg is an array of count size. These functions simply loop over
+that array and register / unregister each individual algorithm. If an
+error occurs, the loop is terminated at the offending algorithm
+definition. That means, the algorithms prior to the offending algorithm
+are successfully registered. Note, the caller has no way of knowing
+which cipher implementations have successfully registered. If this is
+important to know, the caller should loop through the different
+implementations using the single instance \*_alg functions for each
+individual implementation.
+
+Single-Block Symmetric Ciphers [CIPHER]
+---------------------------------------
+
+Example of transformations: aes, arc4, ...
+
+This section describes the simplest of all transformation
+implementations, that being the CIPHER type used for symmetric ciphers.
+The CIPHER type is used for transformations which operate on exactly one
+block at a time and there are no dependencies between blocks at all.
+
+Registration specifics
+~~~~~~~~~~~~~~~~~~~~~~
+
+The registration of [CIPHER] algorithm is specific in that struct
+crypto_alg field .cra_type is empty. The .cra_u.cipher has to be
+filled in with proper callbacks to implement this transformation.
+
+See struct cipher_alg below.
+
+Cipher Definition With struct cipher_alg
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Struct cipher_alg defines a single block cipher.
+
+Here are schematics of how these functions are called when operated from
+other part of the kernel. Note that the .cia_setkey() call might happen
+before or after any of these schematics happen, but must not happen
+during any of these are in-flight.
+
+::
+
+             KEY ---.    PLAINTEXT ---.
+                    v                 v
+              .cia_setkey() -> .cia_encrypt()
+                                      |
+                                      '-----> CIPHERTEXT
+
+
+Please note that a pattern where .cia_setkey() is called multiple times
+is also valid:
+
+::
+
+
+      KEY1 --.    PLAINTEXT1 --.         KEY2 --.    PLAINTEXT2 --.
+             v                 v                v                 v
+       .cia_setkey() -> .cia_encrypt() -> .cia_setkey() -> .cia_encrypt()
+                               |                                  |
+                               '---> CIPHERTEXT1                  '---> CIPHERTEXT2
+
+
+Multi-Block Ciphers
+-------------------
+
+Example of transformations: cbc(aes), ecb(arc4), ...
+
+This section describes the multi-block cipher transformation
+implementations. The multi-block ciphers are used for transformations
+which operate on scatterlists of data supplied to the transformation
+functions. They output the result into a scatterlist of data as well.
+
+Registration Specifics
+~~~~~~~~~~~~~~~~~~~~~~
+
+The registration of multi-block cipher algorithms is one of the most
+standard procedures throughout the crypto API.
+
+Note, if a cipher implementation requires a proper alignment of data,
+the caller should use the functions of crypto_skcipher_alignmask() to
+identify a memory alignment mask. The kernel crypto API is able to
+process requests that are unaligned. This implies, however, additional
+overhead as the kernel crypto API needs to perform the realignment of
+the data which may imply moving of data.
+
+Cipher Definition With struct blkcipher_alg and ablkcipher_alg
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Struct blkcipher_alg defines a synchronous block cipher whereas struct
+ablkcipher_alg defines an asynchronous block cipher.
+
+Please refer to the single block cipher description for schematics of
+the block cipher usage.
+
+Specifics Of Asynchronous Multi-Block Cipher
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+There are a couple of specifics to the asynchronous interface.
+
+First of all, some of the drivers will want to use the Generic
+ScatterWalk in case the hardware needs to be fed separate chunks of the
+scatterlist which contains the plaintext and will contain the
+ciphertext. Please refer to the ScatterWalk interface offered by the
+Linux kernel scatter / gather list implementation.
+
+Hashing [HASH]
+--------------
+
+Example of transformations: crc32, md5, sha1, sha256,...
+
+Registering And Unregistering The Transformation
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+There are multiple ways to register a HASH transformation, depending on
+whether the transformation is synchronous [SHASH] or asynchronous
+[AHASH] and the amount of HASH transformations we are registering. You
+can find the prototypes defined in include/crypto/internal/hash.h:
+
+::
+
+       int crypto_register_ahash(struct ahash_alg *alg);
+
+       int crypto_register_shash(struct shash_alg *alg);
+       int crypto_register_shashes(struct shash_alg *algs, int count);
+
+
+The respective counterparts for unregistering the HASH transformation
+are as follows:
+
+::
+
+       int crypto_unregister_ahash(struct ahash_alg *alg);
+
+       int crypto_unregister_shash(struct shash_alg *alg);
+       int crypto_unregister_shashes(struct shash_alg *algs, int count);
+
+
+Cipher Definition With struct shash_alg and ahash_alg
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Here are schematics of how these functions are called when operated from
+other part of the kernel. Note that the .setkey() call might happen
+before or after any of these schematics happen, but must not happen
+during any of these are in-flight. Please note that calling .init()
+followed immediately by .finish() is also a perfectly valid
+transformation.
+
+::
+
+       I)   DATA -----------.
+                            v
+             .init() -> .update() -> .final()      ! .update() might not be called
+                         ^    |         |            at all in this scenario.
+                         '----'         '---> HASH
+
+       II)  DATA -----------.-----------.
+                            v           v
+             .init() -> .update() -> .finup()      ! .update() may not be called
+                         ^    |         |            at all in this scenario.
+                         '----'         '---> HASH
+
+       III) DATA -----------.
+                            v
+                        .digest()                  ! The entire process is handled
+                            |                        by the .digest() call.
+                            '---------------> HASH
+
+
+Here is a schematic of how the .export()/.import() functions are called
+when used from another part of the kernel.
+
+::
+
+       KEY--.                 DATA--.
+            v                       v                  ! .update() may not be called
+        .setkey() -> .init() -> .update() -> .export()   at all in this scenario.
+                                 ^     |         |
+                                 '-----'         '--> PARTIAL_HASH
+
+       ----------- other transformations happen here -----------
+
+       PARTIAL_HASH--.   DATA1--.
+                     v          v
+                 .import -> .update() -> .final()     ! .update() may not be called
+                             ^    |         |           at all in this scenario.
+                             '----'         '--> HASH1
+
+       PARTIAL_HASH--.   DATA2-.
+                     v         v
+                 .import -> .finup()
+                               |
+                               '---------------> HASH2
+
+
+Specifics Of Asynchronous HASH Transformation
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Some of the drivers will want to use the Generic ScatterWalk in case the
+implementation needs to be fed separate chunks of the scatterlist which
+contains the input data. The buffer containing the resulting hash will
+always be properly aligned to .cra_alignmask so there is no need to
+worry about this.
+
+User Space Interface
+====================
+
+Introduction
+------------
+
+The concepts of the kernel crypto API visible to kernel space is fully
+applicable to the user space interface as well. Therefore, the kernel
+crypto API high level discussion for the in-kernel use cases applies
+here as well.
+
+The major difference, however, is that user space can only act as a
+consumer and never as a provider of a transformation or cipher
+algorithm.
+
+The following covers the user space interface exported by the kernel
+crypto API. A working example of this description is libkcapi that can
+be obtained from [1]. That library can be used by user space
+applications that require cryptographic services from the kernel.
+
+Some details of the in-kernel kernel crypto API aspects do not apply to
+user space, however. This includes the difference between synchronous
+and asynchronous invocations. The user space API call is fully
+synchronous.
+
+[1] http://www.chronox.de/libkcapi.html
+
+User Space API General Remarks
+------------------------------
+
+The kernel crypto API is accessible from user space. Currently, the
+following ciphers are accessible:
+
+-  Message digest including keyed message digest (HMAC, CMAC)
+
+-  Symmetric ciphers
+
+-  AEAD ciphers
+
+-  Random Number Generators
+
+The interface is provided via socket type using the type AF_ALG. In
+addition, the setsockopt option type is SOL_ALG. In case the user space
+header files do not export these flags yet, use the following macros:
+
+::
+
+    #ifndef AF_ALG
+    #define AF_ALG 38
+    #endif
+    #ifndef SOL_ALG
+    #define SOL_ALG 279
+    #endif
+
+
+A cipher is accessed with the same name as done for the in-kernel API
+calls. This includes the generic vs. unique naming schema for ciphers as
+well as the enforcement of priorities for generic names.
+
+To interact with the kernel crypto API, a socket must be created by the
+user space application. User space invokes the cipher operation with the
+send()/write() system call family. The result of the cipher operation is
+obtained with the read()/recv() system call family.
+
+The following API calls assume that the socket descriptor is already
+opened by the user space application and discusses only the kernel
+crypto API specific invocations.
+
+To initialize the socket interface, the following sequence has to be
+performed by the consumer:
+
+1. Create a socket of type AF_ALG with the struct sockaddr_alg
+   parameter specified below for the different cipher types.
+
+2. Invoke bind with the socket descriptor
+
+3. Invoke accept with the socket descriptor. The accept system call
+   returns a new file descriptor that is to be used to interact with the
+   particular cipher instance. When invoking send/write or recv/read
+   system calls to send data to the kernel or obtain data from the
+   kernel, the file descriptor returned by accept must be used.
+
+In-place Cipher operation
+-------------------------
+
+Just like the in-kernel operation of the kernel crypto API, the user
+space interface allows the cipher operation in-place. That means that
+the input buffer used for the send/write system call and the output
+buffer used by the read/recv system call may be one and the same. This
+is of particular interest for symmetric cipher operations where a
+copying of the output data to its final destination can be avoided.
+
+If a consumer on the other hand wants to maintain the plaintext and the
+ciphertext in different memory locations, all a consumer needs to do is
+to provide different memory pointers for the encryption and decryption
+operation.
+
+Message Digest API
+------------------
+
+The message digest type to be used for the cipher operation is selected
+when invoking the bind syscall. bind requires the caller to provide a
+filled struct sockaddr data structure. This data structure must be
+filled as follows:
+
+::
+
+    struct sockaddr_alg sa = {
+        .salg_family = AF_ALG,
+        .salg_type = "hash", /* this selects the hash logic in the kernel */
+        .salg_name = "sha1" /* this is the cipher name */
+    };
+
+
+The salg_type value "hash" applies to message digests and keyed message
+digests. Though, a keyed message digest is referenced by the appropriate
+salg_name. Please see below for the setsockopt interface that explains
+how the key can be set for a keyed message digest.
+
+Using the send() system call, the application provides the data that
+should be processed with the message digest. The send system call allows
+the following flags to be specified:
+
+-  MSG_MORE: If this flag is set, the send system call acts like a
+   message digest update function where the final hash is not yet
+   calculated. If the flag is not set, the send system call calculates
+   the final message digest immediately.
+
+With the recv() system call, the application can read the message digest
+from the kernel crypto API. If the buffer is too small for the message
+digest, the flag MSG_TRUNC is set by the kernel.
+
+In order to set a message digest key, the calling application must use
+the setsockopt() option of ALG_SET_KEY. If the key is not set the HMAC
+operation is performed without the initial HMAC state change caused by
+the key.
+
+Symmetric Cipher API
+--------------------
+
+The operation is very similar to the message digest discussion. During
+initialization, the struct sockaddr data structure must be filled as
+follows:
+
+::
+
+    struct sockaddr_alg sa = {
+        .salg_family = AF_ALG,
+        .salg_type = "skcipher", /* this selects the symmetric cipher */
+        .salg_name = "cbc(aes)" /* this is the cipher name */
+    };
+
+
+Before data can be sent to the kernel using the write/send system call
+family, the consumer must set the key. The key setting is described with
+the setsockopt invocation below.
+
+Using the sendmsg() system call, the application provides the data that
+should be processed for encryption or decryption. In addition, the IV is
+specified with the data structure provided by the sendmsg() system call.
+
+The sendmsg system call parameter of struct msghdr is embedded into the
+struct cmsghdr data structure. See recv(2) and cmsg(3) for more
+information on how the cmsghdr data structure is used together with the
+send/recv system call family. That cmsghdr data structure holds the
+following information specified with a separate header instances:
+
+-  specification of the cipher operation type with one of these flags:
+
+   -  ALG_OP_ENCRYPT - encryption of data
+
+   -  ALG_OP_DECRYPT - decryption of data
+
+-  specification of the IV information marked with the flag ALG_SET_IV
+
+The send system call family allows the following flag to be specified:
+
+-  MSG_MORE: If this flag is set, the send system call acts like a
+   cipher update function where more input data is expected with a
+   subsequent invocation of the send system call.
+
+Note: The kernel reports -EINVAL for any unexpected data. The caller
+must make sure that all data matches the constraints given in
+/proc/crypto for the selected cipher.
+
+With the recv() system call, the application can read the result of the
+cipher operation from the kernel crypto API. The output buffer must be
+at least as large as to hold all blocks of the encrypted or decrypted
+data. If the output data size is smaller, only as many blocks are
+returned that fit into that output buffer size.
+
+AEAD Cipher API
+---------------
+
+The operation is very similar to the symmetric cipher discussion. During
+initialization, the struct sockaddr data structure must be filled as
+follows:
+
+::
+
+    struct sockaddr_alg sa = {
+        .salg_family = AF_ALG,
+        .salg_type = "aead", /* this selects the symmetric cipher */
+        .salg_name = "gcm(aes)" /* this is the cipher name */
+    };
+
+
+Before data can be sent to the kernel using the write/send system call
+family, the consumer must set the key. The key setting is described with
+the setsockopt invocation below.
+
+In addition, before data can be sent to the kernel using the write/send
+system call family, the consumer must set the authentication tag size.
+To set the authentication tag size, the caller must use the setsockopt
+invocation described below.
+
+Using the sendmsg() system call, the application provides the data that
+should be processed for encryption or decryption. In addition, the IV is
+specified with the data structure provided by the sendmsg() system call.
+
+The sendmsg system call parameter of struct msghdr is embedded into the
+struct cmsghdr data structure. See recv(2) and cmsg(3) for more
+information on how the cmsghdr data structure is used together with the
+send/recv system call family. That cmsghdr data structure holds the
+following information specified with a separate header instances:
+
+-  specification of the cipher operation type with one of these flags:
+
+   -  ALG_OP_ENCRYPT - encryption of data
+
+   -  ALG_OP_DECRYPT - decryption of data
+
+-  specification of the IV information marked with the flag ALG_SET_IV
+
+-  specification of the associated authentication data (AAD) with the
+   flag ALG_SET_AEAD_ASSOCLEN. The AAD is sent to the kernel together
+   with the plaintext / ciphertext. See below for the memory structure.
+
+The send system call family allows the following flag to be specified:
+
+-  MSG_MORE: If this flag is set, the send system call acts like a
+   cipher update function where more input data is expected with a
+   subsequent invocation of the send system call.
+
+Note: The kernel reports -EINVAL for any unexpected data. The caller
+must make sure that all data matches the constraints given in
+/proc/crypto for the selected cipher.
+
+With the recv() system call, the application can read the result of the
+cipher operation from the kernel crypto API. The output buffer must be
+at least as large as defined with the memory structure below. If the
+output data size is smaller, the cipher operation is not performed.
+
+The authenticated decryption operation may indicate an integrity error.
+Such breach in integrity is marked with the -EBADMSG error code.
+
+AEAD Memory Structure
+~~~~~~~~~~~~~~~~~~~~~
+
+The AEAD cipher operates with the following information that is
+communicated between user and kernel space as one data stream:
+
+-  plaintext or ciphertext
+
+-  associated authentication data (AAD)
+
+-  authentication tag
+
+The sizes of the AAD and the authentication tag are provided with the
+sendmsg and setsockopt calls (see there). As the kernel knows the size
+of the entire data stream, the kernel is now able to calculate the right
+offsets of the data components in the data stream.
+
+The user space caller must arrange the aforementioned information in the
+following order:
+
+-  AEAD encryption input: AAD \|\| plaintext
+
+-  AEAD decryption input: AAD \|\| ciphertext \|\| authentication tag
+
+The output buffer the user space caller provides must be at least as
+large to hold the following data:
+
+-  AEAD encryption output: ciphertext \|\| authentication tag
+
+-  AEAD decryption output: plaintext
+
+Random Number Generator API
+---------------------------
+
+Again, the operation is very similar to the other APIs. During
+initialization, the struct sockaddr data structure must be filled as
+follows:
+
+::
+
+    struct sockaddr_alg sa = {
+        .salg_family = AF_ALG,
+        .salg_type = "rng", /* this selects the symmetric cipher */
+        .salg_name = "drbg_nopr_sha256" /* this is the cipher name */
+    };
+
+
+Depending on the RNG type, the RNG must be seeded. The seed is provided
+using the setsockopt interface to set the key. For example, the
+ansi_cprng requires a seed. The DRBGs do not require a seed, but may be
+seeded.
+
+Using the read()/recvmsg() system calls, random numbers can be obtained.
+The kernel generates at most 128 bytes in one call. If user space
+requires more data, multiple calls to read()/recvmsg() must be made.
+
+WARNING: The user space caller may invoke the initially mentioned accept
+system call multiple times. In this case, the returned file descriptors
+have the same state.
+
+Zero-Copy Interface
+-------------------
+
+In addition to the send/write/read/recv system call family, the AF_ALG
+interface can be accessed with the zero-copy interface of
+splice/vmsplice. As the name indicates, the kernel tries to avoid a copy
+operation into kernel space.
+
+The zero-copy operation requires data to be aligned at the page
+boundary. Non-aligned data can be used as well, but may require more
+operations of the kernel which would defeat the speed gains obtained
+from the zero-copy interface.
+
+The system-interent limit for the size of one zero-copy operation is 16
+pages. If more data is to be sent to AF_ALG, user space must slice the
+input into segments with a maximum size of 16 pages.
+
+Zero-copy can be used with the following code example (a complete
+working example is provided with libkcapi):
+
+::
+
+    int pipes[2];
+
+    pipe(pipes);
+    /* input data in iov */
+    vmsplice(pipes[1], iov, iovlen, SPLICE_F_GIFT);
+    /* opfd is the file descriptor returned from accept() system call */
+    splice(pipes[0], NULL, opfd, NULL, ret, 0);
+    read(opfd, out, outlen);
+
+
+Setsockopt Interface
+--------------------
+
+In addition to the read/recv and send/write system call handling to send
+and retrieve data subject to the cipher operation, a consumer also needs
+to set the additional information for the cipher operation. This
+additional information is set using the setsockopt system call that must
+be invoked with the file descriptor of the open cipher (i.e. the file
+descriptor returned by the accept system call).
+
+Each setsockopt invocation must use the level SOL_ALG.
+
+The setsockopt interface allows setting the following data using the
+mentioned optname:
+
+-  ALG_SET_KEY -- Setting the key. Key setting is applicable to:
+
+   -  the skcipher cipher type (symmetric ciphers)
+
+   -  the hash cipher type (keyed message digests)
+
+   -  the AEAD cipher type
+
+   -  the RNG cipher type to provide the seed
+
+-  ALG_SET_AEAD_AUTHSIZE -- Setting the authentication tag size for
+   AEAD ciphers. For a encryption operation, the authentication tag of
+   the given size will be generated. For a decryption operation, the
+   provided ciphertext is assumed to contain an authentication tag of
+   the given size (see section about AEAD memory layout below).
+
+User space API example
+----------------------
+
+Please see [1] for libkcapi which provides an easy-to-use wrapper around
+the aforementioned Netlink kernel interface. [1] also contains a test
+application that invokes all libkcapi API calls.
+
+[1] http://www.chronox.de/libkcapi.html
+
+Programming Interface
+=====================
+
+Please note that the kernel crypto API contains the AEAD givcrypt API
+(crypto_aead_giv\* and aead_givcrypt_\* function calls in
+include/crypto/aead.h). This API is obsolete and will be removed in the
+future. To obtain the functionality of an AEAD cipher with internal IV
+generation, use the IV generator as a regular cipher. For example,
+rfc4106(gcm(aes)) is the AEAD cipher with external IV generation and
+seqniv(rfc4106(gcm(aes))) implies that the kernel crypto API generates
+the IV. Different IV generators are available.
+
+Block Cipher Context Data Structures
+------------------------------------
+
+.. kernel-doc:: include/linux/crypto.h
+   :doc: Block Cipher Context Data Structures
+
+.. kernel-doc:: include/crypto/aead.h
+   :functions: aead_request
+
+Block Cipher Algorithm Definitions
+----------------------------------
+
+.. kernel-doc:: include/linux/crypto.h
+   :doc: Block Cipher Algorithm Definitions
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: crypto_alg
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: ablkcipher_alg
+
+.. kernel-doc:: include/crypto/aead.h
+   :functions: aead_alg
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: blkcipher_alg
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: cipher_alg
+
+.. kernel-doc:: include/crypto/rng.h
+   :functions: rng_alg
+
+Symmetric Key Cipher API
+------------------------
+
+.. kernel-doc:: include/crypto/skcipher.h
+   :doc: Symmetric Key Cipher API
+
+.. kernel-doc:: include/crypto/skcipher.h
+   :functions: crypto_alloc_skcipher
+
+.. kernel-doc:: include/crypto/skcipher.h
+   :functions: crypto_free_skcipher
+
+.. kernel-doc:: include/crypto/skcipher.h
+   :functions: crypto_has_skcipher
+
+.. kernel-doc:: include/crypto/skcipher.h
+   :functions: crypto_skcipher_ivsize
+
+.. kernel-doc:: include/crypto/skcipher.h
+   :functions: crypto_skcipher_blocksize
+
+.. kernel-doc:: include/crypto/skcipher.h
+   :functions: crypto_skcipher_setkey
+
+.. kernel-doc:: include/crypto/skcipher.h
+   :functions: crypto_skcipher_reqtfm
+
+.. kernel-doc:: include/crypto/skcipher.h
+   :functions: crypto_skcipher_encrypt
+
+.. kernel-doc:: include/crypto/skcipher.h
+   :functions: crypto_skcipher_decrypt
+
+Symmetric Key Cipher Request Handle
+-----------------------------------
+
+.. kernel-doc:: include/crypto/skcipher.h
+   :doc: Symmetric Key Cipher Request Handle
+
+.. kernel-doc:: include/crypto/skcipher.h
+   :functions: crypto_skcipher_reqsize
+
+.. kernel-doc:: include/crypto/skcipher.h
+   :functions: skcipher_request_set_tfm
+
+.. kernel-doc:: include/crypto/skcipher.h
+   :functions: skcipher_request_alloc
+
+.. kernel-doc:: include/crypto/skcipher.h
+   :functions: skcipher_request_free
+
+.. kernel-doc:: include/crypto/skcipher.h
+   :functions: skcipher_request_set_callback
+
+.. kernel-doc:: include/crypto/skcipher.h
+   :functions: skcipher_request_set_crypt
+
+Asynchronous Block Cipher API - Deprecated
+------------------------------------------
+
+.. kernel-doc:: include/linux/crypto.h
+   :doc: Asynchronous Block Cipher API
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: crypto_alloc_ablkcipher
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: crypto_free_ablkcipher
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: crypto_has_ablkcipher
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: crypto_ablkcipher_ivsize
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: crypto_ablkcipher_blocksize
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: crypto_ablkcipher_setkey
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: crypto_ablkcipher_reqtfm
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: crypto_ablkcipher_encrypt
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: crypto_ablkcipher_decrypt
+
+Asynchronous Cipher Request Handle - Deprecated
+-----------------------------------------------
+
+.. kernel-doc:: include/linux/crypto.h
+   :doc: Asynchronous Cipher Request Handle
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: crypto_ablkcipher_reqsize
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: ablkcipher_request_set_tfm
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: ablkcipher_request_alloc
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: ablkcipher_request_free
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: ablkcipher_request_set_callback
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: ablkcipher_request_set_crypt
+
+Authenticated Encryption With Associated Data (AEAD) Cipher API
+---------------------------------------------------------------
+
+.. kernel-doc:: include/crypto/aead.h
+   :doc: Authenticated Encryption With Associated Data (AEAD) Cipher API
+
+.. kernel-doc:: include/crypto/aead.h
+   :functions: crypto_alloc_aead
+
+.. kernel-doc:: include/crypto/aead.h
+   :functions: crypto_free_aead
+
+.. kernel-doc:: include/crypto/aead.h
+   :functions: crypto_aead_ivsize
+
+.. kernel-doc:: include/crypto/aead.h
+   :functions: crypto_aead_authsize
+
+.. kernel-doc:: include/crypto/aead.h
+   :functions: crypto_aead_blocksize
+
+.. kernel-doc:: include/crypto/aead.h
+   :functions: crypto_aead_setkey
+
+.. kernel-doc:: include/crypto/aead.h
+   :functions: crypto_aead_setauthsize
+
+.. kernel-doc:: include/crypto/aead.h
+   :functions: crypto_aead_encrypt
+
+.. kernel-doc:: include/crypto/aead.h
+   :functions: crypto_aead_decrypt
+
+Asynchronous AEAD Request Handle
+--------------------------------
+
+.. kernel-doc:: include/crypto/aead.h
+   :doc: Asynchronous AEAD Request Handle
+
+.. kernel-doc:: include/crypto/aead.h
+   :functions: crypto_aead_reqsize
+
+.. kernel-doc:: include/crypto/aead.h
+   :functions: aead_request_set_tfm
+
+.. kernel-doc:: include/crypto/aead.h
+   :functions: aead_request_alloc
+
+.. kernel-doc:: include/crypto/aead.h
+   :functions: aead_request_free
+
+.. kernel-doc:: include/crypto/aead.h
+   :functions: aead_request_set_callback
+
+.. kernel-doc:: include/crypto/aead.h
+   :functions: aead_request_set_crypt
+
+.. kernel-doc:: include/crypto/aead.h
+   :functions: aead_request_set_ad
+
+Synchronous Block Cipher API - Deprecated
+-----------------------------------------
+
+.. kernel-doc:: include/linux/crypto.h
+   :doc: Synchronous Block Cipher API
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: crypto_alloc_blkcipher
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: crypto_free_blkcipher
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: crypto_has_blkcipher
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: crypto_blkcipher_name
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: crypto_blkcipher_ivsize
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: crypto_blkcipher_blocksize
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: crypto_blkcipher_setkey
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: crypto_blkcipher_encrypt
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: crypto_blkcipher_encrypt_iv
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: crypto_blkcipher_decrypt
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: crypto_blkcipher_decrypt_iv
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: crypto_blkcipher_set_iv
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: crypto_blkcipher_get_iv
+
+Single Block Cipher API
+-----------------------
+
+.. kernel-doc:: include/linux/crypto.h
+   :doc: Single Block Cipher API
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: crypto_alloc_cipher
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: crypto_free_cipher
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: crypto_has_cipher
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: crypto_cipher_blocksize
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: crypto_cipher_setkey
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: crypto_cipher_encrypt_one
+
+.. kernel-doc:: include/linux/crypto.h
+   :functions: crypto_cipher_decrypt_one
+
+Message Digest Algorithm Definitions
+------------------------------------
+
+.. kernel-doc:: include/crypto/hash.h
+   :doc: Message Digest Algorithm Definitions
+
+.. kernel-doc:: include/crypto/hash.h
+   :functions: hash_alg_common
+
+.. kernel-doc:: include/crypto/hash.h
+   :functions: ahash_alg
+
+.. kernel-doc:: include/crypto/hash.h
+   :functions: shash_alg
+
+Asynchronous Message Digest API
+-------------------------------
+
+.. kernel-doc:: include/crypto/hash.h
+   :doc: Asynchronous Message Digest API
+
+.. kernel-doc:: include/crypto/hash.h
+   :functions: crypto_alloc_ahash
+
+.. kernel-doc:: include/crypto/hash.h
+   :functions: crypto_free_ahash
+
+.. kernel-doc:: include/crypto/hash.h
+   :functions: crypto_ahash_init
+
+.. kernel-doc:: include/crypto/hash.h
+   :functions: crypto_ahash_digestsize
+
+.. kernel-doc:: include/crypto/hash.h
+   :functions: crypto_ahash_reqtfm
+
+.. kernel-doc:: include/crypto/hash.h
+   :functions: crypto_ahash_reqsize
+
+.. kernel-doc:: include/crypto/hash.h
+   :functions: crypto_ahash_setkey
+
+.. kernel-doc:: include/crypto/hash.h
+   :functions: crypto_ahash_finup
+
+.. kernel-doc:: include/crypto/hash.h
+   :functions: crypto_ahash_final
+
+.. kernel-doc:: include/crypto/hash.h
+   :functions: crypto_ahash_digest
+
+.. kernel-doc:: include/crypto/hash.h
+   :functions: crypto_ahash_export
+
+.. kernel-doc:: include/crypto/hash.h
+   :functions: crypto_ahash_import
+
+Asynchronous Hash Request Handle
+--------------------------------
+
+.. kernel-doc:: include/crypto/hash.h
+   :doc: Asynchronous Hash Request Handle
+
+.. kernel-doc:: include/crypto/hash.h
+   :functions: ahash_request_set_tfm
+
+.. kernel-doc:: include/crypto/hash.h
+   :functions: ahash_request_alloc
+
+.. kernel-doc:: include/crypto/hash.h
+   :functions: ahash_request_free
+
+.. kernel-doc:: include/crypto/hash.h
+   :functions: ahash_request_set_callback
+
+.. kernel-doc:: include/crypto/hash.h
+   :functions: ahash_request_set_crypt
+
+Synchronous Message Digest API
+------------------------------
+
+.. kernel-doc:: include/crypto/hash.h
+   :doc: Synchronous Message Digest API
+
+.. kernel-doc:: include/crypto/hash.h
+   :functions: crypto_alloc_shash
+
+.. kernel-doc:: include/crypto/hash.h
+   :functions: crypto_free_shash
+
+.. kernel-doc:: include/crypto/hash.h
+   :functions: crypto_shash_blocksize
+
+.. kernel-doc:: include/crypto/hash.h
+   :functions: crypto_shash_digestsize
+
+.. kernel-doc:: include/crypto/hash.h
+   :functions: crypto_shash_descsize
+
+.. kernel-doc:: include/crypto/hash.h
+   :functions: crypto_shash_setkey
+
+.. kernel-doc:: include/crypto/hash.h
+   :functions: crypto_shash_digest
+
+.. kernel-doc:: include/crypto/hash.h
+   :functions: crypto_shash_export
+
+.. kernel-doc:: include/crypto/hash.h
+   :functions: crypto_shash_import
+
+.. kernel-doc:: include/crypto/hash.h
+   :functions: crypto_shash_init
+
+.. kernel-doc:: include/crypto/hash.h
+   :functions: crypto_shash_update
+
+.. kernel-doc:: include/crypto/hash.h
+   :functions: crypto_shash_final
+
+.. kernel-doc:: include/crypto/hash.h
+   :functions: crypto_shash_finup
+
+Crypto API Random Number API
+----------------------------
+
+.. kernel-doc:: include/crypto/rng.h
+   :doc: Random number generator API
+
+.. kernel-doc:: include/crypto/rng.h
+   :functions: crypto_alloc_rng
+
+.. kernel-doc:: include/crypto/rng.h
+   :functions: crypto_rng_alg
+
+.. kernel-doc:: include/crypto/rng.h
+   :functions: crypto_free_rng
+
+.. kernel-doc:: include/crypto/rng.h
+   :functions: crypto_rng_generate
+
+.. kernel-doc:: include/crypto/rng.h
+   :functions: crypto_rng_get_bytes
+
+.. kernel-doc:: include/crypto/rng.h
+   :functions: crypto_rng_reset
+
+.. kernel-doc:: include/crypto/rng.h
+   :functions: crypto_rng_seedsize
+
+.. WARNING: DOCPROC directive not supported: !Cinclude/crypto/rng.h
+
+Asymmetric Cipher API
+---------------------
+
+.. kernel-doc:: include/crypto/akcipher.h
+   :doc: Generic Public Key API
+
+.. kernel-doc:: include/crypto/akcipher.h
+   :functions: akcipher_alg
+
+.. kernel-doc:: include/crypto/akcipher.h
+   :functions: akcipher_request
+
+.. kernel-doc:: include/crypto/akcipher.h
+   :functions: crypto_alloc_akcipher
+
+.. kernel-doc:: include/crypto/akcipher.h
+   :functions: crypto_free_akcipher
+
+.. kernel-doc:: include/crypto/akcipher.h
+   :functions: crypto_akcipher_set_pub_key
+
+.. kernel-doc:: include/crypto/akcipher.h
+   :functions: crypto_akcipher_set_priv_key
+
+Asymmetric Cipher Request Handle
+--------------------------------
+
+.. kernel-doc:: include/crypto/akcipher.h
+   :functions: akcipher_request_alloc
+
+.. kernel-doc:: include/crypto/akcipher.h
+   :functions: akcipher_request_free
+
+.. kernel-doc:: include/crypto/akcipher.h
+   :functions: akcipher_request_set_callback
+
+.. kernel-doc:: include/crypto/akcipher.h
+   :functions: akcipher_request_set_crypt
+
+.. kernel-doc:: include/crypto/akcipher.h
+   :functions: crypto_akcipher_maxsize
+
+.. kernel-doc:: include/crypto/akcipher.h
+   :functions: crypto_akcipher_encrypt
+
+.. kernel-doc:: include/crypto/akcipher.h
+   :functions: crypto_akcipher_decrypt
+
+.. kernel-doc:: include/crypto/akcipher.h
+   :functions: crypto_akcipher_sign
+
+.. kernel-doc:: include/crypto/akcipher.h
+   :functions: crypto_akcipher_verify
+
+Code Examples
+=============
+
+Code Example For Symmetric Key Cipher Operation
+-----------------------------------------------
+
+::
+
+
+    struct tcrypt_result {
+        struct completion completion;
+        int err;
+    };
+
+    /* tie all data structures together */
+    struct skcipher_def {
+        struct scatterlist sg;
+        struct crypto_skcipher *tfm;
+        struct skcipher_request *req;
+        struct tcrypt_result result;
+    };
+
+    /* Callback function */
+    static void test_skcipher_cb(struct crypto_async_request *req, int error)
+    {
+        struct tcrypt_result *result = req->data;
+
+        if (error == -EINPROGRESS)
+            return;
+        result->err = error;
+        complete(&result->completion);
+        pr_info("Encryption finished successfully\n");
+    }
+
+    /* Perform cipher operation */
+    static unsigned int test_skcipher_encdec(struct skcipher_def *sk,
+                         int enc)
+    {
+        int rc = 0;
+
+        if (enc)
+            rc = crypto_skcipher_encrypt(sk->req);
+        else
+            rc = crypto_skcipher_decrypt(sk->req);
+
+        switch (rc) {
+        case 0:
+            break;
+        case -EINPROGRESS:
+        case -EBUSY:
+            rc = wait_for_completion_interruptible(
+                &sk->result.completion);
+            if (!rc && !sk->result.err) {
+                reinit_completion(&sk->result.completion);
+                break;
+            }
+        default:
+            pr_info("skcipher encrypt returned with %d result %d\n",
+                rc, sk->result.err);
+            break;
+        }
+        init_completion(&sk->result.completion);
+
+        return rc;
+    }
+
+    /* Initialize and trigger cipher operation */
+    static int test_skcipher(void)
+    {
+        struct skcipher_def sk;
+        struct crypto_skcipher *skcipher = NULL;
+        struct skcipher_request *req = NULL;
+        char *scratchpad = NULL;
+        char *ivdata = NULL;
+        unsigned char key[32];
+        int ret = -EFAULT;
+
+        skcipher = crypto_alloc_skcipher("cbc-aes-aesni", 0, 0);
+        if (IS_ERR(skcipher)) {
+            pr_info("could not allocate skcipher handle\n");
+            return PTR_ERR(skcipher);
+        }
+
+        req = skcipher_request_alloc(skcipher, GFP_KERNEL);
+        if (!req) {
+            pr_info("could not allocate skcipher request\n");
+            ret = -ENOMEM;
+            goto out;
+        }
+
+        skcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
+                          test_skcipher_cb,
+                          &sk.result);
+
+        /* AES 256 with random key */
+        get_random_bytes(&key, 32);
+        if (crypto_skcipher_setkey(skcipher, key, 32)) {
+            pr_info("key could not be set\n");
+            ret = -EAGAIN;
+            goto out;
+        }
+
+        /* IV will be random */
+        ivdata = kmalloc(16, GFP_KERNEL);
+        if (!ivdata) {
+            pr_info("could not allocate ivdata\n");
+            goto out;
+        }
+        get_random_bytes(ivdata, 16);
+
+        /* Input data will be random */
+        scratchpad = kmalloc(16, GFP_KERNEL);
+        if (!scratchpad) {
+            pr_info("could not allocate scratchpad\n");
+            goto out;
+        }
+        get_random_bytes(scratchpad, 16);
+
+        sk.tfm = skcipher;
+        sk.req = req;
+
+        /* We encrypt one block */
+        sg_init_one(&sk.sg, scratchpad, 16);
+        skcipher_request_set_crypt(req, &sk.sg, &sk.sg, 16, ivdata);
+        init_completion(&sk.result.completion);
+
+        /* encrypt data */
+        ret = test_skcipher_encdec(&sk, 1);
+        if (ret)
+            goto out;
+
+        pr_info("Encryption triggered successfully\n");
+
+    out:
+        if (skcipher)
+            crypto_free_skcipher(skcipher);
+        if (req)
+            skcipher_request_free(req);
+        if (ivdata)
+            kfree(ivdata);
+        if (scratchpad)
+            kfree(scratchpad);
+        return ret;
+    }
+
+
+Code Example For Use of Operational State Memory With SHASH
+-----------------------------------------------------------
+
+::
+
+
+    struct sdesc {
+        struct shash_desc shash;
+        char ctx[];
+    };
+
+    static struct sdescinit_sdesc(struct crypto_shash *alg)
+    {
+        struct sdescsdesc;
+        int size;
+
+        size = sizeof(struct shash_desc) + crypto_shash_descsize(alg);
+        sdesc = kmalloc(size, GFP_KERNEL);
+        if (!sdesc)
+            return ERR_PTR(-ENOMEM);
+        sdesc->shash.tfm = alg;
+        sdesc->shash.flags = 0x0;
+        return sdesc;
+    }
+
+    static int calc_hash(struct crypto_shashalg,
+                 const unsigned chardata, unsigned int datalen,
+                 unsigned chardigest) {
+        struct sdescsdesc;
+        int ret;
+
+        sdesc = init_sdesc(alg);
+        if (IS_ERR(sdesc)) {
+            pr_info("trusted_key: can't alloc %s\n", hash_alg);
+            return PTR_ERR(sdesc);
+        }
+
+        ret = crypto_shash_digest(&sdesc->shash, data, datalen, digest);
+        kfree(sdesc);
+        return ret;
+    }
+
+
+Code Example For Random Number Generator Usage
+----------------------------------------------
+
+::
+
+
+    static int get_random_numbers(u8 *buf, unsigned int len)
+    {
+        struct crypto_rngrng = NULL;
+        chardrbg = "drbg_nopr_sha256"; /* Hash DRBG with SHA-256, no PR */
+        int ret;
+
+        if (!buf || !len) {
+            pr_debug("No output buffer provided\n");
+            return -EINVAL;
+        }
+
+        rng = crypto_alloc_rng(drbg, 0, 0);
+        if (IS_ERR(rng)) {
+            pr_debug("could not allocate RNG handle for %s\n", drbg);
+            return -PTR_ERR(rng);
+        }
+
+        ret = crypto_rng_get_bytes(rng, buf, len);
+        if (ret < 0)
+            pr_debug("generation of random numbers failed\n");
+        else if (ret == 0)
+            pr_debug("RNG returned no data");
+        else
+            pr_debug("RNG returned %d bytes of data\n", ret);
+
+    out:
+        crypto_free_rng(rng);
+        return ret;
+    }
diff --git a/Documentation/filesystems.rst b/Documentation/filesystems.rst
new file mode 100644
index 000000000000..08293efc6493
--- /dev/null
+++ b/Documentation/filesystems.rst
@@ -0,0 +1,314 @@
+=====================
+Linux Filesystems API
+=====================
+
+The Linux VFS
+=============
+
+The Filesystem types
+--------------------
+
+.. kernel-doc:: include/linux/fs.h
+   :internal:
+
+The Directory Cache
+-------------------
+
+.. kernel-doc:: fs/dcache.c
+   :export:
+
+.. kernel-doc:: include/linux/dcache.h
+   :internal:
+
+Inode Handling
+--------------
+
+.. kernel-doc:: fs/inode.c
+   :export:
+
+.. kernel-doc:: fs/bad_inode.c
+   :export:
+
+Registration and Superblocks
+----------------------------
+
+.. kernel-doc:: fs/super.c
+   :export:
+
+File Locks
+----------
+
+.. kernel-doc:: fs/locks.c
+   :export:
+
+.. kernel-doc:: fs/locks.c
+   :internal:
+
+Other Functions
+---------------
+
+.. kernel-doc:: fs/mpage.c
+   :export:
+
+.. kernel-doc:: fs/namei.c
+   :export:
+
+.. kernel-doc:: fs/buffer.c
+   :export:
+
+.. kernel-doc:: block/bio.c
+   :export:
+
+.. kernel-doc:: fs/seq_file.c
+   :export:
+
+.. kernel-doc:: fs/filesystems.c
+   :export:
+
+.. kernel-doc:: fs/fs-writeback.c
+   :export:
+
+.. kernel-doc:: fs/block_dev.c
+   :export:
+
+The proc filesystem
+===================
+
+sysctl interface
+----------------
+
+.. kernel-doc:: kernel/sysctl.c
+   :export:
+
+proc filesystem interface
+-------------------------
+
+.. kernel-doc:: fs/proc/base.c
+   :internal:
+
+Events based on file descriptors
+================================
+
+.. kernel-doc:: fs/eventfd.c
+   :export:
+
+The Filesystem for Exporting Kernel Objects
+===========================================
+
+.. kernel-doc:: fs/sysfs/file.c
+   :export:
+
+.. kernel-doc:: fs/sysfs/symlink.c
+   :export:
+
+The debugfs filesystem
+======================
+
+debugfs interface
+-----------------
+
+.. kernel-doc:: fs/debugfs/inode.c
+   :export:
+
+.. kernel-doc:: fs/debugfs/file.c
+   :export:
+
+The Linux Journalling API
+=========================
+
+Overview
+--------
+
+Details
+~~~~~~~
+
+The journalling layer is easy to use. You need to first of all create a
+journal_t data structure. There are two calls to do this dependent on
+how you decide to allocate the physical media on which the journal
+resides. The jbd2_journal_init_inode() call is for journals stored in
+filesystem inodes, or the jbd2_journal_init_dev() call can be used
+for journal stored on a raw device (in a continuous range of blocks). A
+journal_t is a typedef for a struct pointer, so when you are finally
+finished make sure you call jbd2_journal_destroy() on it to free up
+any used kernel memory.
+
+Once you have got your journal_t object you need to 'mount' or load the
+journal file. The journalling layer expects the space for the journal
+was already allocated and initialized properly by the userspace tools.
+When loading the journal you must call jbd2_journal_load() to process
+journal contents. If the client file system detects the journal contents
+does not need to be processed (or even need not have valid contents), it
+may call jbd2_journal_wipe() to clear the journal contents before
+calling jbd2_journal_load().
+
+Note that jbd2_journal_wipe(..,0) calls
+jbd2_journal_skip_recovery() for you if it detects any outstanding
+transactions in the journal and similarly jbd2_journal_load() will
+call jbd2_journal_recover() if necessary. I would advise reading
+ext4_load_journal() in fs/ext4/super.c for examples on this stage.
+
+Now you can go ahead and start modifying the underlying filesystem.
+Almost.
+
+You still need to actually journal your filesystem changes, this is done
+by wrapping them into transactions. Additionally you also need to wrap
+the modification of each of the buffers with calls to the journal layer,
+so it knows what the modifications you are actually making are. To do
+this use jbd2_journal_start() which returns a transaction handle.
+
+jbd2_journal_start() and its counterpart jbd2_journal_stop(), which
+indicates the end of a transaction are nestable calls, so you can
+reenter a transaction if necessary, but remember you must call
+jbd2_journal_stop() the same number of times as jbd2_journal_start()
+before the transaction is completed (or more accurately leaves the
+update phase). Ext4/VFS makes use of this feature to simplify handling
+of inode dirtying, quota support, etc.
+
+Inside each transaction you need to wrap the modifications to the
+individual buffers (blocks). Before you start to modify a buffer you
+need to call jbd2_journal_get_{create,write,undo}_access() as
+appropriate, this allows the journalling layer to copy the unmodified
+data if it needs to. After all the buffer may be part of a previously
+uncommitted transaction. At this point you are at last ready to modify a
+buffer, and once you are have done so you need to call
+jbd2_journal_dirty_{meta,}data(). Or if you've asked for access to a
+buffer you now know is now longer required to be pushed back on the
+device you can call jbd2_journal_forget() in much the same way as you
+might have used bforget() in the past.
+
+A jbd2_journal_flush() may be called at any time to commit and
+checkpoint all your transactions.
+
+Then at umount time , in your put_super() you can then call
+jbd2_journal_destroy() to clean up your in-core journal object.
+
+Unfortunately there a couple of ways the journal layer can cause a
+deadlock. The first thing to note is that each task can only have a
+single outstanding transaction at any one time, remember nothing commits
+until the outermost jbd2_journal_stop(). This means you must complete
+the transaction at the end of each file/inode/address etc. operation you
+perform, so that the journalling system isn't re-entered on another
+journal. Since transactions can't be nested/batched across differing
+journals, and another filesystem other than yours (say ext4) may be
+modified in a later syscall.
+
+The second case to bear in mind is that jbd2_journal_start() can block
+if there isn't enough space in the journal for your transaction (based
+on the passed nblocks param) - when it blocks it merely(!) needs to wait
+for transactions to complete and be committed from other tasks, so
+essentially we are waiting for jbd2_journal_stop(). So to avoid
+deadlocks you must treat jbd2_journal_start/stop() as if they were
+semaphores and include them in your semaphore ordering rules to prevent
+deadlocks. Note that jbd2_journal_extend() has similar blocking
+behaviour to jbd2_journal_start() so you can deadlock here just as
+easily as on jbd2_journal_start().
+
+Try to reserve the right number of blocks the first time. ;-). This will
+be the maximum number of blocks you are going to touch in this
+transaction. I advise having a look at at least ext4_jbd.h to see the
+basis on which ext4 uses to make these decisions.
+
+Another wriggle to watch out for is your on-disk block allocation
+strategy. Why? Because, if you do a delete, you need to ensure you
+haven't reused any of the freed blocks until the transaction freeing
+these blocks commits. If you reused these blocks and crash happens,
+there is no way to restore the contents of the reallocated blocks at the
+end of the last fully committed transaction. One simple way of doing
+this is to mark blocks as free in internal in-memory block allocation
+structures only after the transaction freeing them commits. Ext4 uses
+journal commit callback for this purpose.
+
+With journal commit callbacks you can ask the journalling layer to call
+a callback function when the transaction is finally committed to disk,
+so that you can do some of your own management. You ask the journalling
+layer for calling the callback by simply setting
+journal->j_commit_callback function pointer and that function is
+called after each transaction commit. You can also use
+transaction->t_private_list for attaching entries to a transaction
+that need processing when the transaction commits.
+
+JBD2 also provides a way to block all transaction updates via
+jbd2_journal_{un,}lock_updates(). Ext4 uses this when it wants a
+window with a clean and stable fs for a moment. E.g.
+
+::
+
+
+        jbd2_journal_lock_updates() //stop new stuff happening..
+        jbd2_journal_flush()        // checkpoint everything.
+        ..do stuff on stable fs
+        jbd2_journal_unlock_updates() // carry on with filesystem use.
+
+The opportunities for abuse and DOS attacks with this should be obvious,
+if you allow unprivileged userspace to trigger codepaths containing
+these calls.
+
+Summary
+~~~~~~~
+
+Using the journal is a matter of wrapping the different context changes,
+being each mount, each modification (transaction) and each changed
+buffer to tell the journalling layer about them.
+
+Data Types
+----------
+
+The journalling layer uses typedefs to 'hide' the concrete definitions
+of the structures used. As a client of the JBD2 layer you can just rely
+on the using the pointer as a magic cookie of some sort. Obviously the
+hiding is not enforced as this is 'C'.
+
+Structures
+~~~~~~~~~~
+
+.. kernel-doc:: include/linux/jbd2.h
+   :internal:
+
+Functions
+---------
+
+The functions here are split into two groups those that affect a journal
+as a whole, and those which are used to manage transactions
+
+Journal Level
+~~~~~~~~~~~~~
+
+.. kernel-doc:: fs/jbd2/journal.c
+   :export:
+
+.. kernel-doc:: fs/jbd2/recovery.c
+   :internal:
+
+Transasction Level
+~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: fs/jbd2/transaction.c
+   :export:
+
+See also
+--------
+
+`Journaling the Linux ext2fs Filesystem, LinuxExpo 98, Stephen
+Tweedie <http://kernel.org/pub/linux/kernel/people/sct/ext3/journal-design.ps.gz>`__
+
+`Ext3 Journalling FileSystem, OLS 2000, Dr. Stephen
+Tweedie <http://olstrans.sourceforge.net/release/OLS2000-ext3/OLS2000-ext3.html>`__
+
+splice API
+==========
+
+splice is a method for moving blocks of data around inside the kernel,
+without continually transferring them between the kernel and user space.
+
+.. WARNING: DOCPROC directive not supported: !Ffs/splice.c
+
+pipes API
+=========
+
+Pipe interfaces are all for in-kernel (builtin image) use. They are not
+exported for use by modules.
+
+.. kernel-doc:: include/linux/pipe_fs_i.h
+   :internal:
+
+.. WARNING: DOCPROC directive not supported: !Ffs/pipe.c
diff --git a/Documentation/gpu.rst b/Documentation/gpu.rst
new file mode 100644
index 000000000000..d9bcc5f04a92
--- /dev/null
+++ b/Documentation/gpu.rst
@@ -0,0 +1,2556 @@
+==================================
+Linux GPU Driver Developer's Guide
+==================================
+
+:Author: Jesse Barnes Initial version
+:Author: Laurent Pinchart Driver internals
+:Author: Daniel Vetter Contributions all over the place
+:Author: Lukas Wunner vga_switcheroo documentation
+:Date:   2015-10-11
+
+This first part of the GPU Driver Developer's Guide documents core DRM
+code, helper libraries for writing drivers and generic userspace
+interfaces exposed by DRM drivers.
+
+Introduction
+============
+
+The Linux DRM layer contains code intended to support the needs of
+complex graphics devices, usually containing programmable pipelines well
+suited to 3D graphics acceleration. Graphics drivers in the kernel may
+make use of DRM functions to make tasks like memory management,
+interrupt handling and DMA easier, and provide a uniform interface to
+applications.
+
+A note on versions: this guide covers features found in the DRM tree,
+including the TTM memory manager, output configuration and mode setting,
+and the new vblank internals, in addition to all the regular features
+found in current kernels.
+
+[Insert diagram of typical DRM stack here]
+
+Style Guidelines
+----------------
+
+For consistency this documentation uses American English. Abbreviations
+are written as all-uppercase, for example: DRM, KMS, IOCTL, CRTC, and so
+on. To aid in reading, documentations make full use of the markup
+characters kerneldoc provides: @parameter for function parameters,
+@member for structure members, &structure to reference structures and
+function() for functions. These all get automatically hyperlinked if
+kerneldoc for the referenced objects exists. When referencing entries in
+function vtables please use ->vfunc(). Note that kerneldoc does not
+support referencing struct members directly, so please add a reference
+to the vtable struct somewhere in the same paragraph or at least
+section.
+
+Except in special situations (to separate locked from unlocked variants)
+locking requirements for functions aren't documented in the kerneldoc.
+Instead locking should be check at runtime using e.g.
+``WARN_ON(!mutex_is_locked(...));``. Since it's much easier to ignore
+documentation than runtime noise this provides more value. And on top of
+that runtime checks do need to be updated when the locking rules change,
+increasing the chances that they're correct. Within the documentation
+the locking rules should be explained in the relevant structures: Either
+in the comment for the lock explaining what it protects, or data fields
+need a note about which lock protects them, or both.
+
+Functions which have a non-\ ``void`` return value should have a section
+called "Returns" explaining the expected return values in different
+cases and their meanings. Currently there's no consensus whether that
+section name should be all upper-case or not, and whether it should end
+in a colon or not. Go with the file-local style. Other common section
+names are "Notes" with information for dangerous or tricky corner cases,
+and "FIXME" where the interface could be cleaned up.
+
+DRM Internals
+=============
+
+This chapter documents DRM internals relevant to driver authors and
+developers working to add support for the latest features to existing
+drivers.
+
+First, we go over some typical driver initialization requirements, like
+setting up command buffers, creating an initial output configuration,
+and initializing core services. Subsequent sections cover core internals
+in more detail, providing implementation notes and examples.
+
+The DRM layer provides several services to graphics drivers, many of
+them driven by the application interfaces it provides through libdrm,
+the library that wraps most of the DRM ioctls. These include vblank
+event handling, memory management, output management, framebuffer
+management, command submission & fencing, suspend/resume support, and
+DMA services.
+
+Driver Initialization
+---------------------
+
+At the core of every DRM driver is a :ref:`struct drm_driver`
+structure. Drivers typically statically initialize a drm_driver
+structure, and then pass it to :c:func:`drm_dev_alloc` to allocate
+a device instance. After the device instance is fully initialized it can
+be registered (which makes it accessible from userspace) using
+:c:func:`drm_dev_register`.
+
+The :ref:`struct drm_driver` structure contains static information
+that describes the driver and features it supports, and pointers to
+methods that the DRM core will call to implement the DRM API. We will
+first go through the :ref:`struct drm_driver` static information
+fields, and will then describe individual operations in details as they
+get used in later sections.
+
+Driver Information
+~~~~~~~~~~~~~~~~~~
+
+Driver Features
+^^^^^^^^^^^^^^^
+
+Drivers inform the DRM core about their requirements and supported
+features by setting appropriate flags in the driver_features field.
+Since those flags influence the DRM core behaviour since registration
+time, most of them must be set to registering the :ref:`struct
+drm_driver` instance.
+
+u32 driver_features;
+
+DRIVER_USE_AGP
+    Driver uses AGP interface, the DRM core will manage AGP resources.
+
+DRIVER_REQUIRE_AGP
+    Driver needs AGP interface to function. AGP initialization failure
+    will become a fatal error.
+
+DRIVER_PCI_DMA
+    Driver is capable of PCI DMA, mapping of PCI DMA buffers to
+    userspace will be enabled. Deprecated.
+
+DRIVER_SG
+    Driver can perform scatter/gather DMA, allocation and mapping of
+    scatter/gather buffers will be enabled. Deprecated.
+
+DRIVER_HAVE_DMA
+    Driver supports DMA, the userspace DMA API will be supported.
+    Deprecated.
+
+DRIVER_HAVE_IRQ; DRIVER_IRQ_SHARED
+    DRIVER_HAVE_IRQ indicates whether the driver has an IRQ handler
+    managed by the DRM Core. The core will support simple IRQ handler
+    installation when the flag is set. The installation process is
+    described in ?.
+
+    DRIVER_IRQ_SHARED indicates whether the device & handler support
+    shared IRQs (note that this is required of PCI drivers).
+
+DRIVER_GEM
+    Driver use the GEM memory manager.
+
+DRIVER_MODESET
+    Driver supports mode setting interfaces (KMS).
+
+DRIVER_PRIME
+    Driver implements DRM PRIME buffer sharing.
+
+DRIVER_RENDER
+    Driver supports dedicated render nodes.
+
+DRIVER_ATOMIC
+    Driver supports atomic properties. In this case the driver must
+    implement appropriate obj->atomic_get_property() vfuncs for any
+    modeset objects with driver specific properties.
+
+Major, Minor and Patchlevel
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+int major; int minor; int patchlevel;
+The DRM core identifies driver versions by a major, minor and patch
+level triplet. The information is printed to the kernel log at
+initialization time and passed to userspace through the
+DRM_IOCTL_VERSION ioctl.
+
+The major and minor numbers are also used to verify the requested driver
+API version passed to DRM_IOCTL_SET_VERSION. When the driver API
+changes between minor versions, applications can call
+DRM_IOCTL_SET_VERSION to select a specific version of the API. If the
+requested major isn't equal to the driver major, or the requested minor
+is larger than the driver minor, the DRM_IOCTL_SET_VERSION call will
+return an error. Otherwise the driver's set_version() method will be
+called with the requested version.
+
+Name, Description and Date
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+char \*name; char \*desc; char \*date;
+The driver name is printed to the kernel log at initialization time,
+used for IRQ registration and passed to userspace through
+DRM_IOCTL_VERSION.
+
+The driver description is a purely informative string passed to
+userspace through the DRM_IOCTL_VERSION ioctl and otherwise unused by
+the kernel.
+
+The driver date, formatted as YYYYMMDD, is meant to identify the date of
+the latest modification to the driver. However, as most drivers fail to
+update it, its value is mostly useless. The DRM core prints it to the
+kernel log at initialization time and passes it to userspace through the
+DRM_IOCTL_VERSION ioctl.
+
+Device Instance and Driver Handling
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/drm_drv.c
+   :doc: driver instance overview
+
+.. kernel-doc:: drivers/gpu/drm/drm_drv.c
+   :export:
+
+Driver Load
+~~~~~~~~~~~
+
+IRQ Registration
+^^^^^^^^^^^^^^^^
+
+The DRM core tries to facilitate IRQ handler registration and
+unregistration by providing :c:func:`drm_irq_install` and
+:c:func:`drm_irq_uninstall` functions. Those functions only
+support a single interrupt per device, devices that use more than one
+IRQs need to be handled manually.
+
+Managed IRQ Registration
+''''''''''''''''''''''''
+
+:c:func:`drm_irq_install` starts by calling the irq_preinstall
+driver operation. The operation is optional and must make sure that the
+interrupt will not get fired by clearing all pending interrupt flags or
+disabling the interrupt.
+
+The passed-in IRQ will then be requested by a call to
+:c:func:`request_irq`. If the DRIVER_IRQ_SHARED driver feature
+flag is set, a shared (IRQF_SHARED) IRQ handler will be requested.
+
+The IRQ handler function must be provided as the mandatory irq_handler
+driver operation. It will get passed directly to
+:c:func:`request_irq` and thus has the same prototype as all IRQ
+handlers. It will get called with a pointer to the DRM device as the
+second argument.
+
+Finally the function calls the optional irq_postinstall driver
+operation. The operation usually enables interrupts (excluding the
+vblank interrupt, which is enabled separately), but drivers may choose
+to enable/disable interrupts at a different time.
+
+:c:func:`drm_irq_uninstall` is similarly used to uninstall an IRQ
+handler. It starts by waking up all processes waiting on a vblank
+interrupt to make sure they don't hang, and then calls the optional
+irq_uninstall driver operation. The operation must disable all hardware
+interrupts. Finally the function frees the IRQ by calling
+:c:func:`free_irq`.
+
+Manual IRQ Registration
+'''''''''''''''''''''''
+
+Drivers that require multiple interrupt handlers can't use the managed
+IRQ registration functions. In that case IRQs must be registered and
+unregistered manually (usually with the :c:func:`request_irq` and
+:c:func:`free_irq` functions, or their devm_\* equivalent).
+
+When manually registering IRQs, drivers must not set the
+DRIVER_HAVE_IRQ driver feature flag, and must not provide the
+irq_handler driver operation. They must set the :ref:`struct
+drm_device` irq_enabled field to 1 upon registration of the IRQs,
+and clear it to 0 after unregistering the IRQs.
+
+Memory Manager Initialization
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Every DRM driver requires a memory manager which must be initialized at
+load time. DRM currently contains two memory managers, the Translation
+Table Manager (TTM) and the Graphics Execution Manager (GEM). This
+document describes the use of the GEM memory manager only. See ? for
+details.
+
+Miscellaneous Device Configuration
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Another task that may be necessary for PCI devices during configuration
+is mapping the video BIOS. On many devices, the VBIOS describes device
+configuration, LCD panel timings (if any), and contains flags indicating
+device state. Mapping the BIOS can be done using the pci_map_rom()
+call, a convenience function that takes care of mapping the actual ROM,
+whether it has been shadowed into memory (typically at address 0xc0000)
+or exists on the PCI device in the ROM BAR. Note that after the ROM has
+been mapped and any necessary information has been extracted, it should
+be unmapped; on many devices, the ROM address decoder is shared with
+other BARs, so leaving it mapped could cause undesired behaviour like
+hangs or memory corruption.
+
+Bus-specific Device Registration and PCI Support
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A number of functions are provided to help with device registration. The
+functions deal with PCI and platform devices respectively and are only
+provided for historical reasons. These are all deprecated and shouldn't
+be used in new drivers. Besides that there's a few helpers for pci
+drivers.
+
+.. kernel-doc:: drivers/gpu/drm/drm_pci.c
+   :export:
+
+.. kernel-doc:: drivers/gpu/drm/drm_platform.c
+   :export:
+
+Memory management
+-----------------
+
+Modern Linux systems require large amount of graphics memory to store
+frame buffers, textures, vertices and other graphics-related data. Given
+the very dynamic nature of many of that data, managing graphics memory
+efficiently is thus crucial for the graphics stack and plays a central
+role in the DRM infrastructure.
+
+The DRM core includes two memory managers, namely Translation Table Maps
+(TTM) and Graphics Execution Manager (GEM). TTM was the first DRM memory
+manager to be developed and tried to be a one-size-fits-them all
+solution. It provides a single userspace API to accommodate the need of
+all hardware, supporting both Unified Memory Architecture (UMA) devices
+and devices with dedicated video RAM (i.e. most discrete video cards).
+This resulted in a large, complex piece of code that turned out to be
+hard to use for driver development.
+
+GEM started as an Intel-sponsored project in reaction to TTM's
+complexity. Its design philosophy is completely different: instead of
+providing a solution to every graphics memory-related problems, GEM
+identified common code between drivers and created a support library to
+share it. GEM has simpler initialization and execution requirements than
+TTM, but has no video RAM management capabilities and is thus limited to
+UMA devices.
+
+The Translation Table Manager (TTM)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+TTM design background and information belongs here.
+
+TTM initialization
+^^^^^^^^^^^^^^^^^^
+
+    **Warning**
+
+    This section is outdated.
+
+Drivers wishing to support TTM must fill out a drm_bo_driver
+structure. The structure contains several fields with function pointers
+for initializing the TTM, allocating and freeing memory, waiting for
+command completion and fence synchronization, and memory migration. See
+the radeon_ttm.c file for an example of usage.
+
+The ttm_global_reference structure is made up of several fields:
+
+::
+
+              struct ttm_global_reference {
+                      enum ttm_global_types global_type;
+                      size_t size;
+                      void *object;
+                      int (*init) (struct ttm_global_reference *);
+                      void (*release) (struct ttm_global_reference *);
+              };
+
+
+There should be one global reference structure for your memory manager
+as a whole, and there will be others for each object created by the
+memory manager at runtime. Your global TTM should have a type of
+TTM_GLOBAL_TTM_MEM. The size field for the global object should be
+sizeof(struct ttm_mem_global), and the init and release hooks should
+point at your driver-specific init and release routines, which probably
+eventually call ttm_mem_global_init and ttm_mem_global_release,
+respectively.
+
+Once your global TTM accounting structure is set up and initialized by
+calling ttm_global_item_ref() on it, you need to create a buffer
+object TTM to provide a pool for buffer object allocation by clients and
+the kernel itself. The type of this object should be
+TTM_GLOBAL_TTM_BO, and its size should be sizeof(struct
+ttm_bo_global). Again, driver-specific init and release functions may
+be provided, likely eventually calling ttm_bo_global_init() and
+ttm_bo_global_release(), respectively. Also, like the previous
+object, ttm_global_item_ref() is used to create an initial reference
+count for the TTM, which will call your initialization function.
+
+The Graphics Execution Manager (GEM)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The GEM design approach has resulted in a memory manager that doesn't
+provide full coverage of all (or even all common) use cases in its
+userspace or kernel API. GEM exposes a set of standard memory-related
+operations to userspace and a set of helper functions to drivers, and
+let drivers implement hardware-specific operations with their own
+private API.
+
+The GEM userspace API is described in the `GEM - the Graphics Execution
+Manager <http://lwn.net/Articles/283798/>`__ article on LWN. While
+slightly outdated, the document provides a good overview of the GEM API
+principles. Buffer allocation and read and write operations, described
+as part of the common GEM API, are currently implemented using
+driver-specific ioctls.
+
+GEM is data-agnostic. It manages abstract buffer objects without knowing
+what individual buffers contain. APIs that require knowledge of buffer
+contents or purpose, such as buffer allocation or synchronization
+primitives, are thus outside of the scope of GEM and must be implemented
+using driver-specific ioctls.
+
+On a fundamental level, GEM involves several operations:
+
+-  Memory allocation and freeing
+-  Command execution
+-  Aperture management at command execution time
+
+Buffer object allocation is relatively straightforward and largely
+provided by Linux's shmem layer, which provides memory to back each
+object.
+
+Device-specific operations, such as command execution, pinning, buffer
+read & write, mapping, and domain ownership transfers are left to
+driver-specific ioctls.
+
+GEM Initialization
+^^^^^^^^^^^^^^^^^^
+
+Drivers that use GEM must set the DRIVER_GEM bit in the struct
+:ref:`struct drm_driver` driver_features field. The DRM core will
+then automatically initialize the GEM core before calling the load
+operation. Behind the scene, this will create a DRM Memory Manager
+object which provides an address space pool for object allocation.
+
+In a KMS configuration, drivers need to allocate and initialize a
+command ring buffer following core GEM initialization if required by the
+hardware. UMA devices usually have what is called a "stolen" memory
+region, which provides space for the initial framebuffer and large,
+contiguous memory regions required by the device. This space is
+typically not managed by GEM, and must be initialized separately into
+its own DRM MM object.
+
+GEM Objects Creation
+^^^^^^^^^^^^^^^^^^^^
+
+GEM splits creation of GEM objects and allocation of the memory that
+backs them in two distinct operations.
+
+GEM objects are represented by an instance of struct :ref:`struct
+drm_gem_object`. Drivers usually need to extend GEM objects with
+private information and thus create a driver-specific GEM object
+structure type that embeds an instance of struct :ref:`struct
+drm_gem_object`.
+
+To create a GEM object, a driver allocates memory for an instance of its
+specific GEM object type and initializes the embedded struct
+:ref:`struct drm_gem_object` with a call to
+:c:func:`drm_gem_object_init`. The function takes a pointer to
+the DRM device, a pointer to the GEM object and the buffer object size
+in bytes.
+
+GEM uses shmem to allocate anonymous pageable memory.
+:c:func:`drm_gem_object_init` will create an shmfs file of the
+requested size and store it into the struct :ref:`struct
+drm_gem_object` filp field. The memory is used as either main
+storage for the object when the graphics hardware uses system memory
+directly or as a backing store otherwise.
+
+Drivers are responsible for the actual physical pages allocation by
+calling :c:func:`shmem_read_mapping_page_gfp` for each page.
+Note that they can decide to allocate pages when initializing the GEM
+object, or to delay allocation until the memory is needed (for instance
+when a page fault occurs as a result of a userspace memory access or
+when the driver needs to start a DMA transfer involving the memory).
+
+Anonymous pageable memory allocation is not always desired, for instance
+when the hardware requires physically contiguous system memory as is
+often the case in embedded devices. Drivers can create GEM objects with
+no shmfs backing (called private GEM objects) by initializing them with
+a call to :c:func:`drm_gem_private_object_init` instead of
+:c:func:`drm_gem_object_init`. Storage for private GEM objects
+must be managed by drivers.
+
+GEM Objects Lifetime
+^^^^^^^^^^^^^^^^^^^^
+
+All GEM objects are reference-counted by the GEM core. References can be
+acquired and release by :c:func:`calling
+drm_gem_object_reference` and
+:c:func:`drm_gem_object_unreference` respectively. The caller
+must hold the :ref:`struct drm_device` struct_mutex lock when
+calling :c:func:`drm_gem_object_reference`. As a convenience, GEM
+provides :c:func:`drm_gem_object_unreference_unlocked` functions
+that can be called without holding the lock.
+
+When the last reference to a GEM object is released the GEM core calls
+the :ref:`struct drm_driver` gem_free_object operation. That
+operation is mandatory for GEM-enabled drivers and must free the GEM
+object and all associated resources.
+
+void (\*gem_free_object) (struct drm_gem_object \*obj); Drivers are
+responsible for freeing all GEM object resources. This includes the
+resources created by the GEM core, which need to be released with
+:c:func:`drm_gem_object_release`.
+
+GEM Objects Naming
+^^^^^^^^^^^^^^^^^^
+
+Communication between userspace and the kernel refers to GEM objects
+using local handles, global names or, more recently, file descriptors.
+All of those are 32-bit integer values; the usual Linux kernel limits
+apply to the file descriptors.
+
+GEM handles are local to a DRM file. Applications get a handle to a GEM
+object through a driver-specific ioctl, and can use that handle to refer
+to the GEM object in other standard or driver-specific ioctls. Closing a
+DRM file handle frees all its GEM handles and dereferences the
+associated GEM objects.
+
+To create a handle for a GEM object drivers call
+:c:func:`drm_gem_handle_create`. The function takes a pointer to
+the DRM file and the GEM object and returns a locally unique handle.
+When the handle is no longer needed drivers delete it with a call to
+:c:func:`drm_gem_handle_delete`. Finally the GEM object
+associated with a handle can be retrieved by a call to
+:c:func:`drm_gem_object_lookup`.
+
+Handles don't take ownership of GEM objects, they only take a reference
+to the object that will be dropped when the handle is destroyed. To
+avoid leaking GEM objects, drivers must make sure they drop the
+reference(s) they own (such as the initial reference taken at object
+creation time) as appropriate, without any special consideration for the
+handle. For example, in the particular case of combined GEM object and
+handle creation in the implementation of the dumb_create operation,
+drivers must drop the initial reference to the GEM object before
+returning the handle.
+
+GEM names are similar in purpose to handles but are not local to DRM
+files. They can be passed between processes to reference a GEM object
+globally. Names can't be used directly to refer to objects in the DRM
+API, applications must convert handles to names and names to handles
+using the DRM_IOCTL_GEM_FLINK and DRM_IOCTL_GEM_OPEN ioctls
+respectively. The conversion is handled by the DRM core without any
+driver-specific support.
+
+GEM also supports buffer sharing with dma-buf file descriptors through
+PRIME. GEM-based drivers must use the provided helpers functions to
+implement the exporting and importing correctly. See ?. Since sharing
+file descriptors is inherently more secure than the easily guessable and
+global GEM names it is the preferred buffer sharing mechanism. Sharing
+buffers through GEM names is only supported for legacy userspace.
+Furthermore PRIME also allows cross-device buffer sharing since it is
+based on dma-bufs.
+
+GEM Objects Mapping
+^^^^^^^^^^^^^^^^^^^
+
+Because mapping operations are fairly heavyweight GEM favours
+read/write-like access to buffers, implemented through driver-specific
+ioctls, over mapping buffers to userspace. However, when random access
+to the buffer is needed (to perform software rendering for instance),
+direct access to the object can be more efficient.
+
+The mmap system call can't be used directly to map GEM objects, as they
+don't have their own file handle. Two alternative methods currently
+co-exist to map GEM objects to userspace. The first method uses a
+driver-specific ioctl to perform the mapping operation, calling
+:c:func:`do_mmap` under the hood. This is often considered dubious,
+seems to be discouraged for new GEM-enabled drivers, and will thus not
+be described here.
+
+The second method uses the mmap system call on the DRM file handle. void
+\*mmap(void \*addr, size_t length, int prot, int flags, int fd, off_t
+offset); DRM identifies the GEM object to be mapped by a fake offset
+passed through the mmap offset argument. Prior to being mapped, a GEM
+object must thus be associated with a fake offset. To do so, drivers
+must call :c:func:`drm_gem_create_mmap_offset` on the object.
+
+Once allocated, the fake offset value must be passed to the application
+in a driver-specific way and can then be used as the mmap offset
+argument.
+
+The GEM core provides a helper method :c:func:`drm_gem_mmap` to
+handle object mapping. The method can be set directly as the mmap file
+operation handler. It will look up the GEM object based on the offset
+value and set the VMA operations to the :ref:`struct drm_driver`
+gem_vm_ops field. Note that :c:func:`drm_gem_mmap` doesn't map
+memory to userspace, but relies on the driver-provided fault handler to
+map pages individually.
+
+To use :c:func:`drm_gem_mmap`, drivers must fill the struct
+:ref:`struct drm_driver` gem_vm_ops field with a pointer to VM
+operations.
+
+struct vm_operations_struct \*gem_vm_ops struct
+vm_operations_struct { void (\*open)(struct vm_area_struct \* area);
+void (\*close)(struct vm_area_struct \* area); int (\*fault)(struct
+vm_area_struct \*vma, struct vm_fault \*vmf); };
+
+The open and close operations must update the GEM object reference
+count. Drivers can use the :c:func:`drm_gem_vm_open` and
+:c:func:`drm_gem_vm_close` helper functions directly as open and
+close handlers.
+
+The fault operation handler is responsible for mapping individual pages
+to userspace when a page fault occurs. Depending on the memory
+allocation scheme, drivers can allocate pages at fault time, or can
+decide to allocate memory for the GEM object at the time the object is
+created.
+
+Drivers that want to map the GEM object upfront instead of handling page
+faults can implement their own mmap file operation handler.
+
+Memory Coherency
+^^^^^^^^^^^^^^^^
+
+When mapped to the device or used in a command buffer, backing pages for
+an object are flushed to memory and marked write combined so as to be
+coherent with the GPU. Likewise, if the CPU accesses an object after the
+GPU has finished rendering to the object, then the object must be made
+coherent with the CPU's view of memory, usually involving GPU cache
+flushing of various kinds. This core CPU<->GPU coherency management is
+provided by a device-specific ioctl, which evaluates an object's current
+domain and performs any necessary flushing or synchronization to put the
+object into the desired coherency domain (note that the object may be
+busy, i.e. an active render target; in that case, setting the domain
+blocks the client and waits for rendering to complete before performing
+any necessary flushing operations).
+
+Command Execution
+^^^^^^^^^^^^^^^^^
+
+Perhaps the most important GEM function for GPU devices is providing a
+command execution interface to clients. Client programs construct
+command buffers containing references to previously allocated memory
+objects, and then submit them to GEM. At that point, GEM takes care to
+bind all the objects into the GTT, execute the buffer, and provide
+necessary synchronization between clients accessing the same buffers.
+This often involves evicting some objects from the GTT and re-binding
+others (a fairly expensive operation), and providing relocation support
+which hides fixed GTT offsets from clients. Clients must take care not
+to submit command buffers that reference more objects than can fit in
+the GTT; otherwise, GEM will reject them and no rendering will occur.
+Similarly, if several objects in the buffer require fence registers to
+be allocated for correct rendering (e.g. 2D blits on pre-965 chips),
+care must be taken not to require more fence registers than are
+available to the client. Such resource management should be abstracted
+from the client in libdrm.
+
+GEM Function Reference
+~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/drm_gem.c
+   :export:
+
+.. kernel-doc:: include/drm/drm_gem.h
+   :internal:
+
+VMA Offset Manager
+~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/drm_vma_manager.c
+   :doc: vma offset manager
+
+.. kernel-doc:: drivers/gpu/drm/drm_vma_manager.c
+   :export:
+
+.. kernel-doc:: include/drm/drm_vma_manager.h
+   :internal:
+
+PRIME Buffer Sharing
+~~~~~~~~~~~~~~~~~~~~
+
+PRIME is the cross device buffer sharing framework in drm, originally
+created for the OPTIMUS range of multi-gpu platforms. To userspace PRIME
+buffers are dma-buf based file descriptors.
+
+Overview and Driver Interface
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Similar to GEM global names, PRIME file descriptors are also used to
+share buffer objects across processes. They offer additional security:
+as file descriptors must be explicitly sent over UNIX domain sockets to
+be shared between applications, they can't be guessed like the globally
+unique GEM names.
+
+Drivers that support the PRIME API must set the DRIVER_PRIME bit in the
+struct :ref:`struct drm_driver` driver_features field, and
+implement the prime_handle_to_fd and prime_fd_to_handle
+operations.
+
+int (\*prime_handle_to_fd)(struct drm_device \*dev, struct drm_file
+\*file_priv, uint32_t handle, uint32_t flags, int \*prime_fd); int
+(\*prime_fd_to_handle)(struct drm_device \*dev, struct drm_file
+\*file_priv, int prime_fd, uint32_t \*handle); Those two operations
+convert a handle to a PRIME file descriptor and vice versa. Drivers must
+use the kernel dma-buf buffer sharing framework to manage the PRIME file
+descriptors. Similar to the mode setting API PRIME is agnostic to the
+underlying buffer object manager, as long as handles are 32bit unsigned
+integers.
+
+While non-GEM drivers must implement the operations themselves, GEM
+drivers must use the :c:func:`drm_gem_prime_handle_to_fd` and
+:c:func:`drm_gem_prime_fd_to_handle` helper functions. Those
+helpers rely on the driver gem_prime_export and gem_prime_import
+operations to create a dma-buf instance from a GEM object (dma-buf
+exporter role) and to create a GEM object from a dma-buf instance
+(dma-buf importer role).
+
+struct dma_buf \* (\*gem_prime_export)(struct drm_device \*dev,
+struct drm_gem_object \*obj, int flags); struct drm_gem_object \*
+(\*gem_prime_import)(struct drm_device \*dev, struct dma_buf
+\*dma_buf); These two operations are mandatory for GEM drivers that
+support PRIME.
+
+PRIME Helper Functions
+^^^^^^^^^^^^^^^^^^^^^^
+
+.. kernel-doc:: drivers/gpu/drm/drm_prime.c
+   :doc: PRIME Helpers
+
+PRIME Function References
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/drm_prime.c
+   :export:
+
+DRM MM Range Allocator
+~~~~~~~~~~~~~~~~~~~~~~
+
+Overview
+^^^^^^^^
+
+.. kernel-doc:: drivers/gpu/drm/drm_mm.c
+   :doc: Overview
+
+LRU Scan/Eviction Support
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. kernel-doc:: drivers/gpu/drm/drm_mm.c
+   :doc: lru scan roaster
+
+DRM MM Range Allocator Function References
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/drm_mm.c
+   :export:
+
+.. kernel-doc:: include/drm/drm_mm.h
+   :internal:
+
+CMA Helper Functions Reference
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/drm_gem_cma_helper.c
+   :doc: cma helpers
+
+.. kernel-doc:: drivers/gpu/drm/drm_gem_cma_helper.c
+   :export:
+
+.. kernel-doc:: include/drm/drm_gem_cma_helper.h
+   :internal:
+
+Mode Setting
+------------
+
+Drivers must initialize the mode setting core by calling
+:c:func:`drm_mode_config_init` on the DRM device. The function
+initializes the :ref:`struct drm_device` mode_config field and
+never fails. Once done, mode configuration must be setup by initializing
+the following fields.
+
+-  int min_width, min_height; int max_width, max_height;
+   Minimum and maximum width and height of the frame buffers in pixel
+   units.
+
+-  struct drm_mode_config_funcs \*funcs;
+   Mode setting functions.
+
+Display Modes Function Reference
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: include/drm/drm_modes.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_modes.c
+   :export:
+
+Atomic Mode Setting Function Reference
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/drm_atomic.c
+   :export:
+
+.. kernel-doc:: drivers/gpu/drm/drm_atomic.c
+   :internal:
+
+Frame Buffer Abstraction
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Frame buffers are abstract memory objects that provide a source of
+pixels to scanout to a CRTC. Applications explicitly request the
+creation of frame buffers through the DRM_IOCTL_MODE_ADDFB(2) ioctls
+and receive an opaque handle that can be passed to the KMS CRTC control,
+plane configuration and page flip functions.
+
+Frame buffers rely on the underneath memory manager for low-level memory
+operations. When creating a frame buffer applications pass a memory
+handle (or a list of memory handles for multi-planar formats) through
+the ``drm_mode_fb_cmd2`` argument. For drivers using GEM as their
+userspace buffer management interface this would be a GEM handle.
+Drivers are however free to use their own backing storage object
+handles, e.g. vmwgfx directly exposes special TTM handles to userspace
+and so expects TTM handles in the create ioctl and not GEM handles.
+
+The lifetime of a drm framebuffer is controlled with a reference count,
+drivers can grab additional references with
+:c:func:`drm_framebuffer_reference`and drop them again with
+:c:func:`drm_framebuffer_unreference`. For driver-private
+framebuffers for which the last reference is never dropped (e.g. for the
+fbdev framebuffer when the struct :ref:`struct drm_framebuffer` is
+embedded into the fbdev helper struct) drivers can manually clean up a
+framebuffer at module unload time with
+:c:func:`drm_framebuffer_unregister_private`.
+
+Dumb Buffer Objects
+~~~~~~~~~~~~~~~~~~~
+
+The KMS API doesn't standardize backing storage object creation and
+leaves it to driver-specific ioctls. Furthermore actually creating a
+buffer object even for GEM-based drivers is done through a
+driver-specific ioctl - GEM only has a common userspace interface for
+sharing and destroying objects. While not an issue for full-fledged
+graphics stacks that include device-specific userspace components (in
+libdrm for instance), this limit makes DRM-based early boot graphics
+unnecessarily complex.
+
+Dumb objects partly alleviate the problem by providing a standard API to
+create dumb buffers suitable for scanout, which can then be used to
+create KMS frame buffers.
+
+To support dumb objects drivers must implement the dumb_create,
+dumb_destroy and dumb_map_offset operations.
+
+-  int (\*dumb_create)(struct drm_file \*file_priv, struct
+   drm_device \*dev, struct drm_mode_create_dumb \*args);
+   The dumb_create operation creates a driver object (GEM or TTM
+   handle) suitable for scanout based on the width, height and depth
+   from the struct :ref:`struct drm_mode_create_dumb` argument.
+   It fills the argument's handle, pitch and size fields with a handle
+   for the newly created object and its line pitch and size in bytes.
+
+-  int (\*dumb_destroy)(struct drm_file \*file_priv, struct
+   drm_device \*dev, uint32_t handle);
+   The dumb_destroy operation destroys a dumb object created by
+   dumb_create.
+
+-  int (\*dumb_map_offset)(struct drm_file \*file_priv, struct
+   drm_device \*dev, uint32_t handle, uint64_t \*offset);
+   The dumb_map_offset operation associates an mmap fake offset with
+   the object given by the handle and returns it. Drivers must use the
+   :c:func:`drm_gem_create_mmap_offset` function to associate
+   the fake offset as described in ?.
+
+Note that dumb objects may not be used for gpu acceleration, as has been
+attempted on some ARM embedded platforms. Such drivers really must have
+a hardware-specific ioctl to allocate suitable buffer objects.
+
+Output Polling
+~~~~~~~~~~~~~~
+
+void (\*output_poll_changed)(struct drm_device \*dev);
+This operation notifies the driver that the status of one or more
+connectors has changed. Drivers that use the fb helper can just call the
+:c:func:`drm_fb_helper_hotplug_event` function to handle this
+operation.
+
+Locking
+~~~~~~~
+
+Beside some lookup structures with their own locking (which is hidden
+behind the interface functions) most of the modeset state is protected
+by the ``dev-<mode_config.lock`` mutex and additionally per-crtc locks
+to allow cursor updates, pageflips and similar operations to occur
+concurrently with background tasks like output detection. Operations
+which cross domains like a full modeset always grab all locks. Drivers
+there need to protect resources shared between crtcs with additional
+locking. They also need to be careful to always grab the relevant crtc
+locks if a modset functions touches crtc state, e.g. for load detection
+(which does only grab the ``mode_config.lock`` to allow concurrent
+screen updates on live crtcs).
+
+KMS Initialization and Cleanup
+------------------------------
+
+A KMS device is abstracted and exposed as a set of planes, CRTCs,
+encoders and connectors. KMS drivers must thus create and initialize all
+those objects at load time after initializing mode setting.
+
+CRTCs (struct :ref:`struct drm_crtc`)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A CRTC is an abstraction representing a part of the chip that contains a
+pointer to a scanout buffer. Therefore, the number of CRTCs available
+determines how many independent scanout buffers can be active at any
+given time. The CRTC structure contains several fields to support this:
+a pointer to some video memory (abstracted as a frame buffer object), a
+display mode, and an (x, y) offset into the video memory to support
+panning or configurations where one piece of video memory spans multiple
+CRTCs.
+
+CRTC Initialization
+^^^^^^^^^^^^^^^^^^^
+
+A KMS device must create and register at least one struct :ref:`struct
+drm_crtc` instance. The instance is allocated and zeroed by the
+driver, possibly as part of a larger structure, and registered with a
+call to :c:func:`drm_crtc_init` with a pointer to CRTC functions.
+
+Planes (struct :ref:`struct drm_plane`)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A plane represents an image source that can be blended with or overlayed
+on top of a CRTC during the scanout process. Planes are associated with
+a frame buffer to crop a portion of the image memory (source) and
+optionally scale it to a destination size. The result is then blended
+with or overlayed on top of a CRTC.
+
+The DRM core recognizes three types of planes:
+
+-  DRM_PLANE_TYPE_PRIMARY represents a "main" plane for a CRTC.
+   Primary planes are the planes operated upon by CRTC modesetting and
+   flipping operations described in the page_flip hook in
+   :ref:`struct drm_crtc_funcs`.
+-  DRM_PLANE_TYPE_CURSOR represents a "cursor" plane for a CRTC.
+   Cursor planes are the planes operated upon by the
+   DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 ioctls.
+-  DRM_PLANE_TYPE_OVERLAY represents all non-primary, non-cursor
+   planes. Some drivers refer to these types of planes as "sprites"
+   internally.
+
+For compatibility with legacy userspace, only overlay planes are made
+available to userspace by default. Userspace clients may set the
+DRM_CLIENT_CAP_UNIVERSAL_PLANES client capability bit to indicate
+that they wish to receive a universal plane list containing all plane
+types.
+
+Plane Initialization
+^^^^^^^^^^^^^^^^^^^^
+
+To create a plane, a KMS drivers allocates and zeroes an instances of
+struct :ref:`struct drm_plane` (possibly as part of a larger
+structure) and registers it with a call to
+:c:func:`drm_universal_plane_init`. The function takes a bitmask
+of the CRTCs that can be associated with the plane, a pointer to the
+plane functions, a list of format supported formats, and the type of
+plane (primary, cursor, or overlay) being initialized.
+
+Cursor and overlay planes are optional. All drivers should provide one
+primary plane per CRTC (although this requirement may change in the
+future); drivers that do not wish to provide special handling for
+primary planes may make use of the helper functions described in ? to
+create and register a primary plane with standard capabilities.
+
+Encoders (struct :ref:`struct drm_encoder`)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+An encoder takes pixel data from a CRTC and converts it to a format
+suitable for any attached connectors. On some devices, it may be
+possible to have a CRTC send data to more than one encoder. In that
+case, both encoders would receive data from the same scanout buffer,
+resulting in a "cloned" display configuration across the connectors
+attached to each encoder.
+
+Encoder Initialization
+^^^^^^^^^^^^^^^^^^^^^^
+
+As for CRTCs, a KMS driver must create, initialize and register at least
+one struct :ref:`struct drm_encoder` instance. The instance is
+allocated and zeroed by the driver, possibly as part of a larger
+structure.
+
+Drivers must initialize the struct :ref:`struct drm_encoder`
+possible_crtcs and possible_clones fields before registering the
+encoder. Both fields are bitmasks of respectively the CRTCs that the
+encoder can be connected to, and sibling encoders candidate for cloning.
+
+After being initialized, the encoder must be registered with a call to
+:c:func:`drm_encoder_init`. The function takes a pointer to the
+encoder functions and an encoder type. Supported types are
+
+-  DRM_MODE_ENCODER_DAC for VGA and analog on DVI-I/DVI-A
+-  DRM_MODE_ENCODER_TMDS for DVI, HDMI and (embedded) DisplayPort
+-  DRM_MODE_ENCODER_LVDS for display panels
+-  DRM_MODE_ENCODER_TVDAC for TV output (Composite, S-Video,
+   Component, SCART)
+-  DRM_MODE_ENCODER_VIRTUAL for virtual machine displays
+
+Encoders must be attached to a CRTC to be used. DRM drivers leave
+encoders unattached at initialization time. Applications (or the fbdev
+compatibility layer when implemented) are responsible for attaching the
+encoders they want to use to a CRTC.
+
+Connectors (struct :ref:`struct drm_connector`)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A connector is the final destination for pixel data on a device, and
+usually connects directly to an external display device like a monitor
+or laptop panel. A connector can only be attached to one encoder at a
+time. The connector is also the structure where information about the
+attached display is kept, so it contains fields for display data, EDID
+data, DPMS & connection status, and information about modes supported on
+the attached displays.
+
+Connector Initialization
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+Finally a KMS driver must create, initialize, register and attach at
+least one struct :ref:`struct drm_connector` instance. The instance
+is created as other KMS objects and initialized by setting the following
+fields.
+
+interlace_allowed
+    Whether the connector can handle interlaced modes.
+
+doublescan_allowed
+    Whether the connector can handle doublescan.
+
+display_info
+    Display information is filled from EDID information when a display
+    is detected. For non hot-pluggable displays such as flat panels in
+    embedded systems, the driver should initialize the
+    display_info.width_mm and display_info.height_mm fields with the
+    physical size of the display.
+
+polled
+    Connector polling mode, a combination of
+
+    DRM_CONNECTOR_POLL_HPD
+        The connector generates hotplug events and doesn't need to be
+        periodically polled. The CONNECT and DISCONNECT flags must not
+        be set together with the HPD flag.
+
+    DRM_CONNECTOR_POLL_CONNECT
+        Periodically poll the connector for connection.
+
+    DRM_CONNECTOR_POLL_DISCONNECT
+        Periodically poll the connector for disconnection.
+
+    Set to 0 for connectors that don't support connection status
+    discovery.
+
+The connector is then registered with a call to
+:c:func:`drm_connector_init` with a pointer to the connector
+functions and a connector type, and exposed through sysfs with a call to
+:c:func:`drm_connector_register`.
+
+Supported connector types are
+
+-  DRM_MODE_CONNECTOR_VGA
+-  DRM_MODE_CONNECTOR_DVII
+-  DRM_MODE_CONNECTOR_DVID
+-  DRM_MODE_CONNECTOR_DVIA
+-  DRM_MODE_CONNECTOR_Composite
+-  DRM_MODE_CONNECTOR_SVIDEO
+-  DRM_MODE_CONNECTOR_LVDS
+-  DRM_MODE_CONNECTOR_Component
+-  DRM_MODE_CONNECTOR_9PinDIN
+-  DRM_MODE_CONNECTOR_DisplayPort
+-  DRM_MODE_CONNECTOR_HDMIA
+-  DRM_MODE_CONNECTOR_HDMIB
+-  DRM_MODE_CONNECTOR_TV
+-  DRM_MODE_CONNECTOR_eDP
+-  DRM_MODE_CONNECTOR_VIRTUAL
+
+Connectors must be attached to an encoder to be used. For devices that
+map connectors to encoders 1:1, the connector should be attached at
+initialization time with a call to
+:c:func:`drm_mode_connector_attach_encoder`. The driver must
+also set the :ref:`struct drm_connector` encoder field to point to
+the attached encoder.
+
+Finally, drivers must initialize the connectors state change detection
+with a call to :c:func:`drm_kms_helper_poll_init`. If at least
+one connector is pollable but can't generate hotplug interrupts
+(indicated by the DRM_CONNECTOR_POLL_CONNECT and
+DRM_CONNECTOR_POLL_DISCONNECT connector flags), a delayed work will
+automatically be queued to periodically poll for changes. Connectors
+that can generate hotplug interrupts must be marked with the
+DRM_CONNECTOR_POLL_HPD flag instead, and their interrupt handler must
+call :c:func:`drm_helper_hpd_irq_event`. The function will queue
+a delayed work to check the state of all connectors, but no periodic
+polling will be done.
+
+Connector Operations
+^^^^^^^^^^^^^^^^^^^^
+
+    **Note**
+
+    Unless otherwise state, all operations are mandatory.
+
+DPMS
+''''
+
+void (\*dpms)(struct drm_connector \*connector, int mode);
+The DPMS operation sets the power state of a connector. The mode
+argument is one of
+
+-  DRM_MODE_DPMS_ON
+
+-  DRM_MODE_DPMS_STANDBY
+
+-  DRM_MODE_DPMS_SUSPEND
+
+-  DRM_MODE_DPMS_OFF
+
+In all but DPMS_ON mode the encoder to which the connector is attached
+should put the display in low-power mode by driving its signals
+appropriately. If more than one connector is attached to the encoder
+care should be taken not to change the power state of other displays as
+a side effect. Low-power mode should be propagated to the encoders and
+CRTCs when all related connectors are put in low-power mode.
+
+Modes
+'''''
+
+int (\*fill_modes)(struct drm_connector \*connector, uint32_t
+max_width, uint32_t max_height);
+Fill the mode list with all supported modes for the connector. If the
+``max_width`` and ``max_height`` arguments are non-zero, the
+implementation must ignore all modes wider than ``max_width`` or higher
+than ``max_height``.
+
+The connector must also fill in this operation its display_info
+width_mm and height_mm fields with the connected display physical size
+in millimeters. The fields should be set to 0 if the value isn't known
+or is not applicable (for instance for projector devices).
+
+Connection Status
+'''''''''''''''''
+
+The connection status is updated through polling or hotplug events when
+supported (see ?). The status value is reported to userspace through
+ioctls and must not be used inside the driver, as it only gets
+initialized by a call to :c:func:`drm_mode_getconnector` from
+userspace.
+
+enum drm_connector_status (\*detect)(struct drm_connector
+\*connector, bool force);
+Check to see if anything is attached to the connector. The ``force``
+parameter is set to false whilst polling or to true when checking the
+connector due to user request. ``force`` can be used by the driver to
+avoid expensive, destructive operations during automated probing.
+
+Return connector_status_connected if something is connected to the
+connector, connector_status_disconnected if nothing is connected and
+connector_status_unknown if the connection state isn't known.
+
+Drivers should only return connector_status_connected if the
+connection status has really been probed as connected. Connectors that
+can't detect the connection status, or failed connection status probes,
+should return connector_status_unknown.
+
+Cleanup
+~~~~~~~
+
+The DRM core manages its objects' lifetime. When an object is not needed
+anymore the core calls its destroy function, which must clean up and
+free every resource allocated for the object. Every
+:c:func:`drm_\*_init` call must be matched with a corresponding
+:c:func:`drm_\*_cleanup` call to cleanup CRTCs
+(:c:func:`drm_crtc_cleanup`), planes
+(:c:func:`drm_plane_cleanup`), encoders
+(:c:func:`drm_encoder_cleanup`) and connectors
+(:c:func:`drm_connector_cleanup`). Furthermore, connectors that
+have been added to sysfs must be removed by a call to
+:c:func:`drm_connector_unregister` before calling
+:c:func:`drm_connector_cleanup`.
+
+Connectors state change detection must be cleanup up with a call to
+:c:func:`drm_kms_helper_poll_fini`.
+
+Output discovery and initialization example
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+::
+
+    void intel_crt_init(struct drm_device *dev)
+    {
+        struct drm_connector *connector;
+        struct intel_output *intel_output;
+
+        intel_output = kzalloc(sizeof(struct intel_output), GFP_KERNEL);
+        if (!intel_output)
+            return;
+
+        connector = &intel_output->base;
+        drm_connector_init(dev, &intel_output->base,
+                   &intel_crt_connector_funcs, DRM_MODE_CONNECTOR_VGA);
+
+        drm_encoder_init(dev, &intel_output->enc, &intel_crt_enc_funcs,
+                 DRM_MODE_ENCODER_DAC);
+
+        drm_mode_connector_attach_encoder(&intel_output->base,
+                          &intel_output->enc);
+
+        /* Set up the DDC bus. */
+        intel_output->ddc_bus = intel_i2c_create(dev, GPIOA, "CRTDDC_A");
+        if (!intel_output->ddc_bus) {
+            dev_printk(KERN_ERR, &dev->pdev->dev, "DDC bus registration "
+                   "failed.\n");
+            return;
+        }
+
+        intel_output->type = INTEL_OUTPUT_ANALOG;
+        connector->interlace_allowed = 0;
+        connector->doublescan_allowed = 0;
+
+        drm_encoder_helper_add(&intel_output->enc, &intel_crt_helper_funcs);
+        drm_connector_helper_add(connector, &intel_crt_connector_helper_funcs);
+
+        drm_connector_register(connector);
+    }
+
+In the example above (taken from the i915 driver), a CRTC, connector and
+encoder combination is created. A device-specific i2c bus is also
+created for fetching EDID data and performing monitor detection. Once
+the process is complete, the new connector is registered with sysfs to
+make its properties available to applications.
+
+KMS API Functions
+~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/drm_crtc.c
+   :export:
+
+KMS Data Structures
+~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: include/drm/drm_crtc.h
+   :internal:
+
+KMS Locking
+~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/drm_modeset_lock.c
+   :doc: kms locking
+
+.. kernel-doc:: include/drm/drm_modeset_lock.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_modeset_lock.c
+   :export:
+
+Mode Setting Helper Functions
+-----------------------------
+
+The plane, CRTC, encoder and connector functions provided by the drivers
+implement the DRM API. They're called by the DRM core and ioctl handlers
+to handle device state changes and configuration request. As
+implementing those functions often requires logic not specific to
+drivers, mid-layer helper functions are available to avoid duplicating
+boilerplate code.
+
+The DRM core contains one mid-layer implementation. The mid-layer
+provides implementations of several plane, CRTC, encoder and connector
+functions (called from the top of the mid-layer) that pre-process
+requests and call lower-level functions provided by the driver (at the
+bottom of the mid-layer). For instance, the
+:c:func:`drm_crtc_helper_set_config` function can be used to
+fill the struct :ref:`struct drm_crtc_funcs` set_config field.
+When called, it will split the set_config operation in smaller, simpler
+operations and call the driver to handle them.
+
+To use the mid-layer, drivers call :c:func:`drm_crtc_helper_add`,
+:c:func:`drm_encoder_helper_add` and
+:c:func:`drm_connector_helper_add` functions to install their
+mid-layer bottom operations handlers, and fill the :ref:`struct
+drm_crtc_funcs`, :ref:`struct drm_encoder_funcs` and
+:ref:`struct drm_connector_funcs` structures with pointers to the
+mid-layer top API functions. Installing the mid-layer bottom operation
+handlers is best done right after registering the corresponding KMS
+object.
+
+The mid-layer is not split between CRTC, encoder and connector
+operations. To use it, a driver must provide bottom functions for all of
+the three KMS entities.
+
+Atomic Modeset Helper Functions Reference
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Overview
+^^^^^^^^
+
+.. kernel-doc:: drivers/gpu/drm/drm_atomic_helper.c
+   :doc: overview
+
+Implementing Asynchronous Atomic Commit
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. kernel-doc:: drivers/gpu/drm/drm_atomic_helper.c
+   :doc: implementing async commit
+
+Atomic State Reset and Initialization
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. kernel-doc:: drivers/gpu/drm/drm_atomic_helper.c
+   :doc: atomic state reset and initialization
+
+.. kernel-doc:: include/drm/drm_atomic_helper.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_atomic_helper.c
+   :export:
+
+Modeset Helper Reference for Common Vtables
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: include/drm/drm_modeset_helper_vtables.h
+   :internal:
+
+.. kernel-doc:: include/drm/drm_modeset_helper_vtables.h
+   :doc: overview
+
+Legacy CRTC/Modeset Helper Functions Reference
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/drm_crtc_helper.c
+   :export:
+
+.. kernel-doc:: drivers/gpu/drm/drm_crtc_helper.c
+   :doc: overview
+
+Output Probing Helper Functions Reference
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/drm_probe_helper.c
+   :doc: output probing helper overview
+
+.. kernel-doc:: drivers/gpu/drm/drm_probe_helper.c
+   :export:
+
+fbdev Helper Functions Reference
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/drm_fb_helper.c
+   :doc: fbdev helpers
+
+.. kernel-doc:: drivers/gpu/drm/drm_fb_helper.c
+   :export:
+
+.. kernel-doc:: include/drm/drm_fb_helper.h
+   :internal:
+
+Display Port Helper Functions Reference
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/drm_dp_helper.c
+   :doc: dp helpers
+
+.. kernel-doc:: include/drm/drm_dp_helper.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_dp_helper.c
+   :export:
+
+Display Port MST Helper Functions Reference
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/drm_dp_mst_topology.c
+   :doc: dp mst helper
+
+.. kernel-doc:: include/drm/drm_dp_mst_helper.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_dp_mst_topology.c
+   :export:
+
+MIPI DSI Helper Functions Reference
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/drm_mipi_dsi.c
+   :doc: dsi helpers
+
+.. kernel-doc:: include/drm/drm_mipi_dsi.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_mipi_dsi.c
+   :export:
+
+EDID Helper Functions Reference
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/drm_edid.c
+   :export:
+
+Rectangle Utilities Reference
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: include/drm/drm_rect.h
+   :doc: rect utils
+
+.. kernel-doc:: include/drm/drm_rect.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_rect.c
+   :export:
+
+Flip-work Helper Reference
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: include/drm/drm_flip_work.h
+   :doc: flip utils
+
+.. kernel-doc:: include/drm/drm_flip_work.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_flip_work.c
+   :export:
+
+HDMI Infoframes Helper Reference
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Strictly speaking this is not a DRM helper library but generally useable
+by any driver interfacing with HDMI outputs like v4l or alsa drivers.
+But it nicely fits into the overall topic of mode setting helper
+libraries and hence is also included here.
+
+.. kernel-doc:: include/linux/hdmi.h
+   :internal:
+
+.. kernel-doc:: drivers/video/hdmi.c
+   :export:
+
+Plane Helper Reference
+~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/drm_plane_helper.c
+   :export:
+
+.. kernel-doc:: drivers/gpu/drm/drm_plane_helper.c
+   :doc: overview
+
+Tile group
+~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/drm_crtc.c
+   :doc: Tile group
+
+Bridges
+~~~~~~~
+
+Overview
+^^^^^^^^
+
+.. kernel-doc:: drivers/gpu/drm/drm_bridge.c
+   :doc: overview
+
+Default bridge callback sequence
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. kernel-doc:: drivers/gpu/drm/drm_bridge.c
+   :doc: bridge callbacks
+
+.. kernel-doc:: drivers/gpu/drm/drm_bridge.c
+   :export:
+
+KMS Properties
+--------------
+
+Drivers may need to expose additional parameters to applications than
+those described in the previous sections. KMS supports attaching
+properties to CRTCs, connectors and planes and offers a userspace API to
+list, get and set the property values.
+
+Properties are identified by a name that uniquely defines the property
+purpose, and store an associated value. For all property types except
+blob properties the value is a 64-bit unsigned integer.
+
+KMS differentiates between properties and property instances. Drivers
+first create properties and then create and associate individual
+instances of those properties to objects. A property can be instantiated
+multiple times and associated with different objects. Values are stored
+in property instances, and all other property information are stored in
+the property and shared between all instances of the property.
+
+Every property is created with a type that influences how the KMS core
+handles the property. Supported property types are
+
+DRM_MODE_PROP_RANGE
+    Range properties report their minimum and maximum admissible values.
+    The KMS core verifies that values set by application fit in that
+    range.
+
+DRM_MODE_PROP_ENUM
+    Enumerated properties take a numerical value that ranges from 0 to
+    the number of enumerated values defined by the property minus one,
+    and associate a free-formed string name to each value. Applications
+    can retrieve the list of defined value-name pairs and use the
+    numerical value to get and set property instance values.
+
+DRM_MODE_PROP_BITMASK
+    Bitmask properties are enumeration properties that additionally
+    restrict all enumerated values to the 0..63 range. Bitmask property
+    instance values combine one or more of the enumerated bits defined
+    by the property.
+
+DRM_MODE_PROP_BLOB
+    Blob properties store a binary blob without any format restriction.
+    The binary blobs are created as KMS standalone objects, and blob
+    property instance values store the ID of their associated blob
+    object.
+
+    Blob properties are only used for the connector EDID property and
+    cannot be created by drivers.
+
+To create a property drivers call one of the following functions
+depending on the property type. All property creation functions take
+property flags and name, as well as type-specific arguments.
+
+-  struct drm_property \*drm_property_create_range(struct
+   drm_device \*dev, int flags, const char \*name, uint64_t min,
+   uint64_t max);
+   Create a range property with the given minimum and maximum values.
+
+-  struct drm_property \*drm_property_create_enum(struct drm_device
+   \*dev, int flags, const char \*name, const struct
+   drm_prop_enum_list \*props, int num_values);
+   Create an enumerated property. The ``props`` argument points to an
+   array of ``num_values`` value-name pairs.
+
+-  struct drm_property \*drm_property_create_bitmask(struct
+   drm_device \*dev, int flags, const char \*name, const struct
+   drm_prop_enum_list \*props, int num_values);
+   Create a bitmask property. The ``props`` argument points to an array
+   of ``num_values`` value-name pairs.
+
+Properties can additionally be created as immutable, in which case they
+will be read-only for applications but can be modified by the driver. To
+create an immutable property drivers must set the
+DRM_MODE_PROP_IMMUTABLE flag at property creation time.
+
+When no array of value-name pairs is readily available at property
+creation time for enumerated or range properties, drivers can create the
+property using the :c:func:`drm_property_create` function and
+manually add enumeration value-name pairs by calling the
+:c:func:`drm_property_add_enum` function. Care must be taken to
+properly specify the property type through the ``flags`` argument.
+
+After creating properties drivers can attach property instances to CRTC,
+connector and plane objects by calling the
+:c:func:`drm_object_attach_property`. The function takes a
+pointer to the target object, a pointer to the previously created
+property and an initial instance value.
+
+Existing KMS Properties
+~~~~~~~~~~~~~~~~~~~~~~~
+
+The following table gives description of drm properties exposed by
+various modules/drivers.
+
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| Owner Module/Drivers          | Group                | Property Name                                                                                                      | Type                                                                              | Property Values                                                                                                                                                                                                                                                                                                                                                                                                        | Object attached                                   | Description/Restrictions                                                                                                                                                                      |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| DRM                           | Generic              | “rotation”                                                                                                         | BITMASK                                                                           | { 0, "rotate-0" }, { 1, "rotate-90" }, { 2, "rotate-180" }, { 3, "rotate-270" }, { 4, "reflect-x" }, { 5, "reflect-y" }                                                                                                                                                                                                                                                                                                | CRTC, Plane                                       | rotate-(degrees) rotates the image by the specified amount in degrees in counter clockwise direction. reflect-x and reflect-y reflects the image along the specified axis prior to rotation   |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| Connector                     | “EDID”               | BLOB \| IMMUTABLE                                                                                                  | 0                                                                                 | Connector                                                                                                                                                                                                                                                                                                                                                                                                              | Contains id of edid blob ptr object.              |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “DPMS”                        | ENUM                 | { “On”, “Standby”, “Suspend”, “Off” }                                                                              | Connector                                                                         | Contains DPMS operation mode value.                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “PATH”                        | BLOB \| IMMUTABLE    | 0                                                                                                                  | Connector                                                                         | Contains topology path to a connector.                                                                                                                                                                                                                                                                                                                                                                                 |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “TILE”                        | BLOB \| IMMUTABLE    | 0                                                                                                                  | Connector                                                                         | Contains tiling information for a connector.                                                                                                                                                                                                                                                                                                                                                                           |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “CRTC_ID”                    | OBJECT               | DRM_MODE_OBJECT_CRTC                                                                                            | Connector                                                                         | CRTC that connector is attached to (atomic)                                                                                                                                                                                                                                                                                                                                                                            |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| Plane                         | “type”               | ENUM \| IMMUTABLE                                                                                                  | { "Overlay", "Primary", "Cursor" }                                                | Plane                                                                                                                                                                                                                                                                                                                                                                                                                  | Plane type                                        |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “SRC_X”                      | RANGE                | Min=0, Max=UINT_MAX                                                                                               | Plane                                                                             | Scanout source x coordinate in 16.16 fixed point (atomic)                                                                                                                                                                                                                                                                                                                                                              |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “SRC_Y”                      | RANGE                | Min=0, Max=UINT_MAX                                                                                               | Plane                                                                             | Scanout source y coordinate in 16.16 fixed point (atomic)                                                                                                                                                                                                                                                                                                                                                              |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “SRC_W”                      | RANGE                | Min=0, Max=UINT_MAX                                                                                               | Plane                                                                             | Scanout source width in 16.16 fixed point (atomic)                                                                                                                                                                                                                                                                                                                                                                     |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “SRC_H”                      | RANGE                | Min=0, Max=UINT_MAX                                                                                               | Plane                                                                             | Scanout source height in 16.16 fixed point (atomic)                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “CRTC_X”                     | SIGNED_RANGE        | Min=INT_MIN, Max=INT_MAX                                                                                         | Plane                                                                             | Scanout CRTC (destination) x coordinate (atomic)                                                                                                                                                                                                                                                                                                                                                                       |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “CRTC_Y”                     | SIGNED_RANGE        | Min=INT_MIN, Max=INT_MAX                                                                                         | Plane                                                                             | Scanout CRTC (destination) y coordinate (atomic)                                                                                                                                                                                                                                                                                                                                                                       |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “CRTC_W”                     | RANGE                | Min=0, Max=UINT_MAX                                                                                               | Plane                                                                             | Scanout CRTC (destination) width (atomic)                                                                                                                                                                                                                                                                                                                                                                              |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “CRTC_H”                     | RANGE                | Min=0, Max=UINT_MAX                                                                                               | Plane                                                                             | Scanout CRTC (destination) height (atomic)                                                                                                                                                                                                                                                                                                                                                                             |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “FB_ID”                      | OBJECT               | DRM_MODE_OBJECT_FB                                                                                              | Plane                                                                             | Scanout framebuffer (atomic)                                                                                                                                                                                                                                                                                                                                                                                           |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “CRTC_ID”                    | OBJECT               | DRM_MODE_OBJECT_CRTC                                                                                            | Plane                                                                             | CRTC that plane is attached to (atomic)                                                                                                                                                                                                                                                                                                                                                                                |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| DVI-I                         | “subconnector”       | ENUM                                                                                                               | { “Unknown”, “DVI-D”, “DVI-A” }                                                   | Connector                                                                                                                                                                                                                                                                                                                                                                                                              | TBD                                               |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “select subconnector”         | ENUM                 | { “Automatic”, “DVI-D”, “DVI-A” }                                                                                  | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| TV                            | “subconnector”       | ENUM                                                                                                               | { "Unknown", "Composite", "SVIDEO", "Component", "SCART" }                        | Connector                                                                                                                                                                                                                                                                                                                                                                                                              | TBD                                               |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “select subconnector”         | ENUM                 | { "Automatic", "Composite", "SVIDEO", "Component", "SCART" }                                                       | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “mode”                        | ENUM                 | { "NTSC_M", "NTSC_J", "NTSC_443", "PAL_B" } etc.                                                               | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “left margin”                 | RANGE                | Min=0, Max=100                                                                                                     | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “right margin”                | RANGE                | Min=0, Max=100                                                                                                     | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “top margin”                  | RANGE                | Min=0, Max=100                                                                                                     | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “bottom margin”               | RANGE                | Min=0, Max=100                                                                                                     | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “brightness”                  | RANGE                | Min=0, Max=100                                                                                                     | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “contrast”                    | RANGE                | Min=0, Max=100                                                                                                     | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “flicker reduction”           | RANGE                | Min=0, Max=100                                                                                                     | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “overscan”                    | RANGE                | Min=0, Max=100                                                                                                     | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “saturation”                  | RANGE                | Min=0, Max=100                                                                                                     | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “hue”                         | RANGE                | Min=0, Max=100                                                                                                     | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| Virtual GPU                   | “suggested X”        | RANGE                                                                                                              | Min=0, Max=0xffffffff                                                             | Connector                                                                                                                                                                                                                                                                                                                                                                                                              | property to suggest an X offset for a connector   |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “suggested Y”                 | RANGE                | Min=0, Max=0xffffffff                                                                                              | Connector                                                                         | property to suggest an Y offset for a connector                                                                                                                                                                                                                                                                                                                                                                        |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| Optional                      | “scaling mode”       | ENUM                                                                                                               | { "None", "Full", "Center", "Full aspect" }                                       | Connector                                                                                                                                                                                                                                                                                                                                                                                                              | TBD                                               |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| "aspect ratio"                | ENUM                 | { "None", "4:3", "16:9" }                                                                                          | Connector                                                                         | DRM property to set aspect ratio from user space app. This enum is made generic to allow addition of custom aspect ratios.                                                                                                                                                                                                                                                                                             |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “dirty”                       | ENUM \| IMMUTABLE    | { "Off", "On", "Annotate" }                                                                                        | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “DEGAMMA_LUT”                | BLOB                 | 0                                                                                                                  | CRTC                                                                              | DRM property to set the degamma lookup table (LUT) mapping pixel data from the framebuffer before it is given to the transformation matrix. The data is an interpreted as an array of struct drm_color_lut elements. Hardware might choose not to use the full precision of the LUT elements nor use all the elements of the LUT (for example the hardware might choose to interpolate between LUT[0] and LUT[4]).   |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “DEGAMMA_LUT_SIZE”          | RANGE \| IMMUTABLE   | Min=0, Max=UINT_MAX                                                                                               | CRTC                                                                              | DRM property to gives the size of the lookup table to be set on the DEGAMMA_LUT property (the size depends on the underlying hardware).                                                                                                                                                                                                                                                                               |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “CTM”                         | BLOB                 | 0                                                                                                                  | CRTC                                                                              | DRM property to set the current transformation matrix (CTM) apply to pixel data after the lookup through the degamma LUT and before the lookup through the gamma LUT. The data is an interpreted as a struct drm_color_ctm.                                                                                                                                                                                          |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “GAMMA_LUT”                  | BLOB                 | 0                                                                                                                  | CRTC                                                                              | DRM property to set the gamma lookup table (LUT) mapping pixel data after to the transformation matrix to data sent to the connector. The data is an interpreted as an array of struct drm_color_lut elements. Hardware might choose not to use the full precision of the LUT elements nor use all the elements of the LUT (for example the hardware might choose to interpolate between LUT[0] and LUT[4]).         |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “GAMMA_LUT_SIZE”            | RANGE \| IMMUTABLE   | Min=0, Max=UINT_MAX                                                                                               | CRTC                                                                              | DRM property to gives the size of the lookup table to be set on the GAMMA_LUT property (the size depends on the underlying hardware).                                                                                                                                                                                                                                                                                 |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| i915                          | Generic              | "Broadcast RGB"                                                                                                    | ENUM                                                                              | { "Automatic", "Full", "Limited 16:235" }                                                                                                                                                                                                                                                                                                                                                                              | Connector                                         | TBD                                                                                                                                                                                           |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “audio”                       | ENUM                 | { "force-dvi", "off", "auto", "on" }                                                                               | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| SDVO-TV                       | “mode”               | ENUM                                                                                                               | { "NTSC_M", "NTSC_J", "NTSC_443", "PAL_B" } etc.                              | Connector                                                                                                                                                                                                                                                                                                                                                                                                              | TBD                                               |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| "left_margin"                | RANGE                | Min=0, Max= SDVO dependent                                                                                         | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| "right_margin"               | RANGE                | Min=0, Max= SDVO dependent                                                                                         | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| "top_margin"                 | RANGE                | Min=0, Max= SDVO dependent                                                                                         | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| "bottom_margin"              | RANGE                | Min=0, Max= SDVO dependent                                                                                         | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “hpos”                        | RANGE                | Min=0, Max= SDVO dependent                                                                                         | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “vpos”                        | RANGE                | Min=0, Max= SDVO dependent                                                                                         | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “contrast”                    | RANGE                | Min=0, Max= SDVO dependent                                                                                         | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “saturation”                  | RANGE                | Min=0, Max= SDVO dependent                                                                                         | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “hue”                         | RANGE                | Min=0, Max= SDVO dependent                                                                                         | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “sharpness”                   | RANGE                | Min=0, Max= SDVO dependent                                                                                         | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “flicker_filter”             | RANGE                | Min=0, Max= SDVO dependent                                                                                         | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “flicker_filter_adaptive”   | RANGE                | Min=0, Max= SDVO dependent                                                                                         | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “flicker_filter_2d”         | RANGE                | Min=0, Max= SDVO dependent                                                                                         | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “tv_chroma_filter”          | RANGE                | Min=0, Max= SDVO dependent                                                                                         | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “tv_luma_filter”            | RANGE                | Min=0, Max= SDVO dependent                                                                                         | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “dot_crawl”                  | RANGE                | Min=0, Max=1                                                                                                       | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| SDVO-TV/LVDS                  | “brightness”         | RANGE                                                                                                              | Min=0, Max= SDVO dependent                                                        | Connector                                                                                                                                                                                                                                                                                                                                                                                                              | TBD                                               |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| CDV gma-500                   | Generic              | "Broadcast RGB"                                                                                                    | ENUM                                                                              | { “Full”, “Limited 16:235” }                                                                                                                                                                                                                                                                                                                                                                                           | Connector                                         | TBD                                                                                                                                                                                           |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| "Broadcast RGB"               | ENUM                 | { “off”, “auto”, “on” }                                                                                            | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| Poulsbo                       | Generic              | “backlight”                                                                                                        | RANGE                                                                             | Min=0, Max=100                                                                                                                                                                                                                                                                                                                                                                                                         | Connector                                         | TBD                                                                                                                                                                                           |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| SDVO-TV                       | “mode”               | ENUM                                                                                                               | { "NTSC_M", "NTSC_J", "NTSC_443", "PAL_B" } etc.                              | Connector                                                                                                                                                                                                                                                                                                                                                                                                              | TBD                                               |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| "left_margin"                | RANGE                | Min=0, Max= SDVO dependent                                                                                         | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| "right_margin"               | RANGE                | Min=0, Max= SDVO dependent                                                                                         | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| "top_margin"                 | RANGE                | Min=0, Max= SDVO dependent                                                                                         | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| "bottom_margin"              | RANGE                | Min=0, Max= SDVO dependent                                                                                         | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “hpos”                        | RANGE                | Min=0, Max= SDVO dependent                                                                                         | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “vpos”                        | RANGE                | Min=0, Max= SDVO dependent                                                                                         | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “contrast”                    | RANGE                | Min=0, Max= SDVO dependent                                                                                         | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “saturation”                  | RANGE                | Min=0, Max= SDVO dependent                                                                                         | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “hue”                         | RANGE                | Min=0, Max= SDVO dependent                                                                                         | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “sharpness”                   | RANGE                | Min=0, Max= SDVO dependent                                                                                         | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “flicker_filter”             | RANGE                | Min=0, Max= SDVO dependent                                                                                         | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “flicker_filter_adaptive”   | RANGE                | Min=0, Max= SDVO dependent                                                                                         | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “flicker_filter_2d”         | RANGE                | Min=0, Max= SDVO dependent                                                                                         | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “tv_chroma_filter”          | RANGE                | Min=0, Max= SDVO dependent                                                                                         | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “tv_luma_filter”            | RANGE                | Min=0, Max= SDVO dependent                                                                                         | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “dot_crawl”                  | RANGE                | Min=0, Max=1                                                                                                       | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| SDVO-TV/LVDS                  | “brightness”         | RANGE                                                                                                              | Min=0, Max= SDVO dependent                                                        | Connector                                                                                                                                                                                                                                                                                                                                                                                                              | TBD                                               |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| armada                        | CRTC                 | "CSC_YUV"                                                                                                         | ENUM                                                                              | { "Auto" , "CCIR601", "CCIR709" }                                                                                                                                                                                                                                                                                                                                                                                      | CRTC                                              | TBD                                                                                                                                                                                           |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| "CSC_RGB"                    | ENUM                 | { "Auto", "Computer system", "Studio" }                                                                            | CRTC                                                                              | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| Overlay                       | "colorkey"           | RANGE                                                                                                              | Min=0, Max=0xffffff                                                               | Plane                                                                                                                                                                                                                                                                                                                                                                                                                  | TBD                                               |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| "colorkey_min"               | RANGE                | Min=0, Max=0xffffff                                                                                                | Plane                                                                             | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| "colorkey_max"               | RANGE                | Min=0, Max=0xffffff                                                                                                | Plane                                                                             | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| "colorkey_val"               | RANGE                | Min=0, Max=0xffffff                                                                                                | Plane                                                                             | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| "colorkey_alpha"             | RANGE                | Min=0, Max=0xffffff                                                                                                | Plane                                                                             | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| "colorkey_mode"              | ENUM                 | { "disabled", "Y component", "U component" , "V component", "RGB", “R component", "G component", "B component" }   | Plane                                                                             | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| "brightness"                  | RANGE                | Min=0, Max=256 + 255                                                                                               | Plane                                                                             | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| "contrast"                    | RANGE                | Min=0, Max=0x7fff                                                                                                  | Plane                                                                             | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| "saturation"                  | RANGE                | Min=0, Max=0x7fff                                                                                                  | Plane                                                                             | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| exynos                        | CRTC                 | “mode”                                                                                                             | ENUM                                                                              | { "normal", "blank" }                                                                                                                                                                                                                                                                                                                                                                                                  | CRTC                                              | TBD                                                                                                                                                                                           |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| Overlay                       | “zpos”               | RANGE                                                                                                              | Min=0, Max=MAX_PLANE-1                                                           | Plane                                                                                                                                                                                                                                                                                                                                                                                                                  | TBD                                               |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| i2c/ch7006_drv               | Generic              | “scale”                                                                                                            | RANGE                                                                             | Min=0, Max=2                                                                                                                                                                                                                                                                                                                                                                                                           | Connector                                         | TBD                                                                                                                                                                                           |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| TV                            | “mode”               | ENUM                                                                                                               | { "PAL", "PAL-M","PAL-N"}, ”PAL-Nc" , "PAL-60", "NTSC-M", "NTSC-J" }              | Connector                                                                                                                                                                                                                                                                                                                                                                                                              | TBD                                               |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| nouveau                       | NV10 Overlay         | "colorkey"                                                                                                         | RANGE                                                                             | Min=0, Max=0x01ffffff                                                                                                                                                                                                                                                                                                                                                                                                  | Plane                                             | TBD                                                                                                                                                                                           |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “contrast”                    | RANGE                | Min=0, Max=8192-1                                                                                                  | Plane                                                                             | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “brightness”                  | RANGE                | Min=0, Max=1024                                                                                                    | Plane                                                                             | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “hue”                         | RANGE                | Min=0, Max=359                                                                                                     | Plane                                                                             | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “saturation”                  | RANGE                | Min=0, Max=8192-1                                                                                                  | Plane                                                                             | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “iturbt_709”                 | RANGE                | Min=0, Max=1                                                                                                       | Plane                                                                             | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| Nv04 Overlay                  | “colorkey”           | RANGE                                                                                                              | Min=0, Max=0x01ffffff                                                             | Plane                                                                                                                                                                                                                                                                                                                                                                                                                  | TBD                                               |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “brightness”                  | RANGE                | Min=0, Max=1024                                                                                                    | Plane                                                                             | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| Display                       | “dithering mode”     | ENUM                                                                                                               | { "auto", "off", "on" }                                                           | Connector                                                                                                                                                                                                                                                                                                                                                                                                              | TBD                                               |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “dithering depth”             | ENUM                 | { "auto", "off", "on", "static 2x2", "dynamic 2x2", "temporal" }                                                   | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “underscan”                   | ENUM                 | { "auto", "6 bpc", "8 bpc" }                                                                                       | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “underscan hborder”           | RANGE                | Min=0, Max=128                                                                                                     | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “underscan vborder”           | RANGE                | Min=0, Max=128                                                                                                     | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “vibrant hue”                 | RANGE                | Min=0, Max=180                                                                                                     | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| “color vibrance”              | RANGE                | Min=0, Max=200                                                                                                     | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| omap                          | Generic              | “zorder”                                                                                                           | RANGE                                                                             | Min=0, Max=3                                                                                                                                                                                                                                                                                                                                                                                                           | CRTC, Plane                                       | TBD                                                                                                                                                                                           |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| qxl                           | Generic              | “hotplug_mode_update"                                                                                            | RANGE                                                                             | Min=0, Max=1                                                                                                                                                                                                                                                                                                                                                                                                           | Connector                                         | TBD                                                                                                                                                                                           |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| radeon                        | DVI-I                | “coherent”                                                                                                         | RANGE                                                                             | Min=0, Max=1                                                                                                                                                                                                                                                                                                                                                                                                           | Connector                                         | TBD                                                                                                                                                                                           |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| DAC enable load detect        | “load detection”     | RANGE                                                                                                              | Min=0, Max=1                                                                      | Connector                                                                                                                                                                                                                                                                                                                                                                                                              | TBD                                               |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| TV Standard                   | "tv standard"        | ENUM                                                                                                               | { "ntsc", "pal", "pal-m", "pal-60", "ntsc-j" , "scart-pal", "pal-cn", "secam" }   | Connector                                                                                                                                                                                                                                                                                                                                                                                                              | TBD                                               |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| legacy TMDS PLL detect        | "tmds_pll"          | ENUM                                                                                                               | { "driver", "bios" }                                                              | -                                                                                                                                                                                                                                                                                                                                                                                                                      | TBD                                               |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| Underscan                     | "underscan"          | ENUM                                                                                                               | { "off", "on", "auto" }                                                           | Connector                                                                                                                                                                                                                                                                                                                                                                                                              | TBD                                               |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| "underscan hborder"           | RANGE                | Min=0, Max=128                                                                                                     | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| "underscan vborder"           | RANGE                | Min=0, Max=128                                                                                                     | Connector                                                                         | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| Audio                         | “audio”              | ENUM                                                                                                               | { "off", "on", "auto" }                                                           | Connector                                                                                                                                                                                                                                                                                                                                                                                                              | TBD                                               |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| FMT Dithering                 | “dither”             | ENUM                                                                                                               | { "off", "on" }                                                                   | Connector                                                                                                                                                                                                                                                                                                                                                                                                              | TBD                                               |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| rcar-du                       | Generic              | "alpha"                                                                                                            | RANGE                                                                             | Min=0, Max=255                                                                                                                                                                                                                                                                                                                                                                                                         | Plane                                             | TBD                                                                                                                                                                                           |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| "colorkey"                    | RANGE                | Min=0, Max=0x01ffffff                                                                                              | Plane                                                                             | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| "zpos"                        | RANGE                | Min=1, Max=7                                                                                                       | Plane                                                                             | TBD                                                                                                                                                                                                                                                                                                                                                                                                                    |
++-------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+
+Vertical Blanking
+-----------------
+
+Vertical blanking plays a major role in graphics rendering. To achieve
+tear-free display, users must synchronize page flips and/or rendering to
+vertical blanking. The DRM API offers ioctls to perform page flips
+synchronized to vertical blanking and wait for vertical blanking.
+
+The DRM core handles most of the vertical blanking management logic,
+which involves filtering out spurious interrupts, keeping race-free
+blanking counters, coping with counter wrap-around and resets and
+keeping use counts. It relies on the driver to generate vertical
+blanking interrupts and optionally provide a hardware vertical blanking
+counter. Drivers must implement the following operations.
+
+-  int (\*enable_vblank) (struct drm_device \*dev, int crtc); void
+   (\*disable_vblank) (struct drm_device \*dev, int crtc);
+   Enable or disable vertical blanking interrupts for the given CRTC.
+
+-  u32 (\*get_vblank_counter) (struct drm_device \*dev, int crtc);
+   Retrieve the value of the vertical blanking counter for the given
+   CRTC. If the hardware maintains a vertical blanking counter its value
+   should be returned. Otherwise drivers can use the
+   :c:func:`drm_vblank_count` helper function to handle this
+   operation.
+
+Drivers must initialize the vertical blanking handling core with a call
+to :c:func:`drm_vblank_init` in their load operation. The function
+will set the struct :ref:`struct drm_device`
+vblank_disable_allowed field to 0. This will keep vertical blanking
+interrupts enabled permanently until the first mode set operation, where
+vblank_disable_allowed is set to 1. The reason behind this is not
+clear. Drivers can set the field to 1 after :c:func:`calling
+drm_vblank_init` to make vertical blanking interrupts dynamically
+managed from the beginning.
+
+Vertical blanking interrupts can be enabled by the DRM core or by
+drivers themselves (for instance to handle page flipping operations).
+The DRM core maintains a vertical blanking use count to ensure that the
+interrupts are not disabled while a user still needs them. To increment
+the use count, drivers call :c:func:`drm_vblank_get`. Upon return
+vertical blanking interrupts are guaranteed to be enabled.
+
+To decrement the use count drivers call :c:func:`drm_vblank_put`.
+Only when the use count drops to zero will the DRM core disable the
+vertical blanking interrupts after a delay by scheduling a timer. The
+delay is accessible through the vblankoffdelay module parameter or the
+``drm_vblank_offdelay`` global variable and expressed in milliseconds.
+Its default value is 5000 ms. Zero means never disable, and a negative
+value means disable immediately. Drivers may override the behaviour by
+setting the :ref:`struct drm_device` vblank_disable_immediate
+flag, which when set causes vblank interrupts to be disabled immediately
+regardless of the drm_vblank_offdelay value. The flag should only be
+set if there's a properly working hardware vblank counter present.
+
+When a vertical blanking interrupt occurs drivers only need to call the
+:c:func:`drm_handle_vblank` function to account for the interrupt.
+
+Resources allocated by :c:func:`drm_vblank_init` must be freed
+with a call to :c:func:`drm_vblank_cleanup` in the driver unload
+operation handler.
+
+Vertical Blanking and Interrupt Handling Functions Reference
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/drm_irq.c
+   :export:
+
+.. kernel-doc:: include/drm/drmP.h
+   :functions: drm_crtc_vblank_waitqueue
+
+Open/Close, File Operations and IOCTLs
+--------------------------------------
+
+Open and Close
+~~~~~~~~~~~~~~
+
+int (\*firstopen) (struct drm_device \*); void (\*lastclose) (struct
+drm_device \*); int (\*open) (struct drm_device \*, struct drm_file
+\*); void (\*preclose) (struct drm_device \*, struct drm_file \*);
+void (\*postclose) (struct drm_device \*, struct drm_file \*);
+    Open and close handlers. None of those methods are mandatory.
+
+The firstopen method is called by the DRM core for legacy UMS (User Mode
+Setting) drivers only when an application opens a device that has no
+other opened file handle. UMS drivers can implement it to acquire device
+resources. KMS drivers can't use the method and must acquire resources
+in the load method instead.
+
+Similarly the lastclose method is called when the last application
+holding a file handle opened on the device closes it, for both UMS and
+KMS drivers. Additionally, the method is also called at module unload
+time or, for hot-pluggable devices, when the device is unplugged. The
+firstopen and lastclose calls can thus be unbalanced.
+
+The open method is called every time the device is opened by an
+application. Drivers can allocate per-file private data in this method
+and store them in the struct :ref:`struct drm_file` driver_priv
+field. Note that the open method is called before firstopen.
+
+The close operation is split into preclose and postclose methods.
+Drivers must stop and cleanup all per-file operations in the preclose
+method. For instance pending vertical blanking and page flip events must
+be cancelled. No per-file operation is allowed on the file handle after
+returning from the preclose method.
+
+Finally the postclose method is called as the last step of the close
+operation, right before calling the lastclose method if no other open
+file handle exists for the device. Drivers that have allocated per-file
+private data in the open method should free it here.
+
+The lastclose method should restore CRTC and plane properties to default
+value, so that a subsequent open of the device will not inherit state
+from the previous user. It can also be used to execute delayed power
+switching state changes, e.g. in conjunction with the vga_switcheroo
+infrastructure (see ?). Beyond that KMS drivers should not do any
+further cleanup. Only legacy UMS drivers might need to clean up device
+state so that the vga console or an independent fbdev driver could take
+over.
+
+File Operations
+~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/drm_fops.c
+   :doc: file operations
+
+.. kernel-doc:: drivers/gpu/drm/drm_fops.c
+   :export:
+
+IOCTLs
+~~~~~~
+
+struct drm_ioctl_desc \*ioctls; int num_ioctls;
+    Driver-specific ioctls descriptors table.
+
+Driver-specific ioctls numbers start at DRM_COMMAND_BASE. The ioctls
+descriptors table is indexed by the ioctl number offset from the base
+value. Drivers can use the DRM_IOCTL_DEF_DRV() macro to initialize
+the table entries.
+
+::
+
+    DRM_IOCTL_DEF_DRV(ioctl, func, flags)
+
+``ioctl`` is the ioctl name. Drivers must define the DRM_##ioctl and
+DRM_IOCTL_##ioctl macros to the ioctl number offset from
+DRM_COMMAND_BASE and the ioctl number respectively. The first macro is
+private to the device while the second must be exposed to userspace in a
+public header.
+
+``func`` is a pointer to the ioctl handler function compatible with the
+``drm_ioctl_t`` type.
+
+::
+
+    typedef int drm_ioctl_t(struct drm_device *dev, void *data,
+            struct drm_file *file_priv);
+
+``flags`` is a bitmask combination of the following values. It restricts
+how the ioctl is allowed to be called.
+
+-  DRM_AUTH - Only authenticated callers allowed
+
+-  DRM_MASTER - The ioctl can only be called on the master file handle
+
+-  DRM_ROOT_ONLY - Only callers with the SYSADMIN capability allowed
+
+-  DRM_CONTROL_ALLOW - The ioctl can only be called on a control
+   device
+
+-  DRM_UNLOCKED - The ioctl handler will be called without locking the
+   DRM global mutex. This is the enforced default for kms drivers (i.e.
+   using the DRIVER_MODESET flag) and hence shouldn't be used any more
+   for new drivers.
+
+.. kernel-doc:: drivers/gpu/drm/drm_ioctl.c
+   :export:
+
+Legacy Support Code
+-------------------
+
+The section very briefly covers some of the old legacy support code
+which is only used by old DRM drivers which have done a so-called
+shadow-attach to the underlying device instead of registering as a real
+driver. This also includes some of the old generic buffer management and
+command submission code. Do not use any of this in new and modern
+drivers.
+
+Legacy Suspend/Resume
+~~~~~~~~~~~~~~~~~~~~~
+
+The DRM core provides some suspend/resume code, but drivers wanting full
+suspend/resume support should provide save() and restore() functions.
+These are called at suspend, hibernate, or resume time, and should
+perform any state save or restore required by your device across suspend
+or hibernate states.
+
+int (\*suspend) (struct drm_device \*, pm_message_t state); int
+(\*resume) (struct drm_device \*);
+Those are legacy suspend and resume methods which *only* work with the
+legacy shadow-attach driver registration functions. New driver should
+use the power management interface provided by their bus type (usually
+through the struct :ref:`struct device_driver` dev_pm_ops) and
+set these methods to NULL.
+
+Legacy DMA Services
+~~~~~~~~~~~~~~~~~~~
+
+This should cover how DMA mapping etc. is supported by the core. These
+functions are deprecated and should not be used.
+
+Userland interfaces
+===================
+
+The DRM core exports several interfaces to applications, generally
+intended to be used through corresponding libdrm wrapper functions. In
+addition, drivers export device-specific interfaces for use by userspace
+drivers & device-aware applications through ioctls and sysfs files.
+
+External interfaces include: memory mapping, context management, DMA
+operations, AGP management, vblank control, fence management, memory
+management, and output management.
+
+Cover generic ioctls and sysfs layout here. We only need high-level
+info, since man pages should cover the rest.
+
+Render nodes
+------------
+
+DRM core provides multiple character-devices for user-space to use.
+Depending on which device is opened, user-space can perform a different
+set of operations (mainly ioctls). The primary node is always created
+and called card<num>. Additionally, a currently unused control node,
+called controlD<num> is also created. The primary node provides all
+legacy operations and historically was the only interface used by
+userspace. With KMS, the control node was introduced. However, the
+planned KMS control interface has never been written and so the control
+node stays unused to date.
+
+With the increased use of offscreen renderers and GPGPU applications,
+clients no longer require running compositors or graphics servers to
+make use of a GPU. But the DRM API required unprivileged clients to
+authenticate to a DRM-Master prior to getting GPU access. To avoid this
+step and to grant clients GPU access without authenticating, render
+nodes were introduced. Render nodes solely serve render clients, that
+is, no modesetting or privileged ioctls can be issued on render nodes.
+Only non-global rendering commands are allowed. If a driver supports
+render nodes, it must advertise it via the DRIVER_RENDER DRM driver
+capability. If not supported, the primary node must be used for render
+clients together with the legacy drmAuth authentication procedure.
+
+If a driver advertises render node support, DRM core will create a
+separate render node called renderD<num>. There will be one render node
+per device. No ioctls except PRIME-related ioctls will be allowed on
+this node. Especially GEM_OPEN will be explicitly prohibited. Render
+nodes are designed to avoid the buffer-leaks, which occur if clients
+guess the flink names or mmap offsets on the legacy interface.
+Additionally to this basic interface, drivers must mark their
+driver-dependent render-only ioctls as DRM_RENDER_ALLOW so render
+clients can use them. Driver authors must be careful not to allow any
+privileged ioctls on render nodes.
+
+With render nodes, user-space can now control access to the render node
+via basic file-system access-modes. A running graphics server which
+authenticates clients on the privileged primary/legacy node is no longer
+required. Instead, a client can open the render node and is immediately
+granted GPU access. Communication between clients (or servers) is done
+via PRIME. FLINK from render node to legacy node is not supported. New
+clients must not use the insecure FLINK interface.
+
+Besides dropping all modeset/global ioctls, render nodes also drop the
+DRM-Master concept. There is no reason to associate render clients with
+a DRM-Master as they are independent of any graphics server. Besides,
+they must work without any running master, anyway. Drivers must be able
+to run without a master object if they support render nodes. If, on the
+other hand, a driver requires shared state between clients which is
+visible to user-space and accessible beyond open-file boundaries, they
+cannot support render nodes.
+
+VBlank event handling
+---------------------
+
+The DRM core exposes two vertical blank related ioctls:
+
+DRM_IOCTL_WAIT_VBLANK
+    This takes a struct drm_wait_vblank structure as its argument, and
+    it is used to block or request a signal when a specified vblank
+    event occurs.
+
+DRM_IOCTL_MODESET_CTL
+    This was only used for user-mode-settind drivers around modesetting
+    changes to allow the kernel to update the vblank interrupt after
+    mode setting, since on many devices the vertical blank counter is
+    reset to 0 at some point during modeset. Modern drivers should not
+    call this any more since with kernel mode setting it is a no-op.
+
+This second part of the GPU Driver Developer's Guide documents driver
+code, implementation details and also all the driver-specific userspace
+interfaces. Especially since all hardware-acceleration interfaces to
+userspace are driver specific for efficiency and other reasons these
+interfaces can be rather substantial. Hence every driver has its own
+chapter.
+
+drm/i915 Intel GFX Driver
+=========================
+
+The drm/i915 driver supports all (with the exception of some very early
+models) integrated GFX chipsets with both Intel display and rendering
+blocks. This excludes a set of SoC platforms with an SGX rendering unit,
+those have basic support through the gma500 drm driver.
+
+Core Driver Infrastructure
+--------------------------
+
+This section covers core driver infrastructure used by both the display
+and the GEM parts of the driver.
+
+Runtime Power Management
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_runtime_pm.c
+   :doc: runtime pm
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_runtime_pm.c
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_uncore.c
+   :internal:
+
+Interrupt Handling
+~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/i915/i915_irq.c
+   :doc: interrupt handling
+
+.. kernel-doc:: drivers/gpu/drm/i915/i915_irq.c
+   :functions: intel_irq_init intel_irq_init_hw intel_hpd_init
+
+.. kernel-doc:: drivers/gpu/drm/i915/i915_irq.c
+   :functions: intel_runtime_pm_disable_interrupts
+
+.. kernel-doc:: drivers/gpu/drm/i915/i915_irq.c
+   :functions: intel_runtime_pm_enable_interrupts
+
+Intel GVT-g Guest Support(vGPU)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/i915/i915_vgpu.c
+   :doc: Intel GVT-g guest support
+
+.. kernel-doc:: drivers/gpu/drm/i915/i915_vgpu.c
+   :internal:
+
+Display Hardware Handling
+-------------------------
+
+This section covers everything related to the display hardware including
+the mode setting infrastructure, plane, sprite and cursor handling and
+display, output probing and related topics.
+
+Mode Setting Infrastructure
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The i915 driver is thus far the only DRM driver which doesn't use the
+common DRM helper code to implement mode setting sequences. Thus it has
+its own tailor-made infrastructure for executing a display configuration
+change.
+
+Frontbuffer Tracking
+~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_frontbuffer.c
+   :doc: frontbuffer tracking
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_frontbuffer.c
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/i915/i915_gem.c
+   :functions: i915_gem_track_fb
+
+Display FIFO Underrun Reporting
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_fifo_underrun.c
+   :doc: fifo underrun handling
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_fifo_underrun.c
+   :internal:
+
+Plane Configuration
+~~~~~~~~~~~~~~~~~~~
+
+This section covers plane configuration and composition with the primary
+plane, sprites, cursors and overlays. This includes the infrastructure
+to do atomic vsync'ed updates of all this state and also tightly coupled
+topics like watermark setup and computation, framebuffer compression and
+panel self refresh.
+
+Atomic Plane Helpers
+~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_atomic_plane.c
+   :doc: atomic plane helpers
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_atomic_plane.c
+   :internal:
+
+Output Probing
+~~~~~~~~~~~~~~
+
+This section covers output probing and related infrastructure like the
+hotplug interrupt storm detection and mitigation code. Note that the
+i915 driver still uses most of the common DRM helper code for output
+probing, so those sections fully apply.
+
+Hotplug
+~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_hotplug.c
+   :doc: Hotplug
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_hotplug.c
+   :internal:
+
+High Definition Audio
+~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_audio.c
+   :doc: High Definition Audio over HDMI and Display Port
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_audio.c
+   :internal:
+
+.. kernel-doc:: include/drm/i915_component.h
+   :internal:
+
+Panel Self Refresh PSR (PSR/SRD)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_psr.c
+   :doc: Panel Self Refresh (PSR/SRD)
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_psr.c
+   :internal:
+
+Frame Buffer Compression (FBC)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_fbc.c
+   :doc: Frame Buffer Compression (FBC)
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_fbc.c
+   :internal:
+
+Display Refresh Rate Switching (DRRS)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_dp.c
+   :doc: Display Refresh Rate Switching (DRRS)
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_dp.c
+   :functions: intel_dp_set_drrs_state
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_dp.c
+   :functions: intel_edp_drrs_enable
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_dp.c
+   :functions: intel_edp_drrs_disable
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_dp.c
+   :functions: intel_edp_drrs_invalidate
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_dp.c
+   :functions: intel_edp_drrs_flush
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_dp.c
+   :functions: intel_dp_drrs_init
+
+DPIO
+~~~~
+
+.. kernel-doc:: drivers/gpu/drm/i915/i915_reg.h
+   :doc: DPIO
+
+CSR firmware support for DMC
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_csr.c
+   :doc: csr support for dmc
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_csr.c
+   :internal:
+
+Video BIOS Table (VBT)
+~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_bios.c
+   :doc: Video BIOS Table (VBT)
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_bios.c
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_bios.h
+   :internal:
+
+Memory Management and Command Submission
+----------------------------------------
+
+This sections covers all things related to the GEM implementation in the
+i915 driver.
+
+Batchbuffer Parsing
+~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/i915/i915_cmd_parser.c
+   :doc: batch buffer command parser
+
+.. kernel-doc:: drivers/gpu/drm/i915/i915_cmd_parser.c
+   :internal:
+
+Batchbuffer Pools
+~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/i915/i915_gem_batch_pool.c
+   :doc: batch pool
+
+.. kernel-doc:: drivers/gpu/drm/i915/i915_gem_batch_pool.c
+   :internal:
+
+Logical Rings, Logical Ring Contexts and Execlists
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_lrc.c
+   :doc: Logical Rings, Logical Ring Contexts and Execlists
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_lrc.c
+   :internal:
+
+Global GTT views
+~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/i915/i915_gem_gtt.c
+   :doc: Global GTT views
+
+.. kernel-doc:: drivers/gpu/drm/i915/i915_gem_gtt.c
+   :internal:
+
+GTT Fences and Swizzling
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/i915/i915_gem_fence.c
+   :internal:
+
+Global GTT Fence Handling
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. kernel-doc:: drivers/gpu/drm/i915/i915_gem_fence.c
+   :doc: fence register handling
+
+Hardware Tiling and Swizzling Details
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. kernel-doc:: drivers/gpu/drm/i915/i915_gem_fence.c
+   :doc: tiling swizzling details
+
+Object Tiling IOCTLs
+~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/i915/i915_gem_tiling.c
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/i915/i915_gem_tiling.c
+   :doc: buffer object tiling
+
+Buffer Object Eviction
+~~~~~~~~~~~~~~~~~~~~~~
+
+This section documents the interface functions for evicting buffer
+objects to make space available in the virtual gpu address spaces. Note
+that this is mostly orthogonal to shrinking buffer objects caches, which
+has the goal to make main memory (shared with the gpu through the
+unified memory architecture) available.
+
+.. kernel-doc:: drivers/gpu/drm/i915/i915_gem_evict.c
+   :internal:
+
+Buffer Object Memory Shrinking
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This section documents the interface function for shrinking memory usage
+of buffer object caches. Shrinking is used to make main memory
+available. Note that this is mostly orthogonal to evicting buffer
+objects, which has the goal to make space in gpu virtual address spaces.
+
+.. kernel-doc:: drivers/gpu/drm/i915/i915_gem_shrinker.c
+   :internal:
+
+GuC
+---
+
+GuC-specific firmware loader
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_loader.c
+   :doc: GuC-specific firmware loader
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_loader.c
+   :internal:
+
+GuC-based command submission
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/i915/i915_guc_submission.c
+   :doc: GuC-based command submission
+
+.. kernel-doc:: drivers/gpu/drm/i915/i915_guc_submission.c
+   :internal:
+
+GuC Firmware Layout
+~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_fwif.h
+   :doc: GuC Firmware Layout
+
+Tracing
+-------
+
+This sections covers all things related to the tracepoints implemented
+in the i915 driver.
+
+i915_ppgtt_create and i915_ppgtt_release
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/i915/i915_trace.h
+   :doc: i915_ppgtt_create and i915_ppgtt_release tracepoints
+
+i915_context_create and i915_context_free
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/i915/i915_trace.h
+   :doc: i915_context_create and i915_context_free tracepoints
+
+switch_mm
+~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/i915/i915_trace.h
+   :doc: switch_mm tracepoint
+
+.. WARNING: DOCPROC directive not supported: !Cdrivers/gpu/drm/i915/i915_irq.c
+
+.. kernel-doc:: drivers/gpu/vga/vga_switcheroo.c
+   :doc: Overview
+
+Modes of Use
+============
+
+Manual switching and manual power control
+-----------------------------------------
+
+.. kernel-doc:: drivers/gpu/vga/vga_switcheroo.c
+   :doc: Manual switching and manual power control
+
+Driver power control
+--------------------
+
+.. kernel-doc:: drivers/gpu/vga/vga_switcheroo.c
+   :doc: Driver power control
+
+API
+===
+
+Public functions
+----------------
+
+.. kernel-doc:: drivers/gpu/vga/vga_switcheroo.c
+   :export:
+
+Public structures
+-----------------
+
+.. kernel-doc:: include/linux/vga_switcheroo.h
+   :functions: vga_switcheroo_handler
+
+.. kernel-doc:: include/linux/vga_switcheroo.h
+   :functions: vga_switcheroo_client_ops
+
+Public constants
+----------------
+
+.. kernel-doc:: include/linux/vga_switcheroo.h
+   :functions: vga_switcheroo_handler_flags_t
+
+.. kernel-doc:: include/linux/vga_switcheroo.h
+   :functions: vga_switcheroo_client_id
+
+.. kernel-doc:: include/linux/vga_switcheroo.h
+   :functions: vga_switcheroo_state
+
+Private structures
+------------------
+
+.. kernel-doc:: drivers/gpu/vga/vga_switcheroo.c
+   :functions: vgasr_priv
+
+.. kernel-doc:: drivers/gpu/vga/vga_switcheroo.c
+   :functions: vga_switcheroo_client
+
+Handlers
+========
+
+apple-gmux Handler
+------------------
+
+.. kernel-doc:: drivers/platform/x86/apple-gmux.c
+   :doc: Overview
+
+.. kernel-doc:: drivers/platform/x86/apple-gmux.c
+   :doc: Interrupt
+
+Graphics mux
+~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/platform/x86/apple-gmux.c
+   :doc: Graphics mux
+
+Power control
+~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/platform/x86/apple-gmux.c
+   :doc: Power control
+
+Backlight control
+~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/platform/x86/apple-gmux.c
+   :doc: Backlight control
+
+Public functions
+~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: include/linux/apple-gmux.h
+   :internal:
+
+.. WARNING: DOCPROC directive not supported: !Cdrivers/gpu/vga/vga_switcheroo.c
+
+.. WARNING: DOCPROC directive not supported: !Cinclude/linux/vga_switcheroo.h
+
+.. WARNING: DOCPROC directive not supported: !Cdrivers/platform/x86/apple-gmux.c
diff --git a/Documentation/index.rst b/Documentation/index.rst
index 6ca68ef5c89a..7b520cda5a5c 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -17,6 +17,9 @@ Contents:
 
    kernel-hacking
    kernel-api
+   gpu
+   crypto-API
+   filesystems
 
 Indices and tables
 ==================
-- 
2.1.4

Re: [PATCH 00/10] Documentation/Sphinx

[Jani Nikula]

On Fri, 20 May 2016, Jani Nikula <jani.nikula@intel.com> wrote:
> At this time I've put most effort into the configuration and build side
> of things, solving the problems described above, and handling missing
> tools and packages gracefully. There are still issues to be ironed out
> in a) the kernel-doc script rst output and b) the xml template to rst
> conversion. These are somewhat orthogonal from each other and the build,
> and I expect some hand-editing will be required in the end.

Jon -

I've added a significant amount of polish. It works and it looks
pretty. The code is in the "sphinx-wip" branch of [1], gitweb at [2],
and Read the Docs built copy at [3].

There's roughly 30 commits there that I think are getting ready for
merging. The rest is scripted conversion of some DocBook templates for
demonstration purposes; I think the final conversion should be done by
the authors of the documents when they are ready to ditch the DocBook
templates in the same commit.

I also think I've now spearheaded this pretty close to a point where
more benefits can be gained by merging the work to docs-next, and
collaborating there.

Let me know what you think.


BR,
Jani.

PS. I never thought I'd do this much perl coding in my life. It didn't
kill me, I must be stronger now.


[1] git://people.freedesktop.org/~jani/drm
[2] https://cgit.freedesktop.org/~jani/drm/log/?h=sphinx-wip
[3] https://kernel.readthedocs.io/


-- 
Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 00/10] Documentation/Sphinx

[Daniel Vetter]

On Sun, May 29, 2016 at 10:33 PM, Jani Nikula <jani.nikula@intel.com> wrote:
> On Fri, 20 May 2016, Jani Nikula <jani.nikula@intel.com> wrote:
>> At this time I've put most effort into the configuration and build side
>> of things, solving the problems described above, and handling missing
>> tools and packages gracefully. There are still issues to be ironed out
>> in a) the kernel-doc script rst output and b) the xml template to rst
>> conversion. These are somewhat orthogonal from each other and the build,
>> and I expect some hand-editing will be required in the end.
>
> Jon -
>
> I've added a significant amount of polish. It works and it looks
> pretty. The code is in the "sphinx-wip" branch of [1], gitweb at [2],
> and Read the Docs built copy at [3].
>
> There's roughly 30 commits there that I think are getting ready for
> merging. The rest is scripted conversion of some DocBook templates for
> demonstration purposes; I think the final conversion should be done by
> the authors of the documents when they are ready to ditch the DocBook
> templates in the same commit.
>
> I also think I've now spearheaded this pretty close to a point where
> more benefits can be gained by merging the work to docs-next, and
> collaborating there.
>
> Let me know what you think.

I've looked both through the patches in Jani's branch and the
resulting docs. Spotted 2 nitpicks, which are already fixed, and it
looks imo _really_ good.

I think next steps is to get this merged into docs-next, with a stable
tag, so that I can pull it into drm-misc. There's still piles of
little polish to do to make it really pretty, but that's almost all in
the kernel-doc comments or .rst files itself. I think for starting we
could convert a few docs already, or just add the index.rst and leave
conversions to maintainers. At least for gpu.tmpl I expect some need
for cordination with ongoing work.
-Daniel

>
>
> BR,
> Jani.
>
> PS. I never thought I'd do this much perl coding in my life. It didn't
> kill me, I must be stronger now.
>
>
> [1] git://people.freedesktop.org/~jani/drm
> [2] https://cgit.freedesktop.org/~jani/drm/log/?h=sphinx-wip
> [3] https://kernel.readthedocs.io/
>
>
> --
> Jani Nikula, Intel Open Source Technology Center



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH 00/10] Documentation/Sphinx

[Markus Heiser]

Hi,

sorry for my temporary absence, I have been on holiday the last weeks :-)

Am 30.05.2016 um 11:10 schrieb Daniel Vetter <daniel.vetter@ffwll.ch>:

> On Sun, May 29, 2016 at 10:33 PM, Jani Nikula <jani.nikula@intel.com> wrote:
>> On Fri, 20 May 2016, Jani Nikula <jani.nikula@intel.com> wrote:
>>> At this time I've put most effort into the configuration and build side
>>> of things, solving the problems described above, and handling missing
>>> tools and packages gracefully. There are still issues to be ironed out
>>> in a) the kernel-doc script rst output and b) the xml template to rst
>>> conversion. These are somewhat orthogonal from each other and the build,
>>> and I expect some hand-editing will be required in the end.
>> 
>> Jon -
>> 
>> I've added a significant amount of polish. It works and it looks
>> pretty. The code is in the "sphinx-wip" branch of [1], gitweb at [2],
>> and Read the Docs built copy at [3].
>> 
>> There's roughly 30 commits there that I think are getting ready for
>> merging. The rest is scripted conversion of some DocBook templates for
>> demonstration purposes; I think the final conversion should be done by
>> the authors of the documents when they are ready to ditch the DocBook
>> templates in the same commit.
>> 
>> I also think I've now spearheaded this pretty close to a point where
>> more benefits can be gained by merging the work to docs-next, and
>> collaborating there.
>> 
>> Let me know what you think.
> 
> I've looked both through the patches in Jani's branch and the
> resulting docs. Spotted 2 nitpicks, which are already fixed, and it
> looks imo _really_ good.
> 
> I think next steps is to get this merged into docs-next, with a stable
> tag, so that I can pull it into drm-misc. There's still piles of
> little polish to do to make it really pretty, but that's almost all in
> the kernel-doc comments or .rst files itself. I think for starting we
> could convert a few docs already, or just add the index.rst and leave
> conversions to maintainers. At least for gpu.tmpl I expect some need
> for cordination with ongoing work.
> -Daniel

Here my 5cents about Jani's patch series:

1. Migration implementations should not be a part of the kernel tree

2. sed/pandoc migration fits not for all the XML documentation and has disadvantages.
   Jonathan asked it before: http://article.gmane.org/gmane.linux.documentation/37533

   I repeat myself: Summarize, why should one prefer this tools over pandoc + sed?

   * Pandoc coverage is less on reading and writing, this is where 
     dbxml comes into play

     - reading DocBook: https://github.com/jgm/pandoc/blob/master/src/Text/Pandoc/Readers/DocBook.hs#L23
  
     - writing reST has many bugs and leaks (you fixed some of them with sed)

   * Pandoc does not support external entities (linux-tv), covered by dbxml

   * dbxml brings the ability to chunk one large XML book into small 
     reST chunks e.g. kernel-hacking book: https://github.com/return42/sphkerneldoc/tree/master/doc/books/kernel-hacking

   * dbxml lets you manipulate the XML source before you convert it to reST

     this might helpfull e.g. if you have to convert single-column informal-tables 
     to lists or other things ... in short; dbxml and it's hooks are the key to hack
     everything you need in a full automated DocBook-->reST migration workflow.

3. we also discussed before, that ASCII art tables are ugly, because the produce
   confusing diffs, for this I wrote the flat-table directive (dbxml migrates tables
   to flat-tables / pandoc can't). 
   https://return42.github.io/sphkerneldoc/articles/table_concerns.html#flat-table

> With this, we can put any .rst files (including ones that have
> kernel-doc directives) anywhere under Documentation, add a link to them
> in Documentation/index.rst table of contents, and it will just work. It
> can't get much simpler than that.

4. We discussed it / I already mentioned that each document shipped in it's own
   sphinx project. Bundling all documents into one sphinx-project will work for
   4 or 5  small documents, but not for the whole documentation. BTW all XML 
   documents are currently separated DocBook projects .. so why should we merge
   them into one big project? Making one index-file for the different and small 
   ".txt" files seems OK, but not for the XML docs.

5. In general, the markup of the linux kernel's source code comments remains
   unchanged and the reST markup within the comments is passed through the
   output. A closer lookup to the *kernel-doc* and *reST* markup revals, that
   there are some conflicts between reST (inline) markup and kernel-doc
   markup. Determined by the historical development of the kernel-doc comments, the
   *classic* kernel-doc comments contain characters like ``*`` or strings with
   e.g. leading/trailing underscore (``_``), which are inline markups in
   reST. Here a schort example from a *classic* comment::

        <SNIP> -----
        * In contrast to the other drm_get_*_name functions this one here returns a
        * const pointer and hence is threadsafe.
        <SNAP> -----

   In reST markup, the wildcard in the string ``drm_get_*_name`` has to be
   masked: ``drm_get_\\*_name``. Some more examples from reST markup:

   * Emphasis "*":  like ``*emphasis*`` or ``**emphasis strong**``
   * Leading "_" :  is a *anchor* in reST markup (``_foo``).
   * Trailing "_:  is a reference in reST markup (``foo_``).
   * interpreted text: "`"
   * inline literals: "``"
   * substitution references: "|"

    These special strings has to be masked in the output and can't be used as
    *plain-text markup*.  To get in use of the fully reST markup (stop masking
    special characters) we need some options in the sources documentation, comments
    like

       /* parse-markup: reST */

    which influence the behavior.

> Sites like https://readthedocs.org/ can build the documentation,
> including kernel-doc, without extra tweaks. As a whole, the build
> becomes much simpler.


6. This fail assessments I also had before. RTD has limits in 
   resources and in flexibility, that's why I moved to github pages

   https://github.com/return42/sphkerneldoc/issues/1
   
I will stop here ... I think it is good that everyone make its own
experience, BUT ...

  IMO it is a misjudgment to think that changing the 
  markup and it's toolchain is only a series of patches.

Sorry if my words are unpleasant, this is not my intend, but IMO *the 
view of the whole* and concepts are missed.

Many of the facts mentioned above have been covered in my POC at 
https://github.com/return42/sphkerneldoc ... On others, 
like 5. I'am working on ....

> I've had a few moments of spare time to look into Sphinx. 

... a comprehensive solution needs time and will not be done in a
hurry. Please give me a week or may be two, then I could present
a much more comprehensive solution.

Again: my english is not the best, if some of my words has been 
unpleasant I'am sorry for this, it's not my intend.

--Markus--



> 
>> 
>> 
>> BR,
>> Jani.
>> 
>> PS. I never thought I'd do this much perl coding in my life. It didn't
>> kill me, I must be stronger now.
>> 
>> 
>> [1] git://people.freedesktop.org/~jani/drm
>> [2] https://cgit.freedesktop.org/~jani/drm/log/?h=sphinx-wip
>> [3] https://kernel.readthedocs.io/
>> 
>> 
>> --
>> Jani Nikula, Intel Open Source Technology Center
> 
> 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH 00/10] Documentation/Sphinx

[Jani Nikula]

On Mon, 30 May 2016, Markus Heiser <markus.heiser@darmarit.de> wrote:
> Here my 5cents about Jani's patch series:
>
> 1. Migration implementations should not be a part of the kernel tree

If you're referring to the conversion scripts, I don't care either
way. It's probably helpful to have them until everything is converted,
and we can dispose of them afterwards.

> 2. sed/pandoc migration fits not for all the XML documentation and has disadvantages.
>    Jonathan asked it before: http://article.gmane.org/gmane.linux.documentation/37533
>
>    I repeat myself: Summarize, why should one prefer this tools over pandoc + sed?
>
>    * Pandoc coverage is less on reading and writing, this is where 
>      dbxml comes into play
>
>      - reading DocBook: https://github.com/jgm/pandoc/blob/master/src/Text/Pandoc/Readers/DocBook.hs#L23
>   
>      - writing reST has many bugs and leaks (you fixed some of them with sed)
>
>    * Pandoc does not support external entities (linux-tv), covered by dbxml
>
>    * dbxml brings the ability to chunk one large XML book into small 
>      reST chunks e.g. kernel-hacking book: https://github.com/return42/sphkerneldoc/tree/master/doc/books/kernel-hacking
>
>    * dbxml lets you manipulate the XML source before you convert it to reST
>
>      this might helpfull e.g. if you have to convert single-column informal-tables 
>      to lists or other things ... in short; dbxml and it's hooks are the key to hack
>      everything you need in a full automated DocBook-->reST migration workflow.

I am not proposing to merge the documents that I've converted mostly as
samples in the branch. I needed something to demonstrate the build is
sane.

The authors of the DocBook documents should make the conversions as they
see fit, when they see fit, with the tools they see fit, probably with
some manual work on top.

> 3. we also discussed before, that ASCII art tables are ugly, because the produce
>    confusing diffs, for this I wrote the flat-table directive (dbxml migrates tables
>    to flat-tables / pandoc can't). 
>    https://return42.github.io/sphkerneldoc/articles/table_concerns.html#flat-table

See the above. Any authors that think the Sphinx support I've added is
good enough can go ahead and switch.

I think it's safe for me to say the GPU documents won't wait for further
extension directives or conversion tools. Some others will definitely
want to have the flat table extension before switching.

>> With this, we can put any .rst files (including ones that have
>> kernel-doc directives) anywhere under Documentation, add a link to them
>> in Documentation/index.rst table of contents, and it will just work. It
>> can't get much simpler than that.
>
> 4. We discussed it / I already mentioned that each document shipped in it's own
>    sphinx project. Bundling all documents into one sphinx-project will work for
>    4 or 5  small documents, but not for the whole documentation. BTW all XML 
>    documents are currently separated DocBook projects .. so why should we merge
>    them into one big project? Making one index-file for the different and small 
>    ".txt" files seems OK, but not for the XML docs.

FWIW I locally converted all the DocBook documents (except media) and it
works just fine, and to me it looks like exactly what we should
have. One of the goals was to have nice cross-referencing between the
documents (e.g. from GPU to kernel or device driver API). And it works.

This does not exclude having *additional* indexes or Sphinx config files
for subsystems or subprojects to build a subset of the documentation for
specific needs. It's up to the authors of the documents to decide.

For PDF documents, adding the documents separately in pdf_documents
seems to be the right thing to do.

> 5. In general, the markup of the linux kernel's source code comments remains
>    unchanged and the reST markup within the comments is passed through the
>    output. A closer lookup to the *kernel-doc* and *reST* markup revals, that
>    there are some conflicts between reST (inline) markup and kernel-doc
>    markup. Determined by the historical development of the kernel-doc comments, the
>    *classic* kernel-doc comments contain characters like ``*`` or strings with
>    e.g. leading/trailing underscore (``_``), which are inline markups in
>    reST. Here a schort example from a *classic* comment::
>
>         <SNIP> -----
>         * In contrast to the other drm_get_*_name functions this one here returns a
>         * const pointer and hence is threadsafe.
>         <SNAP> -----
>
>    In reST markup, the wildcard in the string ``drm_get_*_name`` has to be
>    masked: ``drm_get_\\*_name``. Some more examples from reST markup:
>
>    * Emphasis "*":  like ``*emphasis*`` or ``**emphasis strong**``
>    * Leading "_" :  is a *anchor* in reST markup (``_foo``).
>    * Trailing "_:  is a reference in reST markup (``foo_``).
>    * interpreted text: "`"
>    * inline literals: "``"
>    * substitution references: "|"
>
>     These special strings has to be masked in the output and can't be used as
>     *plain-text markup*.  To get in use of the fully reST markup (stop masking
>     special characters) we need some options in the sources documentation, comments
>     like
>
>        /* parse-markup: reST */
>
>     which influence the behavior.

I find it totally unacceptable to require explicitly marking kernel-doc
comments or source files as being reStructuredText.

Note that it's all opt-in already. If you add a .rst file that includes
kernel-doc via the kernel-doc extension, you better make sure the
comments parse as reStructuredText and render nicely. I'm willing to do
much of the job for all the things that I care about.

Besides, if you look at the results, you'll find it looks mostly good
without any fixes. In the sample documents, I've erred on the side of
having a few markup hickups here and there while most of it works
perfectly well as reStructuredText. I think this is exactly what we
should do, declare it all reStructuredText and fix issues as we go.

>> Sites like https://readthedocs.org/ can build the documentation,
>> including kernel-doc, without extra tweaks. As a whole, the build
>> becomes much simpler.
>
>
> 6. This fail assessments I also had before. RTD has limits in 
>    resources and in flexibility, that's why I moved to github pages
>
>    https://github.com/return42/sphkerneldoc/issues/1

I'm just personally using Read the Docs to ensure they can build the
documentation as "pure" Sphinx (they won't use the Makefiles), and so I
don't have to host the docs anywhere myself. Sure, I can't add *all* the
files there because it exceeds the build limits. They might cater for us
if they want to carry the kernel documentation going forward, but most
likely the output should be at kernel.org anyway. (Plus we'll have
freedesktop.org and 01.org for the GPU documentation too.)

> I will stop here ... I think it is good that everyone make its own
> experience, BUT ...
>
>   IMO it is a misjudgment to think that changing the 
>   markup and it's toolchain is only a series of patches.
>
> Sorry if my words are unpleasant, this is not my intend, but IMO *the 
> view of the whole* and concepts are missed.

I'm not sure what to say.

For one thing, a concrete series of patches to add Sphinx support to the
kernel, integrating it with the build system and kernel-doc and
everything is *exactly* what is needed. This is what I've done. It's
here now. It works. Anyone can take my git tree, run 'make htmldocs' and
see the results for themselves.

>From your message it remains unclear to me what "view of the whole" and
"concepts" and "comprehensive solution" I have missed.

> Many of the facts mentioned above have been covered in my POC at 
> https://github.com/return42/sphkerneldoc ... On others, 
> like 5. I'am working on ....
>
>> I've had a few moments of spare time to look into Sphinx. 
>
> ... a comprehensive solution needs time and will not be done in a
> hurry. Please give me a week or may be two, then I could present
> a much more comprehensive solution.

Please do not underestimate the productivity of my moments of spare
time. ;)

My view of the whole is that we've been talking about adding lightweight
markup support for the better part of a year now, and I'm getting pretty
tired of talking...


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 00/10] Documentation/Sphinx

[Daniel Vetter]

I concur with Jani on all points, just want to follow-up here.

On Mon, May 30, 2016 at 4:46 PM, Jani Nikula <jani.nikula@intel.com> wrote:
>> Many of the facts mentioned above have been covered in my POC at
>> https://github.com/return42/sphkerneldoc ... On others,
>> like 5. I'am working on ....
>>
>>> I've had a few moments of spare time to look into Sphinx.
>>
>> ... a comprehensive solution needs time and will not be done in a
>> hurry. Please give me a week or may be two, then I could present
>> a much more comprehensive solution.
>
> Please do not underestimate the productivity of my moments of spare
> time. ;)
>
> My view of the whole is that we've been talking about adding lightweight
> markup support for the better part of a year now, and I'm getting pretty
> tired of talking...

Tbh I'd like to get this in soonish, so that we have about 1 month of
time before 4.8 for actually polishing gpu documentation. Maybe
there's some room for more, better tables, other extensions, polish
the kernel-doc script a bit more. But what we have now works, I think
it does address everything we've discussed over the past year that we
absolutely need. I think it makes it possible to extend for all the
more optional use-cases we need to be able to convert, and we can add
those extensions later on. And with Jani's big pile of kernel-doc
patches we now also have someone who understands that perl script,
which is awesome.

In short I want to go nuts improving the docs themselves and stop
discussing the tooling to build them. Can we please make this happen?

Note that Jani's already started to throw out our old ascidoc hacks in
the topic/kerneldoc branch in the drm-intel.git repo, and we'll switch
over the autobuilder for the 01.org docs as soon as that's done. We're
committed, I want this ;-)

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH 00/10] Documentation/Sphinx

[Markus Heiser]

Am 30.05.2016 um 16:46 schrieb Jani Nikula <jani.nikula@intel.com>:

> On Mon, 30 May 2016, Markus Heiser <markus.heiser@darmarit.de> wrote:
>> Here my 5cents about Jani's patch series:
>> 
>> 1. Migration implementations should not be a part of the kernel tree
> 
> If you're referring to the conversion scripts, I don't care either
> way. It's probably helpful to have them until everything is converted,
> and we can dispose of them afterwards.
> 
>> 2. sed/pandoc migration fits not for all the XML documentation and has disadvantages.
>>   Jonathan asked it before: http://article.gmane.org/gmane.linux.documentation/37533
>> 
>>   I repeat myself: Summarize, why should one prefer this tools over pandoc + sed?
>> 
>>   * Pandoc coverage is less on reading and writing, this is where 
>>     dbxml comes into play
>> 
>>     - reading DocBook: https://github.com/jgm/pandoc/blob/master/src/Text/Pandoc/Readers/DocBook.hs#L23
>> 
>>     - writing reST has many bugs and leaks (you fixed some of them with sed)
>> 
>>   * Pandoc does not support external entities (linux-tv), covered by dbxml
>> 
>>   * dbxml brings the ability to chunk one large XML book into small 
>>     reST chunks e.g. kernel-hacking book: https://github.com/return42/sphkerneldoc/tree/master/doc/books/kernel-hacking
>> 
>>   * dbxml lets you manipulate the XML source before you convert it to reST
>> 
>>     this might helpfull e.g. if you have to convert single-column informal-tables 
>>     to lists or other things ... in short; dbxml and it's hooks are the key to hack
>>     everything you need in a full automated DocBook-->reST migration workflow.
> 
> I am not proposing to merge the documents that I've converted mostly as
> samples in the branch. I needed something to demonstrate the build is
> sane.

> The authors of the DocBook documents should make the conversions as they
> see fit, when they see fit, with the tools they see fit, probably with
> some manual work on top.

OK

> 
>> 3. we also discussed before, that ASCII art tables are ugly, because the produce
>>   confusing diffs, for this I wrote the flat-table directive (dbxml migrates tables
>>   to flat-tables / pandoc can't). 
>>   https://return42.github.io/sphkerneldoc/articles/table_concerns.html#flat-table
> 
> See the above. Any authors that think the Sphinx support I've added is
> good enough can go ahead and switch.
> 
> I think it's safe for me to say the GPU documents won't wait for further
> extension directives or conversion tools. Some others will definitely
> want to have the flat table extension before switching.

OK

> 
>>> With this, we can put any .rst files (including ones that have
>>> kernel-doc directives) anywhere under Documentation, add a link to them
>>> in Documentation/index.rst table of contents, and it will just work. It
>>> can't get much simpler than that.
>> 
>> 4. We discussed it / I already mentioned that each document shipped in it's own
>>   sphinx project. Bundling all documents into one sphinx-project will work for
>>   4 or 5  small documents, but not for the whole documentation. BTW all XML 
>>   documents are currently separated DocBook projects .. so why should we merge
>>   them into one big project? Making one index-file for the different and small 
>>   ".txt" files seems OK, but not for the XML docs.
> 
> FWIW I locally converted all the DocBook documents (except media) and it
> works just fine, and to me it looks like exactly what we should
> have.

With DocBook, it was hard to separate a file into small chunks (see media for
how it is done). With Sphinx, it is common to split a document in small chunks 
(along parts, chapters, sections ...) Thats why I recommend chunking documents
(from the beginning).

> One of the goals was to have nice cross-referencing between the
> documents (e.g. from GPU to kernel or device driver API). And it works.

For this, Sphinx-doc brings intersphinx: http://www.sphinx-doc.org/en/stable/ext/intersphinx.html

> This does not exclude having *additional* indexes or Sphinx config files
> for subsystems or subprojects to build a subset of the documentation for
> specific needs. It's up to the authors of the documents to decide.

OK, I think we have a bit different point of view .. IMO it is better
to give the authors a *scalable structure* to place their's documentation. 

> For PDF documents, adding the documents separately in pdf_documents
> seems to be the right thing to do.

I can't recommend to use rst2pdf (it is less maintained), use default
sphinx LaTeX toolchain.

> 
>> 5. In general, the markup of the linux kernel's source code comments remains
>>   unchanged and the reST markup within the comments is passed through the
>>   output. A closer lookup to the *kernel-doc* and *reST* markup revals, that
>>   there are some conflicts between reST (inline) markup and kernel-doc
>>   markup. Determined by the historical development of the kernel-doc comments, the
>>   *classic* kernel-doc comments contain characters like ``*`` or strings with
>>   e.g. leading/trailing underscore (``_``), which are inline markups in
>>   reST. Here a schort example from a *classic* comment::
>> 
>>        <SNIP> -----
>>        * In contrast to the other drm_get_*_name functions this one here returns a
>>        * const pointer and hence is threadsafe.
>>        <SNAP> -----
>> 
>>   In reST markup, the wildcard in the string ``drm_get_*_name`` has to be
>>   masked: ``drm_get_\\*_name``. Some more examples from reST markup:
>> 
>>   * Emphasis "*":  like ``*emphasis*`` or ``**emphasis strong**``
>>   * Leading "_" :  is a *anchor* in reST markup (``_foo``).
>>   * Trailing "_:  is a reference in reST markup (``foo_``).
>>   * interpreted text: "`"
>>   * inline literals: "``"
>>   * substitution references: "|"
>> 
>>    These special strings has to be masked in the output and can't be used as
>>    *plain-text markup*.  To get in use of the fully reST markup (stop masking
>>    special characters) we need some options in the sources documentation, comments
>>    like
>> 
>>       /* parse-markup: reST */
>> 
>>    which influence the behavior.
> 
> I find it totally unacceptable to require explicitly marking kernel-doc
> comments or source files as being reStructuredText.
> Note that it's all opt-in already. If you add a .rst file that includes
> kernel-doc via the kernel-doc extension, you better make sure the
> comments parse as reStructuredText and render nicely. I'm willing to do
> much of the job for all the things that I care about.

We have a different POV ... I try to build up a documentation project,
which could use all given kernel-doc markups without any change, where
reST is an "addition". Your approach is to fix kernel-doc comments 
if they are referred by a kernl-doc directive in a .rst document.
There is nothing wrong about your approach, but I try to build
a whole source code documentation like the one I started here: 
http://return42.github.io/sphkerneldoc/linux_src_doc/index.html

Benefit: Beside a kernel-doc directive, authors (from everywhere, not 
only within the kernel-src-tree) can refer kernel-docs with intersphinx
Here is a example, see "cross references" at: 
http://return42.github.io/sphkerneldoc/articles/linux_src_doc.html?cross-references


> Besides, if you look at the results, you'll find it looks mostly good
> without any fixes. In the sample documents, I've erred on the side of
> having a few markup hickups here and there while most of it works
> perfectly well as reStructuredText. I think this is exactly what we
> should do, declare it all reStructuredText and fix issues as we go.
> 
>>> Sites like https://readthedocs.org/ can build the documentation,
>>> including kernel-doc, without extra tweaks. As a whole, the build
>>> becomes much simpler.
>> 
>> 
>> 6. This fail assessments I also had before. RTD has limits in 
>>   resources and in flexibility, that's why I moved to github pages
>> 
>>   https://github.com/return42/sphkerneldoc/issues/1
> 
> I'm just personally using Read the Docs to ensure they can build the
> documentation as "pure" Sphinx (they won't use the Makefiles), and so I
> don't have to host the docs anywhere myself. Sure, I can't add *all* the
> files there because it exceeds the build limits. They might cater for us
> if they want to carry the kernel documentation going forward, but most
> likely the output should be at kernel.org anyway. (Plus we'll have
> freedesktop.org and 01.org for the GPU documentation too.)

There a some similar discussions on RTD ... yes, they make exceptions
for *special* users, but its all harry, use your default publishing 
sides and forget RTD ;-)

>> I will stop here ... I think it is good that everyone make its own
>> experience, BUT ...
>> 
>>  IMO it is a misjudgment to think that changing the 
>>  markup and it's toolchain is only a series of patches.
>> 
>> Sorry if my words are unpleasant, this is not my intend, but IMO *the 
>> view of the whole* and concepts are missed.
> 
> I'm not sure what to say.

As I said, we have a different POV, which is not in contradiction,
as your requirements are a subset of mine.

I worry a little bit in that reST will be only one more toolchain 
beside DocBook .. in the long term, kernel's documentation 
should get rid of all the DocBook artifacts and for this a more
comprehensive solution is needed.

> Please do not underestimate the productivity of my moments of spare
> time. ;)

1:0 for you ;-)

Am 30.05.2016 um 17:29 schrieb Daniel Vetter <daniel.vetter@ffwll.ch>:

> I concur with Jani on all points, just want to follow-up here.
> 
> Tbh I'd like to get this in soonish, so that we have about 1 month of
> time before 4.8 for actually polishing gpu documentation. Maybe
> there's some room for more, better tables, other extensions, polish
> the kernel-doc script a bit more. But what we have now works, I think
> it does address everything we've discussed over the past year that we
> absolutely need. I think it makes it possible to extend for all the
> more optional use-cases we need to be able to convert, and we can add
> those extensions later on.

OK, I understand your needs, I don't wan't to stop you writing 
documentation with reST. May use Jani's approach for a first
toolchain 

> And with Jani's big pile of kernel-doc
> patches we now also have someone who understands that perl script,
> which is awesome.

? 

https://github.com/return42/sphkerneldoc/blob/master/scripts/kernel-doc#L1736

> In short I want to go nuts improving the docs themselves and stop
> discussing the tooling to build them. Can we please make this happen?
> 
> Note that Jani's already started to throw out our old ascidoc hacks in
> the topic/kerneldoc branch in the drm-intel.git repo, and we'll switch
> over the autobuilder for the 01.org docs as soon as that's done. We're
> committed, I want this ;-)


Am 30.05.2016 um 16:46 schrieb Jani Nikula <jani.nikula@intel.com>:

> I'm getting pretty tired of talking...

Yes, we are all tired in this discussions ... I see, you are in need 
to switch over ... for this, may use your toolchain ... but I have one 
please, do not change more than you really need and be open for
changing the toolchain later. 

I will inform you about any substantial progress within my 
solution ... may we can merge our experience soon or later, 
but don't stop writing documentation.

Thank's for your patience ... :-)

--Markus--

Re: [PATCH 00/10] Documentation/Sphinx

[Jani Nikula]

On Mon, 30 May 2016, Markus Heiser <markus.heiser@darmarit.de> wrote:
> Am 30.05.2016 um 16:46 schrieb Jani Nikula <jani.nikula@intel.com>:
>> I am not proposing to merge the documents that I've converted mostly as
>> samples in the branch. I needed something to demonstrate the build is
>> sane.
>
>> The authors of the DocBook documents should make the conversions as they
>> see fit, when they see fit, with the tools they see fit, probably with
>> some manual work on top.
>
> OK

To be clear, the "sphinx-for-docs-next" branch of [1], [2] is what I
propose to merge at this time. There's the Sphinx configuration, kernel
build integration, Sphinx kernel-doc extension, tons of kernel-doc
updates, etc. There is no DocBook tmpl conversion; all of that is left
to the authors (owners, maintainers) of the documents, but this enables
them to focus on that part.

I was planning on sending out the patches after some feedback here.

[1] git://people.freedesktop.org/~jani/drm
[2] https://cgit.freedesktop.org/~jani/drm/log/?h=sphinx-for-docs-next

> With DocBook, it was hard to separate a file into small chunks (see media for
> how it is done). With Sphinx, it is common to split a document in small chunks 
> (along parts, chapters, sections ...) Thats why I recommend chunking documents
> (from the beginning).

Agreed, but up to the authors.

>> One of the goals was to have nice cross-referencing between the
>> documents (e.g. from GPU to kernel or device driver API). And it works.
>
> For this, Sphinx-doc brings intersphinx: http://www.sphinx-doc.org/en/stable/ext/intersphinx.html

If the kernel is split to several intersphinx "prefixes", we won't know
the prefix of the link targets when we're generating the references in
kernel-doc. Also, can be deferred to follow-up work if someone figures
out the how.

> I can't recommend to use rst2pdf (it is less maintained), use default
> sphinx LaTeX toolchain.

I think we'll use whatever works, rst2pdf seemed to work for now, but we
can change if needed.

>> I find it totally unacceptable to require explicitly marking kernel-doc
>> comments or source files as being reStructuredText.
>> Note that it's all opt-in already. If you add a .rst file that includes
>> kernel-doc via the kernel-doc extension, you better make sure the
>> comments parse as reStructuredText and render nicely. I'm willing to do
>> much of the job for all the things that I care about.
>
> We have a different POV ... I try to build up a documentation project,
> which could use all given kernel-doc markups without any change, where
> reST is an "addition". Your approach is to fix kernel-doc comments 
> if they are referred by a kernl-doc directive in a .rst document.
> There is nothing wrong about your approach, but I try to build
> a whole source code documentation like the one I started here: 
> http://return42.github.io/sphkerneldoc/linux_src_doc/index.html

That looks nice, but I'll argue it would not be much worse even if you
assumed it's all rst.

The bigger point is, if you expect people to tag each source file or
kernel-doc comment with "rst", you'll end up with a mess where some
places have that tag, some not, but it's not conclusive about whether
they actually *are* rst or not. (And you've had tons of patch churn to
add those tags to get there.)

The kernel-doc comments are written by humans who will screw it up
anyway. (Apologies for the distrust, fellow developers, but I've been
reading too many of your fine kernel-doc comments lately.) People will
happily cargo cult rst and current kernel-doc and javadoc and doxygen
and whatnot in a fruit salad. The only thing that will help in the end
is keeping the rules simple and consistent and having the feedback from
the tools.

> I worry a little bit in that reST will be only one more toolchain 
> beside DocBook .. in the long term, kernel's documentation 
> should get rid of all the DocBook artifacts and for this a more
> comprehensive solution is needed.

We agree on the end goal, eradicate DocBook. I must say that in my
experiments, apart from the media docs, almost everything converts
surprisingly nicely or IMO "good enough" with just the tmplcvt script in
this series. Do remember that this is a one time conversion. It needs to
be good enough that there's not too much manual editing involved, but it
doesn't need to be perfect. Some degree of editing will be required no
matter what, not least because the DocBook has also been written by
humans, and the battle against the GIGO principle is a lost one.

>> And with Jani's big pile of kernel-doc
>> patches we now also have someone who understands that perl script,
>> which is awesome.
>
> ? 

I must also question any sentence that implies I understand perl. ;)

>> In short I want to go nuts improving the docs themselves and stop
>> discussing the tooling to build them. Can we please make this happen?
>> 
>> Note that Jani's already started to throw out our old ascidoc hacks in
>> the topic/kerneldoc branch in the drm-intel.git repo, and we'll switch
>> over the autobuilder for the 01.org docs as soon as that's done. We're
>> committed, I want this ;-)

It's done, we're feeding this to our integration tree and dogfooding.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 00/10] Documentation/Sphinx

[Mauro Carvalho Chehab]

Em Mon, 30 May 2016 23:05:34 +0300
Jani Nikula <jani.nikula@intel.com> escreveu:

> > I worry a little bit in that reST will be only one more toolchain 
> > beside DocBook .. in the long term, kernel's documentation 
> > should get rid of all the DocBook artifacts and for this a more
> > comprehensive solution is needed.  
> 
> We agree on the end goal, eradicate DocBook. I must say that in my
> experiments, apart from the media docs, almost everything converts
> surprisingly nicely or IMO "good enough" with just the tmplcvt script in
> this series.

With regards to media, my plan is to merge create a topic branch based
on Kernel 4.7-rc1 at:
	https://git.linuxtv.org/media_tree.git/

As none of the Jani's patches seem to affect the media API docs, it
seems I don't need to merge back from Jon's -next branch.

There, I intend to add Markus patches with the conversion from the
DocBook to rst, plus the flat-table extension logic.

Then, I'll work to manually fix what's needed and I'll add the 
automation scripting logic that we have at the DocBook Makefile
to work with the new media rst files.

Lastly, once the job's done, I'll drop Documentation/DocBook/media.

Markus,

With that regards, could you please send the patches to me?

Thanks,
Mauro

Re: [PATCH 00/10] Documentation/Sphinx

[Markus Heiser]

Am 30.05.2016 um 22:05 schrieb Jani Nikula <jani.nikula@intel.com>:

> On Mon, 30 May 2016, Markus Heiser <markus.heiser@darmarit.de> wrote:
>> Am 30.05.2016 um 16:46 schrieb Jani Nikula <jani.nikula@intel.com>:
>>> I am not proposing to merge the documents that I've converted mostly as
>>> samples in the branch. I needed something to demonstrate the build is
>>> sane.
>> 
>>> The authors of the DocBook documents should make the conversions as they
>>> see fit, when they see fit, with the tools they see fit, probably with
>>> some manual work on top.
>> 
>> OK
> 
> To be clear, the "sphinx-for-docs-next" branch of [1], [2] is what I
> propose to merge at this time. There's the Sphinx configuration, kernel
> build integration, Sphinx kernel-doc extension, tons of kernel-doc
> updates, etc. There is no DocBook tmpl conversion; all of that is left
> to the authors (owners, maintainers) of the documents, but this enables
> them to focus on that part.
> 
> I was planning on sending out the patches after some feedback here.
> 
> [1] git://people.freedesktop.org/~jani/drm
> [2] https://cgit.freedesktop.org/~jani/drm/log/?h=sphinx-for-docs-next
> 
>> With DocBook, it was hard to separate a file into small chunks (see media for
>> how it is done). With Sphinx, it is common to split a document in small chunks 
>> (along parts, chapters, sections ...) Thats why I recommend chunking documents
>> (from the beginning).
> 
> Agreed, but up to the authors.
> 
>>> One of the goals was to have nice cross-referencing between the
>>> documents (e.g. from GPU to kernel or device driver API). And it works.
>> 
>> For this, Sphinx-doc brings intersphinx: http://www.sphinx-doc.org/en/stable/ext/intersphinx.html
> 
> If the kernel is split to several intersphinx "prefixes", we won't know
> the prefix of the link targets when we're generating the references in
> kernel-doc. Also, can be deferred to follow-up work if someone figures
> out the how.

It stands to reason that each book should be placed in a separate folder.
This simple role simplifies much, e.g. chunking, "prefixes" for the 
intersphinx, a place for images of this book .. etc. It is also the
base to have one sphinx-doc project (individual config set) for each book.

Please, place each (DocBook) reST-book at least into a separate folder.


>> I can't recommend to use rst2pdf (it is less maintained), use default
>> sphinx LaTeX toolchain.
> 
> I think we'll use whatever works, rst2pdf seemed to work for now, but we
> can change if needed.

The discussion in the past was dominated by the fear, that something
on the sphinx-doc could not be maintained in the future ... I don't
share theses fears, if needed, I also have no problem to repair or throw
my damaged toolchain away ;-)

>>> I find it totally unacceptable to require explicitly marking kernel-doc
>>> comments or source files as being reStructuredText.
>>> Note that it's all opt-in already. If you add a .rst file that includes
>>> kernel-doc via the kernel-doc extension, you better make sure the
>>> comments parse as reStructuredText and render nicely. I'm willing to do
>>> much of the job for all the things that I care about.
>> 
>> We have a different POV ... I try to build up a documentation project,
>> which could use all given kernel-doc markups without any change, where
>> reST is an "addition". Your approach is to fix kernel-doc comments 
>> if they are referred by a kernl-doc directive in a .rst document.
>> There is nothing wrong about your approach, but I try to build
>> a whole source code documentation like the one I started here: 
>> http://return42.github.io/sphkerneldoc/linux_src_doc/index.html
> 
> That looks nice, but I'll argue it would not be much worse even if you
> assumed it's all rst.

A superficial look on the HTML output may give the impression. But in
the log you will find tons of errors and warnings. My experience is,
that authors will not consult logs if there are tons of errors from the 
beginning, which carries a decrease in quality. IMO not a good starting 
point.

> The bigger point is, if you expect people to tag each source file or
> kernel-doc comment with "rst", you'll end up with a mess where some
> places have that tag, some not, but it's not conclusive about whether
> they actually *are* rst or not. (And you've had tons of patch churn to
> add those tags to get there.)

At the end, only sources which have been modified to reST need one
line (in the first lines) :

  /* parse-markup: reST */

which announce the reST markup in this file, normaly this needs
no additional patches, except the author forget to announce his
movement to reST ...

> The kernel-doc comments are written by humans who will screw it up
> anyway. (Apologies for the distrust, fellow developers, but I've been
> reading too many of your fine kernel-doc comments lately.) People will
> happily cargo cult rst and current kernel-doc and javadoc and doxygen
> and whatnot in a fruit salad. The only thing that will help in the end
> is keeping the rules simple and consistent and having the feedback from
> the tools.

You are right, I have seen tons of individual markups in the kernel-doc
comments. In the past some authors ignored the description in the 
kernel-doc-nano-howto. The "/* parse-markup: reST */" will be only one 
addition more to the kernel-doc-nano-howto they could ignore ;-)

>> I worry a little bit in that reST will be only one more toolchain 
>> beside DocBook .. in the long term, kernel's documentation 
>> should get rid of all the DocBook artifacts and for this a more
>> comprehensive solution is needed.
> 
> We agree on the end goal, eradicate DocBook. I must say that in my
> experiments, apart from the media docs, almost everything converts
> surprisingly nicely or IMO "good enough" with just the tmplcvt script in
> this series. Do remember that this is a one time conversion. It needs to
> be good enough that there's not too much manual editing involved, but it
> doesn't need to be perfect. Some degree of editing will be required no
> matter what, not least because the DocBook has also been written by
> humans, and the battle against the GIGO principle is a lost one.

and I feel like Don Quichotte :-) 

-- Markus--

Re: [PATCH 00/10] Documentation/Sphinx

[Daniel Vetter]

On Tue, May 31, 2016 at 9:27 AM, Markus Heiser
<markus.heiser@darmarit.de> wrote:
>>>> I find it totally unacceptable to require explicitly marking kernel-doc
>>>> comments or source files as being reStructuredText.
>>>> Note that it's all opt-in already. If you add a .rst file that includes
>>>> kernel-doc via the kernel-doc extension, you better make sure the
>>>> comments parse as reStructuredText and render nicely. I'm willing to do
>>>> much of the job for all the things that I care about.
>>>
>>> We have a different POV ... I try to build up a documentation project,
>>> which could use all given kernel-doc markups without any change, where
>>> reST is an "addition". Your approach is to fix kernel-doc comments
>>> if they are referred by a kernl-doc directive in a .rst document.
>>> There is nothing wrong about your approach, but I try to build
>>> a whole source code documentation like the one I started here:
>>> http://return42.github.io/sphkerneldoc/linux_src_doc/index.html
>>
>> That looks nice, but I'll argue it would not be much worse even if you
>> assumed it's all rst.
>
> A superficial look on the HTML output may give the impression. But in
> the log you will find tons of errors and warnings. My experience is,
> that authors will not consult logs if there are tons of errors from the
> beginning, which carries a decrease in quality. IMO not a good starting
> point.

0-day builds all docs, and checks for new warnings. Even in today's
gpu.tmpl build there's a massive pile of warnings, so yes developers
don't look. But 0-day does, and then developers look at the nice mails
from 0-day. It mostly works to keep out new fail I think.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH 00/10] Documentation/Sphinx

[Markus Heiser]

Am 31.05.2016 um 10:07 schrieb Daniel Vetter <daniel.vetter@ffwll.ch>:

> On Tue, May 31, 2016 at 9:27 AM, Markus Heiser
> <markus.heiser@darmarit.de> wrote:
>>>>> I find it totally unacceptable to require explicitly marking kernel-doc
>>>>> comments or source files as being reStructuredText.
>>>>> Note that it's all opt-in already. If you add a .rst file that includes
>>>>> kernel-doc via the kernel-doc extension, you better make sure the
>>>>> comments parse as reStructuredText and render nicely. I'm willing to do
>>>>> much of the job for all the things that I care about.
>>>> 
>>>> We have a different POV ... I try to build up a documentation project,
>>>> which could use all given kernel-doc markups without any change, where
>>>> reST is an "addition". Your approach is to fix kernel-doc comments
>>>> if they are referred by a kernl-doc directive in a .rst document.
>>>> There is nothing wrong about your approach, but I try to build
>>>> a whole source code documentation like the one I started here:
>>>> http://return42.github.io/sphkerneldoc/linux_src_doc/index.html
>>> 
>>> That looks nice, but I'll argue it would not be much worse even if you
>>> assumed it's all rst.
>> 
>> A superficial look on the HTML output may give the impression. But in
>> the log you will find tons of errors and warnings. My experience is,
>> that authors will not consult logs if there are tons of errors from the
>> beginning, which carries a decrease in quality. IMO not a good starting
>> point.
> 
> 0-day builds all docs, and checks for new warnings. Even in today's
> gpu.tmpl build there's a massive pile of warnings, so yes developers
> don't look. But 0-day does, and then developers look at the nice mails
> from 0-day. It mostly works to keep out new fail I think.

In general, I'am not very happy with workarounds like this. IMO these
are workarounds are often, rewards bunglers and punish those with more work,
who want make thinks right. There might be situations where 0-day build
is the only/best solution. But *here* we are talking about one additional
comment line the author adds, when he modify his source comments from kernel-doc 
to reST markup .. IMO not very hard.

This one line helps the doc-builder to distinguish between *vintage* kernel-doc
comments and those with reST additions in.

With the announcement of the markup, we can use all existing kernel-doc
markups "as is" for building a complete src-code documentation, with
thousands of errors less in the log (experience from my POC). IMO a great
benefit ... given by just one additional comment line to distinguish between
vintage and reST ... 

BTW it's is not uncommon to announce the markup in projects with mixed 
markups in the source code comments.


     A few words about my point of view / my thought:

I strict separate markup from the doc-building tools. The decision in favor for
reST is not done because sphinx-doc is a great doc-bulding tool, it is done because
reST is a easy to write / read markup with a clear and expressive syntax definition.
The *best* builder for this markup is sphinx-doc, so it is only natural, that
the decision for the builder falls to sphinx-doc.

But kernel documentation is not a project from scratch, there was the *vintage*
kernel-doc markup first. Therefore, reST is only an additional markup!

With this POV you can add reST (or any other) markup to the doc-building process.
The Linux kernel draws on diverse projects, some of them may use different
markups and these maintainers are not interested in changing there whole markup
when they contribute to the kernel ... but may be there is someone how want's 
to add an other additional markup support to the doc-building process.

I'am not interested in supporting additional markups beside reST. But this is a
scalable future-proof solution, which only needs an announcement of the the markup.
The one additional comment line we are talking about.

--Markus--

> -Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH 00/10] Documentation/Sphinx

[Markus Heiser]

Am 30.05.2016 um 23:23 schrieb Mauro Carvalho Chehab <mchehab@osg.samsung.com>:

> Em Mon, 30 May 2016 23:05:34 +0300
> Jani Nikula <jani.nikula@intel.com> escreveu:
> 
>>> I worry a little bit in that reST will be only one more toolchain 
>>> beside DocBook .. in the long term, kernel's documentation 
>>> should get rid of all the DocBook artifacts and for this a more
>>> comprehensive solution is needed.  
>> 
>> We agree on the end goal, eradicate DocBook. I must say that in my
>> experiments, apart from the media docs, almost everything converts
>> surprisingly nicely or IMO "good enough" with just the tmplcvt script in
>> this series.
> 
> With regards to media, my plan is to merge create a topic branch based
> on Kernel 4.7-rc1 at:
> 	https://git.linuxtv.org/media_tree.git/
> 
> As none of the Jani's patches seem to affect the media API docs, it
> seems I don't need to merge back from Jon's -next branch.
> 
> There, I intend to add Markus patches with the conversion from the
> DocBook to rst, plus the flat-table extension logic.
> 
> Then, I'll work to manually fix what's needed and I'll add the 
> automation scripting logic that we have at the DocBook Makefile
> to work with the new media rst files.
> 
> Lastly, once the job's done, I'll drop Documentation/DocBook/media.
> 
> Markus,
> 
> With that regards, could you please send the patches to me?

Yes. What is your timeline ... is it OK if I send you a patch in the 
next two weeks? ... first I wan't to finish my other work / I'am just
back from holiday .. a lot of work to do :-o

--Markus--

> 
> Thanks,
> Mauro

Re: [PATCH 00/10] Documentation/Sphinx

[Jani Nikula]

On Tue, 31 May 2016, Markus Heiser <markus.heiser@darmarit.de> wrote:
> Am 31.05.2016 um 10:07 schrieb Daniel Vetter <daniel.vetter@ffwll.ch>:
>> 0-day builds all docs, and checks for new warnings. Even in today's
>> gpu.tmpl build there's a massive pile of warnings, so yes developers
>> don't look. But 0-day does, and then developers look at the nice mails
>> from 0-day. It mostly works to keep out new fail I think.
>
> In general, I'am not very happy with workarounds like this. IMO these
> are workarounds are often, rewards bunglers and punish those with more work,
> who want make thinks right. There might be situations where 0-day build
> is the only/best solution. But *here* we are talking about one additional
> comment line the author adds, when he modify his source comments from kernel-doc 
> to reST markup .. IMO not very hard.

That "one line" translates to nearly 50000 kernel-doc comments in more
than 6000 files. If you expect people to add a tag in each file/comment,
it will never happen. If we assume it's all rst, we can at least start
converting.

I quickly wrote a small "kernel-doc-rst-lint" script (70 lines of
python) based on rst-lint [1] that runs kernel-doc on a file and reports
all the kernel-doc and rst-lint errors in the output. This can be run as
a "checker" in the kernel build with

$ make CHECKER=scripts/kernel-doc-rst-lint C=1

and it can provide better and more direct warnings on kernel-doc/rst
errors than a full Sphinx build does.

BR,
Jani.


[1] https://pypi.python.org/pypi/restructuredtext_lint



-- 
Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 00/10] Documentation/Sphinx

[Markus Heiser]

Am 31.05.2016 um 12:30 schrieb Jani Nikula <jani.nikula@intel.com>:

> On Tue, 31 May 2016, Markus Heiser <markus.heiser@darmarit.de> wrote:
>> Am 31.05.2016 um 10:07 schrieb Daniel Vetter <daniel.vetter@ffwll.ch>:
>>> 0-day builds all docs, and checks for new warnings. Even in today's
>>> gpu.tmpl build there's a massive pile of warnings, so yes developers
>>> don't look. But 0-day does, and then developers look at the nice mails
>>> from 0-day. It mostly works to keep out new fail I think.
>> 
>> In general, I'am not very happy with workarounds like this. IMO these
>> are workarounds are often, rewards bunglers and punish those with more work,
>> who want make thinks right. There might be situations where 0-day build
>> is the only/best solution. But *here* we are talking about one additional
>> comment line the author adds, when he modify his source comments from kernel-doc 
>> to reST markup .. IMO not very hard.
> 
> That "one line" translates to nearly 50000 kernel-doc comments in more
> than 6000 files. If you expect people to add a tag in each file/comment,
> it will never happen. If we assume it's all rst, we can at least start
> converting.

I have the impression that we misunderstand us ...

You will add this line only to these files where you have changed the 
markup from *vintage* kerenel-doc to reST. In my solution, you can
change the markup on every comment, but you don't have to .. it
is enough to add one line at the top of the file.

It's hard to describe something without an example, let my finish my
work and after this I can show it by example. Then you will see,
that the impact is less then you fear.

> I quickly wrote a small "kernel-doc-rst-lint" script (70 lines of
> python) based on rst-lint [1] that runs kernel-doc on a file and reports
> all the kernel-doc and rst-lint errors in the output. This can be run as
> a "checker" in the kernel build with
> 
> $ make CHECKER=scripts/kernel-doc-rst-lint C=1
> 
> and it can provide better and more direct warnings on kernel-doc/rst
> errors than a full Sphinx build does.

I haven't tested [1], but I assume that it covers only docutils-reST not
the Sphinx-doc superset (thats might be the reason why you see less errors)
... anyway it could be convenient tool.


--Markus--

PS: I looked closer to [1], it uses the docutils puplischer ..

  from docutils.core import Publisher

with a /dev/null like stream

  document.reporter.stream = None

The errors you get from this are the same you get from a rst2xxx 
tool ...

|  >>> import restructuredtext_lint
|  >>> errors = restructuredtext_lint.lint("""
|  ... Hello World
|  ... =======
|  ... 
|  ... :ref:`label_name` 
|  ... """)
|  >>> errors[0].astext()
|  u'None:3: (WARNING/2) Title underline too short.\n\nHello World\n======='
|  >>> errors[1].astext()
|  u'None:5: (INFO/1) No role entry for "ref" in module "docutils.parsers.rst.languages.en".\nTrying "ref" as canonical role name.'

> 
> BR,
> Jani.
> 
> 
> [1] https://pypi.python.org/pypi/restructuredtext_lint
> 
> 
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 00/10] Documentation/Sphinx

[Jonathan Corbet]

On Mon, 30 May 2016 11:10:26 +0200
Daniel Vetter <daniel.vetter@ffwll.ch> wrote:

> I think next steps is to get this merged into docs-next, with a stable
> tag, so that I can pull it into drm-misc.

So, I want to take another look at this, which probably will need another
day or two before it can happen.  First impression, though, is that this
is great, so I'm expecting that I'll be applying it.

Not sure about the stable tag, though?  It doesn't really seem like
stable material?  

jon

Re: [PATCH 00/10] Documentation/Sphinx

[Daniel Vetter]

On Wed, Jun 1, 2016 at 3:07 AM, Jonathan Corbet <corbet@lwn.net> wrote:
> On Mon, 30 May 2016 11:10:26 +0200
> Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
>> I think next steps is to get this merged into docs-next, with a stable
>> tag, so that I can pull it into drm-misc.
>
> So, I want to take another look at this, which probably will need another
> day or two before it can happen.  First impression, though, is that this
> is great, so I'm expecting that I'll be applying it.
>
> Not sure about the stable tag, though?  It doesn't really seem like
> stable material?

Oh, I meant a git tag of a stable (non-rebasing) branch that I can
pull into drm-misc so that we can apply the gpu.tmpl->gpu.rst
conversion on top. Not a cc: stable tag. Too many kinds of stable tags
I guess ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH 00/10] Documentation/Sphinx

[Jonathan Corbet]

[So I'm finally trying to get into this for real, hopefully I won't be
interrupted too many times...expect a few mails as I catch up.]

On Fri, 20 May 2016 16:39:31 +0300
Jani Nikula <jani.nikula@intel.com> wrote:

> There are a few tradeoffs, of course. First, this requires that the
> EXPORT_SYMBOL markers are placed immediately after the function being
> exported, as kernel-doc will only look at one file at a time. This is
> the recommendation anyway. 

As I understand it, the technical reasons that kept some markers in
separate files should no longer be relevant, so this is probably OK.  It
would be nice to have a sense for how many sites need to be fixed.

> Second, we lose support for the !C docproc directive to check
> that all kernel-doc comments in a file are used. This is probably
> something we'd like to have back in the future, but at this time I think
> it's an acceptable tradeoff wrt the gains.

This is maybe a job for a separate tool.  A related issue is the (fairly
frequent) "oh look, none of the comments in $FILE are being used"
realization that seems to happen fairly often.  It would be nice to check
for that, but that's going to be hard to shoehorn into Sphinx.

jon

Re: [PATCH 00/10] Documentation/Sphinx

[Daniel Vetter]

On Fri, Jun 3, 2016 at 10:16 PM, Jonathan Corbet <corbet@lwn.net> wrote:
>
>> Second, we lose support for the !C docproc directive to check
>> that all kernel-doc comments in a file are used. This is probably
>> something we'd like to have back in the future, but at this time I think
>> it's an acceptable tradeoff wrt the gains.
>
> This is maybe a job for a separate tool.  A related issue is the (fairly
> frequent) "oh look, none of the comments in $FILE are being used"
> realization that seems to happen fairly often.  It would be nice to check
> for that, but that's going to be hard to shoehorn into Sphinx.

I think much more valuable would be a tool that checks whether
comments are pulled in anywhere (for a given source file), over the
entire tree. Very often entire subsystems carg-cult kernel-doc, but
never use it in a .tmpl, which means 0-day won't notice, and neither
anyone else.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH 00/10] Documentation/Sphinx

[Jonathan Corbet]

On Fri, 3 Jun 2016 22:24:03 +0200
Daniel Vetter <daniel.vetter@ffwll.ch> wrote:

> > This is maybe a job for a separate tool.  A related issue is the (fairly
> > frequent) "oh look, none of the comments in $FILE are being used"
> > realization that seems to happen fairly often.  It would be nice to check
> > for that, but that's going to be hard to shoehorn into Sphinx.  
> 
> I think much more valuable would be a tool that checks whether
> comments are pulled in anywhere (for a given source file), over the
> entire tree. Very often entire subsystems carg-cult kernel-doc, but
> never use it in a .tmpl, which means 0-day won't notice, and neither
> anyone else.

That is kind of what I was trying to get at, yes :)

jon

Re: [PATCH 05/10] Documentation/sphinx: add Sphinx kernel-doc directive extension

[Jonathan Corbet]

On Fri, 20 May 2016 16:39:36 +0300
Jani Nikula <jani.nikula@intel.com> wrote:

> Add an extension to handle kernel-doc directives, to call kernel-doc
> according to the arguments and parameters given to the reStructuredText
> directive.
> 
> The syntax for the kernel-doc directive is:
> 
> .. kernel-doc:: FILENAME
>    :export:
>    :internal:
>    :functions: FUNCTION [FUNCTION ...]
>    :doc: SECTION TITLE

So this seems just like what the doctor ordered - nice!

One little thought that has crossed my mind: it might be nice to be able to
put a regex in :functions: so we could say something like:

    :functions: atomic_.*

That requires a kernel-doc tweak too, of course.  Someday.

Might it be worth running this by the Sphinx list just to see what they
have to say?

jon

Re: rst2pdf (was [PATCH 00/10] Documentation/Sphinx)

[Jonathan Corbet]

On Mon, 30 May 2016 23:05:34 +0300
Jani Nikula <jani.nikula@intel.com> wrote:

> > I can't recommend to use rst2pdf (it is less maintained), use default
> > sphinx LaTeX toolchain.  
> 
> I think we'll use whatever works, rst2pdf seemed to work for now, but we
> can change if needed.

I really like the idea of using rst2pdf and keeping the huge latex
dependency out of the mix.  I am a bit concerned, though; I've been able
to crash it in my experiments here.  We may want to have the ability to
support either chain eventually; otherwise, we might just end up picking
up maintenance of rst2pdf at some point so that it works properly for us.

jon

Re: [PATCH 00/10] Documentation/Sphinx

[Jonathan Corbet]

On Mon, 30 May 2016 23:05:34 +0300
Jani Nikula <jani.nikula@intel.com> wrote:

> To be clear, the "sphinx-for-docs-next" branch of [1], [2] is what I
> propose to merge at this time. There's the Sphinx configuration, kernel
> build integration, Sphinx kernel-doc extension, tons of kernel-doc
> updates, etc. 

OK, I do believe that I am ready to do that.  Many, many thanks for doing
this work!  Please drop me a note when you think that the branch is ready
to go.

> There is no DocBook tmpl conversion; all of that is left
> to the authors (owners, maintainers) of the documents, but this enables
> them to focus on that part.

I would like to have some actual documents in there in the near future,
so that interested folks have something to look at and start with.  Maybe
I'll do that myself with some of the docbooks without active maintainers,
or even, maybe, some of the .txt files :)

Thanks,

jon

Re: [PATCH 00/10] Documentation/Sphinx

[Daniel Vetter]

On Fri, Jun 3, 2016 at 11:04 PM, Jonathan Corbet <corbet@lwn.net> wrote:
> On Mon, 30 May 2016 23:05:34 +0300
> Jani Nikula <jani.nikula@intel.com> wrote:
>
>> To be clear, the "sphinx-for-docs-next" branch of [1], [2] is what I
>> propose to merge at this time. There's the Sphinx configuration, kernel
>> build integration, Sphinx kernel-doc extension, tons of kernel-doc
>> updates, etc.
>
> OK, I do believe that I am ready to do that.  Many, many thanks for doing
> this work!  Please drop me a note when you think that the branch is ready
> to go.

I've just fixed the last bug in the line number support. I guess next
week Jani will double-check that and then send out the patch bomb for
you. We have more ideas and work, but I think this is a very good
baseline to get going.

>> There is no DocBook tmpl conversion; all of that is left
>> to the authors (owners, maintainers) of the documents, but this enables
>> them to focus on that part.
>
> I would like to have some actual documents in there in the near future,
> so that interested folks have something to look at and start with.  Maybe
> I'll do that myself with some of the docbooks without active maintainers,
> or even, maybe, some of the .txt files :)

I definitely want to get gpu.tmpl converted for 4.8, but that's
probably better done in drm-misc instead of doc-next for coordination
with ongoing drm work. I'd also like to unify dma-buffer-sharing.txt
with the kerneldoc we have into one .rst. Jani has done all the
testing and development on a full conversion of all .tmpl files
(except media), so I guess we could convert all the others directly in
doc-next.

One bit to think of is how much we want to split things up. For gpu
and related documentation I think we'll go with Documentation/gpu/ and
then put an overview.rst, drm_kms.rst, drm_kms_helper.rst drm_uapi.rst
and so on in there. gpu.tmpl is way too big imo, the only reason we
had it all merged is to keep cross-referencing working. But with
sphinx that works across source files, and we can split things up
more. Many other docs seem fairly small in comparison, so maybe ok to
keep as-is.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH 05/10] Documentation/sphinx: add Sphinx kernel-doc directive extension

[Markus Heiser]

Am 03.06.2016 um 22:35 schrieb Jonathan Corbet <corbet@lwn.net>:

> On Fri, 20 May 2016 16:39:36 +0300
> Jani Nikula <jani.nikula@intel.com> wrote:
> 
>> Add an extension to handle kernel-doc directives, to call kernel-doc
>> according to the arguments and parameters given to the reStructuredText
>> directive.
>> 
>> The syntax for the kernel-doc directive is:
>> 
>> .. kernel-doc:: FILENAME
>>   :export:
>>   :internal:
>>   :functions: FUNCTION [FUNCTION ...]
>>   :doc: SECTION TITLE
> 
> So this seems just like what the doctor ordered - nice!
> 
> One little thought that has crossed my mind: it might be nice to be able to
> put a regex in :functions: so we could say something like:
> 
>    :functions: atomic_.*
> 
> That requires a kernel-doc tweak too, of course.  Someday.

IMO it is better to be explicit ... wildcards (ranges) has the disadvantage that
you can't check if any/all definition is missed ...

--Markus-- 

> 
> Might it be worth running this by the Sphinx list just to see what they
> have to say?
> 
> jon

Re: [PATCH 00/10] Documentation/Sphinx

[Jani Nikula]

On Sat, 04 Jun 2016, Jonathan Corbet <corbet@lwn.net> wrote:
> On Mon, 30 May 2016 23:05:34 +0300
> Jani Nikula <jani.nikula@intel.com> wrote:
>
>> To be clear, the "sphinx-for-docs-next" branch of [1], [2] is what I
>> propose to merge at this time. There's the Sphinx configuration, kernel
>> build integration, Sphinx kernel-doc extension, tons of kernel-doc
>> updates, etc. 
>
> OK, I do believe that I am ready to do that.  Many, many thanks for doing
> this work!  Please drop me a note when you think that the branch is ready
> to go.

In case you missed the patch bomb in your inbox, I think it's ready
now. ;)

>> There is no DocBook tmpl conversion; all of that is left
>> to the authors (owners, maintainers) of the documents, but this enables
>> them to focus on that part.
>
> I would like to have some actual documents in there in the near future,
> so that interested folks have something to look at and start with.  Maybe
> I'll do that myself with some of the docbooks without active maintainers,
> or even, maybe, some of the .txt files :)

So we'll be working on gpu.tmpl next and I'll look at
Documentation/kernel-doc-nano-HOWTO.txt too.

BR,
Jani.



-- 
Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 00/10] Documentation/Sphinx

[Jani Nikula]

On Fri, 03 Jun 2016, Jonathan Corbet <corbet@lwn.net> wrote:
> [So I'm finally trying to get into this for real, hopefully I won't be
> interrupted too many times...expect a few mails as I catch up.]
>
> On Fri, 20 May 2016 16:39:31 +0300
> Jani Nikula <jani.nikula@intel.com> wrote:
>
>> There are a few tradeoffs, of course. First, this requires that the
>> EXPORT_SYMBOL markers are placed immediately after the function being
>> exported, as kernel-doc will only look at one file at a time. This is
>> the recommendation anyway. 
>
> As I understand it, the technical reasons that kept some markers in
> separate files should no longer be relevant, so this is probably OK.  It
> would be nice to have a sense for how many sites need to be fixed.

Actually, mostly this is not a problem due to EXPORT_SYMBOL placement,
but rather due to kernel-doc comments being placed in header files above
function declarations while EXPORT_SYMBOL is where it should be next to
the function definition.

I don't think we can force people to move the kernel-doc comments for
exported functions from header files next to the function definitions.

The straightforward fix to this is to add an optional filename parameter
to the kernel-doc extension :export: argument, to pass additional files
to kernel-doc where to look for the EXPORT_SYMBOLs. For example:

.. kernel-doc:: include/drm/foo.h
   :export: drivers/gpu/drm/foo/foo.c drivers/gpu/drm/foo/bar.c

This would instruct kernel-doc to extract documentation from
include/drm/foo.h for all functions that have been exported using
EXPORT_SYMBOL (or _GPL) in include/drm/foo.h, drivers/gpu/drm/foo/foo.c,
or drivers/gpu/drm/foo/bar.c.

We have something along these lines in docproc already with the !D
directive, so nothing altogether surprising.

If my quick grep-fu serves me right, there are about a thousand exported
symbols with kernel-doc comments in the headers. It's a ballpark
figure. They come in batches; a small fraction of that many filenames in
a fraction of the :export: statements would cover most of them.

Before this fix, the workaround is to name the functions with
:functions: argument instead of using :export:.

I'm hoping this is not a blocker for merging the series. If the proposed
fix is acceptable, I'll get it done before v4.8.

BR,
Jani.


The ugly greps:

$ git grep "^EXPORT_SYMBOL" | sed 's/^[^(]*(\([a-zA-Z0-9_]*\)).*/\1/' | sort > exports
$ git grep -h -A1 "^/\*\*$" -- *.h | grep -v "^\(/\*\*\|--\)" | sed 's/^ \*[         ]*\([a-zA-Z0-9_][a-zA-Z0-9_]*\).*/\1/;' | sort > comments
$ comm -1 -2 comments exports | wc -l
952




-- 
Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 00/10] Documentation/Sphinx

[Jani Nikula]

On Fri, 03 Jun 2016, Jonathan Corbet <corbet@lwn.net> wrote:
> On Fri, 3 Jun 2016 22:24:03 +0200
> Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
>> > This is maybe a job for a separate tool.  A related issue is the (fairly
>> > frequent) "oh look, none of the comments in $FILE are being used"
>> > realization that seems to happen fairly often.  It would be nice to check
>> > for that, but that's going to be hard to shoehorn into Sphinx.  
>> 
>> I think much more valuable would be a tool that checks whether
>> comments are pulled in anywhere (for a given source file), over the
>> entire tree. Very often entire subsystems carg-cult kernel-doc, but
>> never use it in a .tmpl, which means 0-day won't notice, and neither
>> anyone else.
>
> That is kind of what I was trying to get at, yes :)

For the 0-day, I've already got a preliminary kernel-doc-rst-lint
script, which can be used as a checker in the kernel build. This would
catch all kernel-doc comments, whether they're included to documentation
or not, and complain about kernel-doc and rst issues. It won't be as
comprehensive as a full Sphinx build in terms of validation, but it'll
cover more kernel-doc comments. It should catch the silly errors early.

BR,
Jani.



-- 
Jani Nikula, Intel Open Source Technology Center

Re: rst2pdf (was [PATCH 00/10] Documentation/Sphinx)

[Markus Heiser]

Am 03.06.2016 um 22:47 schrieb Jonathan Corbet <corbet@lwn.net>:

> On Mon, 30 May 2016 23:05:34 +0300
> Jani Nikula <jani.nikula@intel.com> wrote:
> 
>>> I can't recommend to use rst2pdf (it is less maintained), use default
>>> sphinx LaTeX toolchain.  
>> 
>> I think we'll use whatever works, rst2pdf seemed to work for now, but we
>> can change if needed.
> 
> I really like the idea of using rst2pdf and keeping the huge latex
> dependency out of the mix.  I am a bit concerned, though; I've been able
> to crash it in my experiments here.  We may want to have the ability to
> support either chain eventually; otherwise, we might just end up picking
> up maintenance of rst2pdf at some point so that it works properly for us.
> 
> jon

I looked closer to rst2pdf, it supports only the docutils reST, but
not the sphinx superset ...  

<SNIP rst2pdf>-------------
$ rst2pdf  index.rst
index.rst:15: (ERROR/3) Unknown interpreted text role "ref".
index.rst:15: (ERROR/3) Unknown interpreted text role "ref".
index.rst:27: (ERROR/3) Unknown directive type "toctree".

.. toctree::
    :maxdepth: 1

    kernel-doc-intro
    kernel-doc-syntax
<SNAP>-------------


rules like ":ref:", domains like ":c:type:" and directives like ".. toctree:"
are a part of the (extended) reST syntax from sphinx, thats why 
standard docutils (like rst2*) will not work ...

> Am 18.04.2016 um 10:10 schrieb Markus Heiser <markus.heiser@darmarIT.de>:
> Re: Kernel docs: muddying the waters a bit
>
> BTW a few words about differences between DockBook and reST (Sphinx).
> 
> With DocBook you write *books*, the protocol (the DocBook application) has
> no facility to *chunk* and interconnect several documents. The external ENTITY 
> is a workaround on the SGML layer, not on XML nor on the DB-application layer.
> Thats the reason, why so many XML-tools don't handle this entities and
> many DocBook to (e.g.) reST tools are fail.
> 
> With **standard** reST it is nearly the same, except there is a "include"
> directive on the application layer. But this directive is very simple,
> comparable to the C preprocessor "#include" directive.
> 
> With the **superset** reST-markup of Sphinx-doc you get a the "toctree" directive,
> which lets you control how a document-tree should be build.
> 
> http://www.sphinx-doc.org/en/stable/markup/toctree.html
> 
> @Mauro: you mentioned a docutils (rst2*) experience in your mail 
>      http://marc.info/?l=linux-doc&m=145735316012094&w=2
> 
>      Because the "toctree" directive -- and other directives
>      we use -- are a part of a superset of the **standard** 
>      reST, the standard docutils (like rst2*) will not work.


-- Markus --

Re: rst2pdf (was [PATCH 00/10] Documentation/Sphinx)

[Jani Nikula]

On Tue, 07 Jun 2016, Markus Heiser <markus.heiser@darmarit.de> wrote:
> I looked closer to rst2pdf, it supports only the docutils reST, but
> not the sphinx superset ...  
>
> <SNIP rst2pdf>-------------
> $ rst2pdf  index.rst
> index.rst:15: (ERROR/3) Unknown interpreted text role "ref".
> index.rst:15: (ERROR/3) Unknown interpreted text role "ref".
> index.rst:27: (ERROR/3) Unknown directive type "toctree".

This doesn't actually happen if you run rst2pdf through Sphinx.

> .. toctree::
>     :maxdepth: 1
>
>     kernel-doc-intro
>     kernel-doc-syntax
> <SNAP>-------------
>
>
> rules like ":ref:", domains like ":c:type:" and directives like ".. toctree:"
> are a part of the (extended) reST syntax from sphinx, thats why 
> standard docutils (like rst2*) will not work ...

You will get warnings like

[WARNING] styles.py:548 Using undefined style 'function', aliased to style 'normal'.
[WARNING] styles.py:548 Using undefined style 'type', aliased to style 'normal'.

but it's a matter of defining a custom rst2pdf stylesheet. It's json
with a sort of inheritance model, so it should be easy to just extend
the existing stylesheet.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center

Re: rst2pdf (was [PATCH 00/10] Documentation/Sphinx)

[Markus Heiser]

Am 07.06.2016 um 08:44 schrieb Jani Nikula <jani.nikula@intel.com>:

> On Tue, 07 Jun 2016, Markus Heiser <markus.heiser@darmarit.de> wrote:
>> I looked closer to rst2pdf, it supports only the docutils reST, but
>> not the sphinx superset ...  
>> 
>> <SNIP rst2pdf>-------------
>> $ rst2pdf  index.rst
>> index.rst:15: (ERROR/3) Unknown interpreted text role "ref".
>> index.rst:15: (ERROR/3) Unknown interpreted text role "ref".
>> index.rst:27: (ERROR/3) Unknown directive type "toctree".
> 
> This doesn't actually happen if you run rst2pdf through Sphinx.
> 

Aaah, thanks for hinting. With this in mind, I think rst2pdf
is a good choice and the minor bugs in could be handled. In the
long term a XeTeX builder as an alternative to produce layouts
with higher quality would be nice.

I (also) added rst2pdf:

https://github.com/return42/linux/commit/d88c4981f86fed85e54ee4d4955b35eb9eaac063

-- M --


>> .. toctree::
>>    :maxdepth: 1
>> 
>>    kernel-doc-intro
>>    kernel-doc-syntax
>> <SNAP>-------------
>> 
>> 
>> rules like ":ref:", domains like ":c:type:" and directives like ".. toctree:"
>> are a part of the (extended) reST syntax from sphinx, thats why 
>> standard docutils (like rst2*) will not work ...
> 
> You will get warnings like
> 
> [WARNING] styles.py:548 Using undefined style 'function', aliased to style 'normal'.
> [WARNING] styles.py:548 Using undefined style 'type', aliased to style 'normal'.
> 
> but it's a matter of defining a custom rst2pdf stylesheet. It's json
> with a sort of inheritance model, so it should be easy to just extend
> the existing stylesheet.
> 
> BR,
> Jani.
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 00/10] Documentation/Sphinx

[Mauro Carvalho Chehab]

Em Tue, 31 May 2016 12:16:25 +0200
Markus Heiser <markus.heiser@darmarit.de> escreveu:

> Am 30.05.2016 um 23:23 schrieb Mauro Carvalho Chehab <mchehab@osg.samsung.com>:
> 
> > Em Mon, 30 May 2016 23:05:34 +0300
> > Jani Nikula <jani.nikula@intel.com> escreveu:
> >   
> >>> I worry a little bit in that reST will be only one more toolchain 
> >>> beside DocBook .. in the long term, kernel's documentation 
> >>> should get rid of all the DocBook artifacts and for this a more
> >>> comprehensive solution is needed.    
> >> 
> >> We agree on the end goal, eradicate DocBook. I must say that in my
> >> experiments, apart from the media docs, almost everything converts
> >> surprisingly nicely or IMO "good enough" with just the tmplcvt script in
> >> this series.  
> > 
> > With regards to media, my plan is to merge create a topic branch based
> > on Kernel 4.7-rc1 at:
> > 	https://git.linuxtv.org/media_tree.git/
> > 
> > As none of the Jani's patches seem to affect the media API docs, it
> > seems I don't need to merge back from Jon's -next branch.
> > 
> > There, I intend to add Markus patches with the conversion from the
> > DocBook to rst, plus the flat-table extension logic.
> > 
> > Then, I'll work to manually fix what's needed and I'll add the 
> > automation scripting logic that we have at the DocBook Makefile
> > to work with the new media rst files.
> > 
> > Lastly, once the job's done, I'll drop Documentation/DocBook/media.
> > 
> > Markus,
> > 
> > With that regards, could you please send the patches to me?  
> 
> Yes. What is your timeline ... is it OK if I send you a patch in the 
> next two weeks? ... first I wan't to finish my other work / I'am just
> back from holiday .. a lot of work to do :-o

Hi Markus,

I'm wanting to start working on it next week, if possible.

I created an experimental branch on my tree for such work, where
I'm merging from both Jon's doc-next tree and from media tree at:
	https://git.linuxtv.org//mchehab/experimental.git/log/?h=docs-next

Could you please rebase your work with the media DocBook and with
the flat-table support to be on the top of it?

Thanks!
Mauro

Re: [PATCH 00/10] Documentation/Sphinx

[Markus Heiser]

Am 24.06.2016 um 12:40 schrieb Mauro Carvalho Chehab <mchehab@osg.samsung.com>:

> Em Tue, 31 May 2016 12:16:25 +0200
> Markus Heiser <markus.heiser@darmarit.de> escreveu:
> 
>> Am 30.05.2016 um 23:23 schrieb Mauro Carvalho Chehab <mchehab@osg.samsung.com>:
>> 
>>> Em Mon, 30 May 2016 23:05:34 +0300
>>> Jani Nikula <jani.nikula@intel.com> escreveu:
>>> 
>>>>> I worry a little bit in that reST will be only one more toolchain 
>>>>> beside DocBook .. in the long term, kernel's documentation 
>>>>> should get rid of all the DocBook artifacts and for this a more
>>>>> comprehensive solution is needed.    
>>>> 
>>>> We agree on the end goal, eradicate DocBook. I must say that in my
>>>> experiments, apart from the media docs, almost everything converts
>>>> surprisingly nicely or IMO "good enough" with just the tmplcvt script in
>>>> this series.  
>>> 
>>> With regards to media, my plan is to merge create a topic branch based
>>> on Kernel 4.7-rc1 at:
>>> 	https://git.linuxtv.org/media_tree.git/
>>> 
>>> As none of the Jani's patches seem to affect the media API docs, it
>>> seems I don't need to merge back from Jon's -next branch.
>>> 
>>> There, I intend to add Markus patches with the conversion from the
>>> DocBook to rst, plus the flat-table extension logic.
>>> 
>>> Then, I'll work to manually fix what's needed and I'll add the 
>>> automation scripting logic that we have at the DocBook Makefile
>>> to work with the new media rst files.
>>> 
>>> Lastly, once the job's done, I'll drop Documentation/DocBook/media.
>>> 
>>> Markus,
>>> 
>>> With that regards, could you please send the patches to me?  
>> 
>> Yes. What is your timeline ... is it OK if I send you a patch in the 
>> next two weeks? ... first I wan't to finish my other work / I'am just
>> back from holiday .. a lot of work to do :-o
> 
> Hi Markus,
> 
> I'm wanting to start working on it next week, if possible.
> 
> I created an experimental branch on my tree for such work, where
> I'm merging from both Jon's doc-next tree and from media tree at:
> 	https://git.linuxtv.org//mchehab/experimental.git/log/?h=docs-next
> 
> Could you please rebase your work with the media DocBook and with
> the flat-table support to be on the top of it?
> 
> Thanks!
> Mauro

Hi Mauro,

sorry for my late reply, I finished the man-page builder last weekend.

> I'm merging from both Jon's doc-next tree and from media tree

Currently I'am working on a rebase on top of the Jon's docs-next branch
(with "s" in "docs-" / think it was only a typo). 

Hopefully I get this done in the next 2 days.

I will send a pull request when I'am finished / thanks for your
patience until then.

Regards 

  --Markus--	

Re: [PATCH 00/10] Documentation/Sphinx

[Mauro Carvalho Chehab]

Em Mon, 27 Jun 2016 08:15:28 +0200
Markus Heiser <markus.heiser@darmarit.de> escreveu:

> Am 24.06.2016 um 12:40 schrieb Mauro Carvalho Chehab <mchehab@osg.samsung.com>:
> 
> > Em Tue, 31 May 2016 12:16:25 +0200
> > Markus Heiser <markus.heiser@darmarit.de> escreveu:
> >   
> >> Am 30.05.2016 um 23:23 schrieb Mauro Carvalho Chehab <mchehab@osg.samsung.com>:
> >>   
> >>> Em Mon, 30 May 2016 23:05:34 +0300
> >>> Jani Nikula <jani.nikula@intel.com> escreveu:
> >>>   
> >>>>> I worry a little bit in that reST will be only one more toolchain 
> >>>>> beside DocBook .. in the long term, kernel's documentation 
> >>>>> should get rid of all the DocBook artifacts and for this a more
> >>>>> comprehensive solution is needed.      
> >>>> 
> >>>> We agree on the end goal, eradicate DocBook. I must say that in my
> >>>> experiments, apart from the media docs, almost everything converts
> >>>> surprisingly nicely or IMO "good enough" with just the tmplcvt script in
> >>>> this series.    
> >>> 
> >>> With regards to media, my plan is to merge create a topic branch based
> >>> on Kernel 4.7-rc1 at:
> >>> 	https://git.linuxtv.org/media_tree.git/
> >>> 
> >>> As none of the Jani's patches seem to affect the media API docs, it
> >>> seems I don't need to merge back from Jon's -next branch.
> >>> 
> >>> There, I intend to add Markus patches with the conversion from the
> >>> DocBook to rst, plus the flat-table extension logic.
> >>> 
> >>> Then, I'll work to manually fix what's needed and I'll add the 
> >>> automation scripting logic that we have at the DocBook Makefile
> >>> to work with the new media rst files.
> >>> 
> >>> Lastly, once the job's done, I'll drop Documentation/DocBook/media.
> >>> 
> >>> Markus,
> >>> 
> >>> With that regards, could you please send the patches to me?    
> >> 
> >> Yes. What is your timeline ... is it OK if I send you a patch in the 
> >> next two weeks? ... first I wan't to finish my other work / I'am just
> >> back from holiday .. a lot of work to do :-o  
> > 
> > Hi Markus,
> > 
> > I'm wanting to start working on it next week, if possible.
> > 
> > I created an experimental branch on my tree for such work, where
> > I'm merging from both Jon's doc-next tree and from media tree at:
> > 	https://git.linuxtv.org//mchehab/experimental.git/log/?h=docs-next
> > 
> > Could you please rebase your work with the media DocBook and with
> > the flat-table support to be on the top of it?
> > 
> > Thanks!
> > Mauro  
> 
> Hi Mauro,
> 
> sorry for my late reply, I finished the man-page builder last weekend.
> 
> > I'm merging from both Jon's doc-next tree and from media tree  
> 
> Currently I'am working on a rebase on top of the Jon's docs-next branch
> (with "s" in "docs-" / think it was only a typo). 
> 
> Hopefully I get this done in the next 2 days.
> 
> I will send a pull request when I'am finished / thanks for your
> patience until then.

Ok!

Thanks for your work!

Regards,
Mauro

Re: [PATCH 00/10] Documentation/Sphinx

[Markus Heiser]

Am 27.06.2016 um 19:08 schrieb Mauro Carvalho Chehab <mchehab@osg.samsung.com>:

> Em Mon, 27 Jun 2016 08:15:28 +0200
> Markus Heiser <markus.heiser@darmarit.de> escreveu:
> 
>> Am 24.06.2016 um 12:40 schrieb Mauro Carvalho Chehab <mchehab@osg.samsung.com>:
>> 
>>> Em Tue, 31 May 2016 12:16:25 +0200
>>> Markus Heiser <markus.heiser@darmarit.de> escreveu:
>>> 
>>>> Am 30.05.2016 um 23:23 schrieb Mauro Carvalho Chehab <mchehab@osg.samsung.com>:
>>>> 
>>>>> Em Mon, 30 May 2016 23:05:34 +0300
>>>>> Jani Nikula <jani.nikula@intel.com> escreveu:
>>>>> 
>>>>>>> I worry a little bit in that reST will be only one more toolchain 
>>>>>>> beside DocBook .. in the long term, kernel's documentation 
>>>>>>> should get rid of all the DocBook artifacts and for this a more
>>>>>>> comprehensive solution is needed.      
>>>>>> 
>>>>>> We agree on the end goal, eradicate DocBook. I must say that in my
>>>>>> experiments, apart from the media docs, almost everything converts
>>>>>> surprisingly nicely or IMO "good enough" with just the tmplcvt script in
>>>>>> this series.    
>>>>> 
>>>>> With regards to media, my plan is to merge create a topic branch based
>>>>> on Kernel 4.7-rc1 at:
>>>>> 	https://git.linuxtv.org/media_tree.git/
>>>>> 
>>>>> As none of the Jani's patches seem to affect the media API docs, it
>>>>> seems I don't need to merge back from Jon's -next branch.
>>>>> 
>>>>> There, I intend to add Markus patches with the conversion from the
>>>>> DocBook to rst, plus the flat-table extension logic.
>>>>> 
>>>>> Then, I'll work to manually fix what's needed and I'll add the 
>>>>> automation scripting logic that we have at the DocBook Makefile
>>>>> to work with the new media rst files.
>>>>> 
>>>>> Lastly, once the job's done, I'll drop Documentation/DocBook/media.
>>>>> 
>>>>> Markus,
>>>>> 
>>>>> With that regards, could you please send the patches to me?    
>>>> 
>>>> Yes. What is your timeline ... is it OK if I send you a patch in the 
>>>> next two weeks? ... first I wan't to finish my other work / I'am just
>>>> back from holiday .. a lot of work to do :-o  
>>> 
>>> Hi Markus,
>>> 
>>> I'm wanting to start working on it next week, if possible.
>>> 
>>> I created an experimental branch on my tree for such work, where
>>> I'm merging from both Jon's doc-next tree and from media tree at:
>>> 	https://git.linuxtv.org//mchehab/experimental.git/log/?h=docs-next
>>> 
>>> Could you please rebase your work with the media DocBook and with
>>> the flat-table support to be on the top of it?
>>> 
>>> Thanks!
>>> Mauro  
>> 
>> Hi Mauro,
>> 
>> sorry for my late reply, I finished the man-page builder last weekend.
>> 
>>> I'm merging from both Jon's doc-next tree and from media tree  
>> 
>> Currently I'am working on a rebase on top of the Jon's docs-next branch
>> (with "s" in "docs-" / think it was only a typo). 
>> 
>> Hopefully I get this done in the next 2 days.
>> 
>> I will send a pull request when I'am finished / thanks for your
>> patience until then.
> 
> Ok!
> 
> Thanks for your work!
> 
> Regards,
> Mauro

Hi Mauro,

you could pull it from (see [1]).

  https://github.com/return42/linux.git docs-next/linux-doc-reST

I tested it local with your experimental/docs-next and it works.
If you don't want to build the whole documentation every time
(target htmldocs), use 

  $ make books/linux_tv.html
  ... 
  $ make books/linux_tv.clean

May you read the Documentation/books_migrated/README.txt. Since
Documentation/books_migrated is only for the period of transition
move the linux_tv folder to Documentation/ when you start your review.

If you want the "media" folder back, rename it:

  mv Documentation/books_migrated/linux_tv Documentation/media

But take into account, that the target and dist-name is the name of the folder

  $ make books/media.html	
  ...
  SPHINX  books/medi.html --> file:///share/linux-test/Documentation/dist/books/media

BTW, if you do so, we have to modify the ref in Documentation/index.rst

If you build the book, you will see messages like this one:

/share/linux-test/Documentation/books_migrated/linux_tv/media/dvb/FE_GET_EVENT.rst:19: WARNING: Inline emphasis start-string without end-string.

These are marginal issues, ignore them for the first, we fix these
in one step later. First, check if you find any *systematic error*
and report me .. hopefully there are none, but who knows ..

If you have any problems or questions, regardless with sphinx-doc
installation, layout issues, with the reST markup or whatever 
... don't hesitate to contact me directly.

One question: is it right, that no man-pages are created from the 
"media" content? I tried the xmlto on the DocBook-XML media but no
man-pages has been created ...

BTW: the man-page build (target books/name.man) is 10^2-10^3 times faster
than the xmlto, no loud fan anymore ... but if you don't have man-pages
you wan't notice a change ;-)

[1] http://article.gmane.org/gmane.linux.kernel/2255354

-- Markus --