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/

The drm_client_panel_rotation function has been used so far to set the
default rotation based on the panel orientation.

However, we can have more sources of information to make that decision,
starting with the command line that we will introduce later in this series.

Change the name to remove the panel mention.
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/8cb0f0d9569d41685bbf30a1538da6578cd2769b.1560783090.git-series.maxime.ripard@bootlin.com

Acquiring drm_client_dev.modeset_mutex after the locks in drm_fb_helper.dev
creates a deadlock with drm_setup_crtcs() as shown below:

  [    4.959319] fbcon: radeondrmfb (fb0) is primary device
  [    4.993952] Console: switching to colour frame buffer device 240x67
  [    4.994040]
  [    4.994041] ======================================================
  [    4.994041] WARNING: possible circular locking dependency detected
  [    4.994042] 5.2.0-rc4-1-default+ #39 Tainted: G            E
  [    4.994043] ------------------------------------------------------
  [    4.994043] systemd-udevd/369 is trying to acquire lock:
  [    4.994044] 00000000fb622acb (&client->modeset_mutex){+.+.}, at: drm_fb_helper_pan_display+0x103/0x1f0 [drm_kms_helper]
  [    4.994055]
  [    4.994055] but task is already holding lock:
  [    4.994055] 0000000028767ae4 (crtc_ww_class_mutex){+.+.}, at: drm_modeset_lock+0x42/0xf0 [drm]
  [    4.994072]
  [    4.994072] which lock already depends on the new lock.
  [    4.994072]
  [    4.994072]
  [    4.994072] the existing dependency chain (in reverse order) is:
  [    4.994073]
  [    4.994073] -> #3 (crtc_ww_class_mutex){+.+.}:
  [    4.994076]        lock_acquire+0x9e/0x170
  [    4.994079]        __ww_mutex_lock.constprop.18+0x97/0xf40
  [    4.994080]        ww_mutex_lock+0x30/0x90
  [    4.994091]        drm_modeset_lock+0x42/0xf0 [drm]
  [    4.994102]        drm_modeset_lock_all_ctx+0x1f/0xe0 [drm]
  [    4.994113]        drm_modeset_lock_all+0x5e/0x1a0 [drm]
  [    4.994163]        intel_modeset_init+0x60b/0xda0 [i915]
  ..
  [    4.994253]
  [    4.994253] -> #2 (crtc_ww_class_acquire){+.+.}:
  [    4.994255]        lock_acquire+0x9e/0x170
  [    4.994270]        drm_modeset_acquire_init+0xcc/0x100 [drm]
  [    4.994280]        drm_modeset_lock_all+0x44/0x1a0 [drm]
  [    4.994320]        intel_modeset_init+0x60b/0xda0 [i915]
  ..
  [    4.994403]
  [    4.994403] -> #1 (&dev->mode_config.mutex){+.+.}:
  [    4.994405]        lock_acquire+0x9e/0x170
  [    4.994408]        __mutex_lock+0x62/0x8c0
  [    4.994413]        drm_setup_crtcs+0x17c/0xc50 [drm_kms_helper]
  [    4.994418]        __drm_fb_helper_initial_config_and_unlock+0x34/0x530 [drm_kms_helper]
  [    4.994450]        radeon_fbdev_init+0x110/0x130 [radeon]
  ..
  [    4.994535]
  [    4.994535] -> #0 (&client->modeset_mutex){+.+.}:
  [    4.994537]        __lock_acquire+0xa85/0xe90
  [    4.994538]        lock_acquire+0x9e/0x170
  [    4.994540]        __mutex_lock+0x62/0x8c0
  [    4.994545]        drm_fb_helper_pan_display+0x103/0x1f0 [drm_kms_helper]
  [    4.994547]        fb_pan_display+0x92/0x120
  [    4.994549]        bit_update_start+0x1a/0x40
  [    4.994550]        fbcon_switch+0x392/0x580
  [    4.994552]        redraw_screen+0x12c/0x220
  [    4.994553]        do_bind_con_driver.cold.30+0xe1/0x10d
  [    4.994554]        do_take_over_console+0x113/0x190
  [    4.994555]        do_fbcon_takeover+0x58/0xb0
  [    4.994557]        notifier_call_chain+0x47/0x70
  [    4.994558]        blocking_notifier_call_chain+0x44/0x60
  [    4.994559]        register_framebuffer+0x231/0x310
  [    4.994564]        __drm_fb_helper_initial_config_and_unlock+0x2fd/0x530 [drm_kms_helper]
  [    4.994590]        radeon_fbdev_init+0x110/0x130 [radeon]
  ..

