Each DRM file-context caches the EUID of the process that opened the file.
It is used exclusively for debugging purposes in /proc/dri/ and friends.

Note, however, that we can already fetch the EUID from
priv->pid->task->creds. The pointer-chasing will not hurt us, since it is
only about debugging, anyway.

Since we already are in an rcu-read-side, we can use __task_cred() rather
than task_cred_xxx().
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20160901124837.680-2-dh.herrmann@gmail.com

Similar to struct drm_update_draw, struct drm_mode_fb_cmd2 has an
unaligned 64 bit field (modifier). This get packed differently between
32 bit and 64 bit modes on architectures that can handle unaligned 64
bit access (X86 and IA64).  Other architectures pack the structs the
same and don't need the compat wrapper. Use the same condition for
drm_mode_fb_cmd2 as we use for drm_update_draw.

Note that only the modifier will be packed differently between compat
and non-compat versions.
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NKristian H. Kristensen <hoegsberg@chromium.org>
[seanpaul added not at bottom of commit msg re: modifier]
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1473801645-116011-1-git-send-email-hoegsberg@chromium.org

Remove unneeded variables and assignments.
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1473863952-7658-5-git-send-email-yamada.masahiro@socionext.com

Remove unneeded variables and assignments.
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
[seanpaul added analogix prefix to subject]
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1473863952-7658-4-git-send-email-yamada.masahiro@socionext.com

Remove unneeded variables and assignments.
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1473863952-7658-3-git-send-email-yamada.masahiro@socionext.com

Remove unneeded variables and assignments.
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1473863952-7658-2-git-send-email-yamada.masahiro@socionext.com

If userspace is running an synchronously atomic commit and interrupts the
atomic operation during fence_wait() it will hang until the timer expires,
so here we change the wait to be interruptible so it stop immediately when
userspace wants to quit.

Also adds the necessary error checking for fence_wait().

v2: Comment by Daniel Vetter
	- Add error checking for fence_wait()

v3: Rebase on top of new atomic noblocking support

v4: Comment by Maarten Lankhorst
	- remove 'swapped' bitfield as it was duplicating information

v5: Comments by Maarten Lankhorst
	- assign plane->state to plane_state if !intr
	- squash previous patch into this one

v6: Comment by Sean Paul
	- rename intr to pre_swap
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
[seanpaul fixed a couple checkpatch warnings and moved the preswap comment]
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1473707291-14781-1-git-send-email-gustavo@padovan.org

Property lifetimes are equal to the device lifetime, so the separate
drm_property_find is not needed. The pointer can be retrieved from
the properties member, which saves us some locking and a extra lookup.
The lifetime for properties is until the device is destroyed, which
happens late in the device unload path.

kms_atomic is also testing for invalid properties which returns -ENOENT,
to be consistent return -ENOENT for valid properties that don't appear
on the object property list.

Changes since v1:
- Return -ENOENT for invalid properties to make kms_atomic pass.
- Change commit message slightly to take this into account.

Testcase: kms_atomic
Testcase: kms_properties
Fixes: 4e9951d9 ("drm/atomic: Reject properties not part of the object.")
Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/599c7fa8-b6fd-a42b-c619-a9e4a9c5c244@linux.intel.com

The Renesas Wheat board has 2 ADV7513 chips on the same I2C bus, however
the ADV751x driver only supports 1 chip as it tries to assign the packet/
EDID/CEC memory I2C devices to the fixed I2C addresses. Assign these I2C
addresses at the fixed offsets (derived from the programming guide) from
the main register map address instead.
Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1580212.O1LYdJFM97@wasted.cogentembedded.com

We get 5 warnings when building kernel with W=1:
drivers/gpu/drm/sun4i/sun4i_framebuffer.c:33:23: warning: no previous prototype for 'sun4i_framebuffer_init' [-Wmissing-prototypes]
drivers/gpu/drm/sun4i/sun4i_framebuffer.c:47:6: warning: no previous prototype for 'sun4i_framebuffer_free' [-Wmissing-prototypes]
drivers/gpu/drm/sun4i/sun4i_rgb.c:202:5: warning: no previous prototype for 'sun4i_rgb_init' [-Wmissing-prototypes]
drivers/gpu/drm/sun4i/sun4i_dotclock.c:151:5: warning: no previous prototype for 'sun4i_dclk_create' [-Wmissing-prototypes]
drivers/gpu/drm/sun4i/sun4i_dotclock.c:186:5: warning: no previous prototype for 'sun4i_dclk_free' [-Wmissing-prototypes]

