dt-bindings: display: drop data-mapping from panel-dpi

data-mapping may not be the best way to describe the
data format used between panels and display interface.

Drop it from the panel-dpi binding so we do not start to rely on it.
We can then work out how to best describe this mapping and when
we know it, we can add it to this binding.

Fixes: fa10224087f1 ("dt-bindings: display: add data-mapping to panel-dpi")
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200314153047.2486-2-sam@ravnborg.org

dma-buf: Improve CONFIG_DMABUF_MOVE_NOTIFY help text

Improve the help text for the CONFIG_DMABUF_MOVE_NOTIFY symbol by:
  1. Removing duplicated single quotes,
  2. Adding a missing subject,
  3. Fixing a misspelling of "yet",
  4. Wrapping long lines.

Fixes: bb42df4662a44765 ("dma-buf: add dynamic DMA-buf handling v15")
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200324125442.21983-1-geert+renesas@glider.be

drm: Mark up racy check of drm_gem_object.handle_count

[ 1715.899800] BUG: KCSAN: data-race in drm_gem_handle_create_tail / drm_gem_object_handle_put_unlocked
[ 1715.899838]
[ 1715.899861] write to 0xffff8881830f3604 of 4 bytes by task 7834 on cpu 1:
[ 1715.899896]  drm_gem_handle_create_tail+0x62/0x250
[ 1715.899927]  drm_gem_open_ioctl+0xc1/0x160
[ 1715.899956]  drm_ioctl_kernel+0xe4/0x120
[ 1715.899981]  drm_ioctl+0x297/0x4c7
[ 1715.900003]  ksys_ioctl+0x89/0xb0
[ 1715.900027]  __x64_sys_ioctl+0x42/0x60
[ 1715.900052]  do_syscall_64+0x6e/0x2c0
[ 1715.900079]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 1715.900100]
[ 1715.900119] read to 0xffff8881830f3604 of 4 bytes by task 8137 on cpu 0:
[ 1715.900149]  drm_gem_object_handle_put_unlocked+0x31/0x130
[ 1715.900180]  drm_gem_object_release_handle+0x93/0xe0
[ 1715.900208]  drm_gem_handle_delete+0x7b/0xe0
[ 1715.900235]  drm_gem_close_ioctl+0x61/0x80
[ 1715.900264]  drm_ioctl_kernel+0xe4/0x120
[ 1715.900291]  drm_ioctl+0x297/0x4c7
[ 1715.900316]  ksys_ioctl+0x89/0xb0
[ 1715.900340]  __x64_sys_ioctl+0x42/0x60
[ 1715.900363]  do_syscall_64+0x6e/0x2c0
[ 1715.900388]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200309120151.7675-1-chris@chris-wilson.co.uk

drm/mm: Allow drm_mm_initialized() to be used outside of the locks

Mark up the potential racy read in drm_mm_initialized(), as we want a
cheap and cheerful check:

[  121.098731] BUG: KCSAN: data-race in _i915_gem_object_create_stolen [i915] / rm_hole
[  121.098766]
[  121.098789] write (marked) to 0xffff8881f01ed330 of 8 bytes by task 3568 on cpu 3:
[  121.098831]  rm_hole+0x64/0x140
[  121.098860]  drm_mm_insert_node_in_range+0x3d3/0x6c0
[  121.099254]  i915_gem_stolen_insert_node_in_range+0x91/0xe0 [i915]
[  121.099646]  _i915_gem_object_create_stolen+0x9d/0x100 [i915]
[  121.100047]  i915_gem_object_create_region+0x7a/0xa0 [i915]
[  121.100451]  i915_gem_object_create_stolen+0x33/0x50 [i915]
[  121.100849]  intel_engine_create_ring+0x1af/0x280 [i915]
[  121.101242]  __execlists_context_alloc+0xce/0x3d0 [i915]
[  121.101635]  execlists_context_alloc+0x25/0x40 [i915]
[  121.102030]  intel_context_alloc_state+0xb6/0xf0 [i915]
[  121.102420]  __intel_context_do_pin+0x1ff/0x220 [i915]
[  121.102815]  i915_gem_do_execbuffer+0x46b4/0x4c20 [i915]
[  121.103211]  i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915]
[  121.103244]  drm_ioctl_kernel+0xe4/0x120
[  121.103269]  drm_ioctl+0x297/0x4c7
[  121.103296]  ksys_ioctl+0x89/0xb0
[  121.103321]  __x64_sys_ioctl+0x42/0x60
[  121.103349]  do_syscall_64+0x6e/0x2c0
[  121.103377]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  121.103403]
[  121.103426] read to 0xffff8881f01ed330 of 8 bytes by task 3109 on cpu 1:
[  121.103819]  _i915_gem_object_create_stolen+0x30/0x100 [i915]
[  121.104228]  i915_gem_object_create_region+0x7a/0xa0 [i915]
[  121.104631]  i915_gem_object_create_stolen+0x33/0x50 [i915]
[  121.105025]  intel_engine_create_ring+0x1af/0x280 [i915]
[  121.105420]  __execlists_context_alloc+0xce/0x3d0 [i915]
[  121.105818]  execlists_context_alloc+0x25/0x40 [i915]
[  121.106202]  intel_context_alloc_state+0xb6/0xf0 [i915]
[  121.106595]  __intel_context_do_pin+0x1ff/0x220 [i915]
[  121.106985]  i915_gem_do_execbuffer+0x46b4/0x4c20 [i915]
[  121.107375]  i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915]
[  121.107409]  drm_ioctl_kernel+0xe4/0x120
[  121.107437]  drm_ioctl+0x297/0x4c7
[  121.107464]  ksys_ioctl+0x89/0xb0
[  121.107489]  __x64_sys_ioctl+0x42/0x60
[  121.107511]  do_syscall_64+0x6e/0x2c0
[  121.107535]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200309121529.16497-1-chris@chris-wilson.co.uk

drm/edid: Distribute switch variables for initialization

