Allow to also drive a slave dw-mipi-dsi controller in a dual-dsi
setup. This will require additional implementation-specific
code to look up the slave instance and do specific setup.
Also will probably need code in the specific crtcs as dual-dsi
does not equal two separate dsi outputs.

To activate, the implementation-specific code should set the slave
using dw_mipi_dsi_set_slave() before calling __dw_mipi_dsi_bind().

v2:
- expect real interface number of lanes
- keep links to both master and slave
v3:
- remove unneeded separate variables
- remove unneeded second slave settings
- disable slave before master
- lane-sum calculation comments
Signed-off-by: NNickey Yang <nickey.yang@rock-chips.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NPhilippe Cornu <philippe.cornu@st.com>
Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181001123845.11818-7-heiko@sntech.de

Add the ROCKCHIP DSI controller driver that uses the Synopsys DesignWare
MIPI DSI host controller bridge and remove the old separate one.

changes:

v2:
   add err_pllref, remove unnecessary encoder.enable & disable
   correct spelling mistakes
v3:
   call dw_mipi_dsi_unbind() in dw_mipi_dsi_rockchip_unbind()
   fix typo, use of_device_get_match_data(),
   change some bind() logic into probe()
   add 'dev_set_drvdata()'
v4:
  return -EINVAL when can not get best_freq
  add a clarifying comment when get vco
  add review tag
v5:
  keep our power domain enabled while touching GRF
v6:
  change func name dw_mipi_encoder_disable to
  dw_mipi_dsi_encoder_disable
v7:
  none
v8: Heiko
  add Archit's Review tag
  adapt to recent changes in the original rockchip-dsi driver
  beautify grf-handling
  split hw-setup (resources, dsi-host) from bind into probe
v2-new: Heiko
  add SPDX header instead of license blurb
  drop old versioning to not confuse people
v3-new: Heiko
  include ordering
  moved hwaccess from mode_set to enable callback
  move pllref_clk enablement to bind (needed by bridge mode_set->lane_mbps)
v4-new: Heiko
  rebase against recent rockchip-dsi changes
  move to call component_add in the new glue host-attach
Signed-off-by: NNickey Yang <nickey.yang@rock-chips.com>
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Reviewed-by: NBrian Norris <briannorris@chromium.org>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Reviewed-by: NArchit Taneja <architt@codeaurora.org>
Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181001123845.11818-6-heiko@sntech.de

With the regular means of adding the dsi-component in probe it creates
a race condition with the panel probing, as the panel device only gets
created after the dsi-bus got created.

When the panel-driver is build as a module it currently fails hard as the
panel cannot be probed directly:

dw_mipi_dsi_bind()
  __dw_mipi_dsi_probe()
    creates dsi bus
    creates panel device
    triggers panel module load
    panel not probed (module not loaded or panel probe slow)
  drm_bridge_attach
    fails with -EINVAL due to empty panel_bridge

Additionally the panel probing can run concurrently with dsi bringup
making it possible that the panel can already be found but dsi-attach
hasn't finished running.

To solve that cleanly we may want to only create the component after
the panel has finished probing, by calling component_add from the
host-attach dsi callback.

As that is specific to glue drivers, add a new struct for host_ops
so that glue drivers can tell the bridge to call specific functions
after the common host-attach and before the common host-detach run.
Suggested-by: NAndrzej Hajda <a.hajda@samsung.com>
Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181001123845.11818-4-heiko@sntech.de

__dw_mipi_dsi_probe() does all the grabbing of resources and does it using
devm-helpers. So this is happening on each try of master bringup possibly
slowing down things a lot.

Drivers using the component framework may instead want to call
dw_mipi_dsi_probe separately in their probe function to setup resources
early. That way the dsi bus also gets created earlier and also not
recreated on each bind-try, so that attached panels can load their modules
and be probed way before the bridge-attach in the bind call.

So drop the call to __dw_mipi_dsi_probe and modify the function to take
a struct dw_mipi_dsi instead of the platform-device.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181001123845.11818-3-heiko@sntech.de

