Add a variant of drm_mode_copy() that explicitly clears out
the list head of the destination mode. Helpful to guarantee
we don't have stack garbage left in there for on-stack modes.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220218100403.7028-2-ville.syrjala@linux.intel.comReviewed-by: NAndrzej Hajda <andrzej.hajda@intel.com>
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>

Initial version of guest backed objects in the host had some performance
issues that made using surface-dma's instead of direct copies faster.
Surface dma's force a migration to vram which at best is slow and at
worst is impossible (e.g. on svga3 where there's not enough vram
to migrate fb's to it).

Slowly migrate away from surface dma's to direct copies by limiting
their usage to systems with more than 32MB of vram.
Signed-off-by: NZack Rusin <zackr@vmware.com>
Reviewed-by: NMaaz Mombasawala <mombasawalam@vmware.com>
Reviewed-by: NMartin Krastev <krastevm@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220302152426.885214-9-zack@kde.org

SVGAv3 deprecates legacy interrupts and adds support for MSI/MSI-X. With
MSI the driver visible side remains largely unchanged but with MSI-X
each interrupt gets delivered on its own vector.

Add support for MSI/MSI-X while preserving the old functionality for
SVGAv2. Code between the SVGAv2 and SVGAv3 is exactly the same, only
the number of available vectors changes, in particular between legacy
and MSI-X interrupts.
Signed-off-by: NZack Rusin <zackr@vmware.com>
Reviewed-by: NMartin Krastev <krastevm@vmware.com>
Reviewed-by: NMaaz Mombasawala <mombasawalam@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220307162412.1183049-1-zack@kde.org

Transition to drm_mode_fb_cmd2 from drm_mode_fb_cmd left the structure
unitialized. drm_mode_fb_cmd2 adds a few additional members, e.g. flags
and modifiers which were never initialized. Garbage in those members
can cause random failures during the bringup of the fbcon.

Initializing the structure fixes random blank screens after bootup due
to flags/modifiers mismatches during the fbcon bring up.

Fixes: dabdcdc9 ("drm/vmwgfx: Switch to mode_cmd2")
Signed-off-by: NZack Rusin <zackr@vmware.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: <stable@vger.kernel.org> # v4.10+
Reviewed-by: NMartin Krastev <krastevm@vmware.com>
Reviewed-by: NMaaz Mombasawala <mombasawalam@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220302152426.885214-7-zack@kde.org

Mesa3D loaders require knowledge of the devices PCI id. SVGAv2 and v3
have different PCI id's, but the same driver is used to handle them both.
To allow Mesa3D svga driver to be loaded automatically for both SVGAv2
and SVGAv3 make the kernel return the PCI id of the currently running
device.
Signed-off-by: NZack Rusin <zackr@vmware.com>
Reviewed-by: NMartin Krastev <krastevm@vmware.com>
Reviewed-by: NMaaz Mombasawala <mombasawalam@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220302152426.885214-6-zack@kde.org

Port of the vmwgfx to SVGAv3 lacked support for fencing. SVGAv3 removed
FIFO's and replaced them with command buffers and extra registers.
The initial version of SVGAv3 lacked support for most advanced features
(e.g. 3D) which made fences unnecessary. That is no longer the case,
especially as 3D support is being turned on.

Switch from FIFO commands and capabilities to command buffers and extra
registers to enable fences on SVGAv3.

Fixes: 2cd80dbd ("drm/vmwgfx: Add basic support for SVGA3")
Signed-off-by: NZack Rusin <zackr@vmware.com>
Reviewed-by: NMartin Krastev <krastevm@vmware.com>
Reviewed-by: NMaaz Mombasawala <mombasawalam@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220302152426.885214-5-zack@kde.org

Capabilities were logged at the end of initialization so any early errors
would make them not appear in the logs. Which is also when they're needed
the most.
Print the the capabilities right after fetching them, before the init
code starts using them to make sure they always show up in the logs.
Signed-off-by: NZack Rusin <zackr@vmware.com>
Reviewed-by: NMartin Krastev <krastevm@vmware.com>
Reviewed-by: NMaaz Mombasawala <mombasawalam@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220302152426.885214-4-zack@kde.org

The results of the legacy display unit initialization were being silently
ignored. Unifying the selection of number of display units based
on whether the underlying device supports multimon makes it easier
to add error checking to all paths.

This makes the driver report the errors in ldu initialization paths
and try to recover from them.
Signed-off-by: NZack Rusin <zackr@vmware.com>
Reviewed-by: NMartin Krastev <krastevm@vmware.com>
Reviewed-by: NMaaz Mombasawala <mombasawalam@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220302152426.885214-3-zack@kde.org

* Add support for CursorMob
* Add support for CursorBypass 4
* Refactor vmw_du_cursor_plane_atomic_update to be kms-helper-atomic
  -- move BO mappings to vmw_du_cursor_plane_prepare_fb
  -- move BO unmappings to vmw_du_cursor_plane_cleanup_fb

Cursor mobs are a new svga feature which enables support for large
cursors, e.g. large accessibility cursor on platforms with vmwgfx. It
also cleans up the cursor code and makes it more uniform with the rest
of modern guest backed objects support.
Signed-off-by: NMartin Krastev <krastevm@vmware.com>
Reviewed-by: NZack Rusin <zackr@vmware.com>
Reviewed-by: NMaaz Mombasawala <mombasawalam@vmware.com>
Signed-off-by: NZack Rusin <zackr@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220302152426.885214-2-zack@kde.org

DP AUX transactions can consist of many short operations. There's no
need to power things up/down in short intervals.

I pick an arbitrary 100ms; for the systems I'm testing (Rockchip
RK3399), runtime-PM transitions only take a few microseconds.
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220301181107.v4.2.I48b18ab197c9b649d376cf8cfd934e59d338f86d@changeid

