DRM core uses reference/unreference suffixes for refcounting
functions, but kernel uses get/put (e.g. kref_get/put()).
Replace reference/unreference with get/put for consistency
and also it's shorter.

The following cocci script was used to generate the patch:

@@
expression e;
@@

(
-drm_gem_object_reference(e);
+drm_gem_object_get(e);
|
-drm_gem_object_unreference(e);
+drm_gem_object_put(e);
|
-drm_gem_object_unreference_unlocked(e);
+drm_gem_object_put_unlocked(e);
)
Signed-off-by: NAastha Gupta <aastha.gupta4104@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1508776686-29664-1-git-send-email-aastha.gupta4104@gmail.com

Remove two trailing spaces.
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171026165731.5793-4-noralf@tronnes.org

DPCD 600h - SET_POWER & SET_DP_PWR_VOLTAGE defines power state

101 = Set Main-Link for local Sink device and all downstream Sink
devices to D3 (power-down mode), keep AUX block fully powered, ready to
reply within a Response Timeout period of 300us.

This state is useful in a MST dock + MST monitor configuration that
doesn't wake up from D3 state.

v2: Use spaces instead of tabs (Jani)
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1502475008-2035-1-git-send-email-dhinakaran.pandiyan@intel.com

Replace use of list_for_each with list_for_each_entry to simplify the
code and remove variables that are used only in list_for_each.
Done with following coccinelle patch:

@r@
identifier fn,i,f,p;
expression e;
iterator name list_for_each, list_for_each_entry;
type T;
@@

fn(...) {
++ T *i;
  <+...
- list_for_each(p,e)
+ list_for_each_entry(i,e,f)
  {
              ...
-   T *i = list_entry(p,T,f);
                  ...
   }
   ...+>
}

@@
identifier r.fn,r.p;
@@

fn(...) {
  ...
- struct list_head *p;
  ... when != p
}

@@
identifier r.fn,r.i,r.f;
expression r.e;
statement S;
@@

fn(...) {
  <...
  list_for_each_entry(i,e,f)
- {
  S
- }
  ...>
}

@s@
identifier i,f,p;
expression e;
type T;
@@

- list_for_each(p,e)
+ list_for_each_entry(i,e,f)
  {
    ... when != T *i;
-   i = list_entry(p,T,f);
    ...
  }

@@
identifier s.p;
@@

- struct list_head *p;
  ... when != p

@@
identifier s.i,s.f;
expression s.e;
statement S;
@@

  list_for_each_entry(i,e,f)
- {
  S
- }
Signed-off-by: NHarsha Sharma <harshasharmaiitr@gmail.com>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20171014202823.29230-1-harshasharmaiitr@gmail.com

I didn't catch this before applying, just right after (of course).

Fixes:
../drivers/gpu/drm/rockchip/analogix_dp-rockchip.c: In function
‘rockchip_dp_of_probe’:
../drivers/gpu/drm/rockchip/analogix_dp-rockchip.c:276:6: warning:
unused variable ‘ret’ [-Wunused-variable]
  int ret;
        ^~~

