drm/syncobj: add transition iotcls between binary and timeline v2

we need to import/export timeline point.

v2: unify to one transfer ioctl

Signed-off-by: Chunming Zhou <david1.zhou@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/295790/?series=58813&rev=1

drm/syncobj: use the timeline point in drm_syncobj_find_fence v4

Implement finding the right timeline point in drm_syncobj_find_fence.

v2: return -EINVAL when the point is not submitted yet.
v3: fix reference counting bug, add flags handling as well
v4: add timeout for find fence

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/295786/?series=58813&rev=1

drm/syncobj: add timeline payload query ioctl v6

user mode can query timeline payload.
v2: check return value of copy_to_user
v3: handle querying entry by entry
v4: rebase on new chain container, simplify interface
v5: query last signaled timeline point, not last point.
v6: add unorder point check

Signed-off-by: Chunming Zhou <david1.zhou@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Cc: Tobias Hector <Tobias.Hector@amd.com>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/295784/?series=58813&rev=1

drm/syncobj: add support for timeline point wait v8

points array is one-to-one match with syncobjs array.
v2:
add seperate ioctl for timeline point wait, otherwise break uapi.
v3:
userspace can specify two kinds waits::
a. Wait for time point to be completed.
b. and wait for time point to become available
v4:
rebase
v5:
add comment for xxx_WAIT_AVAILABLE
v6: rebase and rework on new container
v7: drop _WAIT_COMPLETED, it is the default anyway
v8: correctly handle garbage collected fences

Signed-off-by: Chunming Zhou <david1.zhou@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Cc: Tobias Hector <Tobias.Hector@amd.com>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/295782/?series=58813&rev=1

drm/syncobj: add new drm_syncobj_add_point interface v4

Use the dma_fence_chain object to create a timeline of fence objects
instead of just replacing the existing fence.

v2: rebase and cleanup
v3: fix garbage collection parameters
v4: add unorder point check, print a warn calltrace

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/295780/?series=58813&rev=1

dma-buf: add new dma_fence_chain container v7

Lockless container implementation similar to a dma_fence_array, but with
only two elements per node and automatic garbage collection.

v2: properly document dma_fence_chain_for_each, add dma_fence_chain_find_seqno,
    drop prev reference during garbage collection if it's not a chain fence.
v3: use head and iterator for dma_fence_chain_for_each
v4: fix reference count in dma_fence_chain_enable_signaling
v5: fix iteration when walking each chain node
v6: add __rcu for member 'prev' of struct chain node
v7: fix rcu warnings from kernel robot

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/295778/?series=58813&rev=1

drm: fallback to dma_alloc_coherent when memory encryption is active

We can't just map any randome page we get when memory encryption is
active.

Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.kernel.org/patch/10850833/

drm/sun4i: hdmi: add support for ddc-i2c-bus property

Sometimes it is desirabled to use a separate i2c controller for ddc
access.  This adds support for the ddc-i2c-bus property of the
hdmi-connector node, using the specified controller if provided.

Signed-off-by: Mans Rullgard <mans@mansr.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190328130249.19356-1-mans@mansr.com

drm/stm: add sleep power management

Implements system sleep power management ops.

Signed-off-by: Yannick Fertré <yannick.fertre@st.com>
Acked-by: Philippe Cornu <philippe.cornu@st.com>
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1553156120-13851-1-git-send-email-yannick.fertre@st.com

drm/stm: dw_mipi_dsi-stm: add sleep power management

Implements system sleep power management ops.

Signed-off-by: Yannick Fertré <yannick.fertre@st.com>
Acked-by: Philippe Cornu <philippe.cornu@st.com>
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1553156033-13792-1-git-send-email-yannick.fertre@st.com

drm: rockchip: introduce rk3066 hdmi

The RK3066 HDMI TX serves as interface between a LCD Controller and
a HDMI bus. A HDMI TX consists of one HDMI transmitter controller and
one HDMI transmitter PHY. The interface has three (3) 8-bit data channels
which can be configured for a number of bus widths (8/10/12/16/20/24-bit)
and different video formats (RGB, YCbCr).

Features:
HDMI version 1.4a, HDCP revision 1.4 and
DVI version 1.0 compliant transmitter.
Supports DTV resolutions from 480i to 1080i/p HD.
Master I2C interface for a DDC connection.
HDMI TX supports multiple power save modes.
The HDMI TX input can switch between LCDC0 and LCDC1.
(Sound support is not included in this patch)

Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20190330095639.14626-2-jbx6244@gmail.com

dt-bindings: display: rockchip: add document for rk3066 hdmi

This patch adds a binding that describes the HDMI controller for
rk3066.

Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20190330095639.14626-5-jbx6244@gmail.com

drm/rockchip: vop: Support dithering to RGB666

Splits out the dither register bits and introduces
the same config enumerations as in the rockchip kernel tree.
Tested to fix the banding on my ASUS C201.

Signed-off-by: Urja Rannikko <urjaman@gmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20190318154412.26994-1-urjaman@gmail.com

drm/virtio: rework resource creation workflow.

This patch moves the virtio_gpu_cmd_create_resource() call (which
notifies the host about the new resource created) into the
virtio_gpu_object_create() function.  That way we can call
virtio_gpu_cmd_create_resource() before ttm_bo_init(), so the host
already knows about the object when ttm initializes the object and calls
our driver callbacks.

Specifically the object is already created when the
virtio_gpu_ttm_tt_bind() callback invokes virtio_gpu_object_attach(),
so the extra virtio_gpu_object_attach() calls done after
virtio_gpu_object_create() are not needed any more.

The fence support for the create ioctl becomes a bit more tricky though.
The code moved into virtio_gpu_object_create() too.  We first submit the
(fenced) virtio_gpu_cmd_create_resource() command, then initialize the
ttm object, and finally attach just created object to the fence for the
command in case it didn't finish yet.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Noralf Trønnes <noralf@tronnes.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20190318113332.10900-6-kraxel@redhat.com

drm/virtio: params struct for virtio_gpu_cmd_create_resource_3d()

Add 3d resource parameters to virtio_gpu_object_params struct.  With
that in place we can use it for virtio_gpu_cmd_resource_create_3d()
calls.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Noralf Trønnes <noralf@tronnes.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20190318113332.10900-5-kraxel@redhat.com

drm/virtio: params struct for virtio_gpu_cmd_create_resource()

Add format, width and height fields to the virtio_gpu_object_params
struct.  With that in place we can use the parameter struct for
virtio_gpu_cmd_create_resource() calls too.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Noralf Trønnes <noralf@tronnes.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20190318113332.10900-4-kraxel@redhat.com

drm/virtio: use struct to pass params to virtio_gpu_object_create()

Create virtio_gpu_object_params, use that to pass object parameters to
virtio_gpu_object_create.  This is just the first step, followup patches
will add more parameters to the struct.  The plan is to use the struct
for all object parameters.

Drop unused "kernel" parameter for virtio_gpu_alloc_object(), it is
unused and always false.

Also drop "pinned" parameter.  virtio-gpu doesn't shuffle around
objects, so effecively they all are pinned anyway.  Hardcode
TTM_PL_FLAG_NO_EVICT so ttm knows.  Doesn't change much for the moment
as virtio-gpu supports TTM_PL_FLAG_TT only so there is no opportunity to
move around objects.  That'll probably change in the future though.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Noralf Trønnes <noralf@tronnes.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20190318113332.10900-3-kraxel@redhat.com