In fact, these functions are declared in
drivers/gpu/drm/sun4i/sun4i_framebuffer.h,
drivers/gpu/drm/sun4i/sun4i_rgb.h,
drivers/gpu/drm/sun4i/sun4i_dotclock.h,
so this patch adds missing header dependencies.
Signed-off-by: NBaoyou Xie <baoyou.xie@linaro.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>

This fixes the error path for platforms that don't define the new
page_flip_target() hook.

Fixes: c229bfbb ("drm: Add page_flip_target CRTC hook v2")
Testcase: igt/kms_flip/basic-flip-vs-dpms
CC: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473269025-16148-1-git-send-email-imre.deak@intel.com

The A33 pipeline also has a component called DRC. Even though its exact
features and programming model is not known (or documented), it needs to
be clocked for the pipeline to carry the video signal all the way.

Add a minimal driver for it that just claim the needed resources for the
pipeline to operate properly.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: NChen-Yu Tsai <wens@csie.org>
Acked-by: NPeter Korsgaard <peter@korsgaard.com>

The A33 has an block called SAT that is part of the backend that needs to
be clocked and out of reset to be able for the backend to operate properly.

Extend the binding to have the SAT resources listed, and claim them when
the backend probes.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: NChen-Yu Tsai <wens@csie.org>

The A33 has a significantly different pipeline, with components that differ
too.

Make sure we had compatible for them.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: NChen-Yu Tsai <wens@csie.org>

Some Allwinner SoCs, such as the A33, have a variation of the TCON that
doesn't have a second channel (or it is not wired to anything).

Make sure we can handle that case.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: NChen-Yu Tsai <wens@csie.org>

Register ASoC HDMI codec for audio functionality and adds device tree
binding for audio configuration.

With the registered HDMI codec the tda998x node can be used like a
regular codec node in ASoC card configurations. HDMI audio info-frame
and audio stream header is generated by the ASoC HDMI codec. The codec
also applies constraints for available sample-rates based on Edid Like
Data from the display. The device tree binding document has been
updated [1].

Part of this patch has been inspired by Jean Francoise's "drm/i2c: tda998x:
Add support of a DT graph of ports"-patch [2]. There may still be some
identical lines left from the original patch and some of the ideas
have come from there.

[1] Documentation/devicetree/bindings/display/bridge/tda998x.txt
[2] http://mailman.alsa-project.org/pipermail/alsa-devel/2015-July/095255.htmlSigned-off-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Define struct tda998x_audio_params in include/drm/i2c/tda998x.h and
use it in pdata and for tda998x_configure_audio() parameters. Also
updates tda998x_write_aif() to take struct hdmi_audio_infoframe *
directly as a parameter.
Signed-off-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

This reverts commit 77953bd1.

This causes a kernel panic when trying to assign a blob to a property,
and has obviously never been tested.

Fixes: 77953bd1 ("drm: Unify handling of blob and object properties")
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Tested-by: NLiu Ying <gnuiyl@gmail.com>
Acked-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/8c0d3482-1bb5-6a15-b105-6bda2b31b5dc@linux.intel.com

The usb_driver suspend and resume function pointers must be populated
to prevent forced unbinding of USB interface driver. See usb/core/driver.c:
unbind_no_pm_drivers_interfaces().

Restore mode and damage the entire frame buffer upon resume.

TEST=suspend and resume with the same UDL device connected
TEST=suspend with UDL, unplug UDL and resume
TEST=suspend with UDL, unplug and connect another UDL device then resume
Signed-off-by: NHaixia Shi <hshi@chromium.org>
Reviewed-by: NStéphane Marchesin <marcheu@chromium.org>
[seanpaul fixed checkpatch warnings and gave marcheu his é back]
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1472593821-38429-2-git-send-email-hshi@chromium.org

Use 1UL for unsigned long, or we'll meet a overflow issue with UBSAN.