If the display is not enable()d, then we aren't holding a runtime PM
reference here. Thus, it's easy to accidentally cause a hang, if user
space is poking around at /dev/drm_dp_aux0 at the "wrong" time.

Let's get a runtime PM reference, and check that we "see" the panel.
Don't force any panel power-up, etc., because that can be intrusive, and
that's not what other drivers do (see
drivers/gpu/drm/bridge/ti-sn65dsi86.c and
drivers/gpu/drm/bridge/parade-ps8640.c.)

Fixes: 0d97ad03 ("drm/bridge: analogix_dp: Remove duplicated code")
Cc: <stable@vger.kernel.org>
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220301181107.v4.1.I773a08785666ebb236917b0c8e6c05e3de471e75@changeid

Though the parade bridge chip is a little bit of a black box, I'm at
least interested in hearing about changes to the driver since this
bridge chip is used on some Chromebooks that I'm involved with.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NRobert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220308110615.3.I04f99fbcc14b8c09610b4b18f0696c992a44d2b7@changeid

I've spent quite a bit of time poking at this driver and it's used on
several Chromebooks I'm involved with. I'd like to get notified about
patches. Add myself as a reviewer. It's expected that changes will
still be landed through drm-misc as they always have been.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NRobert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220308110615.2.I4485769d5b25a8096508e839b8fea12ce7b836d3@changeid

The bindings for bridge chips should also get the same maintainers
entry so the right people get notified about bindings changes.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NNeil Armstrong <narmstrong@baylibre.com>
Acked-by: NRobert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220308110615.1.I1f1b10daf7361feb6705f789deb680b8d7720de9@changeid

The function "drm_of_find_panel_or_bridge" has been deprecated in
favor of "devm_drm_of_get_bridge".

Switch to the new function and reduce boilerplate.
Signed-off-by: NJosé Expósito <jose.exposito89@gmail.com>
Reviewed-by: NMaxime Ripard <maxime@cerno.tech>
Signed-off-by: NRobert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220221072835.10032-1-jose.exposito89@gmail.com

Currently the ssd130x driver only sets the segment remap setting when
the device tree requests it; it however does not clear the setting if
it is not requested. This leads to the setting incorrectly persisting
if the hardware is always on and has no reset GPIO wired. This might
happen when a developer is trying to find the correct settings for an
unknown module, and cause the developer to get confused because the
settings from the device tree are not consistently applied.