drm/virtio: move virtio_gpu_object_{attach, detach} calls.

Drop the dummy ttm backend implementation, add a real one for
TTM_PL_FLAG_TT objects.  The bin/unbind callbacks will call
virtio_gpu_object_{attach,detach}, to update the object state
on the host side, instead of invoking those calls from the
move_notify() callback.

With that in place the move and move_notify callbacks are not
needed any more, so drop them.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Noralf Trønnes <noralf@tronnes.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20190318113332.10900-2-kraxel@redhat.com

drm/virtio: add virtio-gpu-features debugfs file.

This file prints which features the virtio-gpu device has.

Also add "virtio-gpu-" prefix to the existing fence file,
to make clear this is a driver-specific debugfs file.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Noralf Trønnes <noralf@tronnes.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20190320083612.32067-1-kraxel@redhat.com

drm/virtio: remove set but not used variable 'vgdev'

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/gpu/drm/virtio/virtgpu_ttm.c: In function 'virtio_gpu_init_mem_type':
drivers/gpu/drm/virtio/virtgpu_ttm.c:117:28: warning:
 variable 'vgdev' set but not used [-Wunused-but-set-variable]

drivers/gpu/drm/virtio/virtgpu_ttm.c: In function 'virtio_gpu_bo_swap_notify':
drivers/gpu/drm/virtio/virtgpu_ttm.c:300:28: warning:
 variable 'vgdev' set but not used [-Wunused-but-set-variable]

It is never used since introduction in dc5698e80cf7 ("Add virtio gpu driver.")

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20190325092631.152060-1-yuehaibing@huawei.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

drm/fb-helper: Fixup fill_info cleanup

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: kbuild test robot <lkp@intel.com>
Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190327125819.16478-1-daniel.vetter@ffwll.ch

drm/edid: Remove defunct EDID_QUIRK_FIRST_DETAILED_PREFERRED

Looks like EDID_QUIRK_FIRST_DETAILED_PREFERRED never did anything.
Its counterpart in f86EdidModes.c is properly hooked up but somehow
that functionality was lost when it was copied into the kernel.

The concensus seems to be that this quirk is a bit misguided
anyway so let's nuke the leftovers.

For posterity here are some links to known cases:
* Proview AY765C
  https://bugs.freedesktop.org/show_bug.cgi?id=15160
* Unknown Acer
  https://bugzilla.redhat.com/show_bug.cgi?id=284231 (got the
  reference from xf86EdidModes.c)
* Peacock Ergovision 19 (only in xf86EdidModes.c)
  https://bugzilla.redhat.com/show_bug.cgi?id=492359
* Philips 107p5 CRT
  "Reported on xorg@ with pastebin", didn't find the mail(s)

Cc: Adam Jackson <ajax@redhat.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190322174244.23945-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>

drm/uapi: Remove unused DRM_DISPLAY_INFO_LEN

Remove the unused DRM_DISPLAY_INFO_LEN from the uapi headers.
I presume the original plan was to expose the display name
via getconnector, but looks like that never happened. So we have
the define for the length of the string but no string anywhere.

A quick scan didn't seem to reveal userspace referencing this
so hopefully we can just nuke it.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190326173401.7329-4-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Kill drm_display_info.name

drm_display_info.name is only ever set by a few panel drivers but
never actually used anywhere except in i915 debugfs code. Trash it.

v2: Fix typo in commit msg (Sam Ravnborg)

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190326173401.7329-3-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Fix tabs vs. spaces

A set of 8 spaces has snuck in. Replace with a tab, and
toss in an extra newline while at it.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190326173401.7329-2-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Nuke unused drm_display_info.pixel_clock

drm_display_info.pixel_clock is unused. Let's get rid of it.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190326173401.7329-1-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/fb-helper: Unexport fill_{var,info}

Not used by drivers anymore.

v2: Rebase

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

drm/udl: Use drm_fb_helper_fill_info

This should not result in any changes.

v2: Rebase

v3: Don't forget to remove the info->par assignment (Noralf)

Acked-by: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Sean Paul <sean@poorly.run>
Cc: Mikulas Patocka <mpatocka@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Emil Lundmark <lndmrk@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190326132008.11781-19-daniel.vetter@ffwll.ch

drm/vboxvideo: Use drm_fb_helper_fill_info

This should not result in any changes.

v2: Rebase over vbox changes - vbox gained it's own line to fill
fix.id.

v3: Rebase

Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (v2)
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Alexander Kapshuk <alexander.kapshuk@gmail.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190326132008.11781-20-daniel.vetter@ffwll.ch

drm/tegra: Use drm_fb_helper_fill_info

Another driver that didn't set fbinfo->fix.id before.

v2: Fix subject and rebase

Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Jonathan Hunter <jonathanh@nvidia.com>
Cc: linux-tegra@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20190326132008.11781-18-daniel.vetter@ffwll.ch

drm/rockchip: Use drm_fb_helper_fill_info

This will set an fb name for the first time!

v2: Rebase

Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Sandy Huang <hjc@rock-chips.com>
Cc: "Heiko Stübner" <heiko@sntech.de>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-rockchip@lists.infradead.org
Link: https://patchwork.freedesktop.org/patch/msgid/20190326132008.11781-17-daniel.vetter@ffwll.ch

drm/radeon: Use drm_fb_helper_fill_info

This should not result in any changes.

v2: Rebase

Acked-by: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: "David (ChunMing) Zhou" <David1.Zhou@amd.com>
Cc: amd-gfx@lists.freedesktop.org
Link: https://patchwork.freedesktop.org/patch/msgid/20190326132008.11781-16-daniel.vetter@ffwll.ch

drm/omap: Use drm_fb_helper_fill_info

This changes the fb name from "omapdrm" to "omapdrmfb".

v2: Rebase

Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190326132008.11781-15-daniel.vetter@ffwll.ch

drm/nouveau: Use drm_fb_helper_fill_info

This changes the fb name from "nouveaufb" to "nouveaudrmfb".

Aside: I wonder whether the in_interrupt() check is good enough for
the nouveau acceleration. Cargo-cult says drm_can_sleep() is needed,
which isn't actually working if you pick a .config without PREEMPT.
For the generic fbdev defio support we've gone with offloading
everything to a worker. For the non-accel callbacks (set_par, blank
and friends) checking for oops_in_progress is good enough to catch all
the evil calling contexts.

v2: Rebase

Acked-by: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: nouveau@lists.freedesktop.org
Link: https://patchwork.freedesktop.org/patch/msgid/20190326132008.11781-14-daniel.vetter@ffwll.ch

drm/msm: Use drm_fb_helper_fill_info

This will change the fb name from "msm" to "msmdrmfb".

v2: Rebase

v3: Fix subject prefix (Noralf)

Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Link: https://patchwork.freedesktop.org/patch/msgid/20190326132008.11781-13-daniel.vetter@ffwll.ch

drm/mga200g: Use drm_fb_helper_fill_info

Only changes the name of the fb from "mgadrmfb" to "mga200drmfb".

v2: Rebase

v3: Note the name change (Noralf)

Acked-by: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: Junwei Zhang <Jerry.Zhang@amd.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20190326132008.11781-12-daniel.vetter@ffwll.ch

