I tried to fix this for real, but it's very sprawling and lots of
drivers get this mildly wrong one way or the other.
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Acked-by: NSimon Ser <contact@emersion.fr>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20201211161113.3350061-2-daniel.vetter@ffwll.ch

The DRM core handles legacy gamma-set ioctl by setting GAMMA_LUT and
clearing CTM and DEGAMMA_LUT.

This works fine on HW where we have either:

degamma -> ctm -> gamma -> out

or

ctm -> gamma -> out

However, if the HW has gamma table before ctm, the atomic property
should be DEGAMMA_LUT, and thus we have:

degamma -> ctm -> out

This is fine for userspace which sets gamma table using the properties,
as the userspace can check for the existence of gamma & degamma, but the
legacy gamma-set ioctl does not work.

Change the DRM core to use DEGAMMA_LUT instead of GAMMA_LUT when the
latter is unavailable.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201211114237.213288-3-tomi.valkeinen@ti.com

setcmap_legacy() does not call drm_modeset_unlock_all() in some exits,
add the missed unlocks with goto to fix it.

Fixes: 964c6006 ("drm/fb-helper: separate the fb_setcmap helper into atomic and legacy paths")
Signed-off-by: NChuhong Yuan <hslester96@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20201203144248.418281-1-hslester96@gmail.com

Flushing the fbdev's shadow buffer requires vmap'ing the BO memory, which
in turn requires pinning the BO. While being pinned, the BO cannot be moved
into VRAM for scanout. Consequently, a concurrent modeset operation that
involves the fbdev framebuffer would likely fail.

Resolve this problem be acquiring the modeset lock of the planes that use
the fbdev framebuffer. On non-atomic drivers, also acquire the mode-config
lock. This serializes the flushing of the framebuffer with concurrent
modeset operations.

v2:
	* only acquire struct drm_fb_helper.lock in damage blitter (Daniel,
	  Christian)
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Acked-by: NMaxime Ripard <mripard@kernel.org>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20201120102545.4047-11-tzimmermann@suse.de

Copy the vmap()'ed instance of struct dma_buf_map before modifying it,
in case the implementation of vunmap() depends on the exact address.
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Acked-by: NMaxime Ripard <mripard@kernel.org>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20201120102545.4047-10-tzimmermann@suse.de

If the damage handling fails, restore the damage area. The next invocation
of the damage worker will then perform the update.

v3:
	* Use drm_WARN_ONCE() with an error message to print warning
v2:
	* print a single warning if dirty callback fails (Daniel, Sebastian)
	* update comment
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Acked-by: NMaxime Ripard <mripard@kernel.org>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20201120102545.4047-9-tzimmermann@suse.de

Introduce a separate function for the blit code and its vmap setup. Done
in preparation of additional changes. No functional changes are made.

v3:
	* Use drm_WARN_ONCE() with an error message to print warning
v2:
	* print a single warning if damage blitter fails
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Acked-by: NMaxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20201120102545.4047-8-tzimmermann@suse.de

Flushing the shadow framebuffer and invoking the dirty callback are two
separate operations, so do them separately. The flush operation is paired
with calls to vmap and vunmap. They are not needed for the dirty callback,
which performs its own invocations if necessary.
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Acked-by: NMaxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20201120102545.4047-7-tzimmermann@suse.de

Returning early in the damage worker if no update is required. Makes the
code more readable. No functional changes are being made.

v3:
	* s/dirty/damage in commit message (Sam)
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Acked-by: NMaxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20201120102545.4047-6-tzimmermann@suse.de

The dirty worker handles all damage updates, instead of just calling
the framebuffer's dirty callback. Rename it to damage worker. Also
rename related variables accordingly. No functional changes are made.
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Acked-by: NMaxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20201120102545.4047-5-tzimmermann@suse.de

The fbdev helper's generic probe function establishes a mapping for
framebuffers without shadow buffer. The clean-up function did not unmap
the buffer object. Add the unmap operation.

