Add copyright lines for Zodiac who paid for driver development.
Signed-off-by: NAndrey Gusakov <andrey.gusakov@cogentembedded.com>
Acked-by: NChris Healy <cphealy@gmail.com>
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1510073785-16108-8-git-send-email-andrey.gusakov@cogentembedded.com

We're currently calling ktime_to_timespec64() on stack garbage
hence the debug output for vblank timestamps also contains garbage.
Let's assing something to the ktime_t first before we go converting
it to a timespec.

While at it micro-optimize the ktime_to_timespec64() calls away
when vblank debugging isn't enabled.

Fixes: 67680d3c ("drm: vblank: use ktime_t instead of timeval")
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Keith Packard <keithp@keithp.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171113150210.11311-1-ville.syrjala@linux.intel.comAcked-by: NArnd Bergmann <arnd@arndb.de>

The normal DRM vblank interrupt events started using monotonic times in
commit c61eef72 ("drm: add support for monotonic vblank timestamps"),
which is useful for a number of reasons, including the possible y2038
overflow.

The VIA_WAIT_IRQ ioctl uses the same drm_wait_vblank_reply as
DRM_IOCTL_WAIT_VBLANK, but still uses wall-clock time.

This converts it to using monotonic time as well, which is more
consistent, and avoids problems with the y2038 overflow as well
as synchronization issues when the real time skips.

I could not find the matching user space that calls the VIA_WAIT_IRQ
ioctl to verify that this is safe, but it very likely is. Please
either test or review the user space side before applying this.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171127111728.1710742-1-arnd@arndb.de

Simple va_args equivalent to the existing drm_printf() for use with the
drm_printer.

v2: Fixup kerneldoc to match final parameter names.
v3: Turn it into a kerneldoc comment
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Rob Clark <robdclark@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: Dave Airlie <airlied@redhat.com>
Acked-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123084051.30203-1-chris@chris-wilson.co.uk

Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch from
3D to 2D mode in a timely fashion if the source simply stops sending the
HDMI infoframe. The suggested workaround is to keep sending the
infoframe even when strictly not necessary (ie. no VIC and no S3D).
HDMI 1.4 does allow for this behaviour, stating that sending the
infoframe is optional in this case.

The infoframe was first specified in HDMI 1.4, so in theory sinks
predating that may not appreciate us sending an uknown infoframe
their way. To avoid regressions let's try to determine if the sink
supports the infoframe or not. Unfortunately there's no direct way
to do that, so instead we'll just check if we managed to parse any
HDMI 1.4 4k or stereo modes from the EDID, and if so we assume the
sink will accept the infoframe. Also if the EDID contains the HDMI
2.0 HDMI Forum VSDB we can assume the sink is prepared to receive
the infoframe.

v2: Fix getting has_hdmi_infoframe from display_info
    Always fail constructing the infoframe if the display
    possibly can't handle it

Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NShashank Sharma <shashank.sharma@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171113170427.4150-3-ville.syrjala@linux.intel.com

platform_get_irq_byname() can fail here and we must check its return
value.
Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/f4b4f1b2cfa5e302ef7ffad4e3efb0d3147709d3.1510914877.git.arvind.yadav.cs@gmail.com

NV12 (YUV420 2 plane) and NV16 (YUV422 2 plane) were
supported, but NV21 and NV61 (same but with Cb and Cr
swapped) weren't. Add them.
Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.org>
Signed-off-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/1f50799525e3401551dff2b0b2828b9ab892f75f.1510841336.git.dave.stevenson@raspberrypi.org

The hardware has enums for altering the Cr and Cb order,
so use this instead of having a flag which swaps the
order the pointers are presented to the hardware
(that only worked for 3 plane formats anyway).

Explicitly sets .pixel_order in each case, rather than
relying on then default XYCBCR order being a value 0.
Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.org>
Signed-off-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/563872b69c1e5df142cb15ebfca7f20056b8a64c.1510841336.git.dave.stevenson@raspberrypi.org