This problem was introduced in

  d81294af	drm/fb-helper: Remove drm_fb_helper_crtc

Reversing the lock ordering in pan_display_legacy() fixes the issue.

Fixes: d81294af ("drm/fb-helper: Remove drm_fb_helper_crtc")
Cc: Noralf Trønnes <noralf@tronnes.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Sean Paul <sean@poorly.run>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Suggested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20190611115716.7052-1-tzimmermann@suse.de

No functional changes, just moving code as-is and fixing includes.
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190608152657.36613-4-noralf@tronnes.org

This prepares the modeset code so it can be moved out as-is in the next
patch.

v3: Remove stray newline
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190608152657.36613-3-noralf@tronnes.org

All drivers add all their connectors so there's no need to keep around an
array of available connectors. Instead we just put the useable (not
writeback) connectors in a temporary array using
drm_client_for_each_connector_iter() everytime we probe the outputs.
Other places where it's necessary to look at the connectors, we just
iterate over them using the same iterator function.

Rename functions which signature is changed since they will be moved to
drm_client in a later patch.

v6: Improve commit message (Sam Ravnborg)
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190608152657.36613-2-noralf@tronnes.org

Move the modeset commit code to drm_client_modeset.
No changes except exporting API.

v7: Export drm_client_panel_rotation() (Gerd Hoffmann)
v2: Move to drm_client_modeset.c instead of drm_client.c
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190531140117.37751-5-noralf@tronnes.org

This makes the necessary changes so the commit code can be moved out to
drm_client as-is in the next patch. It's split up to ease review.
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190531140117.37751-4-noralf@tronnes.org

struct drm_fb_helper_crtc is now just a wrapper around drm_mode_set so
use that directly instead and attach it as a modeset array onto
drm_client_dev. drm_fb_helper will use this array to store its modesets
which means it will always initialize a drm_client, but it will not
register the client (callbacks) unless it's the generic fbdev emulation.

Code will later be moved to drm_client, so add code there in a new file
drm_client_modeset.c with MIT license to match drm_fb_helper.c.

The modeset connector array size is hardcoded for the cloned case to avoid
having to pass in a value from the driver. A value of 8 is chosen to err
on the safe side. This means that the max connector argument for
drm_fb_helper_init() and drm_fb_helper_fbdev_setup() isn't used anymore,
a todo entry for this is added.

In pan_display_atomic() restore_fbdev_mode_force() is used instead of
restore_fbdev_mode_atomic() because that one will later become internal
to drm_client_modeset.

Locking order:
1. drm_fb_helper->lock
2. drm_master_internal_acquire
3. drm_client_dev->modeset_mutex

v6: Improve commit message (Sam Ravnborg)

v3:
- Use full drm_client_init/release for the modesets (Daniel Vetter)
- drm_client_for_each_modeset: use lockdep_assert_held (Daniel Vetter)
- Hook up to Documentation/gpu/drm-client.rst (Daniel Vetter)

v2:
- Add modesets array to drm_client (Daniel Vetter)
- Use a new file for the modeset code (Daniel Vetter)
- File has to be MIT licensed (Emmanuel Vadot)
- Add copyrights from drm_fb_helper.c
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190531140117.37751-3-noralf@tronnes.org