Fixes: 102712a3 ("drm/rockchip: analogix_dp: Remove unnecessary init
code")
Cc: Jeffy Chen <jeffy.chen@rock-chips.com>
Cc: Mark Yao <mark.yao@rock-chips.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-rockchip@lists.infradead.org
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20171020172557.54900-1-seanpaul@chromium.org

Remove old comment style used by doxygen.
And remove comment left from commit 99cdb35e ("drm/doc: move printf
helpers out of drmP.h") after refactoring drmP.h.
Signed-off-by: NHaneen Mohammed <hamohammed.sa@gmail.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/4d89eef3945dbffd402d2ecdc130108b0565c158.1508297716.git.hamohammed.sa@gmail.com

This patch extract DRM_* debug macros from drmP.h to drm_print.h and
move printing related functions used by these macros from drm_drv.[hc]
to drm_print.[hc].
Signed-off-by: NHaneen Mohammed <hamohammed.sa@gmail.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/4020bc7c5ffad2af516919f78bb837c7f366b82b.1508297716.git.hamohammed.sa@gmail.com

Remove unnecessary init code, since we would do it in the power_on()
callback.

Also move of parse code to probe().

Fixes: 9e32e16e ("drm: rockchip: dp: add rockchip platform dp driver")
Signed-off-by: NJeffy Chen <jeffy.chen@rock-chips.com>
Acked-by: NMark Yao <mark.yao@rock-chips.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20171019034812.13768-3-jeffy.chen@rock-chips.com

VC4's DSI1 has a bug where the AXI connection is broken for 32-bit
writes from the CPU, so we use the DMA engine to DMA 32-bit values
into registers instead.  That sleeps, so we can't do it from the top
half.

As a solution, use an interrupt thread so that all our writes happen
when sleeping is is allowed.

v2: Use IRQF_ONESHOT (suggested by Boris)
v3: Style nitpicks.
Signed-off-by: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20171014001255.32005-1-eric@anholt.net
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com> (v2)

This ioctl will allow us to purge inactive userspace buffers when the
system is running out of contiguous memory.

For now, the purge logic is rather dumb in that it does not try to
release only the amount of BO needed to meet the last CMA alloc request
but instead purges all objects placed in the purgeable pool as soon as
we experience a CMA allocation failure.

Note that the in-kernel BO cache is always purged before the purgeable
cache because those objects are known to be unused while objects marked
as purgeable by a userspace application/library might have to be
restored when they are marked back as unpurgeable, which can be
expensive.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20171019125748.3152-1-boris.brezillon@free-electrons.com

Only exposes a single mode and not a complete display timing, as
the datasheet is rather vague about the minimum/maximum values.
Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171018172240.8772-1-l.stach@pengutronix.de

Signed-off-by: NFrank Binns <frank.binns@imgtec.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1508333423-5394-1-git-send-email-frank.binns@imgtec.com

The delays between video data and backlight enable and between backlight
disable and end of video data are given as >= 160 ms in the datasheet.
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Tested-by: NMarco Franchi <marco.franchi@nxp.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171011125958.23064-3-p.zabel@pengutronix.de

For LCD interface controllers that support configuring polarity of
pixel clock and data enable signal, specify bus flags in the panel
descriptor.
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Tested-by: NMarco Franchi <marco.franchi@nxp.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171011125958.23064-2-p.zabel@pengutronix.de

The vsync length should be 10 lines, as specified in the data sheet.
This gets the actual refresh rate closer to nominal 60 Hz given the
9 MHz pixel clock.
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Tested-by: NMarco Franchi <marco.franchi@nxp.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171011125958.23064-1-p.zabel@pengutronix.de

At least when they have vblank support they need to call this, or the
vblank core will happily call into their crtc->enable_vblank callback
even when the crtc is off. Which leads to a boom when the clocks are
off on most hardware (besides the inevitable confusion in the
book-keeping).

The consistency checks in drm_vblank.c will then make sure that
vblank_off/on calls are balanced, and if drivers forget to re-enable
it all the commits will stall, so I think we're covered.

It'd be nice to be able to place this check outside of commit helpers,
but tha's not really possible (due to nonblocking commits and all
that). Placing it into atomic helpers should at least cover most
drivers.

Also note that vblank support is still optional (for virtual drivers,
which tend to not have this), check for that.

v2: Fixup the handling for vblank_put (Rob).

Cc: Rob Clark <robdclark@gmail.com>
Tested-by: NRob Clark <robdclark@gmail.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171017152714.6849-1-daniel.vetter@ffwll.ch

Inspired by discussions with Keith and Ville.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Keith Packard <keithp@keithp.com>
Acked-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171017162918.8380-1-daniel.vetter@ffwll.ch

The default VGA device is normally set in vga_arbiter_add_pci_device() when
we call it for the first enabled device that can be accessed with the
legacy VGA resources ([mem 0xa0000-0xbffff], etc.)

That default device can be overridden by an EFI device that owns the boot
framebuffer.  As a fallback, we can also select a VGA device that can't be
accessed via legacy VGA resources, or a VGA device that isn't even enabled.

Factor out this EFI and fallback selection from vga_arb_device_init() into
a separate vga_arb_select_default_device() function.  This doesn't change
any behavior, but it untangles the "bridge control possible" checking and
messages from the default device selection.

Tested-by: Zhou Wang <wangzhou1@hisilicon.com>  # D05 Hisi Hip07, Hip08
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: NDaniel Axtens <dja@axtens.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171013034729.14630.30419.stgit@bhelgaas-glaptop.roam.corp.google.com

Daniel Axtens reported that on the HiSilicon D05 board, the VGA device is
behind a bridge that doesn't support PCI_BRIDGE_CTL_VGA, so the VGA arbiter
never selects it as the default, which means Xorg auto-detection doesn't
work.

VGA is a legacy PCI feature: a VGA device can respond to addresses, e.g.,
[mem 0xa0000-0xbffff], [io 0x3b0-0x3bb], [io 0x3c0-0x3df], etc., that are
not configurable by BARs.  Consequently, multiple VGA devices can conflict
with each other.  The VGA arbiter avoids conflicts by ensuring that those
legacy resources are only routed to one VGA device at a time.

The arbiter identifies the "default VGA" device, i.e., a legacy VGA device
that was used by boot firmware.  It selects the first device that:

  - is of PCI_CLASS_DISPLAY_VGA,
  - has both PCI_COMMAND_IO and PCI_COMMAND_MEMORY enabled, and
  - has PCI_BRIDGE_CTL_VGA set in all upstream bridges.

Some systems don't have such a device.  For example, if a host bridge
doesn't support I/O space, PCI_COMMAND_IO probably won't be enabled for any
devices below it.  Or, as on the HiSilicon D05, the VGA device may be
behind a bridge that doesn't support PCI_BRIDGE_CTL_VGA, so accesses to the
legacy VGA resources will never reach the device.

This patch extends the arbiter so that if it doesn't find a device that
meets all the above criteria, it selects the first device that:

  - is of PCI_CLASS_DISPLAY_VGA and
  - has PCI_COMMAND_IO or PCI_COMMAND_MEMORY enabled

If it doesn't find even that, it selects the first device that:

  - is of class PCI_CLASS_DISPLAY_VGA.

Such a device may not be able to use the legacy VGA resources, but most
drivers can operate the device without those.  Setting it as the default
device means its "boot_vga" sysfs file will contain "1", which Xorg (via
libpciaccess) uses to help select its default output device.

This fixes Xorg auto-detection on some arm64 systems (HiSilicon D05 in
particular; see the link below).

It also replaces the powerpc fixup_vga() quirk, albeit with slightly
different semantics: the quirk selected the first VGA device we found, and
overrode that selection with any enabled VGA device we found.  If there
were several enabled VGA devices, the *last* one we found would become the
default.

The code here instead selects the *first* enabled VGA device we find, and
if none are enabled, the first VGA device we find.

Link: http://lkml.kernel.org/r/20170901072744.2409-1-dja@axtens.net
Tested-by: Daniel Axtens <dja@axtens.net>       # arm64, ppc64-qemu-tcg
Tested-by: Zhou Wang <wangzhou1@hisilicon.com>  # D05 Hisi Hip07, Hip08
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: NDaniel Axtens <dja@axtens.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171013034721.14630.65913.stgit@bhelgaas-glaptop.roam.corp.google.com

We free "edid", then use it again on the next line.

Fixes: 3b1b9750 ("drm: adv7511/33: add HDMI CEC support")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20171017204343.zctliubjkq7imudi@mwanda

The A20 display pipeline has 2 frontends, 2 backends, and 2 TCONs.
This patch adds support (or a compatible string in the frontend's
case) for these components.

The TCONs support directly outputting to CPU/RGB/LVDS LCD panels,
or it can output to HDMI via an on-chip HDMI controller, or
CVBS/YPbPr/VGA signals via on-chip TV encoders. These additional
encoders are not covered in this patch.
Signed-off-by: NJonathan Liu <net147@gmail.com>
[wens@csie.org: Expand commit message]
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171017121807.2994-6-wens@csie.org

The A10 display pipeline has 2 frontends, 2 backends, and 2 TCONs.
This patch adds support (or a compatible string in the frontend's
case) for these components.

The TCONs support directly outputting to CPU/RGB/LVDS LCD panels,
or it can output to HDMI via an on-chip HDMI controller, or
CVBS/YPbPr/VGA signals via on-chip TV encoders. These additional
encoders are not covered in this patch.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171017121807.2994-5-wens@csie.org

The HDMI controller in the A10 SoC is the same as the one currently
supported in the A10s. It has slightly different setup parameters.
Since these parameters are not thoroughly understood, we add support
for this variant by copying these parameters verbatim.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171017121807.2994-4-wens@csie.org

The A10 has two TCONs that are similar to the ones found on other SoCs.
Like the A31, TCON0 has a register used to mux the TCON outputs to the
downstream encoders. The bit fields are slightly different.
Signed-off-by: NJonathan Liu <net147@gmail.com>
[wens@csie.org: Reworked for A10 and fixed up commit message]
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171017121807.2994-3-wens@csie.org

The backend has a mux to select the destination of the data to output
to. It can select the TCON or the frontends. On the A20, it includes
an option to output to the second TCON. This is not documented in the
user manual, but the vendor kernel uses it nevertheless, so the second
backend outputs to the second TCON.

Although the muxing can be changed on the fly, DRM needs to be able to
group a bunch of layers such that they get switched to another crtc
together. This is because the display backend does the layer compositing,
while the TCON generates the display timings. This constraint is not
supported by DRM.

Here we simply pair up backends and TCONs with the same ID.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171017121807.2994-2-wens@csie.org

Some channel0 setup has to be done, no matter what the output interface is
(RGB, CPU, LVDS). Move that code into a common function in order to avoid
duplication.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/183100/

Just like we did for the TCON enable and disable, for historical reasons we
used to rely on the encoders calling the TCON mode_set function, while the
CRTC has a callback for that.

Let's implement it in order to reduce the boilerplate code.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/faa3a4d511039af1d116270dfef3a8b60ca3591e.1508231063.git-series.maxime.ripard@free-electrons.com

So far, we've required all the TCON-connected encoders to call the TCON
enable and disable functions.

This was made this way because in the RGB/LVDS case, the TCON is the CRTC
and the encoder. However, in all the other cases (HDMI, TV, DSI, etc.), we
have another encoder down the road that needs to be programmed.

We also needed to know which channel the encoder is connected to, which is
encoder-specific.

The CRTC's enable and disable callbacks can work just fine for our use
case, and we can get the channel to use just by looking at the type of
encoder, since that is fixed. Implement those callbacks, which will
remove some of the encoder boilerplate.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/90b4396e19b3eca61b2ebfdae0672074b88ad74d.1508231063.git-series.maxime.ripard@free-electrons.com

The drm_display_mode pointer can be mark const, so let's do it.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/e6f92f126640aa6de639386f9b4677db3d8bb37b.1508231063.git-series.maxime.ripard@free-electrons.com

The drm_display_mode pointer can be mark const, so let's do it.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b0cce5a43fc3b56953d21a54fc3c14672f755f42.1508231063.git-series.maxime.ripard@free-electrons.com

Some options were not padded as they should, and the order in the Makefile
was chaotic. Fix that.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/9410b284ec97453fa692537dffaaa4fb4833347c.1508231063.git-series.maxime.ripard@free-electrons.com

The commit da82b878 ("drm/sun4i: add components in breadth first
traversal order") implemented a breadth first traversal of our device tree
nodes graph. However, it was relying on the kernel linked lists, and those
are not really safe for addition.

Indeed, in a single pipeline stage, your first stage (ie, the mixer or
fronted) will be queued, and it will be the final iteration of that list as
far as list_for_each_entry_safe is concerned. Then, during that final
iteration, we'll queue another element (the TCON or the backend) that
list_for_each_entry_safe will not account for, and we will leave the loop
without having iterated over all the elements. And since we won't have
built our components list properly, the DRM driver will be left
non-functional.

We can instead use a kfifo to queue and enqueue components in-order, as was
the original intention. This also has the benefit of removing any dynamic
allocation, making the error handling path simpler too. The only thing
we're losing is the ability to tell whether an element has already been
queued, but that was only needed to remove spurious logs, and therefore
purely cosmetic.

This means that this commit effectively reverses e8afb7b6 ("drm/sun4i:
don't add components that are already in the queue").

Fixes: da82b878 ("drm/sun4i: add components in breadth first traversal order")
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/4ecb323e787918208f6a5d9f0ebba12c62583c98.1508231063.git-series.maxime.ripard@free-electrons.com

The display backend, as well as other peripherals that have a DRAM
clock gate and access DRAM directly, bypassing the system bus,
address the DRAM starting from 0x0, while physical addresses the
system uses starts from 0x40000000 (or 0x20000000 in A80's case).

This issue was witnessed on the Cubietruck, which has 2GB of RAM.

Devices with less RAM function normally due to the DRAM address
wrapping around. CMA seems to always allocate its buffer at a
very high address, close to the end of DRAM.

On a 1GB RAM device, the physical address would be something like
0x78000000. The DRAM address 0x78000000 would access the same DRAM
region as 0x38000000 on a system, as the DRAM address would only
span 0x0 ~ 0x3fffffff. The bit 0x40000000 is non-functional in this
case.

However on the Cubietruck, the DRAM is 2GB. The physical address
is 0x40000000 ~ 0xbfffffff. The buffer would be something like
0xb8000000. But the DRAM address span 0x0 ~ 0x7fffffff, meaning
the buffer address wraps around to 0x38000000, which is wrong.
The correct DRAM address for it should be 0x78000000.

Correct the address configured into the backend layer registers
by PHYS_OFFSET to account for this.

Fixes: 9026e0d1 ("drm: Add Allwinner A10 Display Engine support")
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171017042349.31743-6-wens@csie.org

We still want to fail with -EBUSY if a plane or connector is part of
a commit, even if it will be assigned to a new commit.

This closes a small hole left open where we should return -EBUSY.
It's not severe, because wait_for_dependencies and swap_state helpers
still block. But it should return -EBUSY and not stall.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: 21a01abb ("drm/atomic: Fix freeing connector/plane state too early by tracking commits, v3.")
Link: https://patchwork.freedesktop.org/patch/msgid/20171016132928.6498-2-maarten.lankhorst@linux.intel.comReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Commit 669c9215 ("drm/atomic: Make async plane update checks work as
intended, v2.") forced planes to always be tracked, but forgot to
explicitly get the crtc commit from the new crtc when available.

This broke plane commit tracking, and caused kms_atomic_transitions
to randomly fail with -EBUSY.

Changes since v1:
- Prefer new_crtc_state->crtc above old_crtc_state->crtc.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: 669c9215 ("drm/atomic: Make async plane update checks work as intended, v2.")
Cc: Gustavo Padovan <gustavo.padovan@collabora.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102671
Testcase: kms_atomic_transitions
Link: https://patchwork.freedesktop.org/patch/msgid/20171017052047.8983-1-maarten.lankhorst@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now DRM/UDL driver retreives all edid data blocks instead of only base one.
Previous approch could lead to improper initialization of video mode with
certain monitors.
Signed-off-by: NRobert Tarasov <tutankhamen@chromium.org>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171013001350.172155-2-tutankhamen@chromium.org

Fixed problem with DisplayLink and DisplayLink certified adapers in drm/udl
driver when adapter doesn't want to work if it was initialized with
disconnected DVI cable by enabling drm connectot polling and updating
current connector's state.
Signed-off-by: NRobert Tarasov <tutankhamen@chromium.org>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171013001350.172155-1-tutankhamen@chromium.org

This patch replace instances of drm_framebuffer_reference/unreference with
*_get/put() suffixes, because get/put is shorter and consistent with the
kernel use of *_get/put suffixes.
This was done with the following Coccinelle script:

@r1@
expression e;
@@

(
-drm_framebuffer_reference(e);
+drm_framebuffer_get(e);
|
-drm_framebuffer_unreference(e);
+drm_framebuffer_put(e);
)
Signed-off-by: NHaneen Mohammed <hamohammed.sa@gmail.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/e1df1b3375faa819029559b11c32e10501c5c5d6.1505932812.git.hamohammed.sa@gmail.com

This patch replace instances of drm_gem_object_reference/unreference with
*_get/put() suffixes, because get/put is shorter and consistent with the
kernel use of *_get/put() suffixes.
This was done with the following Coccinelle script:

@r1@
expression e;
@@

(
-drm_gem_object_reference(e);
+drm_gem_object_get(e);
|
-drm_gem_object_unreference(e);
+drm_gem_object_put(e);
|
-drm_gem_object_unreference_unlocked(e);
+drm_gem_object_put_unlocked(e);
)
Signed-off-by: NHaneen Mohammed <hamohammed.sa@gmail.com>
[resolved small conflict with removed armada_gem_dumb_map_offset]
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/a59ef1ed109ade897bcffcb01b33214262db8942.1505932812.git.hamohammed.sa@gmail.com

drm_gem_cma_create() prints an error message when dma_alloc_wc() fails to
allocate the amount of memory we requested. This can lead to annoying
error messages when CMA is only one possible source of memory for the BO
allocation. Turn this error message into a debug one.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NEric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20171005112917.15949-1-boris.brezillon@free-electrons.com