Filling out the list of supported formats based on those the
hardware can support.
Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.org>
Signed-off-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/b551205d1c33fa49eef2c33ed2d60c5339b2f299.1510841336.git.dave.stevenson@raspberrypi.org

drm_plane_helper_check_update() isn't a transitional helper, so let's
rename it to drm_atomic_helper_check_plane_state() and move it into
drm_atomic_helper.c.

v2: Fix the WARNs about plane_state->crtc matching crtc_state->crtc

Cc: Daniel Vetter <daniel@ffwll.ch>
Suggested-by: NDaniel Vetter <daniel@ffwll.ch>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171101201619.6175-1-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

drm_plane_helper_check_state() is supposed to do things the atomic way,
so it should not be inspecting crtc->enabled. Rather we should be
looking at crtc_state->enable.

We have a slight complication due to drm_plane_helper_check_update()
reusing drm_plane_helper_check_state() for non-atomic drivers. Thus
we'll have to pass the crtc_state in manally and construct a fake
crtc_state in drm_plane_helper_check_update().

v2: Fix the WARNs about plane_state->crtc matching crtc_state->crtc
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171101201558.6059-1-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Try to fix the code to actually clip the plane to the crtc bounds
instead of the user provided crtc coordinates (which would be a no-op
since those are exactly the coordinates before clipping).

Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Sinclair Yeh <syeh@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171101182920.14386-4-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

Atomic drivers have no reason to use drm_plane_helper_check_update()
instead of drm_plane_helper_check_state(). So let's switch over.

Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Sinclair Yeh <syeh@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171101182920.14386-3-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

Throw away the bugs crtc coords vs. fb size check. Crtc coords don't
define the viewport inside the fb, that's a job for the src coords,
which have been checked by the core already.

Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Sinclair Yeh <syeh@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171101182920.14386-2-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

There is no need to #define the license of the driver, just put it in
the MODULE_LICENSE() line directly as a text string.

This allows tools that check that the module license matches the source
code license to work properly, as there is no need to unwind the
unneeded dereference, especially when the string is defined in a .h file
far away from the .c file it is used in.

Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Cc: David Airlie <airlied@linux.ie>
Reported-by: NPhilippe Ombredanne <pombredanne@nexb.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171117141632.GA17880@kroah.com

The i2c adapter on DP AUX is purely a software construct. Linking
it to the device node of the parent device is wrong, as it leads to
2 devices sharing the same device node, which is bad practice, as
well as the i2c trying to populate children of the i2c adapter by
looking at the child device nodes of the parent device.
Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170113173630.22138-1-l.stach@pengutronix.de

The Mitsubishi AA070MC01 is a 7.0" WVGA (800x480) TFT panel working in
8 bit ISP mode (pin 19 "mode" HIGH for 20 pin TFT connector).
Signed-off-by: NLukasz Majewski <lukma@denx.de>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1508537917-1723-1-git-send-email-lukma@denx.de

The Tianma TM070RVHG71 is a 7" WVGA (800x480) TFT LCD panel connected
via LVDS and can be supported by the simple-panel binding.
Signed-off-by: NLukasz Majewski <lukma@denx.de>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171107153058.5554-1-lukma@denx.de

If the sink device is in HDMI mode, enable infoframe interrupt in scdt
irq handle function else call start_video function immediately, because
in DVI mode, there is no infoframe interrupt provided.

Rename start_hdmi function to start_video and get rid of the old
start_video function. In start_video, if the sink is DVI and mode is
MHL1 or MHl2, write appropriate values to registers else the path
should remain the same as in HDMI mode.
Signed-off-by: NMaciej Purski <m.purski@samsung.com>
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1510224822-7732-1-git-send-email-m.purski@samsung.com

The maximum pixel clock depends on the version of the connected MHL
adapter. Add mode_valid callback to filter out modes with too high pixel
clock to avoid failure in mode_fixup later.
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171109102831.19844-1-m.szyprowski@samsung.com