[   15.589489] UBSAN: Undefined behaviour in drivers/gpu/drm/drm_hashtab.c:145:35
[   15.589500] signed integer overflow:
[   15.589999] -2147483648 - 1 cannot be represented in type 'int'
[   15.590434] CPU: 2 PID: 294 Comm: plymouthd Not tainted 3.10.0-327.28.3.el7.x86_64 #1
[   15.590653] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 01/07/2011
[   15.591001]  1ffff1000670fe83 000000000d6b385e ffff88003387f3e0 ffffffff81ee3140
[   15.591028]  ffff88003387f3f8 ffffffff81ee31fd ffffffffa032f460 ffff88003387f560
[   15.591044]  ffffffff81ee46e2 0000002d00000009 0000000000000001 0000000041b58ab3
[   15.591059] Call Trace:
[   15.591078]  [<ffffffff81ee3140>] dump_stack+0x1e/0x20
[   15.591093]  [<ffffffff81ee31fd>] ubsan_epilogue+0x12/0x55
[   15.591109]  [<ffffffff81ee46e2>] handle_overflow+0x1ba/0x215
[   15.591126]  [<ffffffff81ee4528>] ? __ubsan_handle_negate_overflow+0x162/0x162
[   15.591146]  [<ffffffff8103416c>] ? print_context_stack+0x9c/0x160
[   15.591163]  [<ffffffff81031df2>] ? dump_trace+0x252/0x750
[   15.591181]  [<ffffffff81739023>] ? __list_add+0x93/0x160
[   15.591197]  [<ffffffff81ee4798>] __ubsan_handle_sub_overflow+0x2a/0x31
[   15.591261]  [<ffffffffa0282140>] drm_ht_just_insert_please+0x1e0/0x200 [drm]
[   15.591290]  [<ffffffffa0528c7a>] ttm_base_object_init+0x10a/0x270 [ttm]
[   15.591316]  [<ffffffffa052a34c>] ttm_vt_lock+0x28c/0x3a0 [ttm]
[   15.591343]  [<ffffffffa052a0c0>] ? ttm_write_lock+0x180/0x180 [ttm]
[   15.591362]  [<ffffffff81419526>] ? kasan_unpoison_shadow+0x36/0x50
[   15.591379]  [<ffffffff81419526>] ? kasan_unpoison_shadow+0x36/0x50
[   15.591396]  [<ffffffff81419526>] ? kasan_unpoison_shadow+0x36/0x50
[   15.591413]  [<ffffffff81419526>] ? kasan_unpoison_shadow+0x36/0x50
[   15.591442]  [<ffffffffa061cbe1>] vmw_master_set+0x121/0x470 [vmwgfx]
[   15.591459]  [<ffffffff811773a5>] ? __init_waitqueue_head+0x45/0x70
[   15.591487]  [<ffffffffa061cac0>] ? vmw_master_drop+0x310/0x310 [vmwgfx]
[   15.591535]  [<ffffffffa026946a>] drm_open+0x92a/0xc00 [drm]
[   15.591563]  [<ffffffffa0619ff0>] ? vmw_driver_open+0x170/0x170 [vmwgfx]
[   15.591610]  [<ffffffffa0268b40>] ? drm_poll+0xe0/0xe0 [drm]
[   15.591661]  [<ffffffffa02797b4>] drm_stub_open+0x224/0x330 [drm]
[   15.591711]  [<ffffffffa0279590>] ? drm_minor_acquire+0x240/0x240 [drm]
[   15.591727]  [<ffffffff8145fa8a>] chrdev_open+0x1fa/0x3f0
[   15.591742]  [<ffffffff8145f890>] ? cdev_put+0x50/0x50
[   15.591761]  [<ffffffff814f6dc3>] ? __fsnotify_parent+0x53/0x210
[   15.591778]  [<ffffffff8144fde1>] do_dentry_open+0x351/0x670
[   15.591792]  [<ffffffff8145f890>] ? cdev_put+0x50/0x50
[   15.591807]  [<ffffffff814503c2>] vfs_open+0xa2/0x170
[   15.591824]  [<ffffffff8147b5df>] do_last+0xccf/0x2c80
[   15.591842]  [<ffffffff8147a910>] ? filename_create+0x320/0x320
[   15.591858]  [<ffffffff81472549>] ? path_init+0x1b9/0xa90
[   15.591875]  [<ffffffff81472390>] ? mountpoint_last+0x9a0/0x9a0
[   15.591894]  [<ffffffff815f9ccf>] ? selinux_file_alloc_security+0xcf/0x130
[   15.591911]  [<ffffffff8147d777>] path_openat+0x1e7/0xcc0
[   15.591927]  [<ffffffff81031df2>] ? dump_trace+0x252/0x750
[   15.591943]  [<ffffffff8147d590>] ? do_last+0x2c80/0x2c80
[   15.591959]  [<ffffffff81739023>] ? __list_add+0x93/0x160
[   15.591974]  [<ffffffff8104b48d>] ? save_stack_trace+0x7d/0xb0
[   15.591989]  [<ffffffff81480824>] do_filp_open+0xa4/0x160
[   15.592004]  [<ffffffff81480780>] ? user_path_mountpoint_at+0x50/0x50
[   15.592022]  [<ffffffff8149d755>] ? __alloc_fd+0x175/0x300
[   15.592039]  [<ffffffff81453127>] do_sys_open+0x1b7/0x3f0
[   15.592054]  [<ffffffff81452f70>] ? filp_open+0x80/0x80
[   15.592070]  [<ffffffff81453392>] SyS_open+0x32/0x40
[   15.592088]  [<ffffffff81f08989>] system_call_fastpath+0x16/0x1b
Signed-off-by: NXie XiuQi <xiexiuqi@huawei.com>
[seanpaul tweaked subject to remove "gpu/"]
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1473152138-25335-1-git-send-email-xiexiuqi@huawei.com