Variables declared in a switch statement before any case statements
cannot be automatically initialized with compiler instrumentation (as
they are not part of any execution flow). With GCC's proposed automatic
stack variable initialization feature, this triggers a warning (and they
don't get initialized). Clang's automatic stack variable initialization
(via CONFIG_INIT_STACK_ALL=y) doesn't throw a warning, but it also
doesn't initialize such variables[1]. Note that these warnings (or silent
skipping) happen before the dead-store elimination optimization phase,
so even when the automatic initializations are later elided in favor of
direct initializations, the warnings remain.

To avoid these problems, lift such variables up into the next code
block.

drivers/gpu/drm/drm_edid.c: In function ‘drm_edid_to_eld’:
drivers/gpu/drm/drm_edid.c:4395:9: warning: statement will never be
executed [-Wswitch-unreachable]
 4395 |     int sad_count;
      |         ^~~~~~~~~

[1] https://bugs.llvm.org/show_bug.cgi?id=44916

v2: move into function block instead being switch-local (Ville Syrjälä)

Signed-off-by: Kees Cook <keescook@chromium.org>
[danvet: keep the changelog]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/202003060930.DDCCB6659@keescook

drm: lock: Clean up documentation

Fix kernel doc comments to avoid warnings when compiling with W=1.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200306102937.4932-2-benjamin.gaignard@st.com

drm: bufs: Clean up documentation

Fix kernel doc comments to avoid warnings when compiling with W=1.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200306102937.4932-3-benjamin.gaignard@st.com

drm: vm: Clean up documentation

Fix kernel doc comments to avoid warnings when compiling with W=1.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200306102937.4932-1-benjamin.gaignard@st.com

drm: context: Clean up documentation

Fix kernel doc comments to avoid warnings when compiling with W=1.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200306102937.4932-4-benjamin.gaignard@st.com

dt-bindings: display: Add idk-1110wr binding

Add binding for the idk-1110wr LVDS panel from Advantech.

Some panel-specific documentation can be found here:
https://buy.advantech.eu/Displays/Embedded-LCD-Kits-LCD-Kit-Modules/model-IDK-1110WR-55WSA1E.htm

Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1583957020-16359-2-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com

drm/tiny: fix sparse warning: incorrect type in assignment (different base types)

This fixes the following sparse warning:

drivers/gpu/drm/tiny/ili9486.c:61:16: sparse: sparse: incorrect type in assignment (different base types)
drivers/gpu/drm/tiny/ili9486.c:61:16: sparse:    expected unsigned short [usertype]
drivers/gpu/drm/tiny/ili9486.c:61:16: sparse:    got restricted __be16 [usertype]
drivers/gpu/drm/tiny/ili9486.c:71:32: sparse: sparse: incorrect type in assignment (different base types)
drivers/gpu/drm/tiny/ili9486.c:71:32: sparse:    expected unsigned short [usertype]
drivers/gpu/drm/tiny/ili9486.c:71:32: sparse:    got restricted __be16 [usertype]

Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Kamlesh Gurudasani <kamlesh.gurudasani@gmail.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1583684084-4694-1-git-send-email-kamlesh.gurudasani@gmail.com

dt-bindings: display: fix panel warnings

Fix following type af warnings in the panel bindings:

Warning (unit_address_vs_reg): /example-0/dsi/panel: node has a reg or ranges property, but no unit name
Warning (unit_address_vs_reg): /example-0/dsi@ff450000: node has a unit name, but no reg property

Removing the "@xxx" from the node name fixed first warning.
Adding a missing reg property fixed the second warning

v2:
  - renamed mdss_dsi to dsi in panel-simple-dsi.yaml (Rob)

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Benjamin Gaignard <benjamin.gaignard@st.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200308115017.18563-2-sam@ravnborg.org

drm/dp_mst: Convert drm_dp_mst_topology_mgr.is_waiting_for_dwn_reply to bitfield

Small nitpick that I noticed a second ago - we can save some space in
the struct by making this a bitfield and sticking it with the rest of
the bitfields. Also, some small cleanup to the kdocs for this member.

There should be no functional changes in this patch.

Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Wayne Lin <Wayne.Lin@amd.com>
Reviewed-by: Wayne Lin <Wayne.Lin@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200122194846.16025-1-lyude@redhat.com

drm: Remove drm dp mst destroy_connector callbacks

drm_dp_mst_topology_mgr_cbs.destroy_connector callbacks are identical
amongst every driver and don't do anything other than cleaning up the
connector((drm_connector_unregister()/drm_connector_put())) except for
amdgpu_dm driver where some amdgpu_dm specific code in there.

This connector cleaning up is now being handled in the drm core so
driver destroy_connector callbacks are not needed (except for
amdgpu_dm) hence remove them.

Removal is done with below sementic patch:

@r1@
identifier func, E;
@@
struct drm_dp_mst_topology_cbs E = {
...,
-        .destroy_connector = func
};

@delete depends on r1@
identifier r1.func;
@@
- static void func(...){...}

Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Suggested-by: Emil Velikov <emil.velikov@collabora.com>
Suggested-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200307083023.76498-6-pankaj.laxminarayan.bharadiya@intel.com
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm: Add drm_dp_destroy_connector helper and use it

drm_dp_mst_topology_mgr_cbs.destroy_connector callbacks are identical
amongst every driver and don't do anything other than cleaning up the
connector (drm_connector_unregister()/drm_connector_put()) except for
amdgpu_dm driver where some amdgpu_dm specific code in there which I
an not sure if it should stay or not.

Create and use a helper which calls driver's destroy_connector hook if
available otherwise does cleanup internally.

This is the step towards removing identical hooks from every driver.

Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Suggested-by: Emil Velikov <emil.velikov@collabora.com>
Suggested-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200307083023.76498-5-pankaj.laxminarayan.bharadiya@intel.com
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/dp_mst: Remove register_connector callback

Now drm_dp_mst_topology_cbs.register_connector callback is not getting
used anymore hence remove it.

Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Suggested-by: Emil Velikov <emil.velikov@collabora.com>
Suggested-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200307083023.76498-4-pankaj.laxminarayan.bharadiya@intel.com
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm: Remove dp mst register connector callbacks

drm_dp_mst_port_add_connector() directly calls the
drm_connector_register() now and
drm_dp_mst_topology_mgr_cbs.register_connector callback is not getting
called anymore.