RK3126 vop register layout is similar with rk3036, so some feature
can reuse with rk3036.

RK3126 support two overlay plane and one hwc plane, max output
resolution is 1080p. it support IOMMU, and its IOMMU same as
rk3288's
Signed-off-by: NSandy Huang <hjc@rock-chips.com>
Reviewed-by: NMark Yao <mark.yao@rock-chips.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1510658857-90299-1-git-send-email-hjc@rock-chips.com

drm_gem_cma_prime_import_sg_table() will fail if the number of entries
in the sg_table > 1. However, you can have a device that uses an IOMMU
engine and can map a discontiguous buffer with multiple entries that
have consecutive sg_dma_addresses, effectively making it contiguous.
Allow for that scenario by testing the entries in the sg_table for
contiguous coverage.
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NLiviu Dudau <liviu.dudau@arm.com>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110133310.1225-1-Liviu.Dudau@arm.com

It's useful for syncing async connector work like link retraining.

v2: Make it work (Manasi&Ville)

Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110105313.16718-1-daniel.vetter@ffwll.ch

Use the correct name for the function argument in the docs.

Cc: Noralf Trønnes <noralf@tronnes.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114191021.15591-1-ville.syrjala@linux.intel.comAcked-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>

The introduction of: drm/framebuffer: Add framebuffer debugfs file
broke vgem. That patch assumed that all drivers had initialized the
dev->mode_config.fb_lock mutex which happens in drm_mode_config_init().
vgem doesn't need to call drm_mode_config_init().

Fix this by only creating the framebuffer debugfs file for modesetting
drivers.

Fixes: 45d58b40 ("drm/framebuffer: Add framebuffer debugfs file")
Suggested-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171113231201.26177-1-noralf@tronnes.org

On the Samsung Chromebook Plus I get this error with 4.14-rc3:

BUG: scheduling while atomic: kworker/3:1/50/0x00000002
Modules linked in:
CPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 4.14.0-0.rc3-kevin #2
Hardware name: Google Kevin (DT)
Workqueue: events analogix_dp_psr_work
Call trace:
[<ffffff80080873b0>] dump_backtrace+0x0/0x320
[<ffffff80080876e4>] show_stack+0x14/0x20
[<ffffff8008606d38>] dump_stack+0x9c/0xbc
[<ffffff80080c6b5c>] __schedule_bug+0x4c/0x70
[<ffffff80086188c0>] __schedule+0x3f0/0x458
[<ffffff8008618960>] schedule+0x38/0xa0
[<ffffff800861c20c>] schedule_hrtimeout_range_clock+0x84/0xe8
[<ffffff800861c2a0>] schedule_hrtimeout_range+0x10/0x18
[<ffffff800861bcec>] usleep_range+0x64/0x78
[<ffffff8008415a6c>] analogix_dp_transfer+0x16c/0x340
[<ffffff8008412550>] analogix_dpaux_transfer+0x10/0x18
[<ffffff80083ceb14>] drm_dp_dpcd_access+0x4c/0xf0
[<ffffff80083cf614>] drm_dp_dpcd_write+0x1c/0x28
[<ffffff8008413b98>] analogix_dp_disable_psr+0x60/0xa8
[<ffffff800840da3c>] analogix_dp_psr_work+0x4c/0x90
[<ffffff80080bb09c>] process_one_work+0x1d4/0x348
[<ffffff80080bb258>] worker_thread+0x48/0x478
[<ffffff80080c11fc>] kthread+0x12c/0x130
[<ffffff8008084290>] ret_from_fork+0x10/0x18

Changing rockchip_dp_device::psr_lock to a mutex rather
than spinlock seems to fix the issue.
Signed-off-by: NEmil Renner Berthing <kernel@esmil.dk>
Tested-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: NMark Yao <mark.yao@rock-chips.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171004175346.11956-1-kernel@esmil.dk