drm/i915: Use drm_fb_helper_fill_info

This changes the fb name from "inteldrmfb" to "i915drmfb".

v2: Rebase

Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
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
Link: https://patchwork.freedesktop.org/patch/msgid/20190326132008.11781-11-daniel.vetter@ffwll.ch

drm/hibmc: Use drm_fb_helper_fill_info

Should not result in any changes.

v2: Rebase

Acked-by: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Junwei Zhang <Jerry.Zhang@amd.com>
Cc: Xinliang Liu <z.liuxinliang@hisilicon.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: Ajit Negi <ajitn.linux@gmail.com>
Cc: Souptick Joarder <jrdr.linux@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: John Garry <john.garry@huawei.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190326132008.11781-10-daniel.vetter@ffwll.ch

drm/gma500: Use drm_fb_helper_fill_info

This will change the fb name from "psbdrmfb" to "gma500drmfb".

v2: Rebase

Acked-by: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190326132008.11781-9-daniel.vetter@ffwll.ch

drm/exynos: Use drm_fb_helper_fill_info

This will give the exynos fbdev a name!

v2: Rebase

Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Kukjin Kim <kgene@kernel.org>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20190326132008.11781-8-daniel.vetter@ffwll.ch

drm/cirrus: Use drm_fb_helper_fill_info

Should not result in any changes.

v2: Rebase

Acked-by: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190326132008.11781-7-daniel.vetter@ffwll.ch

drm/ast: Use drm_fb_helper_fill_info

Should not result in any changes.

v2: Rebase

Acked-by: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Junwei Zhang <Jerry.Zhang@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sean Paul <sean@poorly.run>
Cc: YueHaibing <yuehaibing@huawei.com>
Cc: Sam Bobroff <sbobroff@linux.ibm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190326132008.11781-6-daniel.vetter@ffwll.ch

drm/armada: Use drm_fb_helper_fill_info

Only changes the name of the fb from "armada-drmfb" to armadadrmfb.

v2: Rebase

v3: Fix commit message (Noralf)

Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Russell King <linux@armlinux.org.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190326132008.11781-5-daniel.vetter@ffwll.ch

drm/amdgpu: Use drm_fb_helper_fill_info

Should not cause any changes.

v2: Rebase

Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
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: Huang Rui <ray.huang@amd.com>
Cc: Junwei Zhang <Jerry.Zhang@amd.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Daniel Stone <daniels@collabora.com>
Cc: Shirish S <shirish.s@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190326132008.11781-4-daniel.vetter@ffwll.ch

drm/fb_helper: set info->par in fill_info()

The fbdev emulation helpers pretty much assume that this is set.
Let's do it for everyone.

Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20190326132008.11781-3-daniel.vetter@ffwll.ch

drm/fb-helper: set fbi->fix.id in fill_info()

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: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190326132008.11781-2-daniel.vetter@ffwll.ch

drm/fb-helper: Add fill_info() functions

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: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190326132008.11781-1-daniel.vetter@ffwll.ch

drm/fbdev: Make skip_vt_switch the default

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 18c437caa5b18a235dd65cec224eab54bebcee65
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: Daniel 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: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Samuel Li <samuel.li@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181127173424.301-1-daniel.vetter@ffwll.ch

drm/doc: Drop "content type" from the legacy kms property table

We want new stuff documented in more verbose form, this table is
deprecated. "content type" is already documented properly.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes: 50525c332b55 ("drm: content-type property for HDMI connector")
Cc: Hans Verkuil <hans.verkuil@cisco.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190326090555.5969-1-daniel.vetter@ffwll.ch

drm: vkms: check status of alloc_ordered_workqueue

alloc_ordered_workqueue may fail and return NULL.
The fix returns ENOMEM when it fails to avoid potential NULL
pointer dereference.

Signed-off-by: Kangjie Lu <kjlu@umn.edu>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20190309043628.6078-1-kjlu@umn.edu

drm/doc: fix missing verb

Add a missing "be". While there, also fix the syntax for
struct drm_device.

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20190313153537.22654-2-luca@lucaceresoli.net

drm/hibmc: Drop best_encoder

This is the default for atomic drivers.

Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190221155857.19773-1-daniel.vetter@ffwll.ch

drm/fourcc: Fix conflicting Y41x definitions

There has unfortunately been a conflict with the following 3 commits:

commit e9961ab95af81b8d29054361cd5f0c575102cf87
Author: Ayan Kumar Halder <ayan.halder@arm.com>
Date:   Fri Nov 9 17:21:12 2018 +0000
    drm: Added a new format DRM_FORMAT_XVYU2101010

commit 7ba0fee247ee7a36b3bfbed68f6988d980aa3aa3
Author: Brian Starkey <brian.starkey@arm.com>
Date:   Fri Oct 5 10:27:00 2018 +0100

    drm/fourcc: Add AFBC yuv fourccs for Mali

and

commit 50bf5d7d595fd0705ef3785f80e679b6da501e5b
Author: Swati Sharma <swati2.sharma@intel.com>
Date:   Mon Mar 4 17:26:33 2019 +0530

    drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc

Unfortunately gcc didn't warn about the redefinitions, because the
double defines were the set to same value, and gcc apparently no longer
warns about that.

Fix this by using new XYVU for i915, without alpha, and making the
Y41x definitions match msdn, with alpha.

Fortunately we caught it early, and the conflict hasn't even landed in
drm-next yet.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Brian Starkey <Brian.Starkey@arm.com>
Cc: Swati Sharma <swati2.sharma@intel.com>
Cc: Ayan Kumar Halder <ayan.halder@arm.com>
Cc: malidp@foss.arm.com
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Sean Paul <sean@poorly.run>
Cc: Dave Airlie <airlied@linux.ie>
Cc: Liviu Dudau <Liviu.Dudau@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190319121702.6814-1-maarten.lankhorst@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com> #irc
Acked-by: Sean Paul <sean@poorly.run>
Reviewed-by: Ayan Kumar halder <ayan.halder@arm.com>

drm/selftests/mm: Switch to bitmap_zalloc()

Switch to bitmap_zalloc() to show clearly what we are allocating.
Besides that it returns pointer of bitmap type instead of opaque void *.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190304092908.57382-1-andriy.shevchenko@linux.intel.com

tinydrm/mipi-dbi: Use dma-safe buffers for all SPI transfers

Buffers passed to spi_sync() must be dma-safe even for tiny buffers since
some SPI controllers use DMA for all transfers.

Example splat with CONFIG_DMA_API_DEBUG enabled:

[   23.750467] DMA-API: dw_dmac_pci 0000:00:15.0: device driver maps memory from stack [probable addr=000000001e49185d]
[   23.750529] WARNING: CPU: 1 PID: 1296 at kernel/dma/debug.c:1161 check_for_stack+0xb7/0x190
[   23.750533] Modules linked in: mmc_block(+) spi_pxa2xx_platform(+) pwm_lpss_pci pwm_lpss spi_pxa2xx_pci sdhci_pci cqhci intel_mrfld_pwrbtn extcon_intel_mrfld sdhci intel_mrfld_adc led_class mmc_core ili9341 mipi_dbi tinydrm backlight ti_ads7950 industrialio_triggered_buffer kfifo_buf intel_soc_pmic_mrfld hci_uart btbcm
[   23.750599] CPU: 1 PID: 1296 Comm: modprobe Not tainted 5.0.0-rc7+ #236
[   23.750605] Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 2015.01.21:18.19.48
[   23.750620] RIP: 0010:check_for_stack+0xb7/0x190
[   23.750630] Code: 8b 6d 50 4d 85 ed 75 04 4c 8b 6d 10 48 89 ef e8 2f 8b 44 00 48 89 c6 4a 8d 0c 23 4c 89 ea 48 c7 c7 88 d0 82 b4 e8 40 7c f9 ff <0f> 0b 8b 05 79 00 4b 01 85 c0 74 07 5b 5d 41 5c 41 5d c3 8b 05 54
[   23.750637] RSP: 0000:ffff97bbc0292fa0 EFLAGS: 00010286
[   23.750646] RAX: 0000000000000000 RBX: ffff97bbc0290000 RCX: 0000000000000006
[   23.750652] RDX: 0000000000000007 RSI: 0000000000000002 RDI: ffff94b33e115450
[   23.750658] RBP: ffff94b33c8578b0 R08: 0000000000000002 R09: 00000000000201c0
[   23.750664] R10: 00000006ecb0ccc6 R11: 0000000000034f38 R12: 000000000000316c
[   23.750670] R13: ffff94b33c84b250 R14: ffff94b33dedd5a0 R15: 0000000000000001
[   23.750679] FS:  0000000000000000(0000) GS:ffff94b33e100000(0063) knlGS:00000000f7faf690
[   23.750686] CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
[   23.750691] CR2: 00000000f7f54faf CR3: 000000000722c000 CR4: 00000000001006e0
[   23.750696] Call Trace:
[   23.750713]  debug_dma_map_sg+0x100/0x340
[   23.750727]  ? dma_direct_map_sg+0x3b/0xb0
[   23.750739]  spi_map_buf+0x25a/0x300
[   23.750751]  __spi_pump_messages+0x2a4/0x680
[   23.750762]  __spi_sync+0x1dd/0x1f0
[   23.750773]  spi_sync+0x26/0x40
[   23.750790]  mipi_dbi_typec3_command_read+0x14d/0x240 [mipi_dbi]
[   23.750802]  ? spi_finalize_current_transfer+0x10/0x10
[   23.750821]  mipi_dbi_typec3_command+0x1bc/0x1d0 [mipi_dbi]

Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190222124329.23046-1-noralf@tronnes.org

drm/vboxvideo: Remove unused including <linux/version.h>

Remove including <linux/version.h> that don't need it.

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190320015429.86347-1-yuehaibing@huawei.com

drm/meson: exclusively use the canvas provider module

Now that the DMC register range is no longer in the bindings, remove any
mention towards it and exclusively use the meson-canvas module.

Signed-off-by: Maxime Jourdan <mjourdan@baylibre.com>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190311105144.7276-3-mjourdan@baylibre.com

dt-bindings: display: amlogic, meson-vpu: exclusively use amlogic, canvas

When the DRM driver for the meson platform was created, the bindings
required that the DMC register region was provided.

Through those DMC registers, the display driver could configure an IP
called "canvas", a video lookup table used by the display IP.

It was later discovered that "canvas" is actually an IP shared by other
components than display: video decoder, 2D engine.. and that it wasn't
possible to keep the canvas code in DRM.

Over the past few months, incremental efforts have been deployed to
create a standalone meson-canvas driver [1], and the DRM driver was
patched to optionally use it if present [2].

This is the final step of those efforts where we simply remove any
control over DMC that the meson DRM driver has.

Please note that this breaks compatibility with older DTs that only
provide the DMC register range but not the amlogic,canvas node.

[1] https://patchwork.kernel.org/cover/10573771/
[2] https://patchwork.freedesktop.org/series/52076/

Signed-off-by: Maxime Jourdan <mjourdan@baylibre.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190311105144.7276-2-mjourdan@baylibre.com

drm: add non-desktop quirks to Sensics and OSVR headsets.

Add two EDID vendor/product pairs used across a variety of
Sensics products, as well as the OSVR HDK and HDK 2.

Signed-off-by: Ryan Pavlik <ryan.pavlik@collabora.com>
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20181203164644.13974-1-ryan.pavlik@collabora.com
Cc: <stable@vger.kernel.org> # v4.15+

drm/sun4i: mixer: Simplify the get_id logic

Using the new helpers introduced since we wrote that code, we can simplify
the code to retrieve the mixer ID significantly.

The new code will also allow us to deal nicely with endpoints that don't
have a reg property, as expected in the case where there's a single
endpoint for a given port.

Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Link: https://patchwork.freedesktop.org/patch/msgid/3da40505e18a981c5ad626127e14ff594a826ef5.1552594551.git-series.maxime.ripard@bootlin.com

drm/sun4i: backend: Simplify the get_id logic

Using the new helpers introduced since we wrote that code, we can simplify
the code to retrieve the backend ID significantly.

The new code will also allow us to deal nicely with endpoints that don't
have a reg property, as expected in the case where there's a single
endpoint for a given port.

Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1a9bf911b0a40475da8025859032514131d5397b.1552594551.git-series.maxime.ripard@bootlin.com

drm/v3d: Use the new shmem helpers to reduce driver boilerplate.

The new shmem helpers from Noralf and Rob abstract out a bunch of our
BO creation and mapping code.

v2: Use the new sgt getter, and flag pages as dirty before freeing.
v3: Remove the mismatched put_pages.

Signed-off-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20190314163451.13431-1-eric@anholt.net
Reviewed-by: Rob Herring <robh@kernel.org> (v2)

drm: Add library for shmem backed GEM objects

This adds a library for shmem backed GEM objects.

v8:
- export drm_gem_shmem_create_with_handle
- call mapping_set_gfp_mask to set default zone to GFP_HIGHUSER
- Add helper drm_gem_shmem_get_pages_sgt()

v7:
- Use write-combine for mmap instead. This is the more common
  case. (robher)

v6:
- Fix uninitialized variable issue in an error path (anholt).
- Add a drm_gem_shmem_vm_open() to the fops to get proper refcounting
  of the pages (anholt).

v5:
- Drop drm_gem_shmem_prime_mmap() (Daniel Vetter)
- drm_gem_shmem_mmap(): Subtract drm_vma_node_start() to get the real
  vma->vm_pgoff
- drm_gem_shmem_fault(): Use vmf->pgoff now that vma->vm_pgoff is correct

v4:
- Drop cache modes (Thomas Hellstrom)
- Add a GEM attached vtable

v3:
- Grammar (Sam Ravnborg)
- s/drm_gem_shmem_put_pages_unlocked/drm_gem_shmem_put_pages_locked/
  (Sam Ravnborg)
- Add debug output in error path (Sam Ravnborg)

Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20190313004344.24169-1-robh@kernel.org

drm/dp: Set the connector's TILE property even for DP SST connectors

Current driver sets the tile property only for DP MST connectors.
However there are some tiled displays where each SST connector
carries a single tile. So we need to attach this property object
for every connector and set it for every connector (DP SST and MST).
Plus since the tile information is obtained as a result of EDID
parsing, the best place to update tile property is where we update
edid property.
Also now we dont need to explicitly set this now for MST connectors.

This has been tested with xrandr --props and modetest and verified
that TILE property is exposed correctly.

