Most importantly per-process address spaces on GPUs that are capable of
providing proper isolation has finished baking. This is the base for
our softpin implementation, which allows us to support the texture
descriptor buffers used by GC7000 series GPUs without a major UAPI
extension/rework.

Shortlog of notable changes:
- code cleanup from Fabio
- fix performance counters on GC880 and GC2000 GPUs from Christian
- drmP.h header removal from Sam
- per process address space support on MMUv2 GPUs from me
- softpin support from me
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Lucas Stach <l.stach@pengutronix.de>
Link: https://patchwork.freedesktop.org/patch/msgid/1565946875.2641.73.camel@pengutronix.de

- R-Car DU fixes
- Misc. DRM cleanups
Signed-off-by: Dave Airlie <airlied@redhat.com>

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190816133500.GJ5020@pendragon.ideasonboard.com

drm-misc-next for 5.4:

UAPI Changes:

Cross-subsystem Changes:

Core Changes:
  - dma-buf: add reservation_object_fences helper, relax
             reservation_object_add_shared_fence, remove
             reservation_object seq number (and then
             restored)
  - dma-fence: Shrinkage of the dma_fence structure,
               Merge dma_fence_signal and dma_fence_signal_locked,
               Store the timestamp in struct dma_fence in a union with
               cb_list

Driver Changes:
  - More dt-bindings YAML conversions
  - More removal of drmP.h includes
  - dw-hdmi: Support get_eld and various i2s improvements
  - gm12u320: Few fixes
  - meson: Global cleanup
  - panfrost: Few refactors, Support for GPU heap allocations
  - sun4i: Support for DDC enable GPIO
  - New panels: TI nspire, NEC NL8048HL11, LG Philips LB035Q02,
                Sharp LS037V7DW01, Sony ACX565AKM, Toppoly TD028TTEC1
                Toppoly TD043MTEA1
Signed-off-by: Dave Airlie <airlied@redhat.com>
[airlied: fixup dma_resv rename fallout]

From: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190819141923.7l2adietcr2pioct@flea

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: Nishka Dasgupta <nishkadg.linux@gmail.com>
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Reviewed-by: Oleksandr 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: Nishka Dasgupta <nishkadg.linux@gmail.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/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: Christian König <christian.koenig@amd.com>
Signed-off-by: Chris 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: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Christian König <christian.koenig@amd.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Christian 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: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Christian König <christian.koenig@amd.com>
Reviewed-by: Christian 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: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Christian König <christian.koenig@amd.com>
Reviewed-by: Christian 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: Colin Ian King <colin.king@canonical.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Sam 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Sam 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reported-by: Stephen 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

Using name "bridge" for macro bridge_to_rcar_lvds argument doesn't
work when the pointer name used by the caller is not "bridge".
Rename the argument to "b" to allow for any pointer name.

While at it, fix the connector_to_rcar_lvds macro similarly.

Fixes: c6a27fa4 ("drm: rcar-du: Convert LVDS encoder code to bridge driver")
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
[Fix connector_to_rcar_lvds]
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

DRM bridges are only used by atomic drivers, and none of them use the
legacy helpers. Drop bridge support from those helpers to prepare for
making the bridge operations atomic-aware.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>

The dw-hdmi, kirin and imx drivers include the drm/drm_encoder_slave.h
header but don't use the encoder slave API. Remove it or replace it with
drm/drm_encoder.h as needed.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

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: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190814182401.25009-1-chris@chris-wilson.co.uk

A couple of independent patches extracted from the 5.3 pull request, fixed for
merge conflicts and a single unused variable warning.

And the drmP.h removal from Sam.
Signed-off-by: Dave Airlie <airlied@redhat.com>

With softpin we allow the userspace to take control over the GPU virtual
address space. The new capability is relected by a bump of the minor DRM
version. There are a few restrictions for userspace to take into
account:

1. The kernel reserves a bit of the address space to implement zero page
faulting and mapping of the kernel internal ring buffer. Userspace can
query the kernel for the first usable GPU VM address via
ETNAVIV_PARAM_SOFTPIN_START_ADDR.

2. We only allow softpin on GPUs, which implement proper process
separation via PPAS. If softpin is not available the softpin start
address will be set to ~0.

3. Softpin is all or nothing. A submit using softpin must not use any
address fixups via relocs.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Guido Günther <agx@sigxcpu.org>

Allow the mapping code to request a specific virtual address for the gem
mapping. If the virtual address is zero we fall back to the old mode of
allocating a virtual address for the mapping.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Guido Günther <agx@sigxcpu.org>

With per-process address spaces in place, a rogue process submitting
bogus command streams can only hurt itself. There is no need to
validate the command stream before execution anymore.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Guido Günther <agx@sigxcpu.org>

This builds on top of the MMU contexts introduced earlier. Instead of having
one context per GPU core, each GPU client receives its own context.

On MMUv1 this still means a single shared pagetable set is used by all
clients, but on MMUv2 there is now a distinct set of pagetables for each
client. As the command fetch is also translated via the MMU on MMUv2 the
kernel command ringbuffer is mapped into each of the client pagetables.

As the MMU context switch is a bit of a heavy operation, due to the needed
cache and TLB flushing, this patch implements a lazy way of switching the
MMU context. The kernel does not have its own MMU context, but reuses the
last client context for all of its operations. This has some visible impact,
as the GPU can now only be started once a client has submitted some work and
we got the client MMU context assigned. Also the MMU context has a different
lifetime than the general client context, as the GPU might still execute the
kernel command buffer in the context of a client even after the client has
completed all GPU work and has been terminated. Only when the GPU is runtime
suspended or switches to another clients MMU context is the old context
freed up.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Guido Günther <agx@sigxcpu.org>