As fbdev devices are usally released during system shutdown, this has
not been a problem in practice.
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Acked-by: NMaxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20201120102545.4047-3-tzimmermann@suse.de

If fbdev uses a shadow framebuffer, call the damage handler. Otherwise
the update might not make it to the screen.

v2:
	* mark virtual screen as dirty (Ville)
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Fixes: 222ec45f ("drm/fb_helper: Support framebuffers in I/O memory")
Acked-by: NMaxime Ripard <mripard@kernel.org>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
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: Gerd Hoffmann <kraxel@redhat.com>
Cc: dri-devel@lists.freedesktop.org
Cc: virtualization@lists.linux-foundation.org
Link: https://patchwork.freedesktop.org/patch/msgid/20201120102545.4047-2-tzimmermann@suse.de

On arm32:

    drivers/gpu/drm/drm_fb_helper.c: In function ‘fb_read_screen_base’:
    include/linux/minmax.h:18:28: warning: comparison of distinct pointer types lacks a cast
    ...
    drivers/gpu/drm/drm_fb_helper.c:2041:22: note: in expansion of macro ‘min’
     2041 |  size_t alloc_size = min(count, PAGE_SIZE);
	  |                      ^~~
    drivers/gpu/drm/drm_fb_helper.c: In function ‘fb_write_screen_base’:
    include/linux/minmax.h:18:28: warning: comparison of distinct pointer types lacks a cast
    ...
    drivers/gpu/drm/drm_fb_helper.c:2115:22: note: in expansion of macro ‘min’
     2115 |  size_t alloc_size = min(count, PAGE_SIZE);
	  |                      ^~~

Indeed, on 32-bit size_t is "unsigned int", not "unsigned long".

Fixes: 222ec45f ("drm/fb_helper: Support framebuffers in I/O memory")
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20201110090119.2667326-1-geert+renesas@glider.be

At least sparc64 requires I/O-specific access to framebuffers. This
patch updates the fbdev console accordingly.

For drivers with direct access to the framebuffer memory, the callback
functions in struct fb_ops test for the type of memory and call the rsp
fb_sys_ of fb_cfb_ functions. Read and write operations are implemented
internally by DRM's fbdev helper.

For drivers that employ a shadow buffer, fbdev's blit function retrieves
the framebuffer address as struct dma_buf_map, and uses dma_buf_map
interfaces to access the buffer.

The bochs driver on sparc64 uses a workaround to flag the framebuffer as
I/O memory and avoid a HW exception. With the introduction of struct
dma_buf_map, this is not required any longer. The patch removes the rsp
code from both, bochs and fbdev.

v7:
	* use min_t(size_t,) (kernel test robot)
	* return the number of bytes read/written, if any (fbdev testcase)
v5:
	* implement fb_read/fb_write internally (Daniel, Sam)
v4:
	* move dma_buf_map changes into separate patch (Daniel)
	* TODO list: comment on fbdev updates (Daniel)
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Tested-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20201103093015.1063-11-tzimmermann@suse.de

Kernel DRM clients now store their framebuffer address in an instance
of struct dma_buf_map. Depending on the buffer's location, the address
refers to system or I/O memory.

Callers of drm_client_buffer_vmap() receive a copy of the value in
the call's supplied arguments. It can be accessed and modified with
dma_buf_map interfaces.

v6:
	* don't call page_to_phys() on framebuffers in I/O memory;
	  warn instead (Daniel)
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20201103093015.1063-9-tzimmermann@suse.de

We didn't take the kernel_fb_helper_lock mutex, which protects that
code. While at it, simplify the code
- inline the function (originally shared with kgdb I think)
- drop the error tracking and all the complications
- drop the pointless early out, it served nothing
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20201007133036.1541639-1-daniel.vetter@ffwll.ch

All slots in sysrq_key_table[] are either used, reserved or at least
commented with their intended use. This patch adds capital letter versions
available, which means adding 26 more entries.