The legacy setprop ioctl doesn't attempt to set properties
that are not enumerated on the object. The atomic ioctl does,
fix this by validating first.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1473062773-5045-1-git-send-email-maarten.lankhorst@linux.intel.com

Choose console BPP that supports RGB and remove the old fbdev bpp
selection code. LCDC on AM335x has red and blue wires switched between
24 bit and 16 bit colors. If 24 format is wired for RGB colors, the 16
bit format is wired for BGR. drm_fbdev_cma_init() does not currently
like anything else but RGB formats, so we must choose such bytes per
pixel value that supports RGB.
Signed-off-by: NJyri Sarha <jsarha@ti.com>
Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Add "blue-and-red-wiring"-device tree property and update devicetree
binding document.

The red and blue components are reversed between 24 and 16 bit modes
on am335x LCDC output pins. To get 24 RGB format the red and blue
wires has to be crossed and this in turn causes 16 colors output to be
in BGR format. With straight wiring the 16 color is RGB and 24 bit is
BGR.

The new property describes whether the red and blue wires are crossed
or not. If the property is not present or its value is not recognized
the legacy mode is assumed. The legacy configuration supports RGB565,
RGB888 and XRGB8888 formats. However, depending on wiring, the red and
blue colors are swapped in either 16 or 24-bit color modes.

For more details see section 3.1.1 in AM335x Silicon Errata:
http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=sprz360Signed-off-by: NJyri Sarha <jsarha@ti.com>
Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Write DMA base and ceiling address with a single instruction, if
available. This should make it more unlikely that LCDC would fetch the
DMA addresses in the middle of an update. Having bad combination of
addresses in dma base and ceiling (e.g base > ceiling) can cause
unpredictaple behavior in LCDC.
Signed-off-by: NJyri Sarha <jsarha@ti.com>
Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

drm_helper_disable_unused_functions() should not be called by atomic
drivers.
Signed-off-by: NJyri Sarha <jsarha@ti.com>
Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

This got accidentally dropped in the fixed commit and is required for
the driver to properly work on the rev1 IP, such as found on the LCDK.

Fixes: 2b2080d7 ("drm/tilcdc: Get rid of complex ping-pong mechanism")
Signed-off-by: NKarl Beldan <kbeldan@baylibre.com>
Signed-off-by: NJyri Sarha <jsarha@ti.com>

The LCDC seems to expect its framebuffer ceiling address pointer to be
an inclusive bound.  The IP rev2 seems to cope with that but rev1 (as
found on the LCDK) don't.
Also note that this is what the framebuffer code does in da8xx-fb.c.

Since, as the TRM puts it, "The 2 LSBs are hardwired to 00b", the
dma_addr_t can be decremented without cast.
I tested it with a v2 (AM335x, rev  0x4F201000) and an LCDK (v1).
Signed-off-by: NKarl Beldan <kbeldan@baylibre.com>
Signed-off-by: NJyri Sarha <jsarha@ti.com>

In function tilcdc_get_external_components the check for
the remote port parent is not correct. We need a '||' instead of
an '&&'.
Signed-off-by: NTeresa Remmet <t.remmet@phytec.de>
Signed-off-by: NJyri Sarha <jsarha@ti.com>

The KMS helpers (drm_atomic_helper_check_modeset/mode_fixup) pass
encoder->bridge directly to drm_bridge_mode_fixup, which expects a
valid pointer, or NULL (in which case it just returns).

Clear encoder->bridge if a bridge is not found, instead of keeping
the ERR_PTR value.

