The drm_fbdev_cma_init function always calls the
drm_helper_disable_unused_functions. Since it's part of the usual probe
process, all the drivers using that helper will end up having their encoder
and CRTC disable functions called at probe if their device has not been
reported as enabled.

This could be fixed by reading out from the registers the current state of
the device if it is enabled, but even that will not handle the case where
the device is actually disabled.

Moreover, the drivers using the atomic modesetting expect that their enable
and disable callback to be called when the device is already enabled or
disabled (respectively).

We can however fix this issue by moving the call to
drm_helper_disable_unused_functions out of drm_fbdev_cma_init and make the
drivers needing it (all the drivers calling drm_fbdev_cma_init and not
using the atomic modesetting) explicitly call it.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452785109-6172-14-git-send-email-maxime.ripard@free-electrons.comAcked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Use kobj_to_dev() instead of open-coding it.

Link: http://patchwork.freedesktop.org/patch/msgid/3fea991541fbfc4ffece2c174adeb02cb9436c90.1452696179.git.geliangtang@163.comSigned-off-by: NGeliang Tang <geliangtang@163.com>

Since

commit ac9b8236
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Fri Nov 27 18:55:26 2015 +0200

    drm/i915: Introduce a gmbus power domain

gmbus also needs the power domain infrastructure right from the start,
since as soon as we register the i2c controllers someone can use them.

v2: Adjust cleanup paths too (Chris).

v3: Rebase onto -nightly (totally bogus tree I had lying around) and
also move dpio init head (Ville).

v4: Ville instead suggested to move gmbus setup later in the sequence,
since it's only needed by the modeset code.

v5: Move even close to the actual user, right next to the comment that
states where we really need gmbus (and interrupts!).

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Meelis Roos <mroos@linux.ee>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Fixes: ac9b8236 ("drm/i915: Introduce a gmbus power domain")
Cc: stable@vger.kernel.org
References: http://www.spinics.net/lists/intel-gfx/msg83075.htmlSigned-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452682528-19437-1-git-send-email-daniel.vetter@ffwll.chSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

An encoder is associated with a connector by the DRM core as a result of
setting up a configuration. Drivers using the atomic or legacy helpers
should never set up this link, even if it is a static one.

While at it, try to catch this kind of error in the future by adding a
WARN_ON() in drm_mode_connector_attach_encoder(). Note that this doesn't
cover all the cases, since drivers could set this up after attaching.
Drivers that use the atomic helpers will get a warning later on, though,
so hopefully the two combined cover enough to help people avoid this in
the future.

Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: Mark yao <mark.yao@rock-chips.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1447694393-24700-1-git-send-email-thierry.reding@gmail.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>

We moved the module options from drm_drv.c to drm_irq.c in 18882995
('drm: Move vblank related module options into drm_irq.c').  Let's move
the MODULE_PARM_DESC()s as well so they're together.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160108110045.GF32195@mwandaSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add a dummy entry to CEA/HDMI mode tables so they can be indexed
directly using the VIC, avoiding a +1/-1 dance here and there. This adds
clarity to the error checking for various functions that return the VIC
on success and zero on failure; we can now explicitly check for 0
instead of just subtracting one from an unsigned type.

Also add drm_valid_cea_vic() and drm_valid_hdmi_vic() helpers for
checking valid VICs.

v2: add drm_valid_cea_vic and drm_valid_hdmi_vic helpers (Ville)
    use { } instead of { 0 } for initializing the dummy modes

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452252111-6439-1-git-send-email-jani.nikula@intel.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that connector_mask is reliable there's no need for this
function any more.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1451908400-25147-6-git-send-email-maarten.lankhorst@linux.intel.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Update connector_mask during readout, v2.

The connector_mask may be used any time during the non-atomic
.crtc_disable which is called before the full atomic state is
set up and needs to be accurate for that reason.

Changes since v1:
- Update connector_mask in readout_hw_state and add a comment.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/568D1C55.8010001@linux.intel.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

drm_gem_handle_delete() contains its own version of
drm_gem_object_release_handle(), so lets just call the release method
instead.
Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1451986951-3703-2-git-send-email-chris@chris-wilson.co.ukReviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Good practice dictates that we do not leak stale information to our
callers, and should avoid overwriting an outparam on an error path.
Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1451986951-3703-1-git-send-email-chris@chris-wilson.co.ukReviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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>

We want this for consistency with existing page_flip semantics.

Since this spurred quite a discussion on IRC also document why we
reject event generation when the pipe is off: It's not that it's hard
to implement, but userspace has a track recording which proves that it's
way too easy to accidentally abuse and cause havoc. We want to make
sure userspace doesn't get away with that.