For already existing SysRq operations the user presses Alt-SysRq-<key>, and
for the newly added ones Alt-Shift-SysRq-<key>.
Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@collabora.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://lore.kernel.org/r/20200818112825.6445-2-andrzej.p@collabora.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Recent kernels have been reported to panic using the bochs_drm
framebuffer under qemu-system-sparc64 which was bisected to
commit 7a0483ac ("drm/bochs: switch to generic drm fbdev emulation").

The backtrace indicates that the shadow framebuffer copy in
drm_fb_helper_dirty_blit_real() is trying to access the real
framebuffer using a virtual address rather than use an IO access
typically implemented using a physical (ASI_PHYS) access on SPARC.

The fix is to replace the memcpy with memcpy_toio() from io.h.

memcpy_toio() uses writeb() where the original fbdev code
used sbus_memcpy_toio(). The latter uses sbus_writeb().

The difference between writeb() and sbus_memcpy_toio() is
that writeb() writes bytes in little-endian, where sbus_writeb() writes
bytes in big-endian. As endian does not matter for byte writes they are
the same. So we can safely use memcpy_toio() here.

Note that this only fixes bochs, in general fbdev helpers still have
issues with mixing up system memory and __iomem space. Fixing that will
require a lot more work.

v3:
  - Improved changelog (Daniel)
  - Added FIXME to fbdev_use_iomem (Daniel)

v2:
  - Added missing __iomem cast (kernel test robot)
  - Made changelog readable and fix typos (Mark)
  - Add flag to select iomem - and set it in the bochs driver
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Reported-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reported-by: Nkernel test robot <lkp@intel.com>
Tested-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: sparclinux@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20200709193016.291267-1-sam@ravnborg.org
Link: https://patchwork.freedesktop.org/patch/msgid/20200725191012.GA434957@ravnborg.org

Change logging information from dev_info() to drm_info().
Signed-off-by: NSuraj Upadhyay <usuraj35@gmail.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/0d37c7a614eb0885f0f0bed18e48a4d26b345a8e.1594136880.git.usuraj35@gmail.com

In the past we had a pile of hacks to orchestrate access between fbdev
emulation and native kms clients. We've tried to streamline this, by
always preferring the kms side above fbdev calls when a drm master
exists, because drm master controls access to the display resources.

Unfortunately this breaks existing userspace, specifically Xorg. When
exiting Xorg first restores the console to text mode using the KDSET
ioctl on the vt. This does nothing, because a drm master is still
around. Then it drops the drm master status, which again does nothing,
because logind is keeping additional drm fd open to be able to
orchestrate vt switches. In the past this is the point where fbdev was
restored, as part of the ->lastclose hook on the drm side.

Now to fix this regression we don't want to go back to letting fbdev
restore things whenever it feels like, or to the pile of hacks we've
had before. Instead try and go with a minimal exception to make the
KDSET case work again, and nothing else.

This means that if userspace does a KDSET call when switching between
graphical compositors, there will be some flickering with fbcon
showing up for a bit. But a) that's not a regression and b) userspace
can fix it by improving the vt switching dance - logind should have
all the information it needs.

While pondering all this I'm also wondering wheter we should have a
SWITCH_MASTER ioctl to allow race-free master status handover. But
that's for another day.

v2: Somehow forgot to cc all the fbdev people.

v3: Fix typo Alex spotted.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=208179
Cc: shlomo@fastmail.com
Reported-and-Tested-by: shlomo@fastmail.com
Cc: Michel Dänzer <michel@daenzer.net>
Fixes: 64914da2 ("drm/fbdev-helper: don't force restores")
Cc: Noralf Trønnes <noralf@tronnes.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Daniel Vetter <daniel.vetter@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
Cc: <stable@vger.kernel.org> # v5.7+
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Nathan Chancellor <natechancellor@gmail.com>
Cc: Qiujun Huang <hqjagain@gmail.com>
Cc: Peter Rosin <peda@axentia.se>
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200624092910.3280448-1-daniel.vetter@ffwll.ch