Hence remove all drm_dp_mst_topology_mgr_cbs.register_connector
callbacks.

This is the preparatory step for removing the
drm_dp_mst_topology_mgr_cbs.register_connector callback hook.

The removal is done with below sementic patch:

@r1@
identifier func, E;
@@
struct drm_dp_mst_topology_cbs E = {
...,
-        .register_connector = func
};

@delete depends on r1@
identifier r1.func;
@@
- static void func(...){...}

Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Suggested-by: Emil Velikov <emil.velikov@collabora.com>
Suggested-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200307083023.76498-3-pankaj.laxminarayan.bharadiya@intel.com
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm: Register connector instead of calling register_connector callback

drm_dp_mst_topology_mgr_cbs.register_connector callbacks are literally
identical amongst every driver and don't do anything other than
calling drm_connector_register(). Hence call drm_connector_register()
directly instead of a callback.

This is the preparatory step for removing the
drm_dp_mst_topology_mgr_cbs.register_connector callback hook.

Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Suggested-by: Emil Velikov <emil.velikov@collabora.com>
Suggested-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200307083023.76498-2-pankaj.laxminarayan.bharadiya@intel.com
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/edid: Add function to parse EDID descriptors for monitor range

Adaptive Sync is a VESA feature so add a DRM core helper to parse
the EDID's detailed descritors to obtain the adaptive sync monitor range.
Store this info as part fo drm_display_info so it can be used
across all drivers.
This part of the code is stripped out of amdgpu's function
amdgpu_dm_update_freesync_caps() to make it generic and be used
across all DRM drivers

v6:
* Call it monitor_range (Ville)
v5:
* Use the renamed flags
v4:
* Use is_display_descriptor() (Ville)
* Name the monitor range flags (Ville)
v3:
* Remove the edid parsing restriction for just DP (Nicholas)
* Use drm_for_each_detailed_block (Ville)
* Make the drm_get_adaptive_sync_range function static (Harry, Jani)
v2:
* Change vmin and vmax to use u8 (Ville)
* Dont store pixel clock since that is just a max dotclock
and not related to VRR mode (Manasi)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Clinton A Taylor <clinton.a.taylor@intel.com>
Cc: Kazlauskas Nicholas <Nicholas.Kazlauskas@amd.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200310231651.13841-2-manasi.d.navare@intel.com

drm/edid: Name the detailed monitor range flags

This patch adds defines for the detailed monitor
range flags as per the EDID specification.

v2:
* Rename the flags with DRM_EDID_ (Jani N)

Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Clinton A Taylor <clinton.a.taylor@intel.com>
Cc: Kazlauskas Nicholas <Nicholas.Kazlauskas@amd.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200310231651.13841-1-manasi.d.navare@intel.com

drm/panel-simple: Fix dotclock for Logic PD Type 28

The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: Adam Ford <aford173@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200302203452.17977-22-ville.syrjala@linux.intel.com
Reviewed-by: Adam Ford <aford173@gmail.com>

drm/panel-sony-acx424akp: Fix dotclocks

The currently listed dotclocks disagree with the currently
listed vrefresh rates. Change the dotclocks to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200302203452.17977-9-ville.syrjala@linux.intel.com
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

drm/panel-lg-lg4573: Fix dotclock

The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.

Someone tell me which (if either) of the dotclock or vreresh is
correct?

Cc: Heiko Schocher <hs@denx.de>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200302203452.17977-7-ville.syrjala@linux.intel.com
Reviewed-by: Heiko Schocher <hs@denx.de>

drm/panel-ilitek-ili9322: Fix dotclocks

The listed dotclocks are two orders of mangnitude out.
Fix them.

v2: Just divide everything by 100 (Linus)

Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200309133809.32585-1-ville.syrjala@linux.intel.com
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

drm/panel-novatek-nt35510: Fix dotclock

The dotclock is three orders of magnitude out. Fix it.

v2: Just set it to 20MHz (Linus)

Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200309133644.32385-1-ville.syrjala@linux.intel.com
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

drm: sysfs: Use scnprintf() for avoiding potential buffer overflow

Since snprintf() returns the would-be-output size instead of the
actual output size, the succeeding calls may go beyond the given
buffer limit.  Fix it by replacing with scnprintf().

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20200311073540.7108-1-tiwai@suse.de

drm/ttm: Use scnprintf() for avoiding potential buffer overflow

Since snprintf() returns the would-be-output size instead of the
actual output size, the succeeding calls may go beyond the given
buffer limit.  Fix it by replacing with scnprintf().

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/357174/
Signed-off-by: Christian König <christian.koenig@amd.com>

drm/ttm: fix false positive assert

The assert sometimes incorrectly triggers when pinned BOs are destroyed.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Tested-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Link: https://patchwork.freedesktop.org/patch/356737/

drm/rockchip: rgb: don't count non-existent devices when determining subdrivers

rockchip_drm_endpoint_is_subdriver() may also return error codes.
For example if the target-node is in the disabled state, so no
platform-device is getting created for it.

In that case current code would count that as external rgb device,
which in turn would make probing the rockchip-drm device fail.

So only count the target as rgb device if the function actually
returns 0.

Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200121224828.4070067-1-heiko@sntech.de

dt-bindings: display: Add idk-2121wr binding

Add binding for the idk-2121wr LVDS panel from Advantech.

Some panel-specific documentation can be found here:
https://buy.advantech.eu/Displays/Embedded-LCD-Kits-High-Brightness/model-IDK-2121WR-K2FHA2E.htm

Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1583869169-1006-1-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com

drm/dp_mst: Fix drm_dp_check_mstb_guid() return code

We actually expect this to return a 0 on success, or negative error code
on failure. In order to do that, we check whether or not we managed to
write the whole GUID and then return 0 if so, otherwise return a
negative error code. Also, let's add an error message here so it's a
little more obvious when this fails in the middle of a link address
probe.

This should fix issues with certain MST hubs seemingly stopping for no
reason in the middle of the link address probe process.