Since other drm_bridge functions also follow this pattern of checking
for a non-NULL pointer, we can drop the ifs around the calls and just
pass the pointer directly.

Fixes: 894f5a9f ("drm/sun4i: Add bridge support")
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>

This reverts commit d10571fc.

This isn't how we get to do this unfortunately.
Signed-off-by: NDave Airlie <airlied@redhat.com>

drm_kms_helper_poll_enable_locked() should check if we have delayed event
pending and if we have, schedule the work to run without delay.

Currently the output_poll_work is only scheduled if any of the connectors
have DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT with
DRM_OUTPUT_POLL_PERIOD delay. It does not matter if we have delayed event
already registered to be handled. The detection will be delayd by
DRM_OUTPUT_POLL_PERIOD in any case.
Furthermore if none of the connectors are marked as POLL_CONNECT or
POLL_DISCONNECT because all connectors are either POLL_HPD or they are
always connected: the output_poll_work will not run at all even if we
have delayed event marked.

When none of the connectors require polling, their initial status change
from unknown to connected/disconnected is not going to be handled until
the first kms application starts or if we have fb console enabled.

Note that in general the output poll work should be enabled already
when this happens, but at driver load usually the first probe happens
before the output polling is enabled. This patch fixes this case.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
[danvet: Note when exactly this is an issue, since the probe code
schedules the poll work itself already.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20160831110905.31289-1-peter.ujfalusi@ti.com

If the enable-gpios property of a simple panel in device tree is set,
the GPIO is not toggled on/off because of missing calls to
drm_panel_prepare and drm_panel_unprepare.
Signed-off-by: NJonathan Liu <net147@gmail.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>

Colorspace and scan information values were being written in wrong
offsets. This patch corrects this and writes the values at the
offsets specified in the databook.
Signed-off-by: NJose Abreu <joabreu@synopsys.com>
Acked-by: NRussell King <rmk+kernel@armlinux.org.uk>
Cc: Carlos Palminha <palminha@synopsys.com>
Cc: Archit Taneja <architt@codeaurora.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/96fd0f06b7ebc2ee5cb8239a99648f3107e24497.1471530573.git.joabreu@synopsys.com

- remove kerneldoc for drm-internal functions
- drm_property_replace_global_blob isn't actually atomic, and doesn't
  need to be. Update docs&comments to match
- document all the types and try to link things a bit better
- nits all over

v2: Appease checkpatch in the moved code (Archit)
Reviewed-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160829082757.17913-9-daniel.vetter@ffwll.ch

They work exactly the same now, after the refcounting unification a bit
ago. The only reason they're distinct is backwards compat with existing
userspace.

Cc: Daniel Stone <daniels@collabora.com>
Reviewed-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20160829082757.17913-8-daniel.vetter@ffwll.ch

This just contains the base property classes and all the code to
handle blobs. I think for any kind of standardized/shared properties
it's better to have separate files - this is fairly big already as-is.

v2: resurrect misplaced hunk (Daniel Stone)

Cc: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160829082757.17913-7-daniel.vetter@ffwll.ch

It's part of the drm fourcc handling code, mapping the old depth/bpp
values to new fourcc codes.

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160829082757.17913-6-daniel.vetter@ffwll.ch

I figured an overview section here is overkill, and better
to just document the 2 structures themselves well enough.

v2: Review from Archit:
- Appease checkpatch in moved code.
- Spelling fixes in the kerneldoc.
Reviewed-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20160829082757.17913-5-daniel.vetter@ffwll.ch

It's only used in drm_mode_object_get_properties, and we can compute
it there directly with a bit of code shuffling.
Reviewed-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20160829082757.17913-4-daniel.vetter@ffwll.ch

Just for the struct drm_mode_object base class. The header file was
already partially extracted to help untangle the include loops.

v2:
- Also move the generic get/set property ioctls. At first this seemed
  like a bad idea since it requires making drm_mode_crtc_set_obj_prop
  non-static. But eventually that will get split away too (like
  the connector version already is) for both crtc and planes. Hence I
  reconsidered.

- drm_mode_object.[hc] instead of drm_modeset.[hc], which requires
  renaming the drm_modeset.h header I already started building up.
  This is more consistent (matches the name of the main structure),
  and I want to be able to use drm_modeset.[hc] for the basic modeset
  init/cleanup functionality like drm_mode_config_init.
Reviewed-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160829082757.17913-3-daniel.vetter@ffwll.ch