Cc: Dave Airlie <airlied@redhat.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190313021722.10068-1-manasi.d.navare@intel.com

drm/v3d: Fix calling drm_sched_resubmit_jobs for same sched.

Also stop calling drm_sched_increase_karma multiple times.

v2: Fix whitespace in the code we're moving (by anholt)

Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/1552409822-17230-1-git-send-email-andrey.grodzovsky@amd.com
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Fixes: 222b5f044159 ("drm/sched: Refactor ring mirror list handling.")

drm/v3d: Remove some dead members of struct v3d_bo.

vmas was from the previous model of page table management (one per
fd), and vaddr was left over from vc4.

Signed-off-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20190308161716.2466-4-eric@anholt.net
Acked-by: Rob Herring <robh@kernel.org>

drm/v3d: Use drm_gem_lock_reservations()/drm_gem_unlock_reservations()

Now that we have core helpers, this gets rid of a lot of boilerplate.

Signed-off-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20190308161716.2466-3-eric@anholt.net
Acked-by: Rob Herring <robh@kernel.org>

drm: Add helpers for locking an array of BO reservations.

Now that we have the reservation object in the GEM object, it's easy
to provide a helper for this common case.  Noticed while reviewing
panfrost and lima drivers.  This particular version came out of v3d,
which in turn was a copy from vc4.

v2: Fix kerneldoc warnings.

Signed-off-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20190308161716.2466-2-eric@anholt.net
Acked-by: Rob Herring <robh@kernel.org> (v1)

Merge tag 'topic/hdr-formats-2019-03-13' of git://anongit.freedesktop.org/drm/drm-misc into drm-misc-next

Add support for floating point half-width formats.

Signed-off-by: Sean Paul <seanpaul@chromium.org>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/00b96cd5-91c7-5677-9620-b138c7a92303@linux.intel.com

gpu: drm: atomic_helper: Fix spelling errors

Trivial fixes identified while working on the DRM code.

  s/artifically/artificially/
  s/achive/achieve/

v2: - Actually spell achieve correctly!

Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190312003307.14116-1-kieran.bingham+renesas@ideasonboard.com

drm/i915/icl: Implement half float formats

64 bpp half float formats are supported on hdr planes only and are subject
to the following restrictions:
  * 90/270 rotation not supported
  * Yf Tiling not supported
  * Frame Buffer Compression not supported
  * Color Keying not supported

v2:
- Drop handling pixel normalize register
- Don't use icl_is_hdr_plane too early

v3:
- Use refactored icl_is_hdr_plane (Ville)
- Use u32 instead of uint32_t (Ville)

v6:
- Rebase and fix merge conflicts
- Reorganize switch statements to keep RGB grouped separately from YUV

Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Kevin Strasser <kevin.strasser@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1552437513-22648-4-git-send-email-kevin.strasser@intel.com

drm/i915: Refactor icl_is_hdr_plane

Change the api in order to enable callers that can't supply a valid
intel_plane pointer, as would be the case prior to calling
drm_universal_plane_init.

v4:
- Rename variables and move a declaration (Ville)

v6:
- Rebase and fix merge conflict

Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Kevin Strasser <kevin.strasser@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1552437513-22648-3-git-send-email-kevin.strasser@intel.com

drm/fourcc: Add 64 bpp half float formats

Add 64 bpp 16:16:16:16 half float pixel formats. Each 16 bit component is
formatted in IEEE-754 half-precision float (binary16) 1:5:10
MSb-sign:exponent:fraction form.

This patch attempts to address the feedback provided when 2 of these
formats were previosly proposed:
  https://patchwork.kernel.org/patch/10072545/

v2:
- Fixed cpp (Ville)
- Added detail pixel formatting (Ville)
- Ordered formats in header (Ville)

v5:
- .depth should be 0 for new formats (Maarten)

Cc: Tina Zhang <tina.zhang@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Kevin Strasser <kevin.strasser@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1552437513-22648-2-git-send-email-kevin.strasser@intel.com

drm/arm/malidp: Added support for AFBC modifiers for all layers except DE_SMART

The list of modifiers to be supported for each plane has been dynamically generated
from 'malidp_format_modifiers[]' and 'malidp_hw_regmap->features'.

Changes from v1:-
1. Replaced DRM_ERROR() with DRM_DEBUG_KMS() in malidp_format_mod_supported()
to report unsupported modifiers.

Changes from v2:-
1. Removed malidp_format_mod_supported() from the current patch. This has been added
in "PATCH 7/12"
2. Dynamically generate the list of modifiers (to be supported for each plane) from
'malidp_format_modifiers' and features.

Changes since v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next

Signed-off-by: Ayan Kumar halder <ayan.halder@arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Link: https://patchwork.freedesktop.org/patch/291767/?series=57895&rev=1

drm/arm/malidp:- Disregard the pitch alignment constraint for AFBC framebuffer.

Considering the fact that some of the AFBC specific pixel formats are expressed
in bits per pixel (ie bpp which is not byte aligned), the pitch (ie width * bpp)
is not guaranteed to be aligned to burst size (ie 8 or 16 bytes).
For example, DRM_FORMAT_VUY101010 is 30 bits per pixel. For a framebuffer of
width 32 pixels, the pitch will be 120 bytes which is not aligned to burst size
(ie 16 bytes) for DP650.

Changes since v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next

Signed-off-by: Ayan Kumar halder <ayan.halder@arm.com>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Link: https://patchwork.freedesktop.org/patch/291764/?series=57895&rev=1

drm/arm/malidp:- Use the newly introduced malidp_format_get_bpp() instead of relying on cpp for calculating framebuffer size

Formats like DRM_FORMAT_VUY101010, DRM_FORMAT_YUV420_8BIT and
DRM_FORMAT_YUV420_10BIT are expressed in bits per pixel as they have a non
integer value of cpp (thus denoted as '0' in drm_format_info[]). Therefore,
the calculation of AFBC framebuffer size needs to use malidp_format_get_bpp().

Changes since v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next

Signed-off-by: Ayan Kumar halder <ayan.halder@arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Link: https://patchwork.freedesktop.org/patch/291766/?series=57895&rev=1

drm/arm/malidp:- Writeback framebuffer does not support any modifiers

In malidp, the writeback pipeline does not support writing crtc output
to a framebuffer with modifiers ie the memory writeback content is
devoid of any compression or tiling, etc.
So we have added a commit check in memory writeback encoder helper function
to validate if the framebuffer has any modifier and if so, return EINVAL.

Changes since v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next

Signed-off-by: Ayan Kumar halder <ayan.halder@arm.com>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Link: https://patchwork.freedesktop.org/patch/291765/?series=57895&rev=1

drm/arm/malidp: Specified the rotation memory requirements for AFBC YUV formats

The newly supported AFBC YUV formats have the following rotation memory
constraints (in DP550/DP650).
1. DRM_FORMAT_VUY888/DRM_FORMAT_VUY101010 :- It can rotate upto 8
horizontal lines in the AFBC output buffer.
2. DRM_FORMAT_YUV420_8BIT :- It can rotate upto 16 horizontal lines
in the AFBC output buffer.

Also some of the pixel formats are specified in bits per pixel (rather
than bytes per pixel), so the calculation needs to take note of this.