Right now the host is only unregistered when the driver is used via the
bridge api and not via the component api, leading to the host staying
registered in cases like probe deferral.

So move the host unregister to the general remove function, so that it
gets cleaned up in all cases.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
Reviewed-by: NPhilippe Cornu <philippe.cornu@st.com>
Tested-by: NPhilippe Cornu <philippe.cornu@st.com>
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181001123845.11818-2-heiko@sntech.de

Use 'unsigned int' with bitfield instead of 'bool' to avoid alignment
issues and remove checkpatch.pl check:

CHECK: Avoid using bool structure members because of possible alignment
issues
Signed-off-by: NShayenne da Luz Moura <shayenneluzmoura@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/fcd9d7ea7eec1ac6a3ad9ad16e0fc9ef13c089fd.1540579956.git.shayenneluzmoura@gmail.comSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

Add space to remove checkpath.pl error:

ERROR: space required before the open parenthesis '('
Signed-off-by: NShayenne da Luz Moura <shayenneluzmoura@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1ab3ba05c140aae01bde66f73ff1f3b78bf7dfb3.1540579956.git.shayenneluzmoura@gmail.comSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

Use 'usigned int' instead of 'usigned' to remove the checkpath.pl warning:

WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
Signed-off-by: NShayenne da Luz Moura <shayenneluzmoura@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/52604806eb18bc25e7e429f5b229fe8c1d271b5c.1540579956.git.shayenneluzmoura@gmail.comSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

Remove extra whiteline to clean the checkpatch.pl check:

CHECK: Please don't use multiple blank lines
Signed-off-by: NShayenne da Luz Moura <shayenneluzmoura@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/5b95e1d4d515d02d01b829ddc5b3ca80af29e2e2.1540579956.git.shayenneluzmoura@gmail.comSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

Add whiteline after variable declarations to remove the checkpath.pl
warning:

WARNING: Missing a blank line after declarations
Signed-off-by: NShayenne da Luz Moura <shayenneluzmoura@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/a1d44c4a30f9b52d0aa7113e4e5093e843f9913b.1540579956.git.shayenneluzmoura@gmail.comSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

Remove extra tab and space to clean the checkpath.pl error.

ERROR: trailing whitespace
Signed-off-by: NShayenne da Luz Moura <shayenneluzmoura@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/fb0e2237bc505c855a0a842c081a39d524c571dc.1540579956.git.shayenneluzmoura@gmail.comSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

Replaced kmem_cache_alloc + memset with kmem_cache_zalloc
Signed-off-by: NSabyasachi Gupta <sabyasachi.linux@gmail.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/5bc9ff7e.1c69fb81.105c2.1fef@mx.google.comSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

It is possible to run out of memory while allocating IDs.  The current
code would create a context with an invalid ID; change it to return
-ENOMEM to userspace.
Signed-off-by: NMatthew Wilcox <willy@infradead.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20180926160031.15721-3-willy@infradead.orgSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

These IDRs were only being used to allocate unique numbers, not to look
up pointers, so they can use the more space-efficient IDA instead.
Signed-off-by: NMatthew Wilcox <willy@infradead.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20180926160031.15721-2-willy@infradead.org

[ kraxel: resolve conflict ]
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Move virtio_gpu_resource_id_{get,put} to virtgpu_object.c and make them
static.  Allocate and free the id on creation and destroy, drop all
other calls.  That way objects have a valid handle for the whole
lifetime of the object.

Also fixes ids leaking.  Worst offender are dumb buffers, and I think
some error paths too.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NDave Airlie <airlied@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20181019061847.18958-7-kraxel@redhat.com

We pass the obj anyway, so obj->hw_res_handle can be used instead
in virtio_gpu_object_attach() and virtio_gpu_cmd_create_resource().
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NDave Airlie <airlied@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20181019061847.18958-6-kraxel@redhat.com

Drop pointless res_id variable in virtio_gpu_resource_create_ioctl(),
just use the hw_res_handle field in virtio_gpu_object directly.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NDave Airlie <airlied@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20181019061847.18958-5-kraxel@redhat.com