Make the driver apply the segment remap setting consistently, setting
the value correctly based on the device tree setting. This also makes
this setting's behavior consistent with the other settings, which are
always applied.

Fixes: a61732e8 ("drm: Add driver for Solomon SSD130x OLED displays")
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Acked-by: NJavier Martinez Canillas <javierm@redhat.com>
Signed-off-by: NJavier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220308160758.26060-2-wens@kernel.org

The SSD130x's command to toggle COM scan direction uses bit 3 and only
bit 3 to set the direction of the scanout. The driver has an incorrect
GENMASK(3, 2), causing the setting to be set on bit 2, rendering it
ineffective.

Fix the mask to only bit 3, so that the requested setting is applied
correctly.

Fixes: a61732e8 ("drm: Add driver for Solomon SSD130x OLED displays")
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Acked-by: NJavier Martinez Canillas <javierm@redhat.com>
Tested-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NJavier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220308160758.26060-1-wens@kernel.org

The function "drm_of_find_panel_or_bridge" has been deprecated in
favor of "devm_drm_of_get_bridge".

Switch to the new function and reduce boilerplate.
Signed-off-by: NJosé Expósito <jose.exposito89@gmail.com>
Reviewed-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: NRobert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220228183955.25508-1-jose.exposito89@gmail.com

