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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200302203452.17977-7-ville.syrjala@linux.intel.comReviewed-by: NHeiko Schocher <hs@denx.de>

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200309133809.32585-1-ville.syrjala@linux.intel.comReviewed-by: NLinus Walleij <linus.walleij@linaro.org>

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200309133644.32385-1-ville.syrjala@linux.intel.comReviewed-by: NLinus Walleij <linus.walleij@linaro.org>

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: NTakashi Iwai <tiwai@suse.de>
Reviewed-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20200311073540.7108-1-tiwai@suse.de

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: NTakashi Iwai <tiwai@suse.de>
Reviewed-by: NHuang Rui <ray.huang@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/357174/Signed-off-by: NChristian König <christian.koenig@amd.com>

The assert sometimes incorrectly triggers when pinned BOs are destroyed.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NHuang Rui <ray.huang@amd.com>
Tested-by: NPierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Link: https://patchwork.freedesktop.org/patch/356737/

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: NHeiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200121224828.4070067-1-heiko@sntech.de

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.htmSigned-off-by: NFabrizio Castro <fabrizio.castro@bp.renesas.com>
Signed-off-by: NLad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1583869169-1006-1-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com

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: cb897542 ("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: NLyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200306234923.547873-3-lyude@redhat.comReviewed-by: NAlex Deucher <alexander.deucher@amd.com>

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: NLyude Paul <lyude@redhat.com>
Fixes: 2f221a5e ("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.comReviewed-by: NAlex Deucher <alexander.deucher@amd.com>

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: NVille Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: NH. Nikolaus Schaller <hns@goldelico.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/e63a0533ad5b5142373437ef758aedbdb716152d.1583826198.git.hns@goldelico.com

The OrtusTech COM43H4M85ULC is a DPI panel, set the connector type
accordingly.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200309184210.10042-1-laurent.pinchart@ideasonboard.com

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
"202b52b7" 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: NAkeem G Abodunrin <akeem.g.abodunrin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200309151156.25040-1-akeem.g.abodunrin@intel.com

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: NNeil Armstrong <narmstrong@baylibre.com>
Reviewed-by: NJernej Škrabec <jernej.skrabec@siol.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-12-narmstrong@baylibre.com

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: NNeil Armstrong <narmstrong@baylibre.com>
Reviewed-by: NJernej Škrabec <jernej.skrabec@siol.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-11-narmstrong@baylibre.com

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: NNeil Armstrong <narmstrong@baylibre.com>
Reviewed-by: NJernej Škrabec <jernej.skrabec@siol.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-10-narmstrong@baylibre.com

To allow using formats from negotiation, stop enforcing input_bus_format
in the private dw-plat-data struct.
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: NJernej Škrabec <jernej.skrabec@siol.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-9-narmstrong@baylibre.com

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: NNeil Armstrong <narmstrong@baylibre.com>
Reviewed-by: NJernej Škrabec <jernej.skrabec@siol.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-8-narmstrong@baylibre.com

Before switching to bridge funcs, make sure drm_display_mode is passed
as const to the venc functions.
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NJernej Škrabec <jernej.skrabec@siol.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-7-narmstrong@baylibre.com

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: NNeil Armstrong <narmstrong@baylibre.com>
Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NJernej Škrabec <jernej.skrabec@siol.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-6-narmstrong@baylibre.com

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: NNeil Armstrong <narmstrong@baylibre.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: NJernej Škrabec <jernej.skrabec@siol.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-5-narmstrong@baylibre.com

Add atomic_duplicate_state/atomic_destroy_state/atomic_reset bridge
funcs to allow setup of atomic bridge state.
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NJernej Škrabec <jernej.skrabec@siol.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-4-narmstrong@baylibre.com

Add the max_bpc property to the dw-hdmi connector to prepare support
for 10, 12 & 16bit output support.
Signed-off-by: NJonas Karlman <jonas@kwiboo.se>
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NJernej Škrabec <jernej.skrabec@siol.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-3-narmstrong@baylibre.com

Configure the correct mtmdsclock for deep colors to prepare support
for 10, 12 & 16bit output.
Signed-off-by: NJonas Karlman <jonas@kwiboo.se>
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Reviewed-by: NJernej Škrabec <jernej.skrabec@siol.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-2-narmstrong@baylibre.com

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: NGurchetan Singh <gurchetansingh@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20200305013212.130640-2-gurchetansingh@chromium.orgSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

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: NGurchetan Singh <gurchetansingh@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20200305013212.130640-1-gurchetansingh@chromium.orgSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

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: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Reviewed-by: NThomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20200307093702.2269-1-chris@chris-wilson.co.uk

This reverts commit 0f9cdd74.

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: NThierry Reding <thierry.reding@gmail.com>
Suggested-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NPeter Rosin <peda@axentia.se>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200305130536.26011-1-peda@axentia.se

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 76497732 ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200305105558.GA19124@embeddedor

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: NDafna Hirschfeld <dafna.hirschfeld@collabora.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20200121154314.3444-1-dafna.hirschfeld@collabora.com

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: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NEmil Velikov <emil.velikov@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200225165835.2394442-1-daniel.vetter@ffwll.ch

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
  "64914da2 drm/fbdev-helper: don't force restores" already fixes
  first one (Daniel)
Signed-off-by: NPankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NEmil Velikov <emil.velikov@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200305120434.111091-8-pankaj.laxminarayan.bharadiya@intel.com

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: NPankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NEmil Velikov <emil.velikov@collabora.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200305120434.111091-7-pankaj.laxminarayan.bharadiya@intel.com

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: NPankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NEmil Velikov <emil.velikov@collabora.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NLyude Paul <lyude@redhat.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200305120434.111091-6-pankaj.laxminarayan.bharadiya@intel.com

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: NPankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Reviewed-by: NEmil Velikov <emil.velikov@collabora.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200305120434.111091-5-pankaj.laxminarayan.bharadiya@intel.com

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: NPankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Reviewed-by: NEmil Velikov <emil.velikov@collabora.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200305120434.111091-4-pankaj.laxminarayan.bharadiya@intel.com

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: NPankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Reviewed-by: NEmil Velikov <emil.velikov@collabora.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200305120434.111091-3-pankaj.laxminarayan.bharadiya@intel.com

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: NPankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Reviewed-by: NEmil Velikov <emil.velikov@collabora.com>
Reviewed-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200305120434.111091-2-pankaj.laxminarayan.bharadiya@intel.com

Commit 52791eee ("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: NSebastian Duda <sebastian.duda@fau.de>
Signed-off-by: NSebastian Duda <sebastian.duda@fau.de>
Signed-off-by: NLukas Bulwahn <lukas.bulwahn@gmail.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/356414/Signed-off-by: NChristian König <christian.koenig@amd.com>

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