Fixes: cb897542c6d2 ("drm/dp_mst: Fix W=1 warnings")
Cc: Benjamin Gaignard <benjamin.gaignard@st.com>
Cc: Sean Paul <sean@poorly.run>
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200306234923.547873-3-lyude@redhat.com
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

drm/dp_mst: Make drm_dp_mst_dpcd_write() consistent with drm_dp_dpcd_write()

Noticed this while having some problems with hubs sometimes not being
detected on the first plug. Every single dpcd read or write function
returns the number of bytes transferred on success or a negative error
code, except apparently for drm_dp_mst_dpcd_write() - which returns 0 on
success.

There's not really any good reason for this difference that I can tell,
and having the two functions give differing behavior means that
drm_dp_dpcd_write() will end up returning 0 on success for MST devices,
but the number of bytes transferred for everything else.

So, fix that and update the kernel doc.

Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: 2f221a5efed4 ("drm/dp_mst: Add MST support to DP DPCD R/W functions")
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Mikita Lipski <mikita.lipski@amd.com>
Cc: Sean Paul <sean@poorly.run>
Link: https://patchwork.freedesktop.org/patch/msgid/20200306234923.547873-2-lyude@redhat.com
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

drm/panel-simple: Fix dotclock for Ortustech COM37H3M

The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.

There are two variants of the COM37H3M panel.
The older one's COM37H3M05DTC data sheet specifies:

                         MIN      TYP     MAX
CLK frequency    fCLK     --       22.4    26.3 MHz (in VGA mode)
VSYNC Frequency  fVSYNC   54       60      66   Hz
VSYNC cycle time tv       --      650      --   H
HSYNC frequency  fHSYNC   --       39.3    --   kHz
HSYNC cycle time th       --      570      --   CLK

The newer one's COM37H3M99DTC data sheet says:

                         MIN      TYP     MAX
CLK frequency    fCLK     18       19.8    27   MHz
VSYNC Frequency  fVSYNC   54       60      66   Hz
VSYNC cycle time tv      646      650     700   H
HSYNC frequency  fHSYNC  --        39.0    50.0 kHz
HSYNC cycle time th      504      508     630   CLK

So we choose a parameter set that lies within the specs
of both variants. We start at .vrefresh = 60,
choose .htotal = 570 and .vtotal = 650 and end up
in a clock of 22.230 MHz.

Reported-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/e63a0533ad5b5142373437ef758aedbdb716152d.1583826198.git.hns@goldelico.com

drm: panel: Set connector type for OrtusTech COM43H4M85ULC panel

The OrtusTech COM43H4M85ULC is a DPI panel, set the connector type
accordingly.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200309184210.10042-1-laurent.pinchart@ideasonboard.com

drm/mm: Remove redundant assignment in drm_mm_reserve_node

In Pete Goodliffe words, "You can improve a system by adding new code. You
can also improve a system by removing code" - In this case, commit
"202b52b7fbf70" added new code to initialize end of the node. So, there
is no need for duplicated initialization, and this patch simply removes it.

Signed-off-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200309151156.25040-1-akeem.g.abodunrin@intel.com

drm/meson: Add YUV420 output support

This patch adds support for the YUV420 output from the Amlogic Meson SoCs
Video Processing Unit to the HDMI Controller.

The YUV420 is obtained by generating a YUV444 pixel stream like
the classic HDMI display modes, but then the Video Encoder output
can be configured to down-sample the YUV444 pixel stream to a YUV420
stream.
In addition if pixel stream down-sampling, the Y Cb Cr components must
also be mapped differently to align with the HDMI2.0 specifications.

This mode needs a different clock generation scheme since the TMDS PHY
clock must match the 10x ratio with the YUV420 pixel clock, but
the video encoder must run at 2x the pixel clock.

This patch enables the bridge bus format negociation, and handles
the YUV420 case if selected by the negociation.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-12-narmstrong@baylibre.com

drm/meson: vclk: add support for YUV420 setup

This patch adds clocking support for the YUV420 output from the
Amlogic Meson SoCs Video Processing Unit to the HDMI Controller.

The YUV420 is obtained by generating a YUV444 pixel stream like
the classic HDMI display modes, but then the Video Encoder output
can be configured to down-sample the YUV444 pixel stream to a YUV420
stream.

This mode needs a different clock generation scheme since the TMDS PHY
clock must match the 10x ratio with the YUV420 pixel clock, but
the video encoder must run at 2x the pixel clock.

This patch adds the TMDS PHY clock value in all the video clock setup
in order to better support these specific uses cases and switch
to the Common Clock framework for clocks handling in the future.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-11-narmstrong@baylibre.com

drm/meson: venc: add support for YUV420 setup

This patch adds encoding support for the YUV420 output from the
Amlogic Meson SoCs Video Processing Unit to the HDMI Controller.

The YUV420 is obtained by generating a YUV444 pixel stream like
the classic HDMI display modes, but then the Video Encoder output
can be configured to down-sample the YUV444 pixel stream to a YUV420
stream.

In addition if pixel stream down-sampling, the Y Cb Cr components must
also be mapped differently to align with the HDMI2.0 specifications.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-10-narmstrong@baylibre.com

drm/meson: dw-hdmi: stop enforcing input_bus_format

To allow using formats from negotiation, stop enforcing input_bus_format
in the private dw-plat-data struct.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-9-narmstrong@baylibre.com

drm/meson: meson_dw_hdmi: add bridge and switch to drm_bridge_funcs

Switch the dw-hdmi driver to drm_bridge_funcs by implementing a new local
bridge, connecting it to the dw-hdmi bridge, then implement the
atomic_get_input_bus_fmts/atomic_get_output_bus_fmts.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-8-narmstrong@baylibre.com

drm/meson: venc: make drm_display_mode const

Before switching to bridge funcs, make sure drm_display_mode is passed
as const to the venc functions.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-7-narmstrong@baylibre.com

drm/bridge: synopsys: dw-hdmi: allow ycbcr420 modes for >= 0x200a

Now the DW-HDMI Controller supports the HDMI2.0 modes, enable support
for these modes in the connector if the platform supports them.
We limit these modes to DW-HDMI IP version >= 0x200a which
are designed to support HDMI2.0 display modes.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-6-narmstrong@baylibre.com