Clang static analysis reports this issue
anx7625.c:876:13: warning: The left operand of '&' is
  a garbage value
  if (!(bcap & 0xOA01)) {
        ~~~~ ^

bcap is only set by a successful call to
anx7625_aux_trans().  So check.

Fixes: cd1637c7 ("drm/bridge: anx7625: add HDCP support")
Signed-off-by: NTom Rix <trix@redhat.com>
Fixes: adca62ec ("drm/bridge: anx7625: Support reading edid through aux channel")
Signed-off-by: NRobert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220303201943.501746-1-trix@redhat.comReviewed-by: NRobert Foss <robert.foss@linaro.org>

This device requires the packets on lanes aligned at the end to fix
screen shift or scroll.
Signed-off-by: NJitao Shi <jitao.shi@mediatek.com>
Signed-off-by: NRex-BC Chen <rex-bc.chen@mediatek.com>
Acked-by: NAngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: NXin Ji <xji@analogixsemi.com>
Reviewed-by: NAndrzej Hajda <andrzej.hajda@intel.com>
Signed-off-by: NRobert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220309073637.3591-4-rex-bc.chen@mediatek.com

Some DSI RX devices (for example, anx7625) require last alignment of
packets on all lanes after each row of data is sent.
Otherwise, there will be some issues of shift or scroll for screen.

Take horizontal_sync_active_byte for a example,
we roundup the HSA packet data to lane number, and the subtraction of 2
is the packet data value added by the roundup operation, making the
long packets are integer multiples of lane number.
This value (2) varies with the lane number, and that is the reason we
do this operation when the lane number is 4.

In the previous operation of function "mtk_dsi_config_vdo_timing",
the length of HSA and HFP data packets has been adjusted to an
integration multiple of lane number.
Since the number of RGB data packets cannot be guaranteed to be an
integer multiple of lane number, we modify the data packet length of
HBP so that the number of HBP + RGB is equal to the lane number.
So after sending a line of data (HSA + HBP + RGB + HFP), the data
lanes are aligned.
Signed-off-by: NJitao Shi <jitao.shi@mediatek.com>
Signed-off-by: NRex-BC Chen <rex-bc.chen@mediatek.com>
Signed-off-by: NXinlei Lee <xinlei.lee@mediatek.com>
Reviewed-by: NAndrzej Hajda <andrzej.hajda@intel.com>
Reviewed-by: NAngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Acked-by: NChun-Kuang Hu <chunkuang.hu@kernel.org>
Signed-off-by: NRobert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220309073637.3591-3-rex-bc.chen@mediatek.com

Since a HS transmission is composed of an arbitrary number
of bytes that may not be an integer multiple of lanes, some
lanes may run out of data before others.
(Defined in 6.1.3 of mipi_DSI_specification_v.01-02-00)

However, for some DSI RX devices (for example, anx7625),
there is a limitation that packet number should be the same
on all DSI lanes. In other words, they need to end a HS at
the same time.

Because this limitation is for some specific DSI RX devices,
it is more reasonable to put the enable control in these
DSI RX drivers. If DSI TX driver knows the information,
they can adjust the setting for this situation.
Signed-off-by: NJitao Shi <jitao.shi@mediatek.com>
Signed-off-by: NRex-BC Chen <rex-bc.chen@mediatek.com>
Acked-by: NAngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: NAndrzej Hajda <andrzej.hajda@intel.com>
Signed-off-by: NRobert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220309073637.3591-2-rex-bc.chen@mediatek.com

The datasheet lists the minimum Serial clock cycle (Write) as 66ns which is
15MHz. Mostly it can do much better than that and is in fact often run at
32MHz. With a clever driver that runs configuration commands at a low speed
and only the pixel data at the maximum speed the configuration can't be
messed up by transfer errors and the speed is only limited by the amount of
pixel glitches that one is able to tolerate.
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Acked-by: NRob Herring <robh@kernel.org>
Acked-by: NDavid Lechner <david@lechnology.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124150757.17929-4-noralf@tronnes.org

There are other ways than using a gpio to reset the controller so make
this property optional.
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Acked-by: NRob Herring <robh@kernel.org>
Acked-by: NDavid Lechner <david@lechnology.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124150757.17929-3-noralf@tronnes.org

The backlight property was lost during conversion to yaml in commit
abdd9e37 ("dt-bindings: display: sitronix,st7735r: Convert to DT schema").
Put it back.

Fixes: abdd9e37 ("dt-bindings: display: sitronix,st7735r: Convert to DT schema")
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Acked-by: NRob Herring <robh@kernel.org>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NDavid Lechner <david@lechnology.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124150757.17929-2-noralf@tronnes.org

Make sure we pull in the kernel-doc for this.
Reported-by: NDaniel Vetter <daniel@ffwll.ch>
Signed-off-by: NMatthew Auld <matthew.auld@intel.com>
Cc: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220208151228.344997-1-matthew.auld@intel.comSigned-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>

The function "drm_of_find_panel_or_bridge" has been deprecated in
favor of "devm_drm_of_get_bridge".

Switch to the new function and reduce boilerplate.
Signed-off-by: NJosé Expósito <jose.exposito89@gmail.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220228183724.25030-1-jose.exposito89@gmail.com

The function "drm_of_find_panel_or_bridge" has been deprecated in
favor of "devm_drm_of_get_bridge".

Switch to the new function and reduce boilerplate.
Signed-off-by: NJosé Expósito <jose.exposito89@gmail.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220228183537.24600-1-jose.exposito89@gmail.com

The function "drm_of_find_panel_or_bridge" has been deprecated in
favor of "devm_drm_of_get_bridge".

Switch to the new function and reduce boilerplate.
Signed-off-by: NJosé Expósito <jose.exposito89@gmail.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220228183342.24129-1-jose.exposito89@gmail.com

The function "drm_of_find_panel_or_bridge" has been deprecated in
favor of "devm_drm_of_get_bridge".

Switch to the new function and reduce boilerplate.
Signed-off-by: NJosé Expósito <jose.exposito89@gmail.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220228183131.23494-1-jose.exposito89@gmail.com

The function "drm_of_find_panel_or_bridge" has been deprecated in
favor of "devm_drm_of_get_bridge".

Switch to the new function and reduce boilerplate.
Signed-off-by: NJosé Expósito <jose.exposito89@gmail.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220228182904.22982-1-jose.exposito89@gmail.com

The function "drm_of_find_panel_or_bridge" has been deprecated in
favor of "devm_drm_of_get_bridge".

Switch to the new function and reduce boilerplate.
Signed-off-by: NJosé Expósito <jose.exposito89@gmail.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220228182600.22463-1-jose.exposito89@gmail.com

The komeda KMS driver will call drm_plane_create_color_properties() with
a default encoding and range values of BT601 and Limited Range,
respectively.

Since the initial value wasn't carried over in the state, the driver had
to set it again in komeda_plane_reset(). However, the helpers have been
adjusted to set it properly at reset, so this is not needed anymore.

Cc: Brian Starkey <brian.starkey@arm.com>
Cc: "James (Qian) Wang" <james.qian.wang@arm.com>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Mihail Atanassov <mihail.atanassov@arm.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Acked-by: NLiviu Dudau <liviu.dudau@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220221095918.18763-20-maxime@cerno.tech

The komeda KMS driver will call drm_plane_create_zpos_property() with an
init value of the plane index.

Since the initial value wasn't carried over in the state, the driver had
to set it again in komeda_plane_reset(). However, the helpers have been
adjusted to set it properly at reset, so this is not needed anymore.

Cc: Brian Starkey <brian.starkey@arm.com>
Cc: "James (Qian) Wang" <james.qian.wang@arm.com>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Mihail Atanassov <mihail.atanassov@arm.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Acked-by: NLiviu Dudau <liviu.dudau@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220221095918.18763-10-maxime@cerno.tech

komeda_plane_reset() does the state initialisation by copying a lot of
the code found in the __drm_atomic_helper_plane_reset(). Let's switch to
that helper and reduce the boilerplate.

Cc: Brian Starkey <brian.starkey@arm.com>
Cc: "James (Qian) Wang" <james.qian.wang@arm.com>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Mihail Atanassov <mihail.atanassov@arm.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Acked-by: NLiviu Dudau <liviu.dudau@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220221095918.18763-2-maxime@cerno.tech

Fix the following coccicheck warning:
./drivers/gpu/drm/omapdrm/omap_overlay.c:89:22-25: ERROR: r_ovl is NULL
but dereferenced.

Here should be ovl->idx rather than r_ovl->idx.

Fixes: e02b5cc9 ("drm/omap: Add a 'right overlay' to plane state")
Signed-off-by: NWan Jiabing <wanjiabing@vivo.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220307095612.409090-1-wanjiabing@vivo.com

Set the error code to -ENOMEM if drm_random_order() fails.

Fixes: e6ff5ef8 ("drm/selftests: add drm buddy smoke testcase")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NArunpravin <Arunpravin.PaneerSelvam@amd.com>
Signed-off-by: NChristian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220307125458.GA16710@kili

It does not make sense to have a comma after a sentinel, as any new
elements must be added before the sentinel.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Acked-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/298f0644275d7d0b4aa3ee7143756a2431a4900c.1646311443.git.geert+renesas@glider.be

efifb is the only user of efifb_setup_from_dmi which is provided by
sysfb which is selected by efifb. That makes the stub redundant.
Signed-off-by: NMichal Suchanek <msuchanek@suse.de>
Reviewed-by: NJavier Martinez Canillas <javierm@redhat.com>
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/7416c439d68e9e96068ea5c77e05c99c7df41750.1645822213.git.msuchanek@suse.de

Since switch to simplefb/simpledrm VESA graphic mode selection with vga=
kernel parameter is no longer available with legacy BIOS.

The x86 realmode boot code enables the VESA graphic modes when option
FB_BOOT_VESA_SUPPORT is enabled.

This option is selected by vesafb but not simplefb/simpledrm.

To enable use of VESA modes with simplefb in legacy BIOS boot mode drop
dependency of BOOT_VESA_SUPPORT on FB, also drop the FB_ prefix. Select
the option from sysfb rather than the drivers that depend on it.

The BOOT_VESA_SUPPORT is not specific to framebuffer but rather to x86
platform, move it from fbdev to x86 Kconfig.

Fixes: e3263ab3 ("x86: provide platform-devices for boot-framebuffers")
Signed-off-by: NMichal Suchanek <msuchanek@suse.de>
Reviewed-by: NJavier Martinez Canillas <javierm@redhat.com>
Acked-by: NBorislav Petkov <bp@suse.de>
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/948c39940a4e99f5b43bdbcbe537faae71a43e1d.1645822213.git.msuchanek@suse.de