With earlier commits, the API no longer discards the const-ness of the
sysrq_key_op. As such we can add the notation.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: linux-kernel@vger.kernel.org
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>
Link: https://lore.kernel.org/r/20200513214351.2138580-8-emil.l.velikov@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Generic fbdev emulation is a DRM client. Drivers should invoke the
setup function, but not depend on its success. Hence remove the return
value.

v3:
	* document stricter requirements for call sequence
v2:
	* warn if fbdev device has not been registered yet
	* document the new behavior
	* convert the existing warning to the new dev_ interface
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Acked-by: NGerd Hoffmann <kraxel@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200408082641.590-11-tzimmermann@suse.de

Currently drivers using drm_fbdev_generic_setup() end up with a single
empty aperture in their fb_info struct.

Not having the proper info in the apertures list causes
register_framebuffer to not remove conflicting framebuffers,
which some drivers currently workaround by manually calling
drm_fb_helper_remove_conflicting_pci_framebuffers().

Add a TODO as a reminder that we need to fix this.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200326151009.102377-1-hdegoede@redhat.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

Plus extend the kerneldoc a bit to explain how this should be used.
With the previous patch to drop the force restore the main user of
this function is not emphasis on the "I hold the internal master lock
already" aspect, so rename the function to match.

Suggested by Noralf.

Cc: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Tested-by: NThomas Zimmermann <tzimmermann@suse.de>
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200204150146.2006481-4-daniel.vetter@ffwll.ch

Instead check for master status, in case we've raced.

This is the last exception to the general rule that we restore fbcon
only when there's no master active. Compositors are supposed to drop
their master status before they switch to a different console back to
text mode (or just switch to text mode directly, without a vt switch).

This is known to break some subtests of kms_fbcon_fbt in igt, but they're
just wrong - it does a graphics/text mode switch for the vt without
updating the master status.

