We've been accumulating code across the driver that depends on the VBT
specific structures and defines. The VBT is an uncontrollable
beast. Encourage encapsulation of the VBT data by hiding the structures
and defines in a private header only to be included from intel_bios.c.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458125015-7931-7-git-send-email-jani.nikula@intel.com

Patch based on a previous series by Shashank Sharma.

This introduces optional properties to enable color correction at the
pipe level. It relies on 3 transformations applied to every pixels
displayed. First a lookup into a degamma table, then a multiplication
of the rgb components by a 3x3 matrix and finally another lookup into
a gamma table.

The following properties can be added to a pipe :
  - DEGAMMA_LUT : blob containing degamma LUT
  - DEGAMMA_LUT_SIZE : number of elements in DEGAMMA_LUT
  - CTM : transformation matrix applied after the degamma LUT
  - GAMMA_LUT : blob containing gamma LUT
  - GAMMA_LUT_SIZE : number of elements in GAMMA_LUT

DEGAMMA_LUT_SIZE and GAMMA_LUT_SIZE are read only properties, set by
the driver to tell userspace applications what sizes should be the
lookup tables in DEGAMMA_LUT and GAMMA_LUT.

A helper is also provided so legacy gamma correction is redirected
through these new properties.

v2: Register LUT size properties as range

v3: Fix round in drm_color_lut_get_value() helper
    More docs on how degamma/gamma properties are used

v4: Update contributors

v5: Rename CTM_MATRIX property to CTM (Doh!)
    Add legacy gamma_set atomic helper
    Describe CTM/LUT acronyms in the kernel doc