drm/bridge: synopsys: dw-hdmi: add bus format negociation

Add the atomic_get_output_bus_fmts, atomic_get_input_bus_fmts to negociate
the possible output and input formats for the current mode and monitor,
and use the negotiated formats in a basic atomic_check callback.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-5-narmstrong@baylibre.com

drm/bridge: dw-hdmi: Plug atomic state hooks to the default implementation

Add atomic_duplicate_state/atomic_destroy_state/atomic_reset bridge
funcs to allow setup of atomic bridge state.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-4-narmstrong@baylibre.com

drm/bridge: dw-hdmi: add max bpc connector property

Add the max_bpc property to the dw-hdmi connector to prepare support
for 10, 12 & 16bit output support.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-3-narmstrong@baylibre.com

drm/bridge: dw-hdmi: set mtmdsclock for deep color

Configure the correct mtmdsclock for deep colors to prepare support
for 10, 12 & 16bit output.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Jernej Škrabec <jernej.skrabec@siol.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-2-narmstrong@baylibre.com

drm/virtio: add case for shmem objects in virtio_gpu_cleanup_object(..)

This function can be reused for hostmem objects.

v2: move virtio_gpu_is_shmem() check to virtio_gpu_cleanup_object()
v3: use-after free fix

Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20200305013212.130640-2-gurchetansingh@chromium.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

drm/virtio: factor out the sg_table from virtio_gpu_object

A resource will be a shmem based resource or a (planned)
vram based resource, so it makes sense to factor out common fields
(resource handle, dumb).

v2: move mapped field to shmem object

Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20200305013212.130640-1-gurchetansingh@chromium.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

drm: Make drm_pci_agp_init legacy

Pull the drm_pci_agp_init() underneath the legacy ifdeffry alongside its
only caller.

The diff chooses it to so it by moving drm_pci_agp_destroy earlier, but
the important bit is moving the #ifdef earlier before drm_pci_agp_init.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20200307093702.2269-1-chris@chris-wilson.co.uk

Revert "drm/panel: simple: Add support for Sharp LQ150X1LG11 panels"

This reverts commit 0f9cdd743f7f8d470fff51b11250f02fc554cf1b.

The interface of the panel is LVDS, not parallel.
The color depth is RGB888, not RGB565.
The panel has additional features, making it not so simple.
The only user (upstream) of this panel is appropriately using panel-lvds.

Suggested-by: Thierry Reding <thierry.reding@gmail.com>
Suggested-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200305130536.26011-1-peda@axentia.se

drm/vboxvideo/vboxvideo.h: Replace zero-length array with flexible-array member

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.

Also, notice that, dynamic memory allocations won't be affected by
this change:

"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200305105558.GA19124@embeddedor

dt-bindings: convert rockchip-drm.txt to rockchip-drm.yaml

convert the binding file rockchip-drm.txt to yaml format.
This was tested and verified on ARM and ARM64 with:
make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml
make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml

Changes since v2:
- add a missing ">" sign in maintainers list
- change the licens to GPL-2.0-only
- add "additionalProperties: false"
- change the commit message to conform that it was tested on both ARM and ARM64
Changes since v1:
- fixed worng sign-off
- fixed the path of the $id property to be the path of the yaml file

Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20200121154314.3444-1-dafna.hirschfeld@collabora.com

drm/pci: Unexport drm_get_pci_dev

Only user left is the shadow attach for legacy drivers.

v2: Shift the #ifdef CONFIG_DRM_LEGACY to now also include
drm_get_pci_dev() (Thomas)

Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Emil Velikov <emil.velikov@collabora.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200225165835.2394442-1-daniel.vetter@ffwll.ch

drm/todo: Update drm_fb_helper tasks

drm_fb_helper tasks are completed now hence remove them from
todo list.

Changes since v1:
* remove entire drm_fb_helper tasks from todo list. Daniel's
  "64914da24ea9 drm/fbdev-helper: don't force restores" already fixes
  first one (Daniel)

Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200305120434.111091-8-pankaj.laxminarayan.bharadiya@intel.com

drm/fb-helper: Remove drm_fb_helper add, add_all and remove connector functions

drm_fb_helper_single_add_all_connectors(),
drm_fb_helper_add_one_connector()
and drm_fb_helper_remove_one_connector() don't keep an array of
connectors anymore and are just dummy. Now we have no callers to these
functions hence remove them.

Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200305120434.111091-7-pankaj.laxminarayan.bharadiya@intel.com

drm: Remove drm_fb_helper add, add all and remove connector calls

drm_fb_helper_{add,remove}_one_connector() and
drm_fb_helper_single_add_all_connectors() are dummy functions now
and serve no purpose. Hence remove their calls.

This is the preparatory step for removing the
drm_fb_helper_{add,remove}_one_connector() functions from
drm_fb_helper.h

This removal is done using below sementic patch and unused variable
compilation warnings are fixed manually.

@@
@@

- drm_fb_helper_single_add_all_connectors(...);

@@
expression e1;
statement S;
@@
- e1 = drm_fb_helper_single_add_all_connectors(...);
- S

@@
@@

- drm_fb_helper_add_one_connector(...);

@@
@@

- drm_fb_helper_remove_one_connector(...);

Changes since v1:
* Squashed warning fixes into the patch that introduced the
  warnings (into 5/7) (Laurent, Emil, Lyude)

Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200305120434.111091-6-pankaj.laxminarayan.bharadiya@intel.com

drm/i915/display: Remove drm_fb_helper_{add,remove}_one_connector calls

drm_fb_helper_{add,remove}_one_connector() are dummy functions now
and serve no purpose. Hence remove their calls.

This is the preparatory step for removing the
drm_fb_helper_{add,remove}_one_connector() functions from
drm_fb_helper.h

Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200305120434.111091-5-pankaj.laxminarayan.bharadiya@intel.com

drm/amdgpu: Remove drm_fb_helper_{add,remove}_one_connector calls

drm_fb_helper_{add,remove}_one_connector() are dummy functions now
and serve no purpose. Hence remove their calls.

This is the preparatory step for removing the
drm_fb_helper_{add,remove}_one_connector() functions from
drm_fb_helper.h

Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200305120434.111091-4-pankaj.laxminarayan.bharadiya@intel.com