Also add a comment to the drm_client->restore hook that this is expected
going forward from all clients (there's currently just one).

v2: Also drop the force in pan_display

v3: Restore the _force to pan_display, this actually means _locked in that
path. Spotted by Noralf.

Cc: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Tested-by: NThomas Zimmermann <tzimmermann@suse.de>
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200204150146.2006481-3-daniel.vetter@ffwll.ch

When userspace requests a video mode parameter value that is not
supported, frame buffer device drivers should round it up to a supported
value, if possible, instead of just rejecting it.  This allows
applications to quickly scan for supported video modes.

Currently this rule is not followed for the number of bits per pixel,
causing e.g. "fbset -depth N" to fail, if N is smaller than the current
number of bits per pixel.

Fix this by returning an error only if bits per pixel is too large, and
setting it to the current value otherwise.

See also Documentation/fb/framebuffer.rst, Section 2 (Programmer's View
of /dev/fb*").

Fixes: 865afb11 ("drm/fb-helper: reject any changes to the fbdev")
Cc: stable@vger.kernel.org
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20191230132734.4538-1-geert+renesas@glider.be

DRM Fb driver expects multiple CRTCs if it sees connector->has_tile
is set, but we need to handle tile support and look for multiple CRTCs
only for the modes that match the tile size. The other modes should
be able to be displayed without tile support or uisng single CRTC.

This patch adds the check to match the tile size with requested mode
to handle the tile support.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Reviewed-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191211212433.18185-1-manasi.d.navare@intel.com

Prefer drm_dbg_kms(), drm_info(), and drm_err() over all other
logging. This is about KMS so switch to the KMS category while at it.
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191210123050.8799-3-jani.nikula@intel.com

Now that the fbops member of struct fb_info is const, we can start
making the ops const as well.

Cc: dri-devel@lists.freedesktop.org
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/59b43629ac60031c5bbf961d8c49695019bc9c6f.1575390740.git.jani.nikula@intel.com

Deferred IO now preserves the fb_ops.

v2: Remove the no-op vfree, drop a local var  (Noralf)

Cc: Noralf Trønnes <noralf@tronnes.org>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1eae0b23d4724d5702b886b6a061ec8219eb9284.1575022735.git.jani.nikula@intel.com

There are no callers of drm_fb_helper_unlink_fbi() left. Remove the
function.
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191114125106.28347-3-tzimmermann@suse.de

Not sure we don't yet have this as a patch somewhere ...

Motivation is that the automatic lifetime management of the generic fbdev
code is quite tricky, and it'll get even more tricky. Allowing drivers
to just use the fb_probe looks like a recipe for disaster.

Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Noralf Trønnes <noralf@tronnes.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20191112175048.1581-1-daniel.vetter@ffwll.ch

Both functions are unused and can be removed. Drivers should use
drm_fbdev_generic_setup() instead.
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191106124727.11641-3-tzimmermann@suse.de

There are no users of drm_fb_helper_defio_init(), so we can remove
it. The documentation around defio support is a bit misleading and
should mention compatibility issues with SHMEM helpers. Clarify this.
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191025092759.13069-2-tzimmermann@suse.de

Sparse complains:
drivers/gpu/drm/drm_fb_helper.c:2409:12: warning: symbol 'drm_fb_helper_modinit' was not declared. Should it be static?

Include the header with the correct prototype.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190710125143.9965-1-ville.syrjala@linux.intel.comReviewed-by: NSean Paul <sean@poorly.run>

Generic framebuffer emulation uses a shadow buffer for framebuffers with
dirty() function. If drivers want to use the shadow FB without such a
function, they can now set prefer_shadow or prefer_shadow_fbdev in their
mode_config structures. The former flag is exported to userspace, the
latter flag is fbdev-only.

v3:
	* only schedule dirty worker if fbdev uses shadow fb
	* test shadow fb settings with boolean operators
	* use bool for struct drm_mode_config.prefer_shadow_fbdev
	* fix documentation comments
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Tested-by: NNoralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/315834/Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

This patch changes DRM clients to not map the buffer by default. The
buffer, like any buffer object, should be mapped and unmapped when
needed.

An unmapped buffer object can be evicted to system memory and does
not consume video ram until displayed. This allows to use generic fbdev
emulation with drivers for low-memory devices, such as ast and mgag200.

This change affects the generic framebuffer console. HW-based consoles
map their console buffer once and keep it mapped. Userspace can mmap this
buffer into its address space. The shadow-buffered framebuffer console
only needs the buffer object to be mapped during updates. While not being
updated from the shadow buffer, the buffer object can remain unmapped.
Userspace will always mmap the shadow buffer.

v2:
	* change DRM client to not map buffer by default
	* manually map client buffer for fbdev with HW framebuffer
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/315830/Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Generic framebuffer emulation uses a shadow buffer for framebuffers with
dirty() function. If drivers want to use the shadow FB without such a
function, they can now set prefer_shadow or prefer_shadow_fbdev in their
mode_config structures. The former flag is exported to userspace, the
latter flag is fbdev-only.

v3:
	* only schedule dirty worker if fbdev uses shadow fb
	* test shadow fb settings with boolean operators
	* use bool for struct drm_mode_config.prefer_shadow_fbdev
	* fix documentation comments
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Tested-by: NNoralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/315834/

This patch changes DRM clients to not map the buffer by default. The
buffer, like any buffer object, should be mapped and unmapped when
needed.

An unmapped buffer object can be evicted to system memory and does
not consume video ram until displayed. This allows to use generic fbdev
emulation with drivers for low-memory devices, such as ast and mgag200.

This change affects the generic framebuffer console. HW-based consoles
map their console buffer once and keep it mapped. Userspace can mmap this
buffer into its address space. The shadow-buffered framebuffer console
only needs the buffer object to be mapped during updates. While not being
updated from the shadow buffer, the buffer object can remain unmapped.
Userspace will always mmap the shadow buffer.

v2:
	* change DRM client to not map buffer by default
	* manually map client buffer for fbdev with HW framebuffer
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/315830/