Wrong DISPLAY_FLAGS used to set the data enable polarity.
Signed-off-by: NYannick Fertré <yannick.fertre@st.com>
Acked-by: NPhilippe Cornu <philippe.cornu@st.com>
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1553874620-31468-1-git-send-email-yannick.fertre@st.com

Use DRM_WARN() instead of DRM_DEBUG_DRIVER() to better
inform the user in case of fifo underruns or
transfer errors.
Signed-off-by: NPhilippe Cornu <philippe.cornu@st.com>
Acked-by: NPhilippe Cornu <philippe.cornu@st.com>
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1553874548-31366-1-git-send-email-yannick.fertre@st.com

Interrupt register must be disabled before call of
devm_request_threaded_irq function to avoid dummy interruption.
Signed-off-by: NYannick Fertré <yannick.fertre@st.com>
Acked-by: NPhilippe Cornu <philippe.cornu@st.com>
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1553874485-31259-1-git-send-email-yannick.fertre@st.com

Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190301125627.7285-4-maarten.lankhorst@linux.intel.com

We already have __drm_atomic_helper_connector_reset() and
__drm_atomic_helper_plane_reset(), extend this to crtc as well.

This will allow us to set default values in the crtc_state, without
having to do it in each driver separately.

Of all drivers that need conversion, only nouveau is done in this
commit, because it wrote its own __drm_atomic_helper_crtc_reset(),
clashing with the drm core.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20190301125627.7285-3-maarten.lankhorst@linux.intel.com

Add support the Evervision VGG804821 800x480 5.0" WVGA TFT panel.
Signed-off-by: NMarco Felsch <m.felsch@pengutronix.de>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190416100645.21689-4-m.felsch@pengutronix.de

Add device tree bindings for the Evervision VG804821 800x480 5.0" LCD
TFT parallel panel.
Signed-off-by: NMarco Felsch <m.felsch@pengutronix.de>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190416100645.21689-3-m.felsch@pengutronix.de

Evervision Electronics is a panel manufacturer from Taipei.
http://www.evervisionlcd.com/index.php?lang=enSigned-off-by: NMarco Felsch <m.felsch@pengutronix.de>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190416100645.21689-2-m.felsch@pengutronix.de

Add support for the EDT ET035012DM6 3.5" 320x240 QVGA 24-bit RGB TFT.

The datasheet with all specs can be retrieved online:
https://www.glynshop.com/erp/owweb/Daten/DSS/EDT/Products/ \
Specifications/Active%20Displays/ET035012DM6.pdf
Signed-off-by: NAndreas Pretzsch <apr@cn-eng.de>
[m.felsch@pengutronix.de: adapt commit message]
[m.felsch@pengutronix.de: rm unecessary comments]
[m.felsch@pengutronix.de: correct data_enable polarity]
Signed-off-by: NMarco Felsch <m.felsch@pengutronix.de>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190416101630.3482-2-m.felsch@pengutronix.de

Add support for the ET035012DM6 3.5" QVGA TFT LCD panel. The datasheet
can be retrieved online:

https://www.glynshop.com/erp/owweb/Daten/DSS/EDT/Products/ \
Specifications/Active%20Displays/ET035012DM6.pdf
Signed-off-by: NMarco Felsch <m.felsch@pengutronix.de>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190416101630.3482-1-m.felsch@pengutronix.de

Remove duplicate header which is included twice.
Signed-off-by: NSouptick Joarder <jrdr.linux@gmail.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1555183750-11028-1-git-send-email-jrdr.linux@gmail.com

Add support for Three Five displays TFC S9700RTWV43TR-01B 800x480
panel with resistive touch found on TI's AM335X-EVM.
Signed-off-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ba4b2c26beec014b7b3c84a27b9413cec7ef2902.1553243203.git.jsarha@ti.com

Add bindign for TFC S9700RTWV43TR-01B 7" Three Five Corp 800x480 LCD
panel with resistive touch.