drm/radeon: remove radeon_fb_{add,remove}_connector functions

drm_fb_helper_{add,remove}_one_connector() are dummy functions now
and serve no purpose. Hence remove their calls.

This is the preparatory step for removing the
drm_fb_helper_{add,remove}_one_connector() functions from
drm_fb_helper.h

Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200305120434.111091-3-pankaj.laxminarayan.bharadiya@intel.com

drm: Remove unused arg from drm_fb_helper_init

The max connector argument for drm_fb_helper_init() isn't used anymore
hence remove it.

All the drm_fb_helper_init() calls are modified with below sementic
patch.

@@
expression E1, E2, E3;
@@
-  drm_fb_helper_init(E1,E2, E3)
+  drm_fb_helper_init(E1,E2)

Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200305120434.111091-2-pankaj.laxminarayan.bharadiya@intel.com

MAINTAINERS: adjust to reservation.h renaming

Commit 52791eeec1d9 ("dma-buf: rename reservation_object to dma_resv")
renamed include/linux/reservation.h to include/linux/dma-resv.h, but
missed the reference in the MAINTAINERS entry.

Since then, ./scripts/get_maintainer.pl --self-test complains:

  warning: no file matches F: include/linux/reservation.h

Adjust the DMA BUFFER SHARING FRAMEWORK entry in MAINTAINERS.

Co-developed-by: Sebastian Duda <sebastian.duda@fau.de>
Signed-off-by: Sebastian Duda <sebastian.duda@fau.de>
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/356414/
Signed-off-by: Christian König <christian.koenig@amd.com>

drm: unbreak the DRM menu, broken by DRM_EXPORT_FOR_TESTS

Unbreak the DRM menu. This Kconfig symbol does not depend on DRM,
so the menu is broken at that point.

Move the symbol to a location in the Kconfig file so that it does
not break the dependency continuity.

Fixes: 6349120ddcbf ("drm: Move EXPORT_SYMBOL_FOR_TESTS_ONLY under a separate Kconfig")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/04221997-79ba-f8a2-4f2d-3c3d9f5219bc@infradead.org

drm/mm: Break long searches in fragmented address spaces

We try hard to select a suitable hole in the drm_mm first time. But if
that is unsuccessful, we then have to look at neighbouring nodes, and
this requires traversing the rbtree. Walking the rbtree can be slow
(much slower than a linear list for deep trees), and if the drm_mm has
been purposefully fragmented our search can be trapped for a long, long
time. For non-preemptible kernels, we need to break up long CPU bound
sections by manually checking for cond_resched(); similarly we should
also bail out if we have been told to terminate. (In an ideal world, we
would break for any signal, but we need to trade off having to perform
the search again after ERESTARTSYS, which again may form a trap of
making no forward progress.)

Reported-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200207151720.2812125-1-chris@chris-wilson.co.uk

drm/bridge/mhl.h: Replace zero-length array with flexible-array member

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.

Also, notice that, dynamic memory allocations won't be affected by
this change:

"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200305110011.GA21056@embeddedor

drm/vc4/vc4_drv.h: Replace zero-length array with flexible-array member

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.

Also, notice that, dynamic memory allocations won't be affected by
this change:

"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200305105707.GA19261@embeddedor

drm/gma500/intel_bios.h: Replace zero-length array with flexible-array member

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.

Also, notice that, dynamic memory allocations won't be affected by
this change:

"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200305105306.GA18788@embeddedor

drm/vblank: Fix documentation of VBLANK timestamp helper

Per-CRTC VBLANK information used to be addressed by device and pipe
index. A call drm_crtc_vblank_helper_get_vblank_timestamp_internal()
receives a pointer to the CRTC instead. Fix the documentation.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reported-by: Daniel Vetter <daniel@ffwll.ch>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fixes: f1e2b6371c12 ("drm: Add get_scanout_position() to struct drm_crtc_helper_funcs")
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Link: https://patchwork.freedesktop.org/patch/msgid/20200303073135.10605-1-tzimmermann@suse.de

drm/simple-kms: Fix documentation for drm_simple_encoder_init()

Brings the documentation of drm_simple_encoder_init() in sync with the
function's signature. Also add a paragraph clarifying the management of
the encoder's memory.

v2:
* document memory management

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fixes: 63170ac6f2e8 ("drm/simple-kms: Add drm_simple_encoder_{init,create}()")
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Link: https://patchwork.freedesktop.org/patch/msgid/20200304145312.26458-1-tzimmermann@suse.de

drm/panel: add panel driver for Elida KD35T133 panels

Panel driver for the KD35T133 display from Elida, used for example
in the rk3326-based Odroid Go Advance handheld.

changes in v3:
- add missing return value assignment (Francesco)
- re-sort header includes (Sam)
changes in v2:
- rename dsi_generic_write_seq macro to dsi_dcs_write_seq to honor
  the underlying mipi_dsi_dcs_write (Robin)

Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200229151506.750242-3-heiko@sntech.de

dt-bindings: display: panel: Add binding document for Elida KD35T133

The KD35T133 is a 3.5" 320x480 DSI display used in the RK3326-based
Odroid Go Advance handheld device.

Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200229151506.750242-2-heiko@sntech.de

drm/v3d: Replace wait_for macros to remove use of msleep

The wait_for macro's for Broadcom V3D driver used msleep, which is
inappropriate due to its inaccuracy at low values (minimum wait time
is about 30ms on the Raspberry Pi).  This sleep was triggering in
v3d_clean_caches(), causing us to only be able to dispatch ~33 compute
jobs per second.

This patch replaces the macro with the one from the Intel i915 version
which uses usleep_range to provide more accurate waits.

v2: Split from the vc4 patch so that we can confidently apply to
    stable (by anholt)

Signed-off-by: James Hughes <james.hughes@raspberrypi.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200217153145.13780-1-james.hughes@raspberrypi.com
Link: https://github.com/raspberrypi/linux/issues/3460
Fixes: 57692c94dcbe ("drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+")

drm/vc4: Replace wait_for macros to remove use of msleep