Drop pointless resid variable in virtio_gpu_mode_dumb_create(), just use
the hw_res_handle field in virtio_gpu_object directly.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NDave Airlie <airlied@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20181019061847.18958-4-kraxel@redhat.com

Drop pointless resid variable in virtio_gpufb_create(), just use
the hw_res_handle field in virtio_gpu_object directly.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NDave Airlie <airlied@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20181019061847.18958-3-kraxel@redhat.com

Track whenever the virtio_gpu_object is already created (i.e. host knows
about it) in a new variable.  Add checks to virtio_gpu_object_attach()
to do nothing on objects not created yet.

Make virtio_gpu_ttm_bo_destroy() use the new variable too, instead of
expecting hw_res_handle indicating the object state.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NDave Airlie <airlied@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20181019061847.18958-2-kraxel@redhat.com

Trivial fix to a spelling mistake of the error access name EACCESS,
rename to EACCES
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181026180512.4908-1-colin.king@canonical.com

This patch avoids that building the bridge/analogix source code with
smatch triggers complaints about inconsistent indenting. It also fixes
a typo in DRM_ERROR message, attch is replaced for attach.
Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016095336.15656-1-enric.balletbo@collabora.com

The is_double flag is a boolean currently assigned to the value of the d
variable, that is either 1 or 2. It means that this is_double variable is
always set to true, even though the initial intent was to have it set to
true when d is 2.

Fix this.

Fixes: 9c568101 ("drm/sun4i: Add HDMI support")
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: NGiulio Benetti <giulio.benetti@micronovasrl.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181021163446.29135-2-maxime.ripard@bootlin.com

The is_double variable is used to store, and possibly returning to the
calling function, whether it needs to double the rate of the parent clock
or not.

In the case where it does, the variable is affected, but in the case where
it doesn't we return some uninitialized value. Fix this.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: NGiulio Benetti <giulio.benetti@micronovasrl.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181021163446.29135-1-maxime.ripard@bootlin.com

Earlier commit updated the vgem driver to improve the topology, by
passing a platform device as parent to drm_dev_init(). Shortly
afterwords we updated the core function to BUG() in order to catch any
buggy drivers passing NULL as parent.

While I missed the vkms driver (as the patch predates vkms by a few
months), the BUG caught the issue within couple of hours.

Swap the drm_dev_init <> platform_device_register_simple order, to
the driver back to life.

Fixes: f08877e7 ("drm: BUG_ON if passing NULL parent to drm_dev_init")
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Deepak Sharma <deepak.sharma@amd.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Sean Paul <sean@poorly.run>
Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Reported-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NEmil Velikov <emil.velikov@collabora.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181026100550.625-1-emil.l.velikov@gmail.com

HDMI 2.0 monitors may not support SCDC and still be able to accept VICs
above 63. Use multiple EDID capbilities to determine if the SINK is
actually an HDMI 2.0 device. The QD980B HDMI 2.0 Analyzer generates unique
EDIDs during CTS tests that don't contain a HDMI Forum VSDB if the block is
not used during the test. The current HDMI AVI infoframe code only uses the
SCDC supported information in the HDMI Forum VSDB to determine if the sink
is HDMI 2.0. This patch adds a check for YCbCr420 present in the EDID
supported formats as well as the existing SCDC supported check.

HDMI 2.0 CTS HF1-51 test fails on the QD980B.

V2: Make check for display_info->color formats == YCbCR420 and SCDC

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107894
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: NClint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1540415073-5102-1-git-send-email-clinton.a.taylor@intel.com

