Prep work for next patch.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Signed-off-by: NRob Clark <robdclark@gmail.com>

We'll want to be able to pass in flags, such as asking for explicit
fencing, and possibly other things down the road.  Fortunately we
don't need a full 32b for the pipe-id.  So use the upper 16 bits
for flags (which could be extended or reduced later if needed, so
start adding flags from the high bits).

Since anything with the upper bits set would not be a valid pipe-id,
an old userspace would not set any of the upper bits, and an old
kernel would reject it as an invalid pipe-id.
Signed-off-by: NRob Clark <robdclark@gmail.com>

0 isn't a valid rotation property value, so let's set the initial value
of the property to DRM_ROTATE_0 instead.

In the same vein, we must always have at leat one angle as part of set
of supported rotation bits, so let's include DRM_ROTATE_0 in there.

Cc: Rob Clark <robdclark@gmail.com>
Cc: Jilai Wang <jilaiw@codeaurora.org>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The core will do this for us now.
Signed-off-by: NWolfram Sang <wsa-dev@sang-engineering.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>

We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/msm/mdp/mdp4/mdp4_lcdc_encoder.c:96:23: warning: no previous prototype for 'get_connector' [-Wmissing-prototypes]
drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c:84:5: warning: no previous prototype for 'mdp4_plane_set_property' [-Wmissing-prototypes]

In fact, these functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
So this patch marks these functions with 'static'.
Signed-off-by: NBaoyou Xie <baoyou.xie@linaro.org>
Reviewed-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
need to handle such conversion in the caller. The only challenge are
those callers that wish to differentiate the error code between the
nonblocking busy check and potentially blocking wait.

v2: 9 is only 0 in German.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Make the following changes in the HDMI gpio bindings:

- Use "-gpios" as the suffix for all the gpio names
- Move all the gpios to optional, since there are platforms that use none
  of them.
- The HPD gpio is a standard one, remove the "qcom,hdmi-tx-" prefix from
  it.
- Remove the HDMI DDC clk/data gpios. They are just leftovers of an old
  way to configure pinctrl properties.
- Add a missing lpm gpio used on some platforms.

Make the necessary changes in the driver to incorporate these changes.

There hasn't been any upstream DT that uses the HDMI bindings, so it's
okay to change and move around these properties.

Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The LVDS port is the first in the list of the output ports in MDP4.
The driver assumed that if the port and its corresponding endpoint
is defined, then there should be a panel node too. This isn't
necessary since boards may not really use a LVDS panel. Don't fail
if there isn't a panel node available.

While we're at it, use of_graph_get_endpoint_by_regs instead of
of_graph_get_next_endpoint to make it more explicit that the LVDS
output is at port 0.
Tested-by: NJohn Stultz <john.stultz@linaro.org>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.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