v6: Fix missing blob unref in drm_atomic_helper_crtc_reset
Signed-off-by: NShashank Sharma <shashank.sharma@intel.com>
Signed-off-by: NKumar, Kiran S <kiran.s.kumar@intel.com>
Signed-off-by: NKausal Malladi <kausalmalladi@gmail.com>
Signed-off-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Acked-by: NRob Bradford <robert.bradford@intel.com>
[danvet: CrOS maintainers are also happy with the userspacde side:
https://codereview.chromium.org/1182063002/ ]
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1456506302-640-4-git-send-email-lionel.g.landwerlin@intel.com

The formats use three planes through the multiplanar API, allowing for
non-contiguous planes in memory.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Some drivers also need a control like
V4L2_CID_MPEG_MFC51_VIDEO_FORCE_FRAME_TYPE to force an encoder
key frame. Add a general V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME
so the new drivers and applications can use it.
Signed-off-by: NWu-Cheng Li <wuchengli@chromium.org>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Defining it as a connector was a bad idea. Remove it while it is
not too late.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Defining it as a connector was a bad idea. Remove it while it is
not too late.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Document these new controls.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Centralize gmux' ACPI HID in a header file and add apple_gmux_present().
This can be used by other drivers to activate quirks specific to dual
GPU MacBook Pros & Mac Pros. The alternative would be to hardcode DMI
or PCI IDs and amend them whenever Apple introduces a new machine.
Tested-by: NLukas Wunner <lukas@wunner.de>
    [MBP  9,1 2012  intel IVB + nvidia GK107  pre-retina  15"]
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Reviewed-by: NDarren Hart <dvhart@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/89c23769058a340e5e11d4a7102f3793d3b0c94c.1452525860.git.lukas@wunner.de

Allow handlers to declare their capabilities and allow clients to
obtain that information. So far we have these use cases:

* If the handler is able to switch DDC separately, clients need to
  probe EDID with drm_get_edid_switcheroo(). We should allow them
  to detect a capable handler to ensure this function only gets
  called when needed.

* Likewise if the handler is unable to switch AUX separately, the active
  client needs to communicate link training parameters to the inactive
  client, which may then skip the AUX handshake and set up its output
  with these pre-calibrated values (DisplayPort specification v1.1a,
  section 2.5.3.3). Clients need a way to recognize such a situation.

The flags for the radeon_atpx_handler and amdgpu_atpx_handler are
initially set to 0, this can later on be amended with
  handler_flags |= VGA_SWITCHEROO_CAN_SWITCH_DDC;
when a ->switch_ddc callback is added.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115Tested-by: NLukas Wunner <lukas@wunner.de>
    [MBP  9,1 2012  intel IVB + nvidia GK107  pre-retina  15"]
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Reviewed-by: NDarren Hart <dvhart@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/2b0d93ed6e511ca09e95e45e0b35627f330fabce.1452525860.git.lukas@wunner.de

The two formats are very similar, having two separate pages to describe
them is overkill.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

A driver might detect a new standard or DV timings, but it will never change to
those new timings automatically. Instead it will send an event and let the application
take care of it.

Make this explicit in the documentation.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Very old hardware may have an analog stage tuner. Those hardware
consists of a PLL that converts a RF signal into IF signals.

Depending on the hardware, those video IF signal can be
decoded directly by the bridge chipset. Most Conexant
chips (bt8x8, cx2388x, etc) have internally the decoders
for that. Yet, even on such hardware, the tuner may have
internally its own TV multi-standard decoder like tda9887.

The same happens with the audio IF signal, where some bridges
are capable of receiving it, while others require an external
IF-PLL sound decoder, like msp3400.

Those external IF-PLL audio and video decoders have their own
I2C address, and use different drivers to handle them. So, they're
mapped as different subdevices on Linux.

Thankfully, all modern hardware comes with an IC chip that
has both the RF and the IF stages on it, being capable of
decoding audio and video IF signals internally.

Yet, as we need to support drivers that can work with either
analog or silicon tuners, we need to add two entity types
for those old hardware.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

The customer PC hardware can be shipped with lots of different
configurations, as vendors use to replace some of the chips on
their hardware along the time. All drivers that support such
devices are prepared to handle the hardware differences, using
their own auto-probing logic.

They do it in a way that number of inputs and outputs for a given
hardware type doesn't change.

Now that we're adding media controller capabilities to those drivers,
we need to standardize the number of inputs and outputs for each
hardware type, as we want to have a generic function at the V4L2
core that would create the links for the entities that are expected
on such hardware.

Such standard is already there for tuners, but tuner.h is not the
best place to store such data, as we'll need to add definitions also
for analog TV demodulators.

Also, we'll need a place to put a set of MC handling functions. So,
let's create a v4l2-mc.h to store such kind of definitions.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Enable MEDIA_IOC_G_TOPOLOGY ioctl for Kernel 4.6.

This reverts commit be0270ec.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Just prep work before I throw more drm_event refactorings on top.
Acked-by: NDaniel Stone <daniels@collabora.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452548477-15905-2-git-send-email-daniel.vetter@ffwll.chSigned-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Document what I've learned so far about the gmux so that we can
collaboratively reverse-engineer its remaining unknown bits
without everyone having to start from scratch.

The DOC sections are bound together in the gpu.tmpl DocBook
under a new vga_switcheroo "Handlers" chapter. Eventually
this should be amended with documentation about the four other
handlers that exist so far (nouveau v1 DSM, nouveau Optimus DSM,
radeon ATPX, amdgpu ATPX).

Requires kernel-doc with asciidoc support.

The EFI variable was reverse-engineered by Bruno Bierbaumer
<bruno@bierbaumer.net> and Andreas Heider <andreas@meetr.de>.

Some of the remaining open questions:

* How are vblank intervals synchronized on retinas to achieve seamless
  switching? Is the DP mux capable of this? It's not mentioned in the
  data sheets. Or is it done at the OS level, i.e. do we have to
  synchronize vblank intervals between DRM drivers? There's a signal
  coming from the panel connector and going into gmux, could this be
  the vblank signal as received by the panel to properly time the
  switch?

* On retinas there's an I2C bus between gmux and the connector of the
  right I/O board, apparently leading to the Parade PS8401A HDMI
  repeater. What is this for, is it controlled via gmux registers?
  Data sheet:
  http://www.paradetech.com/products/jitter-cleaning-repeaters/ps8401/

* On retinas there's an I2C bus between gmux and the LED driver.
  Pre-retinas connected the LED driver to SMBUS. Are there additional
  gmux registers on retinas to control it?

* The MacPro6,1 2013 also has a gmux, the same Renesas R4F2113 as the
  retina MacBook Pro. The Mac Pro doesn't have a built-in display,
  so what is its purpose? Power control of the dual FirePro GPUs?
  Switching of the external DP/Thunderbolt ports? The iFixit teardown
  clearly shows one TI HD3SS212 DisplayPort mux on the logic board next
  to one of the three Thunderbolt controllers. However six muxes would
  be necessary to switch all six ports between GPUs. The mux is probably
  necessary for one of the display configurations allowed by Apple,
  but which one?
  https://www.ifixit.com/Teardown/Mac+Pro+Late+2013+Teardown/20778
  https://d3nevzfk7ii3be.cloudfront.net/igi/fELBTnt31QhnDsqq.huge
  https://support.apple.com/en-us/HT202801

* Registers we haven't decoded yet:
  0x700 32 Bit configmap?
  0x708 32 Bit power sequence?
  0x712  8 Bit status of clock from panel on retinas?
  0x713  8 Bit dito?
  0x724 16 Bit backlight, raw value?
  0x760 32 Bit backlight
  0x764 32 Bit backlight
  0x768  8 Bit backlight
  0x76a 16 Bit backlight
  0x76c 16 Bit backlight
  0x76e 16 Bit backlight
  0x77f        edp/dp/hdmi probe? retina only.

* Addition by Bruno Prémont <bonbons@linux-vserver.org>:
  "Missing is also precise knowledge as to what the gmux depends on.
  From behavioral reports, it is somehow sensitive to VGA IO/MEM
  routing (it apparently needs the routing to go to integrated GPU,
  not discrete GPU).
  When the routing is inappropriate backlight control IO just reads back
  as 0xFF (and eventually gmux IO in general does so)."
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Acked-by: NDarren Hart <dvhart@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/da309e436fbeac886477d80376457b7d83ea4b2d.1452431795.git.lukas@wunner.deSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There are a few discussions left with regards to this ioctl:

1) the name of the new structs will contain _v2_ on it?
2) what's the best alternative to avoid compat32 issues?

Due to that, let's postpone the addition of this new ioctl to
the next Kernel version, to give people more time to discuss it.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Add description for this new media controller ioctl.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Document the media controller interfaces at the media
uAPI docbook.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

There were some changes on the media types that were not reflected
on the types tables. Update them to reflect the upstream changes.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

As MEDIA_IOC_G_TOPOLOGY shares the data types already declared
for entities, pads and links, we should move those to a separate
part of the document, and use cross-references where needed.

So, move the following tables to a separate section at the
DocBook:
	media-entity-type
	media-entity-flag
	media-pad-flag
	media-link-flag
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

The Media Controller next generation patches added a new graph
element type: interfaces. It also allows links between interfaces
and entities. Update the docbook to reflect that.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Instead of using a text file, let's put it together with the
struct documentation for the Media Controller.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Both revision and group_id fields were never used and were always
initialized to zero. Remove them.
Suggested-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Due to the rename, the documentation became outdated.

Update it to reflect what's there at media.h.
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Cleanup the media controller entities description:
- remove MEDIA_ENT_T_DEVNODE and MEDIA_ENT_T_V4L2_SUBDEV entity
  types, as they don't mean anything;
- add MEDIA_ENT_T_UNKNOWN with a proper description;
- remove ALSA and FB entity types. Those should not be used, as
  the types are deprecated. We'll soon be adidng ALSA, but with
  a different entity namespace;
- improve the description of some entities.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Now that interfaces and entities are distinct, it makes no sense
of keeping something named as MEDIA_ENT_T_DEVNODE_DVB_foo.

Made via this script:
	for i in $(git grep -l MEDIA_ENT_T|grep -v uapi/linux/media.h); do sed s,MEDIA_ENT_T_DEVNODE_DVB_,MEDIA_ENT_T_DVB_, <$i >a && mv a $i; done
	for i in $(git grep -l MEDIA_ENT_T|grep -v uapi/linux/media.h); do sed s,MEDIA_ENT_T_DVB_DVR,MEDIA_ENT_T_DVB_TSOUT, <$i >a && mv a $i; done
	for i in $(git grep -l MEDIA_ENT_T|grep -v uapi/linux/media.h); do sed s,MEDIA_ENT_T_DVB_FE,MEDIA_ENT_T_DVB_DEMOD, <$i >a && mv a $i; done
	for i in $(git grep -l MEDIA_ENT_T|grep -v uapi/linux/media.h); do sed s,MEDIA_ENT_T_DVB_NET,MEDIA_ENT_T_DVB_DEMOD_NET_DECAP, <$i >a && mv a $i; done
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Now that interfaces and entities are distinct, it makes no sense
of keeping something named as MEDIA_ENT_T_DEVNODE.

This change was done with this script:

	for i in $(git grep -l MEDIA_ENT_T|grep -v uapi/linux/media.h); do sed s,MEDIA_ENT_T_DEVNODE_V4L,MEDIA_ENT_T_V4L2_VIDEO, <$i >a && mv a $i; done
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Another pile of vfuncs from the old gpu.tmpl xml documentation that
I've forgotten to delete. I spotted a few more things to
clarify/extend in the new kerneldoc while going through this once
more.

v2: Spelling fixes (Thierry).

v3: More spelling fixes and use Thierry's proposal to clarify why
drivers need to validate modes both in ->mode_fixup and ->mode_valid.

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Thierry Reding <treding@nvidia.com>
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Fix indentation of vga_switcheroo sections in gpu.tmpl.

Change section type of API documentation from "chapter" to "sect1"
so that the individual functions no longer clutter up the ToC.
Group together under a new "API" chapter.

Fix wording "heretoforth" -> "henceforth".
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add an overview and documentation for the VBT/BDB header structures.
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/3d826d4600688ca3518713776ab5bd8a8fc9f20f.1450702954.git.jani.nikula@intel.com

The MTD device is now directly embedded in the nand_chip struct. Update the
mtdnand documentation to mention this aspect and fix the different
examples.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

During the Seoul media workshop we decided to relax the VIDIOC_CREATE_BUFS
specification so it would no longer require drivers to validate the format
field since almost no driver did that anyway.

Instead drivers use the buffer size(s) based on the format type and the
corresponding format fields and will ignore any other fields. If the size
cannot be used an error is returned, otherwise the size is used as-is.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

I missed a few paragraphs in the docbook that need to be pulled into
the fbdev vfunc docs.

v2: Spelling fixes from Thierry.

Cc: Thierry Reding <treding@nvidia.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449564561-3896-3-git-send-email-daniel.vetter@ffwll.chReviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

DRM Docbook is now Markdown ready. This means its doc is able to
use markdown text on it.

* Documentation/DocBook/drm.tmpl: Contains a table duplicated from
  drivers/gpu/drm/i915/i915_reg.h. This is not needed anymore

* drivers/gpu/drm/drm_modeset_lock.c: had a code example that used
  to look pretty bad on html. Fixed by using proper code markup.

* drivers/gpu/drm/drm_prime.c: Remove spaces between lines to make
  a proper markup list.

* drivers/gpu/drm/i915/i915_reg.h: Altought pandoc supports tables,
  it doesn't support table cell spanning. But we can use fixed-width
  for those special cases.

* include/drm/drm_vma_manager.h: Another code example that should be
  proper indented with four spaces.

v2 (Daniel): Adjust name to gpu.xml due to rename.

v3 (Daniel):
Split out the actual enabling in the Makefile - this way we can merge
the conversion, while just keeping the enabling in a drm-private tree.

Signed-off-by: Danilo Cesar Lemes de Paula <danilo.cesar@collabora.co.uk> (v1)
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Stephan Mueller <smueller@chronox.de>
Cc: Michal Marek <mmarek@suse.cz>
Cc: linux-kernel@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>
Cc: dri-devel <dri-devel@lists.freedesktop.org>
Acked-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448471279-19748-2-git-send-email-daniel.vetter@ffwll.ch

Every time I type or review docs this seems a bit different. Try to
document the common style so we can try to unify at least new docs.

v2: Spelling fixes from Pierre, Laurent and Jani.

v3: More spelling fixes from Lukas.

Cc: Pierre Moreau <pierre.morrow@free.fr>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Lukas Wunner <lukas@wunner.de>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449564561-3896-1-git-send-email-daniel.vetter@ffwll.ch

This was in the documentation for modeset helper hooks, where it is a
bit misplaced.

v2: Reindent the drm_mode_status enum, inspired by Ville.

v3: Suggestions from Ville and Thierry.

v4: Small fixup that 0day spotted.

v5: Slight change to avoid accidental headings in kerneldoc output.

Cc: ville.syrjala@linux.intel.com
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449218769-16577-27-git-send-email-daniel.vetter@ffwll.ch
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v3)
Reviewed-by: Thierry Reding <treding@nvidia.com> (v3)