We need to serialise the addition of a new fence into the shared list
such that the fence is visible before we claim it is there. Otherwise a
concurrent reader of the shared fence list will see an uninitialised
fence slot before it is set.

  <4> [109.613162] general protection fault: 0000 [#1] PREEMPT SMP PTI
  <4> [109.613177] CPU: 1 PID: 1357 Comm: gem_busy Tainted: G     U            4.19.0-rc8-CI-CI_DRM_5035+ #1
  <4> [109.613189] Hardware name: Dell Inc. XPS 8300  /0Y2MRG, BIOS A06 10/17/2011
  <4> [109.613252] RIP: 0010:i915_gem_busy_ioctl+0x146/0x380 [i915]
  <4> [109.613261] Code: 0b 43 04 49 83 c6 08 4d 39 e6 89 43 04 74 6d 4d 8b 3e e8 5d 54 f4 e0 85 c0 74 0d 80 3d 08 71 1d 00 00
  0f 84 bb 00 00 00 31 c0 <49> 81 7f 08 20 3a 2c a0 75 cc 41 8b 97 50 02 00 00 49 8b 8f a8 00
  <4> [109.613283] RSP: 0018:ffffc9000044bcf8 EFLAGS: 00010246
  <4> [109.613292] RAX: 0000000000000000 RBX: ffffc9000044bdc0 RCX: 0000000000000001
  <4> [109.613302] RDX: 0000000000000000 RSI: 00000000ffffffff RDI: ffffffff822474a0
  <4> [109.613311] RBP: ffffc9000044bd28 R08: ffff88021e158680 R09: 0000000000000001
  <4> [109.613321] R10: 0000000000000040 R11: 0000000000000000 R12: ffff88021e1641b8
  <4> [109.613331] R13: 0000000000000003 R14: ffff88021e1641b0 R15: 6b6b6b6b6b6b6b6b
  <4> [109.613341] FS:  00007f9c9fc84980(0000) GS:ffff880227a40000(0000) knlGS:0000000000000000
  <4> [109.613352] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  <4> [109.613360] CR2: 00007f9c9fcb8000 CR3: 00000002247d4005 CR4: 00000000000606e0

Fixes: 27836b64 ("dma-buf: remove shared fence staging in reservation object")
Testcase: igt/gem_busy/close-race
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Christian König <christian.koenig@amd.com>
Cc: Junwei Zhang <Jerry.Zhang@amd.com>
Cc: Huang Rui <ray.huang@amd.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181026080302.11507-1-chris@chris-wilson.co.uk

drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line 389 but uses GFP_KERNEL

  Find functions that refer to GFP_KERNEL but are called with locks held.

Generated by: scripts/coccinelle/locks/call_kern.cocci

v2:
syncobj->timeline still needs protect.

v3:
use a global signaled fence instead of re-allocation.

v4:
Don't need moving lock.
Don't expose func.

v5:
rename func and directly return.

Tested by: syncobj_wait and ./deqp-vk -n dEQP-VK.*semaphore* with
lock debug kernel options enabled.
Signed-off-by: NChunming Zhou <david1.zhou@amd.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: Christian König <easy2remember.chk@googlemail.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
CC: Julia Lawall <julia.lawall@lip6.fr>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NChristian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/258623/

Add the device tree bindings for Truly NT35597 panel driver. This panel
driver supports both single DSI and dual DSI.

However, this patch series supports only dual DSI.

Changes in v10:
  - Remove active high in the documentation for mode gpio
  - Fix commmit text detail about the board and also
    fix a typo
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NAbhinav Kumar <abhinavk@codeaurora.org>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1538787139-28122-2-git-send-email-abhinavk@codeaurora.org

Add support for Truly NT35597 panel driver used in MSM reference
platforms. This panel driver supports both single DSI and dual
DSI modes.

However, this patch series adds support only for dual DSI mode.

Changes in v10:
- None
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NAbhinav Kumar <abhinavk@codeaurora.org>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1538787139-28122-1-git-send-email-abhinavk@codeaurora.org

The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by the emulation code. Additionally fbdev unregister happens
automatically on drm_dev_unregister().

The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
driver. This is done to highlight the fact that fbdev emulation is an
internal client that makes use of the driver, it is not part of the
driver as such. If fbdev setup fails, an error is printed, but the driver
succeeds probing.

drm_fbdev_generic_setup() handles mode_config.num_connector being zero.
In that case it retries fbdev setup on the next .output_poll_changed.

Cc: Yannick Fertre <yannick.fertre@st.com>
Cc: Philippe Cornu <philippe.cornu@st.com>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Acked-by: NYannick Fertré <yannick.fertre@st.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180908134648.2582-15-noralf@tronnes.org

The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by the emulation code. Additionally fbdev unregister happens
automatically on drm_dev_unregister().

The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
driver. This is done to highlight the fact that fbdev emulation is an
internal client that makes use of the driver, it is not part of the
driver as such. If fbdev setup fails, an error is printed, but the driver
succeeds probing.

Cc: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Acked-by: NNeil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180908134648.2582-6-noralf@tronnes.org

A while back we removed it, yet that lead to regressions. At some later
point, I've attempted to remove it again without fully grasping the
unique (pun intended) situation that virtio is in.

Add a bulky comment to document why the call should stay as-is, for the
next person who's around.

As a Tl;Dr: virtio sits on top of struct virtio_device, which confuses
dev_is_pci(), wrong info gets sent to userspace and X doesn't start.
Driver needs to explicitly call drm_dev_set_unique() to keep it working.

v2: Fix handful of typos (Laszlo)

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: NEmil Velikov <emil.velikov@collabora.com>
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181024144252.16518-1-emil.l.velikov@gmail.com

Previous commit removed the only reason why we were allowing NULL as
a parent device. With that resolved, we can enforce nobody else does
that mistake.

With that we can drop the ugly drm_dev_set_unique workaround.

v2: rebase, silence checkpatch "== NULL" warning

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Deepak Sharma <deepak.sharma@amd.com>
Signed-off-by: NEmil Velikov <emil.velikov@collabora.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181023163550.15211-2-emil.l.velikov@gmail.com

Modify vgem_init to take platform dev as parent in drm_dev_init.
This will make drm device available at "/sys/devices/platform/vgem"
in x86 chromebook.

v2: rebase, address checkpatch typo and line over 80 characters

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDeepak Sharma <deepak.sharma@amd.com>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NEmil Velikov <emil.velikov@collabora.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181023163550.15211-1-emil.l.velikov@gmail.com

Set shared_max to the number of shared fences right before we release
the lock.

This way every attempt to add a shared fence without previously
reserving a slot will cause an error.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NHuang Rui <ray.huang@amd.com>
Acked-by: NJunwei Zhang <Jerry.Zhang@amd.com>
Link: https://patchwork.kernel.org/patch/10626147/

Let's support simultaneous submissions to multiple engines.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
Reviewed-by: NJunwei Zhang <Jerry.Zhang@amd.com>
Reviewed-by: NHuang Rui <ray.huang@amd.com>
Link: https://patchwork.kernel.org/patch/10626149/

No need for that any more. Just replace the list when there isn't enough
room any more for the additional fence.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NJunwei Zhang <Jerry.Zhang@amd.com>
Reviewed-by: NHuang Rui <ray.huang@amd.com>
Link: https://patchwork.kernel.org/patch/10626143/

Fixes the following warnings:
../drivers/gpu/drm/drm_connector.c:305: warning: Excess function parameter 'dev' description in 'drm_connector_attach_edid_property'
../drivers/gpu/drm/drm_connector.c:306: warning: Excess function parameter 'dev' description in 'drm_connector_attach_edid_property'
../drivers/gpu/drm/drm_connector.c:305: warning: Excess function parameter 'dev' description in 'drm_connector_attach_edid_property'
../drivers/gpu/drm/drm_connector.c:305: warning: Excess function parameter 'dev' description in 'drm_connector_attach_edid_property'
../drivers/gpu/drm/drm_connector.c:305: warning: Excess function parameter 'dev' description in 'drm_connector_attach_edid_property'

Fixes: 6b7e2d5c ("drm: add drm_connector_attach_edid_property()")
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20181024182442.206411-1-sean@poorly.run

There's no reason to track the atomic state three times. Unfortunately,
this is currently what we're doing, and even worse is that there is only
one actually correct state pointer: the one in mst_state->base.state.
mgr->state never seems to be used, along with the one in
mst_state->state.

This confused me for over 4 hours until I realized there was no magic
behind these pointers. So, let's save everyone else from the trouble.

Signed-off-by: Lyude Paul <lyude@redhat.com>.
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181023231251.16883-3-lyude@redhat.com