The original HiKey (620) board has had a long running issue
where when using a 1080p montior, the display would occasionally
blink and come come back with a horizontal offset (usually also
shifting the colors, depending on the value of the offset%4).

After lots of analysis by HiSi developers, they found the issue
was due to when running at 1080p, it was possible to hit the
device memory bandwidth limits, which could cause the DSI signal
to get out of sync.

Unfortunately the DSI logic doesn't have the ability to
automatically recover from this situation, but we can get a an
LDI underflow interrupt when it happens.

To then correct the issue, when we get an LDI underflow irq, we
we can simply suspend and resume the display, which resets the
hardware.

Thus, this patch enables the ldi underflow interrupt, and
initializes a workqueue that is used to suspend/resume the
display to recover. Then when the irq occurs we clear it and
schedule the workqueue to reset display engine.

Cc: Rongrong Zou <zourongrong@gmail.com>
Cc: Xinliang Liu <z.liuxinliang@hisilicon.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel <dri-devel@lists.freedesktop.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Acked-by: NXinliang Liu <z.liuxinliang@hisilicon.com>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NDa Lv <lvda3@hisilicon.com>
Signed-off-by: NYidong Lin <linyidong@huawei.com>
[jstultz: Reworded the commit message, checkpatch cleanups]
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190820230626.23253-2-john.stultz@linaro.org

TTM assumes that drivers initialize the embedded GEM object before
calling the ttm_bo_init() function. This is not currently the case
in the Nouveau driver. Fix this by splitting up nouveau_bo_new()
into nouveau_bo_alloc() and nouveau_bo_init() so that the GEM can
be initialized before TTM BO initialization when necessary.

Fixes: b96f3e7c ("drm/ttm: use gem vma_node")
Acked-by: NGerd Hoffmann <kraxel@redhat.com>
Acked-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190814093524.GA31345@ulmo

This patch update describe panel/port links, including
unit addresses in documentation of device tree bindings
for the rockchip DSI controller based on the Synopsys
DesignWare MIPI DSI host controller.
Signed-off-by: NNickey Yang <nickey.yang@rock-chips.com>
Reviewed-by: NBrian Norris <briannorris@chromium.org>
Reviewed-by: NRob Herring <robh@kernel.org>
[this seems to have gotten lost when the original dsi-series was applied]
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20181001123845.11818-5-heiko@sntech.de

The dma-fence selftest uses an on-stack timer that requires explicit
annotation for debugobjects.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111442Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20190820122118.13698-1-chris@chris-wilson.co.uk

The 'memory-region' property of the komeda display driver DT binding
allows the use of a 'reserved-memory' node for buffer allocations. Add
the requisite of_reserved_mem_device_{init,release} calls to actually
make use of the memory if present.

Changes since v1:
 - Move handling inside komeda_parse_dt
Signed-off-by: NMihail Atanassov <mihail.atanassov@arm.com>
Signed-off-by: NAyan Kumar Halder <ayan.halder@arm.com>
Reviewed-by: NJames Qian Wang (Arm Technology China) <james.qian.wang@arm.com>
Link:- https://patchwork.kernel.org/patch/11076413/

Use the %zu format specifier for a size_t returned by sizeof.

Reported-by: kbuild-all@01.org
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20190819195740.27608-1-chris@chris-wilson.co.uk

Use the new cec_notifier_cec_adap_(un)register() functions to
(un)register the notifier for the CEC adapter.

Also adds CEC_CAP_CONNECTOR_INFO capability to the adapter.

Changes since v3:
	- add CEC_CAP_CONNECTOR_INFO to cec_allocate_adapter,
	- replace CEC_CAP_LOG_ADDRS | CEC_CAP_TRANSMIT |
	CEC_CAP_RC | CEC_CAP_PASSTHROUGH with CEC_CAP_DEFAULTS.
Signed-off-by: NDariusz Marcinkiewicz <darekm@google.com>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Tested-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190814104520.6001-4-darekm@google.com

Use the new cec_notifier_conn_(un)register() functions to
(un)register the notifier for the HDMI connector, and fill in
the cec_connector_info.