In preparation to having a context per process, etnaviv_gem_mapping_get
should not use the current GPU context, but needs to be told which
context to use.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Guido Günther <agx@sigxcpu.org>

Move buffer setup and starting of the FE loop in the kernel ringbuffer
into a separate function. This is a preparation to start the FE later
in the submit process.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Guido Günther <agx@sigxcpu.org>

This reworks the MMU handling to make it possible to have multiple MMU contexts.
A context is basically one instance of GPU page tables. Currently we have one
set of page tables per GPU, which isn't all that clever, as it has the
following two consequences:

1. All GPU clients (aka processes) are sharing the same pagetables, which means
there is no isolation between clients, but only between GPU assigned memory
spaces and the rest of the system. Better than nothing, but also not great.

2. Clients operating on the same set of buffers with different etnaviv GPU
cores, e.g. a workload using both the 2D and 3D GPU, need to map the used
buffers into the pagetable sets of each used GPU.

This patch reworks all the MMU handling to introduce the abstraction of the
MMU context. A context can be shared across different GPU cores, as long as
they have compatible MMU implementations, which is the case for all systems
with Vivante GPUs seen in the wild.

As MMUv1 is not able to change pagetables on the fly, without a
"stop the world" operation, which stops GPU, changes pagetables via CPU
interaction, restarts GPU, the implementation introduces a shared context on
MMUv1, which is returned whenever there is a request for a new context.

This patch assigns a MMU context to each GPU, so on MMUv2 systems there is
still one set of pagetables per GPU, but due to the shared context MMUv1
systems see a change in behavior as now a single pagetable set is used
across all GPU cores.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Guido Günther <agx@sigxcpu.org>

If a MMU is shared between multiple GPUs, all of them need to flush their
TLBs, so a single marker that gets reset on the first flush won't do.
Replace the flush marker with a sequence number, so that it's possible to
check if the TLB is in sync with the current page table state for each GPU.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Guido Günther <agx@sigxcpu.org>

There is no need for each GPU to have it's own cmdbuf suballocation
region. Only allocate a single one for the the etnaviv virtual device
and share it across all GPUs.

As the suballoc space is now potentially shared by more hardware jobs
running in parallel, double its size to 512KB to avoid contention.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Guido Günther <agx@sigxcpu.org>

This allows to decouple the cmdbuf suballocator create and mapping
the region into the GPU address space. Allowing multiple AS to share
a single cmdbuf suballoc.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Guido Günther <agx@sigxcpu.org>

Remember if the GPU has been sucessfully initialized. Only in that case
do we need to clean up various structures in the unbind path. If the
GPU hasn't been sucessfully initialized all the cleanups should happen
in the failure paths of the init function.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Guido Günther <agx@sigxcpu.org>

This function does only need the mmu part part of the gpu struct.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>

Due to the tracking provided by the scheduler we know exactly which
submit is failing. Only dump this single submit and the required
auxiliary information. This cuts down the size of the devcoredumps
by only including relevant information.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>

TTM provides a means to assign eviction priorities to buffer object. This
means that all buffer objects with a lower priority will be evicted first
on memory pressure.
Use this to make sure surfaces and in particular non-dirty surfaces are
evicted first. Evicting in particular shaders, cotables and contexts imply
a significant performance hit on vmwgfx, so make sure these resources are
evicted last.
Some buffer objects are sub-allocated in user-space which means we can have
many resources attached to a single buffer object or resource. In that case
the buffer object is given the highest priority of the attached resources.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>

Drop use of the deprecated drmP.h file from the
remaining files.
In several cases the drmP.h include could be removed without
furter fixes. Other files required a few header files to be added.

In all files divided includes files in blocks and sort them.

v2:
- fix warning in i386 build wiht HIGHMEM disabled
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Reported-by: kbuild test robot <lkp@intel.com> [warning in i386 build]
Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
Signed-off-by: Deepak Rawat <drawat@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>

To facilitate removal of drmP.h in the .c
files remove the use from header files first.
Fix fallout in the other files.

Sorted include files in blocks and sorted files
within each block in alphabetical order.

This revealed a dependency from an uapi header to a header
located below drivers/gpu/drm/vmwgfx/.
Added FIXME to remind someone to fix this.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
Signed-off-by: Deepak Rawat <drawat@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>

At one point, the GPU command verifier and user-space handle manager
couldn't properly protect GPU clients from accessing each other's data.
Instead there was an elaborate mechanism to make sure only the active
master's primary clients could render. The other clients were either
put to sleep or even killed (if the master had exited). VRAM was
evicted on master switch. With the advent of render-node functionality,
we relaxed the VRAM eviction, but the other mechanisms stayed in place.

Now that the GPU  command verifier and ttm object manager properly
isolates primary clients from different master realms we can remove the
master switch related code and drop those legacy features.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>

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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Sam 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Sam 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Sam 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Sam 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190813201101.30980-6-laurent.pinchart@ideasonboard.com

This panel is used on the Gumstix Overo Palo35.

The code is based on the omapdrm-specific panel-lgphilips-lb035q02
driver.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190813201101.30980-5-laurent.pinchart@ideasonboard.com