Besides there are some difference between DP550 and DP650 and these are
as follows:-
1. DRM_FORMAT_X0L2 (in uncompressed format) does not support rotation in
DP550. For DP650, it can rotate upto 16 horizontal lines in the AFBC
output buffer, whereas in DP550 (with AFBC), it can rotate upto 8
horizontal lines.
2. DRM_FORMAT_YUV420_10BIT :- It can rotate upto 8 horizontal lines in
dp550 and 16 horizontal lines in DP650.

Changes since v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next

Signed-off-by: Ayan Kumar halder <ayan.halder@arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Link: https://patchwork.freedesktop.org/patch/291763/?series=57895&rev=1

drm/arm/malidp:- Define a common list of AFBC format modifiers supported for DP500, DP550 and DP650

We need to define a common list of format modifiers supported by each of
the Mali display processors.

The following are the constraints with AFBC:-

1. AFBC is not supported for the formats defined in
malidp_hw_format_is_linear_only()

2. Some of the formats are supported only with AFBC modifiers. Thus we have
introduced a new function 'malidp_hw_format_is_afbc_only()' which verifies
the same.

3. AFBC_FORMAT_MOD_YTR needs to be provided for any RGB format.

4. Formats <= 16bpp cannot support AFBC_FORMAT_MOD_SPLIT.

5. CBR should not be set for non-subsampled formats.

6. SMART layer does not support framebuffer with AFBC modifiers.
Return -EINVAL for such a scenario.

7. AFBC_FORMAT_MOD_YTR is not supported for any YUV formats.

8. Formats which are subsampled cannot support AFBC_FORMAT_MOD_SPLIT.
However in DP550, YUV_420_10BIT is supported with AFBC_FORMAT_MOD_SPLIT.
This feature has been identified with
MALIDP_DEVICE_AFBC_YUV_420_10_SUPPORT_SPLIT.

9. In DP550 and DP650, for YUYV, the hardware supports different
format-ids to be used with and without AFBC modifier. We have used the
feature 'MALIDP_DEVICE_AFBC_YUYV_USE_422_P2' to identify this
characteristic.

10. DP500 does not support split mode (ie AFBC_FORMAT_MOD_SPLIT). We have
used the feature 'MALIDP_DEVICE_AFBC_SUPPORT_SPLIT' to identify the DPs
which support SPLIT mode.

11. DP550 supports YUV420 with split mode. We have defined the feature
'AFBC_SUPPORT_SPLIT_WITH_YUV_420_10' to identify this characteristic.

Changes since v1:-
- Merged https://patchwork.freedesktop.org/patch/265215/ into this patch
- As Liviu pointed out in the last patch, we can pull the checks outside
of the 'while (*modifiers != DRM_FORMAT_MOD_INVALID)' loop
- Rebased

Changes since v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next

Signed-off-by: Ayan Kumar halder <ayan.halder@arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Link: https://patchwork.freedesktop.org/patch/291762/?series=57895&rev=1

drm/arm/malidp:- Added support for new YUV formats for DP500, DP550 and DP650

We have added support for some AFBC only pixel formats like :-
DRM_FORMAT_YUV420_8BIT (single plane YUV 420 8 bit format)
DRM_FORMAT_VUY888 (single plane YUV 444 8 bit format)
DRM_FORMAT_VUY101010 (single plane YUV 444 10 bit format)
DRM_FORMAT_YUV420_10BIT (single plane YUV 420 10 bit format)

Generally, these formats are supported by our hardware using the same
hw-ids as the equivalent multi plane pixel formats.

Also we have added support for XYUV 444 8 and 10 bit formats

Changes since v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next

Signed-off-by: Ayan Kumar Halder <ayan.halder@arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Link: https://patchwork.freedesktop.org/patch/291761/?series=57895&rev=1

drm/arm/malidp: Set the AFBC register bits if the framebuffer has AFBC modifier

Added the AFBC decoder registers for DP500 , DP550 and DP650.
These registers control the processing of AFBC buffers. It controls various
features like AFBC decoder enable, lossless transformation and block split
as well as setting of the left, right, top and bottom cropping of AFBC
buffers (in number of pixels).
All the layers (except DE_SMART) support framebuffers with AFBC modifiers.
One needs to set the pixel values of the top, left, bottom and right
cropping for the AFBC framebuffer.
Cropping an AFBC framebuffer is controlled by the AFBC crop registers.
In that case, the layer input size registers should be configured with
framebuffer's dimensions and not with drm_plane_state source width/height
values (which is used for non AFBC framebuffer to denote cropping).

Changes from v1:
 - Removed the "if (fb->modifier)" check from malidp_de_plane_update()
and added it in malidp_de_set_plane_afbc(). This will consolidate all the
AFBC specific register configurations in a single function ie
malidp_de_set_plane_afbc().

Changes from v2:
 - For AFBC framebuffer, layer input size register should be set to
framebuffer's width and height.

Changes from v3:
- Rebased on top of latest drm-misc-next
- Some cleanups/sanity changes based on Liviu's comments

Changes from v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next

Signed-off-by: Ayan Kumar Halder <ayan.halder@arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Link: https://patchwork.freedesktop.org/patch/291760/?series=57895&rev=1

drm: Added a new format DRM_FORMAT_XVYU2101010

This new format is supported by DP550 and DP650

Changes since v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next

Signed-off-by: Ayan Kumar halder <ayan.halder@arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Link: https://patchwork.freedesktop.org/patch/291758/?series=57895&rev=1

drm/fourcc: Add AFBC yuv fourccs for Mali

As we look to enable AFBC using DRM format modifiers, we run into
problems which we've historically handled via vendor-private details
(i.e. gralloc, on Android).

AFBC (as an encoding) is fully flexible, and for example YUV data can
be encoded into 1, 2 or 3 encoded "planes", much like the linear
equivalents. Component order is also meaningful, as AFBC doesn't
necessarily care about what each "channel" of the data it encodes
contains. Therefore ABGR8888 and RGBA8888 can be encoded in AFBC with
different representations. Similarly, 'X' components may be encoded
into AFBC streams in cases where a decoder expects to decode a 4th
component.

In addition, AFBC is a licensable IP, meaning that to support the
ecosystem we need to ensure that _all_ AFBC users are able to describe
the encodings that they need. This is much better achieved by
preserving meaning in the fourcc codes when they are combined with an
AFBC modifier.

In essence, we want to use the modifier to describe the parameters of
the AFBC encode/decode, and use the fourcc code to describe the data
being encoded/decoded.

To do anything different would be to introduce redundancy - we would
need to duplicate in the modifier information which is _already_
conveyed clearly and non-ambigiously by a fourcc code.

I hope that for RGB this is non-controversial.
(BGRA8888 + MODIFIER_AFBC) is a different format from
(RGBA8888 + MODIFIER_AFBC).

Possibly more controversial is that (XBGR8888 + MODIFIER_AFBC)
is different from (BGR888 + MODIFIER_AFBC). I understand that in some
schemes it is not the case - but in AFBC it is so.

Where we run into problems is where there are not already fourcc codes
which represent the data which the AFBC encoder/decoder is processing.
To that end, we want to introduce new fourcc codes to describe the
data being encoded/decoded, in the places where none of the existing
fourcc codes are applicable.