The panel is found on TI AM335x-evm.
Signed-off-by: NJyri Sarha <jsarha@ti.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/24fea39438decd1e17a9c9afa320d49aca03f60d.1553243203.git.jsarha@ti.com

The EDT ETM0430G0DH6 is 4.3" 480x272 panel, which can be
supported by the simple panel driver.
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190219140438.17063-2-marex@denx.de

Document the Emerging Display Technology Corp. (EDT) ETM0430G0DH6
display, which is a 480x272 4.3" TFT display.
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Jan Tuerk <jan.tuerk@emtrion.com>
Cc: Thierry Reding <treding@nvidia.com>
Cc: devicetree@vger.kernel.org
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190219140438.17063-1-marex@denx.de

In case mipi_dsi_attach() fails remove the registered panel to avoid added
panel without corresponding device.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190226081153.31334-1-peter.ujfalusi@ti.com

The panel is similar to OSD101T2045-53TS (which is handled by panel-simple)
with one big difference: osd101t2587-53ts needs MIPI_DSI_TURN_ON_PERIPHERAL
message to be sent from the host to be operational and thus can not be
handled by panel-simple.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190226075523.28997-5-peter.ujfalusi@ti.com

This adds the device-tree bindings for the OSD101T2587-53TS 10.1"
1920x1200 panel from One Stop Displays.

Note: the panel is similar to OSD101T2045-53TS, but it needs additional
MIPI_DSI_TURN_ON_PERIPHERAL message from the host.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190226075523.28997-4-peter.ujfalusi@ti.com

Add support for the OSD101T2045-53TS 10.1" 1920x1200 panel from One Stop
Displays to the panel-simple driver
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190226075523.28997-3-peter.ujfalusi@ti.com

This adds the device-tree bindings for the OSD101T2045-53TS 10.1"
1920x1200 panel from One Stop Displays.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190226075523.28997-2-peter.ujfalusi@ti.com

This patch adds Samsung S6E63M0 AMOLED LCD panel driver, connected over
spi. It's based on already removed, non-device-tree S6E63M0 driver and
panel-samsung-ld9040. It can be found for example in some of Samsung
Aries based phones.
Signed-off-by: NPaweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190222175153.20567-2-pawel.mikolaj.chmiel@gmail.com

This commit adds documentation for Samsung S6E63M0 AMOLED LCD panel
driver.
Signed-off-by: NJonathan Bakker <xc-racer2@live.ca>
Signed-off-by: NPaweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190222175153.20567-1-pawel.mikolaj.chmiel@gmail.com

Add support for the VXT VL050-8048NT-C01 800x480 panel to the
panel-simple driver.

This panel is used on some boards manufactured by TechNexion, such as
imx7d-pico.
Reviewed-by: NOtavio Salvador <otavio@ossystems.com.br>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NFabio Estevam <festevam@gmail.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190219002706.20077-3-festevam@gmail.com

The VXT VL050-8048NT-C01 is a TFT LCD panel with a 800x480 resolution
connected via 24 width parallel interface.
Reviewed-by: NOtavio Salvador <otavio@ossystems.com.br>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NFabio Estevam <festevam@gmail.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190219002706.20077-2-festevam@gmail.com

VXT Ltd is a manufacturer of projected capacitive touch panel
and display solutions: http://www.vxt.com.tw/Reviewed-by: NOtavio Salvador <otavio@ossystems.com.br>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NFabio Estevam <festevam@gmail.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190219002706.20077-1-festevam@gmail.com

sync_dump() is an unused, unexported, function that adds 64k to the
kernel image and doesn't even provide locking around the global array it
uses.

add/remove: 0/2 grow/shrink: 0/0 up/down: 0/-65734 (-65734)
Function                                     old     new   delta
sync_dump                                    198       -    -198
sync_dump_buf                              65536       -  -65536
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20190419181904.6199-1-chris@chris-wilson.co.uk