The use of the drmP.h header file is deprecated.
Remove use from all files in drm/*
so people do not look there and follow a bad example.

Build tested allyesconfig,allmodconfig on x86, arm etc.
Including alpha that is as always more challenging than
the rest.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Acked-by: NDaniel Vetter <daniel@ffwll.ch>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Sean Paul <sean@poorly.run>
Cc: David Airlie <airlied@linux.ie>
Link: https://patchwork.freedesktop.org/patch/msgid/20190526173535.32701-8-sam@ravnborg.org

drm_format_info_plane_cpp() basically just returns the cpp array content
found in the drm_format_info structure.

Since it's pretty trivial, let's remove the function and have the users use
the array directly
Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NPaul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c0a78c87cd0410a1819edad2794ad06543c85bb5.1558002671.git-series.maxime.ripard@bootlin.com

So far, the drm_format_plane_cpp function was operating on the format's
fourcc and was doing a lookup to retrieve the drm_format_info structure and
return the cpp.

However, this is inefficient since in most cases, we will have the
drm_format_info pointer already available so we shouldn't have to perform a
new lookup. Some drm_fourcc functions also already operate on the
drm_format_info pointer for that reason, so the API is quite inconsistent
there.

Let's follow the latter pattern and remove the extra lookup while being a
bit more consistent. In order to be extra consistent, also rename that
function to drm_format_info_plane_cpp and to a static function in the
header to match the current policy.
Reviewed-by: NEmil Velikov <emil.velikov@collabora.com>
Reviewed-by: NPaul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/32aa13e53dbc98a90207fd290aa8e79f785fb11e.1558002671.git-series.maxime.ripard@bootlin.com

drm_fb_helper_hotplug_event() should tolerate the fb_helper argument being
NULL. Commit 03a9606e ("drm/fb-helper: Avoid race with DRM userspace")
introduced a fb_helper dereference before the NULL check.
Fixup by moving the dereference after the NULL check.

Fixes: 03a9606e ("drm/fb-helper: Avoid race with DRM userspace")
Reported-by: Nkbuild test robot <lkp@intel.com>
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20190515132925.48867-1-noralf@tronnes.org

The values are already present in the modeset.

This is done in preparation for the removal of struct drm_fb_helper_crtc.
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190506180139.6913-5-noralf@tronnes.org

Getting rotation info is cheap so we can do it on demand.

This is done in preparation for the removal of struct drm_fb_helper_crtc.

Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190506180139.6913-4-noralf@tronnes.org

drm_fb_helper_is_bound() is used to check if DRM userspace is in control.
This is done by looking at the fb on the primary plane. By the time
fb-helper gets around to committing, it's possible that the facts have
changed.

Avoid this race by holding the drm_device->master_mutex lock while
committing. When DRM userspace does its first open, it will now wait
until fb-helper is done. The helper will stay away if there's a master.

Two igt tests fail with the new 'bail out if master' rule. Work around
this by relaxing this rule for drm_fb_helper_restore_fbdev_mode_unlocked()
until the tests have been fixed. Add todo entry for this.

Locking rule: Always take the fb-helper lock first.

v5: drm_fb_helper_restore_fbdev_mode_unlocked(): Use
    restore_fbdev_mode_force()

v2:
- Remove drm_fb_helper_is_bound() (Daniel Vetter)
- No need to check fb_helper->dev->master in
  drm_fb_helper_single_fb_probe(), restore_fbdev_mode() has the check.
Suggested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20190506180139.6913-3-noralf@tronnes.org

Non-atomic drivers like ast doesn't have connector->state set resulting
in a NULL pointer deref:

[   29.609593] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
[   29.609619] Call Trace:
[   29.609630]  ? drm_helper_probe_single_connector_modes+0x27f/0x680
[   29.609640]  drm_setup_crtcs+0x431/0xd80 [drm_kms_helper]
[   29.753065]  __drm_fb_helper_initial_config_and_unlock+0x6f/0x6a0
[   29.753160]  ? drm_modeset_unlock_all+0x31/0x50 [drm]
[   29.765758]  ast_fbdev_init+0xa8/0xc0 [ast]
[   29.765762]  ast_driver_load.cold.7+0x2b3/0xe11 [ast]
[   29.765775]  drm_dev_register+0x111/0x150 [drm]

Fix by bailing out if the driver does not support atomic modesetting.

Fixes: 09ded8af ("drm/i915/fbdev: Move intel_fb_initial_config() to fbdev helper")
Reported-by: NThomas Zimmermann <tzimmermann@suse.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: NThomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20190423145353.30158-1-noralf@tronnes.org

This code moved in here in master, so revert it the same way.

This is the same revert as 9fa24625 ("Revert "drm/i915/fbdev:
Actually configure untiled displays"") in drm-fixes.
Signed-off-by: NDave Airlie <airlied@redhat.com>

It is generic code and having it in the helper will let other drivers
benefit from it.

One change was necessary assuming this to be true:
INTEL_INFO(dev_priv)->num_pipes == dev->mode_config.num_crtc
Suggested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190407165243.54043-4-noralf@tronnes.org

This is done to stay consistent with our naming scheme of
_register() = others can start calling us from any thread.
Suggested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20190403125658.32389-1-noralf@tronnes.org

Hotplug can happen while drm_fbdev_generic_setup() is running so move
drm_client_add() call after setup is done to avoid
drm_fbdev_client_hotplug() running in two threads at the same time.

Fixes: 9060d7f4 ("drm/fb-helper: Finish the generic fbdev emulation")
Cc: stable@vger.kernel.org
Reported-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20190401141358.25309-1-noralf@tronnes.org

For each enabled crtc the functions sets dpms on all registered connectors.
Limit this to only doing it once and on the connectors actually in use.
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Fixes: 023eb571 ("drm: correctly update connector DPMS status in drm_fb_helper")
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20190326175546.18126-3-noralf@tronnes.org

The gamma_size variable has not been used since
commit 4abe3520 ("drm/kms/fb: use slow work mechanism for normal hotplug also.")

While in the area move a comment back to its code block.
They got separated by
commit d50ba256 ("drm/kms: start adding command line interface using fb.").
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20190326175546.18126-2-noralf@tronnes.org

I forgot the !CONFIG_FBDEV case. Also some kerneldoc needed more
adjusting.

Cc: Noralf Trønnes <noralf@tronnes.org>
Cc: Alex Deucher <alexander.deucher@amd.com>
Reported-by: Nkbuild test robot <lkp@intel.com>
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190327125819.16478-1-daniel.vetter@ffwll.ch

Not used by drivers anymore.

v2: Rebase
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190326132008.11781-21-daniel.vetter@ffwll.ch

The fbdev emulation helpers pretty much assume that this is set.
Let's do it for everyone.
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20190326132008.11781-3-daniel.vetter@ffwll.ch

Looking at the oldest/most popular drivers ${driver}drmfb seems to be
the standard, except i915.ko went with "inteldrmfb". I guess renaming
that for consistency won't hurt, it definitely confused me when I
started with kms 10 years ago.

I hope this never became uapi ... worst case drivers can overwrite it
after having called fill_info().

Since subsequent patches change this for some drivers later on in the
series, here's the exhaustive list of where all fix.id is used:
- /proc/fb which prints the minor number and fix.id name.
- per-fb sysfs name file
- getfix ioctl, which is used by fbset only to print out the name when
dumping information
- lots and lots of places in dmesg, anytime anything happens with an
fbdev really

I think minimal to 0 chances that changing this will screw up a config
script or something, since outside of informational message it's not
used by anything to identify which fbdev maps to which minor. After
all the last fbset release is from 1999, and that predates even devfs
I think.

v2: Rebase and amend commit message, thanks to Ilia for pointing out
that this needs to be spelled out.

Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190326132008.11781-2-daniel.vetter@ffwll.ch

The fbdev split between fix and var information is kinda
pointless for drm drivers since everything is fixed: The fbdev
emulation doesn't support changing modes at all.

Create a new simplified helper and use it in the generic fbdev
helper code. Follow-up patches will beef it up more and roll
it out to all drivers.

v2: We need to keep sizes, since they might not match the fb dimensions
(Noralf)

v3: Fix typo in commit message and remove extraneous line in kerneldoc (Noralf)
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190326132008.11781-1-daniel.vetter@ffwll.ch

KMS drivers really should all be able to restore their display state
on resume without fbcon helping out. So make this the default.

Since I'm not entirely foolish, make it only a default, which drivers
can still override. That way when the inevitable regression report
happens I can fix things up with a one-liner plus FIXME comment that
someone should fix up the suspend/resume code in that driver.

But at least all new drivers won't be broken by accident as soon as
you turn off fbcon because "suspend/resume worked when I tested it".

v2: Keep this for radeon because of

commit 18c437ca
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Nov 14 17:19:29 2017 -0500

    Revert "drm/radeon: dont switch vt on suspend"

Thanks to Michel Dänzer for pointing this one out.
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Cc: Michel Dänzer <michel@daenzer.net>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Sean Paul <sean@poorly.run>
Cc: David Airlie <airlied@linux.ie>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Sandy Huang <hjc@rock-chips.com>
Cc: "Heiko Stübner" <heiko@sntech.de>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: Samuel Li <Samuel.Li@amd.com>
Cc: "Michel Dänzer" <michel.daenzer@amd.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Junwei Zhang <Jerry.Zhang@amd.com>
Cc: Huang Rui <ray.huang@amd.com>
Cc: Shirish S <shirish.s@amd.com>
Cc: Daniel Stone <daniels@collabora.com>
Cc: "Noralf Trønnes" <noralf@tronnes.org>
Cc: intel-gfx@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-rockchip@lists.infradead.org
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Reviewed-by: NSamuel Li <samuel.li@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181127173424.301-1-daniel.vetter@ffwll.ch

If the downscaling fails and we end up with a best_depth of 0,
then ignore it.

This actually works around a cascade of failure, but it the
simplest fix for now.

The scaling patch broke the udl driver, as the udl driver doesn't
expose planes at all, so gets the two default 32-bit formats, but
the udl driver then ask for 16bpp fbdev, and the scaling code falls
over.

This fixes the udl driver since the scaled depth support was added.

Fixes: f4bd542b ("drm/fb-helper: Scale back depth to supported maximum")
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190315014621.21816-2-airlied@gmail.com