Where we don't support an equivalent non-compressed layout, or where
no "obvious" linear layout exists, we are proposing adding fourcc
codes which have no associated linear layout - because any layout we
proposed would be completely arbitrary.

Some formats are following the naming conventions from [2].

The summary of the new formats is:
 DRM_FORMAT_VUY888 - Packed 8-bit YUV 444. Y followed by U then V.
 DRM_FORMAT_VUY101010 - Packed 10-bit YUV 444. Y followed by U then
                        V. No defined linear encoding.
 DRM_FORMAT_Y210 - Packed 10-bit YUV 422. Y followed by U (then Y)
                   then V. 10-bit samples in 16-bit words.
 DRM_FORMAT_Y410 - Packed 10-bit YUV 444, with 2-bit alpha.
 DRM_FORMAT_P210 - Semi-planar 10-bit YUV 422. Y plane, followed by
                   interleaved U-then-V plane. 10-bit samples in
                   16-bit words.
 DRM_FORMAT_YUV420_8BIT - Packed 8-bit YUV 420. Y followed by U then
                          V. No defined linear encoding
 DRM_FORMAT_YUV420_10BIT - Packed 10-bit YUV 420. Y followed by U
                           then V. No defined linear encoding

Please also note that in the absence of AFBC, we would still need to
add Y410, Y210 and P210.

Full rationale follows:

YUV 444 8-bit, 1-plane
----------------------
 The currently defined AYUV format encodes a 4th alpha component,
 which makes it unsuitable for representing a 3-component YUV 444
 AFBC stream.

 The proposed[1] XYUV format which is supported by Mali-DP in linear
 layout is also unsuitable, because the component order is the
 opposite of the AFBC version, and it encodes a 4th 'X' component.

 DRM_FORMAT_VUY888 is the "obvious" format for a 3-component, packed,
 YUV 444 8-bit format, with the component order which our HW expects to
 encode/decode. It conforms to the same naming convention as the
 existing packed YUV 444 format.
 The naming here is meant to be consistent with DRM_FORMAT_AYUV and
 DRM_FORMAT_XYUV[1]

YUV 444 10-bit, 1-plane
-----------------------
 There is no currently-defined YUV 444 10-bit format in
 drm_fourcc.h, irrespective of number of planes.

 The proposed[1] XVYU2101010 format which is supported by Mali-DP in
 linear layout uses the wrong component order, and also encodes a 4th
 'X' component, which doesn't match the AFBC version of YUV 444
 10-bit which we support.

 DRM_FORMAT_Y410 is the same layout as XVYU2101010, but with 2 bits of
 alpha.  This format is supported with linear layout by Mali GPUs. The
 naming follows[2].

 There is no "obvious" linear encoding for a 3-component 10:10:10
 packed format, and so DRM_FORMAT_VUY101010 defines a component
 order, but not a bit encoding. Again, the naming is meant to be
 consistent with DRM_FORMAT_AYUV.

YUV 422 8-bit, 1-plane
----------------------
 The existing DRM_FORMAT_YUYV (and the other component orders) are
 single-planar YUV 422 8-bit formats. Following the convention of
 the component orders of the RGB formats, YUYV has the correct
 component order for our AFBC encoding (Y followed by U followed by
 V). We can use YUYV for AFBC YUV 422 8-bit.

YUV 422 10-bit, 1-plane
-----------------------
 There is no currently-defined YUV 422 10-bit format in drm_fourcc.h

 DRM_FORMAT_Y210 is analogous to YUYV, but with 10-bits per sample
 packed into the upper 10-bits of 16-bit samples. This format is
 supported in both linear and AFBC by Mali GPUs.

YUV 422 10-bit, 2-plane
-----------------------
 The recently defined DRM_FORMAT_P010 format is a 10-bit semi-planar
 YUV 420 format, which has the correct component ordering for an AFBC
 2-plane YUV 420 buffer. The linear layout contains meaningless padding
 bits, which will not be encoded in an AFBC stream.

YUV 420 8-bit, 1-plane
----------------------
 There is no currently defined single-planar YUV 420, 8-bit format
 in drm_fourcc.h. There's differing opinions on whether using the
 existing fourcc-implied n_planes where possible is a good idea or
 not when using modifiers.

 For me, it's much more "obvious" to use NV12 for 2-plane AFBC and
 YUV420 for 3-plane AFBC. This keeps the aforementioned separation
 between the AFBC codec settings (in the modifier) and the pixel data
 format (in the fourcc). With different vendors using AFBC, this helps
 to ensure that there is no confusion in interoperation. It also
 ensures that the AFBC modifiers describe AFBC itself (which is a
 licensable component), and not implementation details which are not
 defined by AFBC.

 The proposed[1] X0L0 format which Mali-DP supports with Linear layout
 is unsuitable, as it contains a 4th 'X' component, and our AFBC
 decoder expects only 3 components.

 To that end, we propose a new YUV 420 8-bit format. There is no
 "obvious" linear encoding for a 3-component 8:8:8, 420, packed format,
 and so DRM_FORMAT_YUV420_8BIT defines a component order, but not a
 bit encoding. I'm happy to hear different naming suggestions.

YUV 420 8-bit, 2-, 3-plane
--------------------------
 These already exist, we can use NV12 and YUV420.

YUV 420 10-bit, 1-plane
-----------------------
 As above, no current definition exists, and X0L2 encodes a 4th 'X'
 channel.

 Analogous to DRM_FORMAT_YUV420_8BIT, we define DRM_FORMAT_YUV420_10BIT.

[1] https://lists.freedesktop.org/archives/dri-devel/2018-July/184598.html
[2] https://docs.microsoft.com/en-us/windows/desktop/medfound/10-bit-and-16-bit-yuv-video-formats

Changes since RFC v1:
 - Fix confusing subsampling vs bit-depth X:X:X notation in
   descriptions (danvet)
 - Rename DRM_FORMAT_AVYU1101010 to DRM_FORMAT_Y410 (Lisa Wu)
 - Add drm_format_info structures for the new formats, using the
   new 'bpp' field for those with non-integer bytes-per-pixel
 - Rebase, including Juha-Pekka Heikkila's format definitions

Changes since RFC v2:
- Rebase on top of latest changes in drm-misc-next
- Change the description of DRM_FORMAT_P210 in __drm_format_info and
drm_fourcc.h so as to make it consistent with other DRM_FORMAT_PXXX
formats.

Changes since v3:
- Added the ack
- Rebased on the latest drm-misc-next

Signed-off-by: Brian Starkey <brian.starkey@arm.com>
Signed-off-by: Ayan Kumar Halder <ayan.halder@arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Link: https://patchwork.freedesktop.org/patch/291759/?series=57895&rev=1

MAINTAINERS: Add an entry for the vboxvideo driver

Add a MAINTAINERS entry for the vboxvideo driver, now that it has been
moved out of staging.

Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190311163522.22045-1-hdegoede@redhat.com

drm/vboxvideo: Move the vboxvideo driver out of staging

The vboxvideo driver has been converted to the atomic modesetting API
and all FIXME and TODO items have been fixed, so it is time to move it out
of staging.

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190304164724.10210-4-hdegoede@redhat.com

staging/vboxvideo: Refactor vbox_update_mode_hints

Refactor vbox_update_mode_hints to no longer use the obsolete
drm_modeset_lock_all() and switch it over to drm_connector_list_iter
instead of directly accessing the list using list_for_each_entry.

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190304164724.10210-3-hdegoede@redhat.com