Sam has been helping out a lot with reviewing DRM panel patches. Add him
as reviewer to help him do this important work.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Acked-by: NJagan Teki <jagan@amarulasolutions.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190416075910.12015-1-thierry.reding@gmail.com

On Hikey board all lima ip blocks are shared with one irq.
This patch avoids a NULL ptr deref crash on this platform
on startup. Tested with Weston and kmscube.
Signed-off-by: NPeter Griffin <peter.griffin@linaro.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Qiang Yu <yuq825@gmail.com>
Signed-off-by: NQiang Yu <yuq825@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1555662781-22570-7-git-send-email-peter.griffin@linaro.org

After patch "drm: Use the same mmap-range offset and size for GEM and
TTM", application failed to create bo of system memory because drm
mmap_range size decrease to 64GB from original 1TB. This is not big
enough for applications. Increase the drm mmap_range size to 1TB.
Reviewed-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NPhilip Yang <Philip.Yang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190417221507.933-1-Philip.Yang@amd.com

It is the expectation of existing userspace (X11 + Mesa, in
particular) that jobs submitted to the kernel against a shared BO will
get implicitly synchronized by their submission order.  If we want to
allow clever userspace to disable implicit synchronization, we should
do that under its own submit flag (as amdgpu and lima do).

Note that we currently only implicitly sync for the rendering pass,
not binning -- if you texture-from-pixmap in the binning vertex shader
(vertex coordinate generation), you'll miss out on synchronization.

Fixes flickering when multiple clients are running in parallel,
particularly GL apps and compositors.

v2: Fix a missing refcount on the CSD done fence for L2 cleaning.
Signed-off-by: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20190416225856.20264-6-eric@anholt.netAcked-by: NRob Clark <robdclark@gmail.com>

We only set the excl (possible-writing) fence pointer and never add a
shared (read-only) fence.
Signed-off-by: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20190416225856.20264-5-eric@anholt.netAcked-by: NRob Clark <robdclark@gmail.com>

The compute shader dispatch interface is pretty simple -- just pass in
the regs that userspace has passed us, with no CLs to run.  However,
with no CL to run it means that we need to do manual cache flushing of
the L2 after the HW execution completes (for SSBO, atomic, and
image_load_store writes that are the output of compute shaders).

This doesn't yet expose the L2 cache's ability to have a region of the
address space not write back to memory (which could be used for
shared_var storage).