The wait_for macro's for Broadcom VC4 driver used msleep, which is
inappropriate due to its inaccuracy at low values (minimum wait time
is about 30ms on the Raspberry Pi).  This sleep was triggering in
v3d_clean_caches(), causing us to only be able to dispatch ~33 compute
jobs per second.

This patch replaces the macro with the one from the Intel i915 version
which uses usleep_range to provide more accurate waits.

v2: Split from the v3d patch in case this tickles modesetting bugs (by
    anholt)

Signed-off-by: James Hughes <james.hughes@raspberrypi.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200217153145.13780-1-james.hughes@raspberrypi.com

Merge drm/drm-next into drm-misc-next

Daniel needs a few commits from drm-next.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

drm/hdcp: fix DRM_HDCP_2_KSV_COUNT_2_LSBITS

Need to extract the 2 most significant bits from a byte for constructing
the revoked KSV count of the SRM.

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200212102942.26568-3-ramalingam.c@intel.com

drm/hdcp: optimizing the srm handling

As we are not using the sysfs infrastructure anymore, link to it is
removed. And global srm data and mutex to protect it are removed,
with required handling at revocation check function.

v2:
  srm_data is dropped and few more comments are addressed.
v3:
  ptr passing around is fixed with functional testing.
v4:
  fix htmldoc [lkp]

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Suggested-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>
Link: https://patchwork.freedesktop.org/patch/msgid/20200212102942.26568-2-ramalingam.c@intel.com

video: Replace zero-length array with flexible-array member

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.

Also, notice that, dynamic memory allocations won't be affected by
this change:

"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200221160005.GA13552@embeddedor

video: fbdev: radeon: Remove dead code

This is dead code since 3.15 and can be removed if not
going to be useful further.

Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1582042556-21555-1-git-send-email-jrdr.linux@gmail.com

fbdev: simplefb: Platform data shan't include kernel.h

Replace with appropriate types.h.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200204162114.28937-1-andriy.shevchenko@linux.intel.com

matroxfb: add Matrox MGA-G200eW board support

It's needed to support the onboard video on my Spectre-free
Atom S1260 server board.

Signed-off-by: Rich Felker <dalias@libc.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
[b.zolnierkie: patch description fixup]
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200125195506.GA16638@brightrain.aerifal.cx

video: fbdev: atyfb: remove set but not used variable 'mach64RefFreq'

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/video/fbdev/aty/mach64_gx.c: In function ‘aty_var_to_pll_8398’:
drivers/video/fbdev/aty/mach64_gx.c:621:36: warning: variable
‘mach64RefFreq’ set but not used [-Wunused-but-set-variable]

It is never used, and so can be removed.

Signed-off-by: yu kuai <yukuai3@huawei.com>
Cc: zhengbin <zhengbin13@huawei.com>
Cc: yi.zhang <yi.zhang@huawei.com>
[b.zolnierkie: minor patch summary fixup]
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200120063327.43548-1-yukuai3@huawei.com

video: fbdev: kyrofb: remove set but not used variable 'ulScaleRight'

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/video/fbdev/kyro/STG4000OverlayDevice.c: In function
‘SetOverlayViewPort’:
drivers/video/fbdev/kyro/STG4000OverlayDevice.c:334:19: warning:
variable ‘ulScaleRight’ set but not used [-Wunused-but-set-variable]

It is never used, and so can be removed.

Signed-off-by: yu kuai <yukuai3@huawei.com>
Cc: zhengbin <zhengbin13@huawei.com>
Cc: yi.zhang <yi.zhang@huawei.com>
[b.zolnierkie: minor patch summary fixup]
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200119121945.12517-1-yukuai3@huawei.com

video: fbdev: radeonfb: remove set but not used variable 'bytpp'

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/video/fbdev/aty/radeon_base.c: In function
‘radeonfb_set_par’:
drivers/video/fbdev/aty/radeon_base.c:1660:32: warning:
variable ‘bytpp’ set but not used [-Wunused-but-set-variable]

It is never used, and so can be removed.

Signed-off-by: yu kuai <yukuai3@huawei.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: zhengbin <zhengbin13@huawei.com>
Cc: yi.zhang <yi.zhang@huawei.com>
[b.zolnierkie: minor patch summary fixup]
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200119121730.10701-5-yukuai3@huawei.com

video: fbdev: radeonfb: remove set but not used variable '‘cSync’'

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/video/fbdev/aty/radeon_base.c: In function
‘radeonfb_set_par’:
drivers/video/fbdev/aty/radeon_base.c:1653:48: warning: variable
‘cSync’ set but not used [-Wunused-but-set-variable]

It is never used, and so can be removed.

Signed-off-by: yu kuai <yukuai3@huawei.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: zhengbin <zhengbin13@huawei.com>
Cc: yi.zhang <yi.zhang@huawei.com>
[b.zolnierkie: patch summary fixups]
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200119121730.10701-4-yukuai3@huawei.com

video: fbdev: radeonfb: remove set but not used variable 'vSyncPol'

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/video/fbdev/aty/radeon_base.c: In function
‘radeonfb_set_par’:
drivers/video/fbdev/aty/radeon_base.c:1653:38: warning: variable
‘vSyncPol’ set but not used [-Wunused-but-set-variable]

It is never used, and so can be removed.

Signed-off-by: yu kuai <yukuai3@huawei.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: zhengbin <zhengbin13@huawei.com>
Cc: yi.zhang <yi.zhang@huawei.com>
[b.zolnierkie: minor patch summary fixup]
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200119121730.10701-3-yukuai3@huawei.com

video: fbdev: radeonfb: remove set but not used variable 'hSyncPol'

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/video/fbdev/aty/radeon_base.c: In function
‘radeonfb_set_par’:
drivers/video/fbdev/aty/radeon_base.c:1653:6: warning: variable
‘hSyncPol’ set but not used [-Wunused-but-set-variable]

It is never used, and so can be removed.

Signed-off-by: yu kuai <yukuai3@huawei.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: zhengbin <zhengbin13@huawei.com>
Cc: yi.zhang <yi.zhang@huawei.com>
[b.zolnierkie: minor patch summary fixup]
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200119121730.10701-2-yukuai3@huawei.com

