This patch add a config to support to create multi buffer for cma fbdev.
Such as double buffer and triple buffer.

Cma fbdev is convient to add a legency fbdev. And still many Android
devices use fbdev now and at least double buffer is needed for these
Android devices, so that a buffer flip can be operated. It will need
some time for Android device vendors to abondon legency fbdev. So multi
buffer for fbdev is needed.
Signed-off-by: NXinliang Liu <xinliang.liu@linaro.org>
[s.christ@phytec.de: Picking patch from
                     https://lkml.org/lkml/2015/9/14/188]
Signed-off-by: NStefan Christ <s.christ@phytec.de>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Tested-by: NNeil Armstrong <narmstrong@baylibre.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/075ffb50cc16ab055b5d47b30163401bb356ab51.1487175046.git-series.maxime.ripard@free-electrons.com

We can not allow the worker to run after its fbdev, or even the module,
has been removed.

Fixes: cfe63423 ("drm/fb-helper: Add drm_fb_helper_set_suspend_unlocked()")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Noralf Trønnes <noralf@tronnes.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: dri-devel@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v4.9+
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170207124956.14954-2-chris@chris-wilson.co.uk

We can not allow the worker to run after its fbdev, or even the module,
has been removed.

Fixes: eaa434de ("drm/fb-helper: Add fb_deferred_io support")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Noralf Trønnes <noralf@tronnes.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: dri-devel@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v4.7+
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170207124956.14954-1-chris@chris-wilson.co.uk

Noticed that everyone duplicates the same logic here and we could safe
a few lines per driver. Yay for lots of drivers to make such tiny
refactors worth-while!

v2: Forgot to git add everything :(

v3: Actually remove release_fbi (Sean, Emil, Chris) ...

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Noralf Trønnes <noralf@tronnes.org>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170207161603.17611-1-daniel.vetter@ffwll.ch

While reviewing Chris' patches to properly cancel our async workers I
checked that this happens after the fbdev is already unregistered.
That's the case, but I found a small gap in our docs, fill that in.

Note that I don't explain what release_fbi does, because that function
will disappear in the next patch ...

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170207141050.1129-1-daniel.vetter@ffwll.ch

Instead of receiving the num_crts as a parameter, we can read it
directly from the mode_config structure.  I audited the drivers that
invoke this helper and I believe all of them initialize the mode_config
struct accordingly, prior to calling the fb_helper.

I used the following coccinelle hack to make this transformation, except
for the function headers and comment updates.  The first and second
rules are split because I couldn't find a way to remove the unused
temporary variables at the same time I removed the parameter.

// <smpl>
@r@
expression A,B,D,E;
identifier C;
@@
(
- drm_fb_helper_init(A,B,C,D)
+ drm_fb_helper_init(A,B,D)
|
- drm_fbdev_cma_init_with_funcs(A,B,C,D,E)
+ drm_fbdev_cma_init_with_funcs(A,B,D,E)
|
- drm_fbdev_cma_init(A,B,C,D)
+ drm_fbdev_cma_init(A,B,D)
)

@@
expression A,B,C,D,E;
@@
(
- drm_fb_helper_init(A,B,C,D)
+ drm_fb_helper_init(A,B,D)
|
- drm_fbdev_cma_init_with_funcs(A,B,C,D,E)
+ drm_fbdev_cma_init_with_funcs(A,B,D,E)
|
- drm_fbdev_cma_init(A,B,C,D)
+ drm_fbdev_cma_init(A,B,D)
)

@@
identifier r.C;
type T;
expression V;
@@
- T C;
<...
when != C
- C = V;
...>
// </smpl>

Changes since v1:
 - Rebased on top of the tip of drm-misc-next.
 - Remove mention to sti since a proper fix got merged.
Suggested-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NGabriel Krisman Bertazi <krisman@collabora.co.uk>
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170202162640.27261-1-krisman@collabora.co.uk

I just learned that &struct_name.member_name works and looks pretty
even. It doesn't (yet) link to the member directly though, which would
be really good for big structures or vfunc tables (where the
per-member kerneldoc tends to be long).

Also some minor drive-by polish where it makes sense, I read a lot
of docs ...

v2: Comments from Gustavo.

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Rewiewed-by: NGustavo Padovan <gustavo.padovan@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-2-daniel.vetter@ffwll.ch

drm_pick_cmdline_mode width and height parameters are useless.
Just remove them.

Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: NVincent Abriou <vincent.abriou@st.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1483721084-20278-2-git-send-email-vincent.abriou@st.com

This check is useful for drivers that do not have DRIVER_ATOMIC set but
have atomic modesetting internally implemented. Wrap the check into a
function since this is used in many places and as a bonus, the function
name helps to document what the check is for.

v2:
Change return type to bool (Ville)
Move the function drm_atomic.h (Daniel)
Fixed comment marker for documentation
Suggested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
[danvet: Move back to drmP.h because include hell.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1482396643-32456-1-git-send-email-dhinakaran.pandiyan@intel.com

Mostly nothing special (except making sure that really all error paths
and friends call iter_put).

v2: Don't forget the raw connector_list walking in
drm_helper_move_panel_connectors_to_head. That one unfortunately can't
be converted to the iterator helpers, but since it's just some list
splicing best to just wrap the entire thing up in one critical
section.

v3: Bail out after iter_put (Harry).

Cc: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161215155843.13408-1-daniel.vetter@ffwll.ch

Replace uses of fb->bits_per_pixel with fb->format->cpp[0]*8.
Less duplicated information is a good thing.

Note that I didn't put parens around the cpp*8 in the below cocci script,
on account of not wanting spurious parens all over the place. Instead I
did the unsafe way, and tried to look over the entire diff to spot if
any dangerous expressions were produced. I didn't see any.

There are some cases where previously the code did X*bpp/8, so the
division happened after the multiplication. Those are now just X*cpp
so the division effectively happens before the multiplication,
but that is perfectly fine since bpp is always a multiple of 8.

@@
struct drm_framebuffer *FB;
expression E;
@@
 drm_helper_mode_fill_fb_struct(...) {
	...
-	FB->bits_per_pixel = E;
	...
 }

@@
struct drm_framebuffer *FB;
expression E;
@@
 i9xx_get_initial_plane_config(...) {
	...
-	FB->bits_per_pixel = E;
	...
 }

@@
struct drm_framebuffer *FB;
expression E;
@@
 ironlake_get_initial_plane_config(...) {
	...
-	FB->bits_per_pixel = E;
	...
 }

@@
struct drm_framebuffer *FB;
expression E;
@@
 skylake_get_initial_plane_config(...) {
	...
-	FB->bits_per_pixel = E;
	...
 }

@@
struct drm_framebuffer FB;
expression E;
@@
(
- E * FB.bits_per_pixel / 8
+ E * FB.format->cpp[0]
|
- FB.bits_per_pixel / 8
+ FB.format->cpp[0]
|
- E * FB.bits_per_pixel >> 3
+ E * FB.format->cpp[0]
|
- FB.bits_per_pixel >> 3
+ FB.format->cpp[0]
|
- (FB.bits_per_pixel + 7) / 8
+ FB.format->cpp[0]
|
- FB.bits_per_pixel
+ FB.format->cpp[0] * 8
|
- FB.format->cpp[0] * 8 != 8
+ FB.format->cpp[0] != 1
)

@@
struct drm_framebuffer *FB;
expression E;
@@
(
- E * FB->bits_per_pixel / 8
+ E * FB->format->cpp[0]
|
- FB->bits_per_pixel / 8
+ FB->format->cpp[0]
|
- E * FB->bits_per_pixel >> 3
+ E * FB->format->cpp[0]
|
- FB->bits_per_pixel >> 3
+ FB->format->cpp[0]
|
- (FB->bits_per_pixel + 7) / 8
+ FB->format->cpp[0]
|
- FB->bits_per_pixel
+ FB->format->cpp[0] * 8
|
- FB->format->cpp[0] * 8 != 8
+ FB->format->cpp[0] != 1
)

@@
struct drm_plane_state *state;
expression E;
@@
(
- E * state->fb->bits_per_pixel / 8
+ E * state->fb->format->cpp[0]
|
- state->fb->bits_per_pixel / 8
+ state->fb->format->cpp[0]
|
- E * state->fb->bits_per_pixel >> 3
+ E * state->fb->format->cpp[0]
|
- state->fb->bits_per_pixel >> 3
+ state->fb->format->cpp[0]
|
- (state->fb->bits_per_pixel + 7) / 8
+ state->fb->format->cpp[0]
|
- state->fb->bits_per_pixel
+ state->fb->format->cpp[0] * 8
|
- state->fb->format->cpp[0] * 8 != 8
+ state->fb->format->cpp[0] != 1
)

@@
@@
- (8 * 8)
+ 8 * 8

@@
struct drm_framebuffer FB;
@@
- (FB.format->cpp[0])
+ FB.format->cpp[0]

@@
struct drm_framebuffer *FB;
@@
- (FB->format->cpp[0])
+ FB->format->cpp[0]

@@
@@
 struct drm_framebuffer {
	 ...
-	 int bits_per_pixel;
	 ...
 };

v2: Clean up the 'cpp*8 != 8' and '(8 * 8)' cases (Laurent)
v3: Adjusted the semantic patch a bit and regenerated due to code
    changes
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1)
Link: http://patchwork.freedesktop.org/patch/msgid/1481751140-18352-1-git-send-email-ville.syrjala@linux.intel.com

Replace uses of fb->depth with fb->format->depth. Less duplicate
information is a good thing.

@@
struct drm_framebuffer *fb;
expression E;
@@
 drm_helper_mode_fill_fb_struct(...) {
	...
-	fb->depth = E;
	...
 }

@@
struct nouveau_framebuffer *fb;
@@
- fb->base.depth
+ fb->base.format->depth

@@
struct drm_framebuffer fb;
@@
- fb.depth
+ fb.format->depth

@@
struct drm_framebuffer *fb;
@@
- fb->depth
+ fb->format->depth

@@
struct drm_framebuffer fb;
@@
- (fb.format->depth)
+ fb.format->depth

@@
struct drm_framebuffer *fb;
@@
- (fb->format->depth)
+ fb->format->depth

@@
@@
 struct drm_framebuffer {
	 ...
-	 unsigned int depth;
	 ...
 };

v2: Drop the vmw stuff (Daniel)
    Rerun spatch due to code changes
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1481751095-18249-1-git-send-email-ville.syrjala@linux.intel.com

Though we only walk the kernel_fb_helper_list inside a panic (or single
thread debugging), we still need to protect the list manipulation on
creating/removing a framebuffer device in order to prevent list
corruption.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20161129120217.7344-3-chris@chris-wilson.co.uk

drm_fb_helper_probe_connector_modes() is always called before
drm_setup_crtcs(), so just move the call into drm_setup_crtcs for a
small bit of code compaction.

Note that register_framebuffer will do a modeset (when fbcon is enabled)
and hence must be moved out of the critical section. A follow-up patch
will add new locking for the fb list, hence move all the related
registration code together.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20161129120217.7344-2-chris@chris-wilson.co.uk

The fb_helper->connector_count is modified when a new connector is
constructed following a hotplug event (e.g. DP-MST). This causes trouble
for drm_setup_crtcs() and friends that assume that fb_helper is
constant:

[ 1250.872997] BUG: KASAN: slab-out-of-bounds in drm_setup_crtcs+0x320/0xf80 at addr ffff88074cdd2608
[ 1250.873020] Write of size 40 by task kworker/u8:3/480
[ 1250.873039] CPU: 2 PID: 480 Comm: kworker/u8:3 Tainted: G     U          4.9.0-rc6+ #285
[ 1250.873043] Hardware name:                  /NUC6i3SYB, BIOS SYSKLi35.86A.0024.2015.1027.2142 10/27/2015
[ 1250.873050] Workqueue: events_unbound async_run_entry_fn
[ 1250.873056]  ffff88070f9d78f0 ffffffff814b72aa ffff88074e40c5c0 ffff88074cdd2608
[ 1250.873067]  ffff88070f9d7918 ffffffff8124ff3c ffff88070f9d79b0 ffff88074cdd2600
[ 1250.873079]  ffff88074e40c5c0 ffff88070f9d79a0 ffffffff812501e4 0000000000000005
[ 1250.873090] Call Trace:
[ 1250.873099]  [<ffffffff814b72aa>] dump_stack+0x67/0x9d
[ 1250.873106]  [<ffffffff8124ff3c>] kasan_object_err+0x1c/0x70
[ 1250.873113]  [<ffffffff812501e4>] kasan_report_error+0x204/0x4f0
[ 1250.873120]  [<ffffffff81698df0>] ? drm_dev_printk+0x140/0x140
[ 1250.873127]  [<ffffffff81250ac3>] kasan_report+0x53/0x60
[ 1250.873134]  [<ffffffff81688b40>] ? drm_setup_crtcs+0x320/0xf80
[ 1250.873142]  [<ffffffff8124f18e>] check_memory_region+0x13e/0x1a0
[ 1250.873147]  [<ffffffff8124f5f3>] memset+0x23/0x40
[ 1250.873154]  [<ffffffff81688b40>] drm_setup_crtcs+0x320/0xf80
[ 1250.873161]  [<ffffffff810be7c5>] ? wake_up_q+0x45/0x80
[ 1250.873169]  [<ffffffff81b0c180>] ? mutex_lock_nested+0x5a0/0x5a0
[ 1250.873176]  [<ffffffff8168a0e6>] drm_fb_helper_initial_config+0x206/0x7a0
[ 1250.873183]  [<ffffffff81689ee0>] ? drm_fb_helper_set_par+0x90/0x90
[ 1250.873303]  [<ffffffffa0b68690>] ? intel_fbdev_fini+0x140/0x140 [i915]
[ 1250.873387]  [<ffffffffa0b686b2>] intel_fbdev_initial_config+0x22/0x40 [i915]
[ 1250.873391]  [<ffffffff810b50ff>] async_run_entry_fn+0x7f/0x270
[ 1250.873394]  [<ffffffff810a64b0>] process_one_work+0x3d0/0x960
[ 1250.873398]  [<ffffffff810a641d>] ? process_one_work+0x33d/0x960
[ 1250.873401]  [<ffffffff810a60e0>] ? max_active_store+0xf0/0xf0
[ 1250.873406]  [<ffffffff810f6f9d>] ? do_raw_spin_lock+0x10d/0x1a0
[ 1250.873413]  [<ffffffff810a767d>] worker_thread+0x8d/0x840
[ 1250.873419]  [<ffffffff810a75f0>] ? create_worker+0x2e0/0x2e0
[ 1250.873426]  [<ffffffff810b0454>] kthread+0x194/0x1c0
[ 1250.873432]  [<ffffffff810b02c0>] ? kthread_park+0x60/0x60
[ 1250.873438]  [<ffffffff810f095d>] ? trace_hardirqs_on+0xd/0x10
[ 1250.873446]  [<ffffffff810b02c0>] ? kthread_park+0x60/0x60
[ 1250.873453]  [<ffffffff810b02c0>] ? kthread_park+0x60/0x60
[ 1250.873457]  [<ffffffff81b12277>] ret_from_fork+0x27/0x40
[ 1250.873460] Object at ffff88074cdd2608, in cache kmalloc-32 size: 32

However, when holding the mode_config.lock around the fb_helper, we have
to be careful of any callbacks that may reenter the fb_helper and so try
to reacquire the mode_config.lock (e.g. register_framebuffer). To avoid
the mutex recursion, we have to rearrange the sequence to move the
registration into the caller outside of the mode_config.lock.

v2: drop the 1; following the lockdep assertion inside the for(;;), I
anticipated an error that doesn't happen!

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98826Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20161129120217.7344-1-chris@chris-wilson.co.uk

smatch correctly warns:

	drivers/gpu/drm/drm_fb_helper.c:1960 drm_target_preferred() warn: should '1 << i' be a 64 bit type?
	drivers/gpu/drm/drm_fb_helper.c:2001 drm_target_preferred() warn: should '1 << i' be a 64 bit type?
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

A drm driver that is implementing

      fb_debug_enter and fb_debug_leave

in struct fb_ops with drm fb helper functions

     drm_fb_helper_debug_enter and drm_fb_helper_debug_leave

must also implement the callback 'mode_set_base_atomic' in struct
drm_crtc_helper_funcs. See Documentation/DocBook/kgdb.tmpl.  The current
implementation will segfault when 'mode_set_base_atomic' is a NULL
pointer.

Before this patch at least the drm drivers armada, ast, qxl, udl and
virtio do not have a 'mode_set_base_atomic' implementation but using
drm_fb_helper_debug_(enter|leave). So these drivers may segfault when
callbacks fb_debug_(enter|leave) are called.

Avoid the issue by just checking for NULL pointers. So all drivers can
unconditionally implement fb_debug_(enter|leave) with the drm_fb_helper
functions. If callback 'mode_set_base_atomic' is not implemented, the
code in drm_fb_helper_debug_(enter|leave) does effectively nothing.
Signed-off-by: NStefan Christ <contact@stefanchrist.eu>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1479078208-25221-2-git-send-email-contact@stefanchrist.eu

The fbdev helper code keeps around two lists of connectors. One is the
list of all connectors it could use, and that list already holds
references for all the connectors. However the other list, or rather
lists, is the one actively being used. That list is tracked per-crtc
and currently doesn't hold any extra references. Let's grab those
extra references to avoid oopsing when the connector vanishes. The
list of all possible connectors should get updated when the hpd happens,
but the list of actively used connectors would not get updated until
the next time the fb-helper picks through the set of possible connectors.
And so we need to hang on to the connectors until that time.

Since we need to clean up in drm_fb_helper_crtc_free() as well,
let's pull the code to a common place. And while at it let's
pull in up the modeset->mode cleanup in there as well. The case
of modeset->fb is a bit less clear. I'm thinking we should probably
hold a reference to it, but for now I just slapped on a FIXME.

v2: Cleanup things drm_fb_helper_crtc_free() too (Chris)
v3: Don't leak modeset->connectors (Chris)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Cc: Carlos Santa <carlos.santa@intel.com>
Cc: Kirill A. Shutemov <kirill@shutemov.name>
Tested-by: Carlos Santa <carlos.santa@intel.com> (v1)
Tested-by: Kirill A. Shutemov <kirill@shutemov.name> (v1)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97666Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1477492878-4990-1-git-send-email-ville.syrjala@linux.intel.com

We need to drop the connector references already taken when we
abort in the middle of drm_fb_helper_single_add_all_connectors()

Cc: stable@vger.kernel.org
Cc: Carlos Santa <carlos.santa@intel.com>
Cc: Kirill A. Shutemov <kirill@shutemov.name>
Tested-by: NCarlos Santa <carlos.santa@intel.com>
Tested-by: NKirill A. Shutemov <kirill@shutemov.name>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1477472755-15288-2-git-send-email-ville.syrjala@linux.intel.com

Since 4.7 kernel, we've seen the error messages like

 kernel: [TTM] Buffer eviction failed
 kernel: qxl 0000:00:02.0: object_init failed for (4026540032, 0x00000001)
 kernel: [drm:qxl_alloc_bo_reserved [qxl]] *ERROR* failed to allocate VRAM BO

on QXL when switching and accessing on VT.  The culprit was the
generic deferred_io code (qxl driver switched to it since 4.7).
There is a race between the dirty clip update and the call of
callback.

In drm_fb_helper_dirty(), the dirty clip is updated in the spinlock,
while it kicks off the update worker outside the spinlock.  Meanwhile
the update worker clears the dirty clip in the spinlock, too.  Thus,
when drm_fb_helper_dirty() is called concurrently, schedule_work() is
called after the clip is cleared in the first worker call.

This patch addresses it by validating the clip before calling the
dirty fb callback.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98322
Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1003298
Fixes: eaa434de ('drm/fb-helper: Add fb_deferred_io support')
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161020150530.5787-1-tiwai@suse.de

Now that all drivers have been converted over to the per-plane rotation
property, we can just nuke the global rotation property.

v2: Rebase due to BIT(),__builtin_ffs() & co.
    Deal with superfluous code shuffling
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1477077768-4274-4-git-send-email-ville.syrjala@linux.intel.com

Not all planes on the system may support the same rotations/reflections,
so make it possible to create a separate property for each plane.
This way userspace gets told exactly which rotations/reflections are
possible for each plane.

v2: Add drm_plane_create_rotation_property() helper
v3: Drop the BIT(), __builtin_ffs(x) - 1,
    Moar WARNs for bad parameters
    Deal with superfluous code shuffling
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1474907460-10717-4-git-send-email-ville.syrjala@linux.intel.com

The current fbdev emulation does not allow to push back changes in
width, height or depth to KMS, hence reject any changes with an
error. This makes sure that fbdev ioctl's fail properly and user
space does not assume that changes succeeded.
Signed-off-by: NStefan Agner <stefan@agner.ch>
Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161011231504.17688-1-stefan@agner.ch

drm_atomic_state has a complicated single owner model that tracks the
single reference from allocation through to destruction on another
thread - or perhaps on a local error path. We can simplify this tracking
by using reference counting (at a cost of a few more atomics). This is
even more beneficial when the lifetime of the state becomes more
convoluted than being passed to a single worker thread for the commit.

v2: Double check !intel atomic_commit functions for missing gets
v3: Update kerneldocs
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: NEric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161014121833.439-27-chris@chris-wilson.co.uk

drm/drm_fb_helper.c:2306:12: warning: symbol 'drm_fb_helper_modinit' was not declared. Should it be static?

While at it, move the lefover static inline to the right place.

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sean Paul <seanpaul@chromium.org>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1474292035-15695-4-git-send-email-ville.syrjala@linux.intel.com

I figured I might as well go ocd and make them booleans and rename the
locked version too.

v2: Review from Noralf.
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Cc: Noralf Trønnes <noralf@tronnes.org>
Fixes: cfe63423 ("drm/fb-helper: Add drm_fb_helper_set_suspend_unlocked()")
Acked-by: NNoralf Trønnes <noralf@tronnes.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160823152727.31788-1-daniel.vetter@ffwll.ch

This adds a function that also takes the console lock before calling
fb_set_suspend() in contrast to drm_fb_helper_set_suspend() which is
a plain wrapper around fb_set_suspend().
Resume is run asynchronously using a worker if the console lock is
already taken. This is modelled after the i915 driver.
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1471953246-29602-1-git-send-email-noralf@tronnes.org

This reverts commit:

  fa7d81bb ("drm/fb-helper: Reduce READ_ONCE(master) to lockless_dereference")

As Peter explained:

  [...] lockless_dereference() is _stronger_ than READ_ONCE(), not weaker.

  [...]

  Also, clue is in the name: 'dereference', you don't actually dereference
  the pointer here, only load it.

My next patch breaks the compile without this revert, because it assumes
you want to deference and thus also need the struct type visible (which
it isn't here), so revert it.
Tested-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1470909022-687-1-git-send-email-johannes@sipsolutions.netSigned-off-by: NIngo Molnar <mingo@kernel.org>

These are the leftovers I could only track down using keep_warnings =
True. For some of them we might want to update our style guide on how
to reference structures and constants, not sure ...

Cc: Markus Heiser <markus.heiser@darmarit.de>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1471034937-651-1-git-send-email-daniel.vetter@ffwll.ch

Everyone who uses the fbdev emulation helpers doesn't need to include
fb.h directly. Remove it.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1470847958-28465-3-git-send-email-daniel.vetter@ffwll.ch

Only property creation uses the rotation as an index, so convert the
to figure the index when needed.

v2: Use the new defines to build the _MASK defines (Sean)

Cc: intel-gfx@lists.freedesktop.org
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Cc: malidp@foss.arm.com
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: Sean Paul <seanpaul@chromium.org>
Acked-by: NLiviu Dudau <Liviu.Dudau@arm.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1469771405-17653-1-git-send-email-joonas.lahtinen@linux.intel.com

We are only documenting that the read is outside of the lock, and do not
require strict ordering on the operation. In this case the more relaxed
lockless_dereference() will suffice.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Julia Lawall <julia.lawall@lip6.fr>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466581572-16608-1-git-send-email-chris@chris-wilson.co.uk

There can only be one current master, and it's for the overall device.
Render/control minors don't support master-based auth at all.

This simplifies the master logic a lot, at least in my eyes: All these
additional pointer chases are just confusing.

While doing the conversion I spotted some locking fail:
- drm_lock/drm_auth check dev->master without holding the
  master_mutex. This is fallout from

  commit c996fd0b
  Author: Thomas Hellstrom <thellstrom@vmware.com>
  Date:   Tue Feb 25 19:57:44 2014 +0100

      drm: Protect the master management with a drm_device::master_mutex v3

  but I honestly don't care one bit about those old legacy drivers
  using this.

- debugfs name info should just grab master_mutex.

- And the fbdev helper looked at it to figure out whether someone is
  using KMS. We just need a consistent value, so READ_ONCE. Aside: We
  should probably check if anyone has opened a control node too, but I
  guess current userspace doesn't really do that yet.

v2: Balance locking, reported by Julia.

v3: Rebase on top of Chris' oops fixes.

Cc: Julia Lawall <julia.lawall@lip6.fr>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v2)
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> (v2)
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466499262-18717-1-git-send-email-daniel.vetter@ffwll.ch

Drivers transitioning to atomic might not yet want to enable full
DRIVER_ATOMIC support when it's not entirely working. But using atomic
internally makes a lot more sense earlier.

Instead of spreading such flags to more places I figured it's simpler
to just check for mode_config->funcs->atomic_commit, and use atomic
paths if that is set. For the only driver currently transitioning
(i915) this does the right thing.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1465388359-8070-23-git-send-email-daniel.vetter@ffwll.ch

Adapt drm_pick_crtcs() and update_connector_routing() to fallback to
drm_atomic_helper_best_encoder() if funcs->best_encoder() is NULL so
that DRM drivers can leave this hook unassigned if they know they want
to use drm_atomic_helper_best_encoder().

Update the vtables documentation accordingly.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1465300095-16971-2-git-send-email-boris.brezillon@free-electrons.com

Change return value to int to propagate errors from gamma_set,
and remove start parameter. Updates always use the full size,
and some drivers even ignore the start parameter altogether.

This is needed for atomic drivers, where an atomic commit can
fail with -EINTR or -ENOMEM and should be restarted. This is already
and issue for drm_atomic_helper_legacy_set_gamma, which this patch
fixes up.

Changes since v1:
- Fix compiler warning. (Emil)
- Fix commit message (Daniel)

Cc: Alex Deucher <alexander.deucher@amd.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Mathieu Larouche <mathieu.larouche@matrox.com>
Cc: Thierry Reding <treding@nvidia.com>
Acked-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
[danvet: Improve commit message a bit more, mention that this fixes
the helper.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/742944bc-9f41-1acb-df4f-0fd4c8a10168@linux.intel.com

DRM fbdev emulation only supports pallete_color with depth == 8, and
truecolor with depth > 8. Handling depth == 16 for palettes is hence
dead code, let's remove it.
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1459331485-28376-3-git-send-email-daniel.vetter@ffwll.ch

During boot, MST hotplugs are generally expected (even if no physical
hotplugging occurs) and result in DRM's connector topology changing.
This means that using num_connector from the current mode configuration
can lead to the number of connectors changing under us. This can lead to
some nasty scenarios in fbcon:

- We allocate an array to the size of dev->mode_config.num_connectors.
- MST hotplug occurs, dev->mode_config.num_connectors gets incremented.
- We try to loop through each element in the array using the new value
  of dev->mode_config.num_connectors, and end up going out of bounds
  since dev->mode_config.num_connectors is now larger then the array we
  allocated.

fb_helper->connector_count however, will always remain consistent while
we do a modeset in fb_helper.

Note: This is just polish for 4.7, Dave Airlie's drm_connector
refcounting fixed these bugs for real. But it's good enough duct-tape
for stable kernel backporting, since backporting the refcounting
changes is way too invasive.

Cc: stable@vger.kernel.org
Signed-off-by: NLyude <cpaul@redhat.com>
[danvet: Clarify why we need this. Also remove the now unused "dev"
local variable to appease gcc.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1463065021-18280-3-git-send-email-cpaul@redhat.com

This was forgotten to fixup in the latest version of the deferred_io
patch which made FB_DEFERRED_IO mandatory.
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1462982962-10530-2-git-send-email-noralf@tronnes.org

s/modest/modeset/
s/aftert/after/
Signed-off-by: NLyude <cpaul@redhat.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1462375734-8213-3-git-send-email-cpaul@redhat.com