So far, the Mesa side has been tested on V3D v4.2 simpenrose (passing
the ES31 tests), and on the kernel side on 7278 (failing atomic
compswap tests in a way that doesn't reproduce on simpenrose).

v2: Fix excessive allocation for the clean_job (reported by Dan
    Carpenter).  Keep refs on jobs until clean_job is finished, to
    avoid spurious MMU errors if the output BOs are freed by userspace
    before L2 cleaning is finished.
Signed-off-by: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20190416225856.20264-4-eric@anholt.netAcked-by: NRob Clark <robdclark@gmail.com>

The CL submission had two jobs embedded in an exec struct.  When I
added TFU support, I had to replicate some of the exec stuff and some
of the job stuff.  As I went to add CSD, it became clear that actually
what was in exec should just be in the two CL jobs, and it would let
us share a lot more code between the 4 queues.

v2: Fix missing error path in TFU ioctl's bo[] allocation.
Signed-off-by: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20190416225856.20264-3-eric@anholt.netAcked-by: NRob Clark <robdclark@gmail.com>

All consumers wanted drm_gem_object * now.
Signed-off-by: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20190416225856.20264-2-eric@anholt.netAcked-by: NRob Clark <robdclark@gmail.com>

Our driver makes a typical use of CMA, with GEM object allocated as
GEM CMA objects. Use DRM_GEM_CMA_VMAP_DRIVER_OPS to describe the ops
instead of duplicating them.

Because DRM_GEM_CMA_VMAP_DRIVER_OPS implements a gem_create_object op
which sets per-object funcs (drm_cma_gem_default_funcs), we can also
get rid of free_object_unlocked and gem_vm_ops, which are superseded
by the object funcs.
Signed-off-by: NPaul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190418130509.3569-1-paul.kocialkowski@bootlin.com

If a job times out in slot 0 while a reset is performed because a job
timed out in slot 1, the drm-sched core can get into a deadlock.
Signed-off-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: NRob Herring <robh@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190418084305.45021-1-tomeu.vizoso@collabora.com

Since panfrost has a 'select' on IOMMU_IO_PGTABLE_LPAE we must depend on
the same set of flags. Otherwise IOMMU_IO_PGTABLE_LPAE will be forced on
even though it cannot build (no support for cmpxchg64).

This fixes the following warning from kconfig:

WARNING: unmet direct dependencies detected for IOMMU_IO_PGTABLE_LPAE
  Depends on [n]: IOMMU_SUPPORT [=y] && (ARM || ARM64 || COMPILE_TEST [=y] && !GENERIC_ATOMIC64 [=y])
  Selected by [y]:
  - DRM_PANFROST [=y] && HAS_IOMEM [=y] && DRM [=y] && (ARM || ARM64 || COMPILE_TEST [=y]) && MMU [=y]
Reported-by: Nkbuild test robot <lkp@intel.com>
Signed-off-by: NSteven Price <steven.price@arm.com>
Signed-off-by: NRob Herring <robh@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190417152928.10790-1-steven.price@arm.com

Fix sparse warnings:
drivers/gpu/drm/panfrost/panfrost_devfreq.c:133:5:
 warning: symbol 'panfrost_devfreq_init' was not declared. Should it be static?
drivers/gpu/drm/panfrost/panfrost_devfreq.c:168:6:
 warning: symbol 'panfrost_devfreq_resume' was not declared. Should it be static?
drivers/gpu/drm/panfrost/panfrost_devfreq.c:182:6:
 warning: symbol 'panfrost_devfreq_suspend' was not declared. Should it be static?
drivers/gpu/drm/panfrost/panfrost_devfreq.c:212:6:
 warning: symbol 'panfrost_devfreq_record_transition' was not declared. Should it be static?
Signed-off-by: NSteven Price <steven.price@arm.com>
Signed-off-by: NRob Herring <robh@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/7c9d75dd-ec67-4491-ca0c-79743211f308@arm.com

Fix sparse warning:

drivers/gpu/drm/panfrost/panfrost_gem.c:17:6:
 warning: symbol 'panfrost_gem_free_object' was not declared. Should it be static?
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Reviewed-by: NSteven Price <steven.price@arm.com>
Reviewed-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: NRob Herring <robh@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190416150051.34092-1-yuehaibing@huawei.com

As explained by Robin Murphy:
> the IOMMU shutdown disables paging, so if the VOP is still
> scanning out then that will result in whatever IOVAs it was using now going
> straight out onto the bus as physical addresses.

We had a more radical approach before in commit
7f3ef5de ("drm/rockchip: Allow driver to be shutdown on reboot/kexec")
but that resulted in new warnings and oopses on shutdown on rk3399
chromeos devices.

So second try is resurrecting Vicentes shutdown change which should
achieve the same result but in a less drastic way.

Fixes: 63238173 ("Revert "drm/rockchip: Allow driver to be shutdown on reboot/kexec"")
Cc: Jeffy Chen <jeffy.chen@rock-chips.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Brian Norris <briannorris@chromium.org>
Cc: Doug Anderson <dianders@chromium.org>
Cc: stable@vger.kernel.org
Suggested-by: NJeffyChen <jeffy.chen@rock-chips.com>
Suggested-by: NRobin Murphy <robin.murphy@arm.com>
Signed-off-by: NVicente Bergas <vicencb@gmail.com>
[adapted commit message to explain the history]
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NBrian Norris <briannorris@chromium.org>
Tested-by: NDouglas Anderson <dianders@chromium.org>
Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190402113753.10118-1-heiko@sntech.de