Changes since v6:
        - move cec_notifier_conn_unregister to a bridge detach
	  function,
	- add a mutex protecting a CEC notifier.
Changes since v4:
	- typo fix
Changes since v2:
	- removed unnecessary NULL check before a call to
	cec_notifier_conn_unregister,
	- use cec_notifier_phys_addr_invalidate to invalidate physical
	address.
Changes since v1:
	Add memory barrier to make sure that the notifier
	becomes visible to the irq thread once it is fully
	constructed.
Signed-off-by: NDariusz Marcinkiewicz <darekm@google.com>
Acked-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Tested-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190814104520.6001-9-darekm@google.com

Include the DMABUF_SELFTESTS as part of the standard build for IGT, so
that they can be run by igt/dmabuf

Testcase: igt/dmabuf
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190819171900.4501-1-chris@chris-wilson.co.uk

This improves Sphinx output in two ways:

- It avoids an unmatched single-quote ('), about which Sphinx complained:

    Documentation/gpu/drm-internals.rst:298:
    WARNING: Could not lex literal_block as "c". Highlighting skipped.

  An alternative approach would be to replace "can't" with a word that
  doesn't have a single-quote.

- It lets Sphinx format the comments in italics and grey, making the
  code slightly easier to read.
Signed-off-by: NJonathan Neuschäfer <j.neuschaefer@gmx.net>
Acked-by: Daniel Vetter <daniel@ffwll.ch> [via irc]
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190808163629.14280-1-j.neuschaefer@gmx.net

Exercise the dma-fence API exported to drivers.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20190819095928.32091-2-chris@chris-wilson.co.uk

In light of recent review slip ups, the absence of a suite of tests for
dma-buf became apparent. Given the current plethora of testing
frameworks, opt for one already in use by Intel's CI and so allow easy
hook up into igt.

We introduce a new module that when loaded will execute the list of
selftests and their subtest. The names of the selftests are put into the
modinfo as parameters so that igt can identify each, and run them
independently, principally for ease of error reporting.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20190819095928.32091-1-chris@chris-wilson.co.uk

The devfreq opp table needs to be removed when unloading the driver to
free the memory associated with it.
Signed-off-by: NSteven Price <steven.price@arm.com>
Signed-off-by: NRob Herring <robh@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190816093107.30518-3-steven.price@arm.com

If there is no regulator defined for the GPU then still control the
frequency using the supplied clock.

Some boards have clock control but no (direct) control of the regulator.
For example the HiKey960 uses a mailbox protocol to a MCU to control
frequencies and doesn't directly control the voltage. This patch allows
frequency control of the GPU on this system.
Signed-off-by: NSteven Price <steven.price@arm.com>
Signed-off-by: NRob Herring <robh@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190816093107.30518-1-steven.price@arm.com

Up until now, a single shared GPU address space was used. This is not
ideal as there's no protection between processes and doesn't work for
supporting the same GPU/CPU VA feature. Most importantly, this will
hopefully mitigate Alyssa's fear of WebGL, whatever that is.

Most of the changes here are moving struct drm_mm and struct
panfrost_mmu objects from the per device struct to the per FD struct.
The critical function is panfrost_mmu_as_get() which handles allocating
and switching the h/w address spaces.

There's 3 states an AS can be in: free, allocated, and in use. When a
job runs, it requests an address space and then marks it not in use when
job is complete(but stays assigned). The first time thru, we find a free
AS in the alloc_mask and assign the AS to the FD. Then the next time
thru, we most likely already have our AS and we just mark it in use with
a ref count. We need a ref count because we have multiple job slots. If
the job/FD doesn't have an AS assigned and there are no free ones, then
we pick an allocated one not in use from our LRU list and switch the AS
from the old FD to the new one.

Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Steven Price <steven.price@arm.com>
Signed-off-by: NRob Herring <robh@kernel.org>
Acked-by: NAlyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: NSteven Price <steven.price@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190813150115.30338-1-robh@kernel.org

Add the missing unlock before return from function panfrost_mmu_map_fault_addr()
in the error handling case.

Fixes: 187d2929 ("drm/panfrost: Add support for GPU heap allocations")
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Reviewed-by: NSteven Price <steven.price@arm.com>
Signed-off-by: NRob Herring <robh@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190814044814.102294-1-weiyongjun1@huawei.com

Static structure dlfb_ops, of type fb_ops, is not used except to be
copied into another variable. Hence make dlfb_ops constant to protect it
from unintended modification.
Issue found with Coccinelle.
Signed-off-by: NNishka Dasgupta <nishkadg.linux@gmail.com>
Cc: Bernie Thompson <bernie@plugable.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190819075236.1051-1-nishkadg.linux@gmail.com

One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:

struct mmp_path {
	...
        struct mmp_overlay overlays[0];
};

size = sizeof(struct mmp_path) + count * sizeof(struct mmp_overlay);
instance = kzalloc(size, GFP_KERNEL)

Instead of leaving these open-coded and prone to type mistakes, we can
now use the new struct_size() helper:

instance = kzalloc(struct_size(instance, overlays, count), GFP_KERNEL)

Notice that, in this case, variable size is not necessary, hence it
is removed.

This code was detected with the help of Coccinelle.
Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190807161312.GA26835@embeddedor

This is dead code since 3.15. If there is no plan to use
it further, this can be removed forever.
Signed-off-by: NSouptick Joarder <jrdr.linux@gmail.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
[b.zolnierkie: fix patch summary]
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1564515200-5020-1-git-send-email-jrdr.linux@gmail.com

This is dead code since 3.15. If there is no plan to use it
further, this can be removed forever.
Signed-off-by: NSouptick Joarder <jrdr.linux@gmail.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: Mikulas Patocka <mpatocka@redhat.com>
Cc: "Ville Syrjälä" <syrjala@sci.fi>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
[b.zolnierkie: fix patch summary]
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1564514053-4571-1-git-send-email-jrdr.linux@gmail.com

Now that -Wimplicit-fallthrough is passed to GCC by default, the
following warnings shows up:

../drivers/video/fbdev/sh_mobile_lcdcfb.c: In function ‘sh_mobile_lcdc_channel_fb_init’:
../drivers/video/fbdev/sh_mobile_lcdcfb.c:2086:22: warning: this statement may fall
 through [-Wimplicit-fallthrough=]
   info->fix.ypanstep = 2;
   ~~~~~~~~~~~~~~~~~~~^~~
../drivers/video/fbdev/sh_mobile_lcdcfb.c:2087:2: note: here
  case V4L2_PIX_FMT_NV16:
  ^~~~
../drivers/video/fbdev/sh_mobile_lcdcfb.c: In function ‘sh_mobile_lcdc_overlay_fb_init’:
../drivers/video/fbdev/sh_mobile_lcdcfb.c:1596:22: warning: this statement may fall
 through [-Wimplicit-fallthrough=]
   info->fix.ypanstep = 2;
   ~~~~~~~~~~~~~~~~~~~^~~
../drivers/video/fbdev/sh_mobile_lcdcfb.c:1597:2: note: here
  case V4L2_PIX_FMT_NV16:
  ^~~~

Rework to address a warnings due to the enablement of
-Wimplicit-fallthrough.
Signed-off-by: NAnders Roxell <anders.roxell@linaro.org>
Cc: Gustavo A. R. Silva <gustavo@embeddedor.com>
[b.zolnierkie: fix patch summary]
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190730152530.3055-1-anders.roxell@linaro.org

Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.
Signed-off-by: NChuhong Yuan <hslester96@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[b.zolnierkie: fix patch summary and intendation]
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190724131900.2039-1-hslester96@gmail.com

Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.
Signed-off-by: NChuhong Yuan <hslester96@gmail.com>
Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Cc: Teddy Wang <teddy.wang@siliconmotion.com>
[b.zolnierkie: fix patch summary]
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190724131744.1709-1-hslester96@gmail.com

There is no need to compare *var->xoffset* or *var->yoffset* with < 0
because such variables are of type unsigned, making it impossible to
hold a negative value.

Fix this by removing such comparisons.

Addresses-Coverity-ID: 1451964 ("Unsigned compared against 0")
Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190722203358.GA29111@embeddedor

For various reasons, at least with x86 EFI firmwares, the xoffset and
yoffset in the BGRT info are not always reliable.

Extensive testing has shown that when the info is correct, the
BGRT image is always exactly centered horizontally (the yoffset variable
is more variable and not always predictable).

This commit simplifies / improves the bgrt_sanity_check to simply
check that the BGRT image is exactly centered horizontally and skips
(re)drawing it when it is not.

This fixes the BGRT image sometimes being drawn in the wrong place.

Cc: stable@vger.kernel.org
Fixes: 88fe4ceb ("efifb: BGRT: Do not copy the boot graphics for non native resolutions")
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Cc: Peter Jones <pjones@redhat.com>,
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190721131918.10115-1-hdegoede@redhat.com

Static structure fb_funcs, of type drm_framebuffer_funcs, is used only
when it is passed to drm_gem_fb_create_with_funcs() as its last
argument. drm_gem_fb_create_with_funcs does not modify its lst argument
(fb_funcs) and hence fb_funcs is never modified. Therefore make fb_funcs
constant to protect it from further modification.
Issue found with Coccinelle.
Signed-off-by: NNishka Dasgupta <nishkadg.linux@gmail.com>
Signed-off-by: NOleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Reviewed-by: NOleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190813062712.24993-1-nishkadg.linux@gmail.com

The static structure vbox_fb_helper_funcs, of type drm_fb_helper_funcs,
is used only when it is passed as the third argument to
drm_fb_helper_fbdev_setup(), which does not modify it. Hence make it
constant to protect it from unintended modifications.
Issue found with Coccinelle.
Signed-off-by: NNishka Dasgupta <nishkadg.linux@gmail.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190813062548.24770-1-nishkadg.linux@gmail.com

The timestamp and the cb_list are mutually exclusive, the cb_list can
only be added to prior to being signaled (and once signaled we drain),
while the timestamp is only valid upon being signaled. Both the
timestamp and the cb_list are only valid while the fence is alive, and
as soon as no references are held can be replaced by the rcu_head.

By reusing the union for the timestamp, we squeeze the base dma_fence
struct to 64 bytes on x86-64.

v2: Sort the union chronologically
Suggested-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Christian König <christian.koenig@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>.
Link: https://patchwork.freedesktop.org/patch/msgid/20190817153022.5749-1-chris@chris-wilson.co.uk

Currently dma_fence_signal() tries to avoid the spinlock and only takes
it if absolutely required to walk the callback list. However, to allow
for some users to surreptitiously insert lazy signal callbacks that
do not depend on enabling the signaling mechanism around every fence,
we always need to notify the callbacks on signaling. As such, we will
always need to take the spinlock and dma_fence_signal() effectively
becomes a clone of dma_fence_signal_locked().

v2: Update the test_and_set_bit() before entering the spinlock.
v3: Drop the test_[and_set]_bit() before the spinlock, it's a caller
error so expected to be very unlikely.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Christian König <christian.koenig@amd.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190817152300.5370-1-chris@chris-wilson.co.uk

Before we notify the fence signal callback, we remove the cb from the
list. However, since we are processing the entire list from underneath
the spinlock, we do not need to individual delete each element, but can
simply reset the link and the entire list.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Christian König <christian.koenig@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190817144736.7826-4-chris@chris-wilson.co.uk

Rearrange the couple of 32-bit atomics hidden amongst the field of
pointers that unnecessarily caused the compiler to insert some padding,
shrinks the size of the base struct dma_fence from 80 to 72 bytes on
x86-64.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Christian König <christian.koenig@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190817144736.7826-3-chris@chris-wilson.co.uk

Variable val is initialized to a value in a for-loop that is
never read and hence it is redundant. Remove it.

Addresses-Coverity: ("Unused value")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190817122124.29650-1-colin.king@canonical.com

drm_panel-based drivers for the ACX565AKM, LB035Q02, LS037V7DW01,
NL8048HL11, TD028TTEC1 and TD043MTEA1 are available, remove the
omapdrm-specific drivers.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190816122228.9475-3-laurent.pinchart@ideasonboard.com

Standard DRM panel drivers for several panels used by omapfb2 are now
available. Their module name clashes with the modules from
drivers/video/fbdev/omap2/omapfb/displays, part of the deprecated omapfb2
fbdev driver. As omapfb2 can only be compiled when the omapdrm driver is
disabled, and the DRM panel drivers are useless in that case, make the
omapfb2 panels depend on the standard DRM panels being disabled to fix
the name clash.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Fixes: dc2e1e5b ("drm/panel: Add driver for the Toppoly TD043MTEA1 panel")
Fixes: 415b8dd0 ("drm/panel: Add driver for the Toppoly TD028TTEC1 panel")
Fixes: 1c8fc3f0 ("drm/panel: Add driver for the Sony ACX565AKM panel")
Fixes: c9cf4c2a ("drm/panel: Add driver for the Sharp LS037V7DW01 panel")
Fixes: df439abe ("drm/panel: Add driver for the NEC NL8048HL11 panel")
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> [added tags]
Link: https://patchwork.freedesktop.org/patch/msgid/20190816122228.9475-2-laurent.pinchart@ideasonboard.com

This reverts
67c97fb7 ("dma-buf: add reservation_object_fences helper")
dd7a7d1f ("drm/i915: use new reservation_object_fences helper")
0e1d8083 ("dma-buf: further relax reservation_object_add_shared_fence")
5d344f58 ("dma-buf: nuke reservation_object seq number")

The scenario that defeats simply grabbing a set of shared/exclusive
fences and using them blissfully under RCU is that any of those fences
may be reallocated by a SLAB_TYPESAFE_BY_RCU fence slab cache. In this
scenario, while keeping the rcu_read_lock we need to establish that no
fence was changed in the dma_resv after a read (or full) memory barrier.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NChristian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190814182401.25009-1-chris@chris-wilson.co.uk

This panel is used on the OMAP3 Pandora.

The code is based on the omapdrm-specific panel-tpo-td043mtea1 driver.

v2:
- fix checkpatch warnings
  o (lcd == NULL) => (!lcd) (sam)
  o alignment to open '(' (sam)
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190813201101.30980-10-laurent.pinchart@ideasonboard.com

This panel is used on the OpenMoko Neo FreeRunner and Neo 1973.

The code is based on the omapdrm-specific panel-tpo-td028ttec1 driver.

v2:
- fix checkpatch warnings:
  o (lcd == NULL) => (!lcd) (sam)
  o (1 << X) => BIT(X) (sam)
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190813201101.30980-9-laurent.pinchart@ideasonboard.com

This panel is used on the Nokia N900.

The code is based on the omapdrm-specific panel-sony-acx565akm driver.
The hardware-related logic has been changed as little as possible to
avoid regressions as hardware availability is lacking to test the
changes. Follow-up patches should address the items listed in the TODO
list.

v2:
- fix checkpatch warning (lcd == NULL) => (!lcd) (sam)
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190813201101.30980-8-laurent.pinchart@ideasonboard.com

This panel is used on the TI SDP3430 board.

The code is based on the omapdrm-specific panel-sharp-ls037v7dw01
driver.

v2:
- fix checkpatch warning (lcd == NULL) => (!lcd) (sam)
- drop __exit_p() from remove. It caused a build warning.
  And no other panel drivers needs this (sam)
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190813201101.30980-7-laurent.pinchart@ideasonboard.com

This panel is used on the Zoom2/3/3630 SDP boards.

The code is based on the omapdrm-specific panel-nec-nl8048hl11 driver

v2:
- fix checkpatch warning (lcd == NULL) => (!lcd) (sam)
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190813201101.30980-6-laurent.pinchart@ideasonboard.com