video: fbdev: wm8505fb: add COMPILE_TEST support

Add COMPILE_TEST support to wm8505fb driver for better compile
testing coverage.

Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/900c16b3-9306-7d17-f467-0f98bc95416a@samsung.com

video: fbdev: wm8505fb: fix sparse warnings about using incorrect types

Use ->screen_buffer instead of ->screen_base to fix sparse warnings.

[ Please see commit 17a7b0b4d974 ("fb.h: Provide alternate screen_base
  pointer") for details. ]

Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/567cba81-5fec-4d91-f711-c0bdbfe5b513@samsung.com

video: fbdev: w100fb: add COMPILE_TEST support

Add COMPILE_TEST support to w100fb driver for better compile
testing coverage.

Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/a929db5e-d373-7b09-ae2b-efec227f7e85@samsung.com

video: fbdev: w100fb: fix sparse warnings

* Add missing __iomem annotations where needed.
* Make w100fb_probe() static.
* Return NULL pointer (instead of using plain integer) in
  w100_get_xtal_tabl().

Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/d438108a-e569-a14a-a9b1-3fefd88fcadc@samsung.com

video: fbdev: arcfb: add COMPILE_TEST support

Add COMPILE_TEST support to arcfb driver for better compile
testing coverage.

Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/acf2cc2e-614d-f0fb-ce40-cee62bfcde4c@samsung.com

video: fbdev: sh_mobile_lcdcfb: add COMPILE_TEST support

Add COMPILE_TEST support to sh_mobile_lcdcfb driver for better compile
testing coverage.

Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patchwork.freedesktop.org/patch/msgid/d98fea18-b72e-6d0f-33ac-1421738bd12b@samsung.com

video: fbdev: sh_mobile_lcdcfb: fix sparse warnings about using incorrect types

Use ->screen_buffer instead of ->screen_base to fix sparse warnings.

[ Please see commit 17a7b0b4d974 ("fb.h: Provide alternate screen_base
  pointer") for details. ]

Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patchwork.freedesktop.org/patch/msgid/c687dbc5-cf5a-9508-2a61-e757a1a14568@samsung.com

video: fbdev: pxa168fb: remove unnecessary platform_get_irq

commit 640ba2444fa9 ("drivers/video/pxa168fb.c: use devm_ functions")
left behind this, it can be removed.

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Chuhong Yuan <hslester96@gmail.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200117032241.59148-1-yuehaibing@huawei.com

drm/qxl: Use simple encoder

The qxl driver uses an empty implementation for its encoder. Replace
the code with the generic simple encoder.

v4:
* handle errors returned from drm_simple_encoder_init()
v2:
* rebase onto new simple-encoder interface

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20200228081828.18463-5-tzimmermann@suse.de

drm/mgag200: Use simple encoder

The mgag200 driver uses an empty implementation for its encoder. Replace
the code with the generic simple encoder.

v4:
* print error message with drm_err()
v3:
* init pre-allocated encoder with drm_simple_encoder_init()
v2:
* rebase onto new simple-encoder interface

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200228081828.18463-4-tzimmermann@suse.de

drm/ast: Use simple encoder

The ast driver uses an empty implementation for its encoder. Replace
the code with the generic simple encoder.

v2:
* rebase onto new simple-encoder interface

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200228081828.18463-3-tzimmermann@suse.de

drm/simple-kms: Add drm_simple_encoder_{init,create}()

This patch makes the internal encoder implementation of the simple
KMS helpers available to drivers.

These simple-encoder helpers initialize an encoder with an empty
implementation. This covers the requirements of most of the existing
DRM drivers. A call to drm_simple_encoder_create() allocates and
initializes an encoder instance, a call to drm_simple_encoder_init()
initializes a pre-allocated instance.

v3:
* remove drm_simple_encoder_create(); not required yet
* provide more precise documentation
v2:
* move simple encoder to KMS helpers
* remove name argument; simplifies implementation
* don't allocate with devm_ interfaces; unsafe with DRM

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200228081828.18463-2-tzimmermann@suse.de

drm/panel: simple: add panel-dpi support

The panel-dpi compatible is a fallback that
allows the DT to specify the timing.

When matching panel-dpi expect the device tree to include the
timing information for the display-panel.

Background for this change:
There are a lot of panels and new models hits the market very often.
It is a lost cause trying to chase them all and users of new panels
will often find them in situations that the panel they ues are not
supported by the kernel.
On top of this a lot of panels are customized based on customer
specifications.

Including the panel timing in the device tree allows for a simple
way to describe the actual HW and use this description in a generic
way in the kernel.
This allows uses of proprietary panels, or panels which are not
included in the kernel, to specify the timing in the device tree
together with all the other HW descriptions.
And thus, using the device tree it is then easy to add support
for an otherwise unknown panel.

The current support expect panels that do not require any
delays for prepare/enable/disable/unprepare.

Oleksandr Suvorov replied:
I've just tested this patch on Apalis iMX6Q and Colibri iMX7D using
panel settings from the following patch:
https://lore.kernel.org/linux-arm-kernel/20200115123401.2264293-4-oleksandr.suvorov@toradex.com/

It works for me, thanks!

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
Tested-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200216181513.28109-6-sam@ravnborg.org

dt-bindings: display: add data-mapping to panel-dpi

Add data-mapping property that can be used to specify
the media format used for the connection betwwen the
display controller (connector) and the panel.

v2:
  - drop lvds666 (Rob)

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200216181513.28109-5-sam@ravnborg.org

dt-bindings: display: convert panel-dpi to DT schema

With panel-timing converted, now convert the single
remaining .txt user in panel/ of panel-timing to DT schema.

v2:
  - Drop Thierry as maintainer, as this is not a general panel binding
    and I have no acks.
  - Drop requirement for a panel- specific binding - "panel-dpi" is enough
  - Updated example

v3:
  - added yaml document terminator "..."
  - always require a specific binding - panel-dpi (based on feedback from Rob)
  - use "power-supply" for the supply property, and made it mandatory
    "power-supply" is the standard property for panels

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200216181513.28109-4-sam@ravnborg.org