And merge any docbook we have into the kerneldoc comments.

Since it's a legacy entry point with only two implementation (one each
in atomic and legacy crtc helpers) I've made the documentation for
set_config fairly sparse - no one should ever need to look at this
again, all the ABI we have is baked into code.

For ->page_flip otoh I kept all the extensive docs from the docbook
and even extended it where it was lacking: Currently we have a pile of
legacy page_flip implemantations, and even for atomic drivers there's
not yet a standard implementation in the helpers. Which means every
driver needs to implement this itself, and precise specs are really
valuable.

Otherwise there's just cursor, which really just boils down to "use at
least universal planes". And gamma tables (where we have a bit a mess
with the fbdev helper gamma hooks).

v2: Spelling fixes (Eric).

v3: Suggestions from Thierry.

Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449218769-16577-20-git-send-email-daniel.vetter@ffwll.ch

Yes these are internal functions and not exported and we generally
don't document them. But for symmetry with the _set_property functions
(which are exported for the atomic helpers) I'd like to document them.
Upcoming vtable kerneldoc will reference both the set and get_property
functions.

v2: Suggestions from Thierry.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449218769-16577-17-git-send-email-daniel.vetter@ffwll.ch

- Merge the docbook into the kerneldoc comments.

- Spec in detail the precise semantics of the callbacks.

- For consistency in wording and easier review roll out kerneldoc also
  for crtc, encoder and connector for the standard hooks they share
  with planes.

v2: Suggestions from Thierry.
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449218769-16577-8-git-send-email-daniel.vetter@ffwll.chReviewed-by: NThierry Reding <treding@nvidia.com>