staging/vboxvideo: Drop initial_mode_queried workaround

Drop the initial_mode_queried workaround for kms clients which do not
support hotplug, all kms clients should be able to deal with hotplug.

Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190304164724.10210-2-hdegoede@redhat.com

staging/vboxvideo: Another FIXME item

Found while grepping around.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190221155951.19855-1-daniel.vetter@ffwll.ch

drm/stm: fix CONFIG_FB dependency

The DRM_STM driver can be built independently of the framebuffer
layer, but it causes a Kconfig warning:

WARNING: unmet direct dependencies detected for FB_PROVIDE_GET_FB_UNMAPPED_AREA
  Depends on [n]: HAS_IOMEM [=y] && FB [=n]
  Selected by [y]:
  - DRM_STM [=y] && HAS_IOMEM [=y] && DRM [=y] && (ARCH_STM32 [=n] || ARCH_MULTIPLATFORM [=y])

Selecting FB_PROVIDE_GET_FB_UNMAPPED_AREA actually has no effect
if CONFIG_FB is disabled, so we can make it a conditional 'select'
instead.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190307155323.2949975-1-arnd@arndb.de

drm/v3d: Add support for V3D v4.2.

No compatible string for it yet, just the version-dependent changes.
They've now tied the hub and the core interrupt lines into a single
interrupt line coming out of the block.  It also turns out I made a
mistake in modeling the V3D v3.3 and v4.1 bridge as a part of V3D
itself -- the bridge is going away in favor of an external reset
controller in a larger HW module.

v2: Use consistent checks for whether we're on 4.2, and fix a leak in
    an error path.
v3: Use more general means of determining if the current 4.2 changes
    are in place, as apparently other platforms may switch back (noted
    by Dave).  Update the binding doc.
v4: Improve error handling for IRQ init.

Signed-off-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20190308174336.7866-2-eric@anholt.net
Reviewed-by: Dave Emett <david.emett@broadcom.com>

drm/v3d: Handle errors from IRQ setup.

Noted in review by Dave Emett for V3D 4.2 support.

Signed-off-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20190308174336.7866-1-eric@anholt.net
Reviewed-by: Dave Emett <david.emett@broadcom.com>

drm/v3d: Make sure the GPU is on when measuring clocks.

You'll get garbage measurements if the registers always read back
0xdeadbeef

Signed-off-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20190220233658.986-3-eric@anholt.net
Reviewed-by: Dave Emett <david.emett@broadcom.com>

drm/v3d: Don't try to set OVRTMUOUT on V3D 4.x.

The old field is gone and the register now has a different field,
QRMAXCNT for how many TMU requests get serviced before thread switch.
We were accidentally reducing it from its default of 0x3 (4 requests)
to 0x0 (1).

v2: Skip setting the reg at all on 4.x, instead of trying to update
    only the old field.

Signed-off-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20190220233658.986-2-eric@anholt.net
Reviewed-by: Dave Emett <david.emett@broadcom.com>

Merge tag 'topic/hdr-formats-2019-03-07' of git://anongit.freedesktop.org/drm/drm-misc into drm-misc-next

Add support for Y21x and Y41x to drm core and i915, and P01x support to i915.

Signed-off-by: Sean Paul <seanpaul@chromium.org>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/f2485309-d645-bed4-95f4-e66ff312aa05@linux.intel.com

drm: export drm_timeout_abs_to_jiffies

For other driver like lima usage.

Cc: Rob Herring <robh@kernel.org>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190225140717.20586-2-yuq825@gmail.com

drm/sun4i: rgb: Change the pixel clock validation check

The current code, since commit bb43d40d7c83 ("drm/sun4i: rgb: Validate the
clock rate"), perform some validation on the pixel clock to filter out the
EDID modes provided by monitors (through bridges) that we wouldn't be able
to reach. For the usual modes, we're able to generate a perfect clock rate,
so a strict check was enough.

However, this had the side effect of preventing displays that would work
otherwise to operate properly, since we would pretty much never be able to
generate an exact rate for those displays, even though we would fall within
that panel tolerance.

This was also shown to happen for unusual modes exposed through EDIDs, for
example on eDP panels.

We can work around this by simplifying a bit the problem: no panels we've
encountered so far actually needed that check. All of them are tied to a
particular board when it is produced, and made to work with the Allwinner
BSP. That pretty much guarantees that we never have a pixel clock out of
reach.

On the other hand, the EDIDs modes that needed to be validated have always
been exposed through bridges.

Let's just use that metric to instead of validating all modes, only
validate modes when we have a bridge attached. It should be good enough for
now, while we still have room for improvements or refinements using the
display_timings structure for example for panels.

We also add a tolerance for EDID-based modes instead of doing a strict
check. This tolerance is of 0.5% which is the one advertised in the VESA
DVT and CVT specs. If that needed to be extended in the future, we can add
a custom module parameter to relax it a bit.

Fixes: bb43d40d7c83 ("drm/sun4i: rgb: Validate the clock rate")
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Tested-by: Vasily Khoruzhick <anarsoul@gmail.com> # tested on pinebook
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ec2dc2a7b3d4bd44f7a2a6e1c1813f92449a7310.1551191081.git-series.maxime.ripard@bootlin.com

drm/sun4i: Move rate variables to long long

Our clock rate variables are getting pretty close to the LONG_MAX / ULONG_MAX
limit, especially since we will start doing arithmetic on it. Move those
types to unsigned long long to be sure we don't overflow their type.

Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Tested-by: Vasily Khoruzhick <anarsoul@gmail.com> # tested on pinebook
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/022c3b850413edd6afbca20062f100971de2f5af.1551191081.git-series.maxime.ripard@bootlin.com

drm/sun4i: rgb: Store the bridge pointer

We'll need the bridge pointer, if any, in the mode_valid callback in
addition to the init function. Store the pointer to the bridge in the
rgb private structure.

Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Tested-by: Vasily Khoruzhick <anarsoul@gmail.com> # tested on pinebook
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/2f16d70fb09613b3a030fd6a016343047d519d43.1551191081.git-series.maxime.ripard@bootlin.com

drm/sun4i: Move the panel pointer from the TCON to the encoders

The TCON driver used to need the panel pointer in order to configure the
tcon according to the various parameters of the panel. However, this has
evolved over time (especially to support bridges), and therefore the panel
pointer isn't needed anymore by the TCON driver.

Move that pointer to the LVDS and RGB encoders drivers.

Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Tested-by: Vasily Khoruzhick <anarsoul@gmail.com> # tested on pinebook
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/13288b6b8f27b614a6c9aef348923c34b2803ad4.1551191081.git-series.maxime.ripard@bootlin.com

drm/vc4: Use 16bpp by default for the fbdev buffer

The preferred bpp for the fbdev emulation buffer has been 32 so far, which
means that by default we will allocate an 8MB buffer with a 1920x1080
resolution.

Worse this memory will be allocated from the CMA pool, and will never be
freed even if we don't use the fbdev emulation. Therefore, reducing it is a
big deal, and switching to 16bpp by default will gain us around 4MB at
1920x1080, while keeping decent color depth. And users still have the
option to switch to 32bpp using the kernel command line.

Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190306140245.21973-1-maxime.ripard@bootlin.com