drm_fb_cma_debugfs_show() and drm_gem_cma_describe() are superseded
by drm_framebuffer_debugfs_init() and drm_gem_cma_print_info().

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171107191348.17555-13-noralf@tronnes.org

There is a new core debugfs file that prints fb/gem info:
<debugfs>/dri/<n>/framebuffer

Use drm_gem_cma_print_info() to provide info to that output instead
of using drm_fb_cma_debugfs_show().
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171107191348.17555-12-noralf@tronnes.org

There is a new core debugfs file that prints fb/gem info:
<debugfs>/dri/<n>/framebuffer

Use drm_gem_cma_print_info() to provide info to that output instead
of using drm_fb_cma_debugfs_show().

Cc: Jyri Sarha <jsarha@ti.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Acked-by: NJyri Sarha <jsarha@ti.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171107191348.17555-11-noralf@tronnes.org

There is a new core debugfs file that prints fb/gem info:
<debugfs>/dri/<n>/framebuffer

Use drm_gem_cma_print_info() to provide info to that output instead
of using drm_fb_cma_debugfs_show().

Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Brian Starkey <brian.starkey@arm.com>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Acked-by: NLiviu Dudau <liviu.dudau@arm.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171107191348.17555-10-noralf@tronnes.org

There is a new core debugfs file that prints fb/gem info:
<debugfs>/dri/<n>/framebuffer

Use drm_gem_cma_print_info() to provide info to that output instead
of using drm_fb_cma_debugfs_show().

Cc: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NAlexey Brodkin <abrodkin@synopsys.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171107191348.17555-9-noralf@tronnes.org

Add drm_gem_cma_print_info() for debugfs printing
struct drm_gem_cma_object specific info.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20171107191348.17555-8-noralf@tronnes.org

Use drm_framebuffer_print_info() to print framebuffer info in
drm_atomic_plane_print_state(). This will give optional GEM info as well.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171107191348.17555-6-noralf@tronnes.org

Add debugfs file that dumps info about the framebuffers and its planes.
Also dump info about any connected gem object(s).
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171107191348.17555-5-noralf@tronnes.org

Remove redundant task name copying because:

1. task->comm is already NUL-terminated
2. virtio_gpu_context_create() trims passed dbgname anyway
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Link: http://patchwork.freedesktop.org/patch/msgid/588612bbc672e8b598e10f79fcbc041122e844ba.1504202471.git.mirq-linux@rere.qmqm.plSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

Simply mmap'ing /dev/dri/card0 repeatedly will spam the kernel
log with qxl_mmap information messages. The following example code
illustrates this:

int main(void)
{
	int fd = open("/dev/dri/card0", O_RDONLY);
	if (fd == -1)
		err(1, "open failed");

	for (;;) {
		void *m = mmap(NULL, 4096, PROT_READ,
			MAP_SHARED, fd, 0);
		if (m != MAP_FAILED)
			munmap(m, 4096);
	}
}

Stop the spamming by removing the pr_info message. Since the mmap'ing
returns -EINVAL there is no need for the pr_info message.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170912173422.14062-1-colin.king@canonical.comSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

Add create_handle support to cirrus fb. Without this, screenshot tool
in chromium OS can't work.
Signed-off-by: NLepton Wu <ytht.net@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20171108185537.56167-1-ytht.net@gmail.comSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

Add create_handle support to virtio fb. Without this, screenshot tool
in chromium OS can't work.
Signed-off-by: NLepton Wu <ytht.net@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20171108184209.46211-1-ytht.net@gmail.comSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

The lease updates missed a few bits of docs, fixed up
the wrong name on the property lookup fn as well.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Use rcu_dereference_protected() and rcu_assign_pointer() for accessing
the rcu protected syncobj->fence pointer. This eliminates several sparse
warnings.

Cc: Dave Airlie <airlied@redhat.com>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Cc: linaro-mm-sig@lists.linaro.org
Cc: linux-media@vger.kernel.org
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171102200336.23347-4-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NChristian König <christian.koenig@amd.com>