v2: Somehow thought we do reject events already, but that code only
existed in my imagination ... Also suggestions from Thierry.

Cc: Daniel Stone <daniels@collabora.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449564561-3896-4-git-send-email-daniel.vetter@ffwll.ch

It can be useful to iterate over connectors without grabbing
connection_mutex. It can also be used to see how many connectors
are on a crtc without iterating over the list.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1451908400-25147-4-git-send-email-maarten.lankhorst@linux.intel.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Changes since v1:
- Do not reset if state allocation fails.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Thierry Reding <treding@nvidia.com> #irc
Link: http://patchwork.freedesktop.org/patch/msgid/1451908400-25147-3-git-send-email-maarten.lankhorst@linux.intel.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is useful for drivers that subclass connector_state, like tegra.

Changes since v1:
- Docbook updates.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1451908400-25147-2-git-send-email-maarten.lankhorst@linux.intel.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The atomic helper sets connector_state->connector, which the i915
code didn't. This will become a problem when we start using it.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: NThierry Reding <treding@nvidia.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1451908400-25147-1-git-send-email-maarten.lankhorst@linux.intel.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Unlike the handle, the name table uses a sleeping mutex rather than a
spinlock. The allocation is in a normal context, and we can use the
simpler sleeping gfp_t, rather than have to take from the atomic
reserves.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1451902261-25380-3-git-send-email-chris@chris-wilson.co.ukSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We only need a single reference count for all handles (i.e. non-zero
obj->handle_count) and so can trim a few atomic operations by only
taking the reference on the first handle and dropping it after the last.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1451902261-25380-2-git-send-email-chris@chris-wilson.co.ukSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The current error path for failure when establishing a handle for a GEM
object is unbalance, e.g. we call object_close() without calling first
object_open(). Use the typical onion structure to only undo what has
been set up prior to the error.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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>

The drm_dp_mst_topology_cbs structures are never modified, so declare them
as const.

Done with the help of Coccinelle.
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Use to_pci_dev() instead of open-coding it.
Signed-off-by: NGeliang Tang <geliangtang@163.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

pan_display_atomic() calls drm_atomic_clean_old_fb() to sanitize the
legacy FB fields (plane->fb and plane->old_fb).  However it was building
the plane mask to pass to this function incorrectly (the bitwise OR was
using plane indices rather than plane masks).  The end result was that
sometimes the legacy pointers would become out of sync with the atomic
pointers.  If another operation tried to re-set the same FB onto the
plane, we might end up with the pointers back in sync, but improper
reference counts, which would eventually lead to system crashes when we
accessed a pointer to a prematurely-destroyed FB.

The cause here was a very subtle bug introduced in commit:

        commit 07d3bad6
        Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
        Date:   Wed Nov 11 11:29:11 2015 +0100

            drm/core: Fix old_fb handling in pan_display_atomic.

I found the crashes were most easily reproduced (on i915 at least) by
starting X and then VT switching to a VT that wasn't running a console
instance...the sequence of vt/fbcon entries that happen in that case
trigger a reference count mismatch and crash the system.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93313Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The following code pattern exists in some DRM drivers:

    ddev = drm_dev_alloc(&driver, parent_dev);
    drm_dev_set_unique(ddev, dev_name(parent_dev));

(Sometimes dev_name(ddev->dev) is used, which is the same.)

As suggested in
http://lists.freedesktop.org/archives/dri-devel/2015-December/096441.html,
the unique name of a new DRM device can be set as dev_name(parent_dev)
when parent_dev is not NULL (vgem is a special case).
Signed-off-by: NNicolas Iooss <nicolas.iooss_linux@m4x.org>
Acked-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

drm_dev_set_unique() uses a format string to define the unique name of a
device.  This feature is not used as currently all the calls to this
function either use "%s" as a format string or directly use
dev_name().

Even though this second kind of call does not introduce security
problems, because there cannot be "%" characters in dev_name() results,
gcc issues a warning when building with -Wformat-security flag
("warning: format string is not a string literal (potentially
insecure)").  This warning is useful to find real bugs like the one
fixed by commit 3958b792 ("configfs: fix kernel infoleak through
user-controlled format string").  False positives which do not bring
an extra value make the work of finding real bugs harder.

Therefore remove the format-string feature from drm_dev_set_unique().
Signed-off-by: NNicolas Iooss <nicolas.iooss_linux@m4x.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1449829228-4425-1-git-send-email-nicolas.iooss_linux@m4x.orgSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Moves a bunch of junk to .rodata from .data.

 drivers/gpu/drm/vmwgfx/vmwgfx.ko:
-.text                       132244
+.text                       132240
-.rodata                      18296
+.rodata                      18680
-.data                         5096
+.data                         4712
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178476-26284-28-git-send-email-boris.brezillon@free-electrons.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Moves a bunch of junk to .rodata from .data.

 drivers/gpu/drm/udl/udl.ko:
-.text                       11336
+.text                       11332
-.rodata                       560
+.rodata                       684
-.data                         696
+.data                         572
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178476-26284-27-git-send-email-boris.brezillon@free-electrons.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Moves a bunch of junk to .rodata from .data.

 drivers/gpu/drm/tegra/tegra-drm.ko:
-.rodata                     13672
+.rodata                     13684
-.data                        1108
+.data                        1096
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178476-26284-26-git-send-email-boris.brezillon@free-electrons.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Moves a bunch of junk to .rodata from .data.

 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.ko:
-.rodata                      772
+.rodata                      828
-.data                        148
+.data                         92

 drivers/gpu/drm/rockchip/rockchipdrm.ko:
-.rodata                      748
+.rodata                      760
-.data                        448
+.data                        436
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178476-26284-25-git-send-email-boris.brezillon@free-electrons.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Moves a bunch of junk to .rodata from .data.

 drivers/gpu/drm/nouveau/nouveau.ko:
-.rodata                      105688
+.rodata                      105792
-.data                        125724
+.data                        125620
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178476-26284-24-git-send-email-boris.brezillon@free-electrons.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Moves a bunch of junk to .rodata from .data.

 drivers/gpu/drm/mgag200/mgag200.ko:
-.text                       29244
+.text                       29232
-.rodata                       600
+.rodata                       668
-.data                         688
+.data                         620
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178476-26284-23-git-send-email-boris.brezillon@free-electrons.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Moves a bunch of junk to .rodata from .data.

 drivers/gpu/drm/imx/imxdrm.ko:
-.rodata                      624
+.rodata                      652
-.data                        372
+.data                        344

 drivers/gpu/drm/imx/imx-ipuv3-crtc.ko:
-.rodata                      224
+.rodata                      280
-.data                        184
+.data                        128

 drivers/gpu/drm/imx/imx-ldb.ko:
-.rodata                      660
+.rodata                      784
-.data                        240
+.data                        116

 drivers/gpu/drm/imx/imx-tve.ko:
-.rodata                      400
+.rodata                      524
-.data                        416
+.data                        292

 drivers/gpu/drm/imx/parallel-display.ko:
-.rodata                      400
+.rodata                      524
-.data                        216
+.data                         92
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178476-26284-22-git-send-email-boris.brezillon@free-electrons.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Moves a bunch of junk to .rodata from .data.

 drivers/gpu/drm/i2c/sil164.ko:
-.text                       1660
+.text                       1656
-.rodata                       56
+.rodata                      104
-.data                        212
+.data                        164
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178476-26284-21-git-send-email-boris.brezillon@free-electrons.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Moves a bunch of junk to .rodata from .data.

 drivers/gpu/drm/i2c/adv7511.ko:
-.rodata                     1368
+.rodata                     1416
-.data                        164
+.data                        116
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178476-26284-20-git-send-email-boris.brezillon@free-electrons.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Moves a bunch of junk to .rodata from .data.

 drivers/gpu/drm/exynos/exynosdrm.ko:
-.text                       125792
+.text                       125788
-.rodata                      10972
+.rodata                      11748
-.data                         6720
+.data                         5944
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178476-26284-19-git-send-email-boris.brezillon@free-electrons.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Moves a bunch of junk to .rodata from .data.

 drivers/gpu/drm/cirrus/cirrus.ko:
-.text                       10104
+.text                       10092
-.rodata                       528
+.rodata                       596
-.data                         608
+.data                         540
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178476-26284-18-git-send-email-boris.brezillon@free-electrons.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Moves a bunch of junk to .rodata from .data.

 drivers/gpu/drm/i2c/ch7006.ko:
-.text                        5752
+.text                        5760
-.rodata                      6608
+.rodata                      6656
-.data                         216
+.data                         168
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178476-26284-17-git-send-email-boris.brezillon@free-electrons.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Moves a bunch of junk to .rodata from .data.

 drivers/gpu/drm/bridge/nxp-ptn3460.ko:
-.rodata                      440
+.rodata                      536
-.data                        208
+.data                        112
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178476-26284-16-git-send-email-boris.brezillon@free-electrons.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Moves a bunch of junk to .rodata from .data.

 drivers/gpu/drm/bridge/dw_hdmi.ko:
-.rodata                      120
+.rodata                      216
-.data                         96
+.data                          0
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178476-26284-15-git-send-email-boris.brezillon@free-electrons.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>