This patch does not change current behaviour.

The driver's job timeout handler now returns
status indicating back to the DRM layer whether
the device (GPU) is no longer available, such as
after it's been unplugged, or whether all is
normal, i.e. current behaviour.

All drivers which make use of the
drm_sched_backend_ops' .timedout_job() callback
have been accordingly renamed and return the
would've-been default value of
DRM_GPU_SCHED_STAT_NOMINAL to restart the task's
timeout timer--this is the old behaviour, and is
preserved by this patch.

v2: Use enum as the status of a driver's job
    timeout callback method.

v3: Return scheduler/device information, rather
    than task information.

Cc: Alexander Deucher <Alexander.Deucher@amd.com>
Cc: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Russell King <linux+etnaviv@armlinux.org.uk>
Cc: Christian Gmeiner <christian.gmeiner@gmail.com>
Cc: Qiang Yu <yuq825@gmail.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Steven Price <steven.price@arm.com>
Cc: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Cc: Eric Anholt <eric@anholt.net>
Reported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NLuben Tuikov <luben.tuikov@amd.com>
Acked-by: NAlyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Acked-by: NSteven Price <steven.price@arm.com>
Signed-off-by: NChristian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/415095/

The devm_memremap() function never returns NULL, it returns error
pointers so the test needs to be fixed.  Also we need to call
pci_release_regions() to avoid a memory leak.

Fixes: be4f77ac ("drm/vmwgfx: Cleanup fifo mmio handling")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NZack Rusin <zackr@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/YA6FMboLhnE3uSvb@mwanda

The CEC and hotplug interrupts were missing when that binding was
introduced, let's add them in now that we've figured out how it works.
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Acked-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Acked-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Tested-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111142309.193441-14-maxime@cerno.tech

We introduced the BCM2711 support to the vc4 HDMI controller with 5.10,
but this was lacking any of the interrupts of the CEC controller so we
have to deal with the backward compatibility.

Do so by simply ignoring the CEC setup if the DT doesn't have the
interrupts property.
Reviewed-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Acked-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Tested-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111142309.193441-13-maxime@cerno.tech

Now that our HDMI controller supports CEC for the BCM2711, let's remove
that flag.
Reviewed-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: NDom Cobley <popcornmix@gmail.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Acked-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Tested-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111142309.193441-12-maxime@cerno.tech

The HDMI controller found in the BCM2711 has an external interrupt
controller for the CEC and hotplug interrupt shared between the two
instances.

Let's add a variant flag to register a single interrupt handler and
deals with the interrupt handler setup, or two interrupt handlers
relying on an external irqchip.
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Reviewed-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Acked-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Tested-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111142309.193441-11-maxime@cerno.tech

The BCM2711 has two different interrupt sources to transmit and receive
CEC messages, provided through an external interrupt chip shared between
the two HDMI interrupt controllers.

The rest of the CEC controller is identical though so we need to change
a bit the code organisation to share the code as much as possible, yet
still allowing to register independent handlers.
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Reviewed-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Acked-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Tested-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111142309.193441-10-maxime@cerno.tech

While the BCM2835 had the CEC clock derived from the HSM clock, the
BCM2711 has a dedicated parent clock for it.

Let's introduce a separate clock for it so that we can handle both
cases.
Reviewed-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Acked-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Tested-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111142309.193441-9-maxime@cerno.tech

As part of the enable sequence we might change the HSM clock rate if the
pixel rate is different than the one we were already dealing with.

On the BCM2835 however, the CEC clock derives from the HSM clock so any
rate change will need to be reflected in the CEC clock divider to output
40kHz.

Fixes: cd4cb49d ("drm/vc4: hdmi: Adjust HSM clock rate depending on pixel rate")
Reviewed-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Acked-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Tested-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111142309.193441-8-maxime@cerno.tech

The CEC clock divider needs to output a frequency of 40kHz from the HSM
rate on the BCM2835. The driver used to have a fixed frequency for it,
but that changed for the BCM2711 and we now need to compute it
dynamically to maintain the proper rate.

Fixes: cd4cb49d ("drm/vc4: hdmi: Adjust HSM clock rate depending on pixel rate")
Reviewed-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Acked-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Tested-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111142309.193441-7-maxime@cerno.tech

Currently we call cec_phys_addr_invalidate on a hotplug deassert.
That may be due to a TV power cycling, or an AVR being switched
on (and switching edid).

This makes CEC unusable since our controller wouldn't have a physical
address anymore.

Set it back up again on the hotplug assert.

Fixes: 15b4511a ("drm/vc4: add HDMI CEC support")
Signed-off-by: NDom Cobley <popcornmix@gmail.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Acked-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Acked-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Tested-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111142309.193441-6-maxime@cerno.tech

The commit 311e305f ("drm/vc4: hdmi: Implement a register layout
abstraction") forgot one CEC register, and made a copy and paste mistake
for another one. Fix those mistakes.

Fixes: 311e305f ("drm/vc4: hdmi: Implement a register layout abstraction")
Reviewed-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: NDom Cobley <popcornmix@gmail.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Acked-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Tested-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111142309.193441-5-maxime@cerno.tech

The code prior to 311e305f ("drm/vc4: hdmi: Implement a register
layout abstraction") was relying on the fact that the register offset
was incremented by 4 for each readl call. That worked since the register
width is 4 bytes.

However, since that commit the HDMI_READ macro is now taking an enum,
and the offset doesn't increment by 4 but 1 now. Divide the index by 4
to fix this.

Fixes: 311e305f ("drm/vc4: hdmi: Implement a register layout abstraction")
Reviewed-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: NDom Cobley <popcornmix@gmail.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Acked-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Tested-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111142309.193441-4-maxime@cerno.tech

The hdmi reset got moved to a later point in the commit 9045e91a
("drm/vc4: hdmi: Add reset callback").

However, the reset now occurs after vc4_hdmi_cec_init and so tramples
the setup of registers like HDMI_CEC_CNTRL_1

This only affects pi0-3 as on pi4 the cec registers are in a separate
block

Fixes: 9045e91a ("drm/vc4: hdmi: Add reset callback")
Reviewed-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: NDom Cobley <popcornmix@gmail.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Acked-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Tested-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111142309.193441-3-maxime@cerno.tech

The 'r' in dsi_vc_send_short() is of type 'unsigned int', so the
'r < 0' can't be true.

Fix this by introducing a 'err' of type 'int' insteaded.

Fixes: 1ed62538 ("drm/omap: dsi: switch dsi_vc_send_long/short to mipi_dsi_msg")
Signed-off-by: NMenglong Dong <dong.menglong@zte.com.cn>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210127015117.23267-1-dong.menglong@zte.com.cn

Add a new entry for "type" in the section for standard plane properties.

v3: improve paragraph about mixing legacy IOCTLs with explicit usage,
note that a driver may support cursors without cursor planes (Daniel)

v4: fixing rebase gone wrong

v5:
- Fix typo (Daniel)
- Mention CAP_ATOMIC instead of CAP_UNIVERSAL_PLANES when referring to
  atomic test-only commits (Daniel)
- Add newlines at end of sections (Daniel)
Signed-off-by: NSimon Ser <contact@emersion.fr>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NPekka Paalanen <pekka.paalanen@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210115110626.12233-2-contact@emersion.fr

The docs for enum drm_plane_type mention legacy IOCTLs, however the
plane type is not tied to legacy IOCTLs, the drm_cursor.primary and
cursor fields are. Add a small paragraph to reference these.

Instead, document expectations for primary and cursor planes for
non-legacy userspace. Note that these docs are for driver developers,
not userspace developers, so internal kernel APIs are mentionned.
Signed-off-by: NSimon Ser <contact@emersion.fr>
Reviewed-by: NDaniel Vetter <daniel@ffwll.ch>
Acked-by: NPekka Paalanen <pekka.paalanen@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210115110626.12233-1-contact@emersion.fr

NXP's i.MX8MM has an LCDIF as well.
Signed-off-by: NMarek Vasut <marex@denx.de>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NRob Herring <robh@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210115222304.5427-4-laurent.pinchart@ideasonboard.com

Additional compatible strings have been added in DT source for the
i.MX6SL, i.MX6SLL, i.MX6UL and i.MX7D without updating the bindings.
Most of the upstream DT sources use the fsl,imx28-lcdif compatible
string, which mostly predates the realization that the LCDIF in the
i.MX6 and newer SoCs have extra features compared to the i.MX28.

Update the bindings to add the missing compatible strings, with the
correct fallback values. This fails to validate some of the upstream DT
sources. Instead of adding the incorrect compatible fallback to the
binding, the sources should be updated separately.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NRob Herring <robh@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210115222304.5427-3-laurent.pinchart@ideasonboard.com

Convert the mxsfb binding to YAML. The deprecated binding is dropped, as
neither the DT sources nor the driver support it anymore. The converted
binding is named fsl,lcdif.yaml to match the usual bindings naming
scheme.

The compatible strings are messy, and DT sources use different kinds of
combination of documented and undocumented values. Keep it simple for
now, and update the example to make it valid. Aligning the binding with
the existing DT sources will be performed separately.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NRob Herring <robh@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210115222304.5427-2-laurent.pinchart@ideasonboard.com

The simple_ondemand devfreq governor uses two thresholds to decide about
the frequency change: upthreshold, downdifferential. These two tunable
change the behavior of the governor decision, e.g. how fast to increase
the frequency or how rapidly limit the frequency. This patch adds needed
governor data with thresholds values gathered experimentally in different
workloads.
Signed-off-by: NLukasz Luba <lukasz.luba@arm.com>
Reviewed-by: NSteven Price <steven.price@arm.com>
Signed-off-by: NSteven Price <steven.price@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210121170445.19761-1-lukasz.luba@arm.com

The explicit out-fences in crtc are signaled as part of vblank event,
indicating all framebuffers present on the Atomic Commit request are
scanned out on the screen. Though the fence signal and the vblank event
notification happens at the same time, triggered by the same hardware
vsync event, the timestamp set in both are different. With drivers
supporting precise vblank timestamp the difference between the two
timestamps would be even higher. This might have an impact on use-mode
frameworks using these fence timestamps for purposes other than simple
buffer usage. For instance, the Android framework [1] uses the
retire-fences as an alternative to vblank when frame-updates are in
progress. Set the fence timestamp during send vblank event using a new
drm_send_event_timestamp_locked variant to avoid discrepancies.

[1] https://android.googlesource.com/platform/frameworks/native/+/master/
services/surfaceflinger/Scheduler/Scheduler.cpp#397

Changes in v2:
- Use drm_send_event_timestamp_locked to update fence timestamp
- add more information to commit text

Changes in v3:
- use same backend helper function for variants of drm_send_event to
avoid code duplications

Changes in v4:
- remove WARN_ON from drm_send_event_timestamp_locked
Signed-off-by: NVeera Sundaram Sankaran <veeras@codeaurora.org>
Reviewed-by: NJohn Stultz <john.stultz@linaro.org>
Signed-off-by: NSumit Semwal <sumit.semwal@linaro.org>
  [sumits: minor parenthesis alignment correction]
Link: https://patchwork.freedesktop.org/patch/msgid/1610757107-11892-2-git-send-email-veeras@codeaurora.org

Some drivers have hardware capability to get the precise HW timestamp
of certain events based on which the fences are triggered. The delta
between the event HW timestamp & current HW reference timestamp can
be used to calculate the timestamp in kernel's CLOCK_MONOTONIC time
domain. This allows it to set accurate timestamp factoring out any
software and IRQ latencies. Add a timestamp variant of fence signal
function, dma_fence_signal_timestamp to allow drivers to update the
precise timestamp for fences.

Changes in v2:
- Add a new fence signal variant instead of modifying fence struct

Changes in v3:
- Add timestamp domain information to commit-text and
dma_fence_signal_timestamp documentation
Signed-off-by: NVeera Sundaram Sankaran <veeras@codeaurora.org>
Reviewed-by: NJohn Stultz <john.stultz@linaro.org>
Signed-off-by: NSumit Semwal <sumit.semwal@linaro.org>
 [sumits: minor parenthesis alignment]
Link: https://patchwork.freedesktop.org/patch/msgid/1610757107-11892-1-git-send-email-veeras@codeaurora.org

Every heap needs to create a dmabuf and then export it to a fd
via dma_buf_fd(), so to consolidate things a bit, have the heaps
just return a struct dmabuf * and let the top level
dma_heap_buffer_alloc() call handle creating the fd via
dma_buf_fd().

Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Liam Mark <lmark@codeaurora.org>
Cc: Laura Abbott <labbott@kernel.org>
Cc: Brian Starkey <Brian.Starkey@arm.com>
Cc: Hridya Valsaraju <hridya@google.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Sandeep Patil <sspatil@google.com>
Cc: Daniel Mentz <danielmentz@google.com>
Cc: Chris Goldsworthy <cgoldswo@codeaurora.org>
Cc: Ørjan Eide <orjan.eide@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Ezequiel Garcia <ezequiel@collabora.com>
Cc: Simon Ser <contact@emersion.fr>
Cc: James Jones <jajones@nvidia.com>
Cc: linux-media@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
Signed-off-by: NSumit Semwal <sumit.semwal@linaro.org>
 [sumits: minor reword of commit message]

Link: https://patchwork.freedesktop.org/patch/msgid/20210119204508.9256-3-john.stultz@linaro.org

If we abort from the allocation due to a fatal_signal_pending(),
be sure we report an error so any return code paths don't trip
over the fact that the allocation didn't succeed.

Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Liam Mark <lmark@codeaurora.org>
Cc: Laura Abbott <labbott@kernel.org>
Cc: Brian Starkey <Brian.Starkey@arm.com>
Cc: Hridya Valsaraju <hridya@google.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Sandeep Patil <sspatil@google.com>
Cc: Daniel Mentz <danielmentz@google.com>
Cc: Chris Goldsworthy <cgoldswo@codeaurora.org>
Cc: Ørjan Eide <orjan.eide@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Ezequiel Garcia <ezequiel@collabora.com>
Cc: Simon Ser <contact@emersion.fr>
Cc: James Jones <jajones@nvidia.com>
Cc: linux-media@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Suggested-by: NSuren Baghdasaryan <surenb@google.com>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
Signed-off-by: NSumit Semwal <sumit.semwal@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210119204508.9256-1-john.stultz@linaro.org

Internship season is starting, let's review this. One thing that's
pending is Maxime's work to roll out drm_atomic_state pointers to all
callbacks, he said he'll remove that entry once it's all done.

v2: Fix typos (Maxime)
Acked-by: NMaxime Ripard <maxime@cerno.tech>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210121112919.1460322-1-daniel.vetter@ffwll.ch

Rename ttm_bo_device to ttm_device.
Rename ttm_bo_driver to ttm_device_funcs.
Rename ttm_bo_global to ttm_global.

Move global and device related functions to ttm_device.[ch].

No functional change.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/415222/

There's currently four users of the same logic to wait for a commit to
be flipped: three for the CRTCs, connectors and planes in
drm_atomic_helper_wait_for_dependencies, and one in vc4.

Let's consolidate this a bit to avoid any code duplication.
Suggested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111084401.117152-1-maxime@cerno.tech

We were not correctly unpinning no longer needed buffers. In particular
vmw_buffer_object, which is internally often pinned on creation wasn't
unpinned on destruction and none of the internal MOB buffers were
unpinned before being put back. Technically this existed for a
long time but commit 57fcd550 ("drm/ttm: Warn on pinning without
holding a reference") introduced a WARN_ON which was filling up the
kernel logs rather quickly.

Quite frankly internal usage of vmw_buffer_object and in general
pinning needs to be refactored in vmwgfx but for now this makes
it work.
Signed-off-by: NZack Rusin <zackr@vmware.com>
Reviewed-by: NMartin Krastev <krastevm@vmware.com>
Reviewed-by: NRoland Scheidegger <sroland@vmware.com>
Fixes: 57fcd550 ("drm/ttm: Warn on pinning without holding a reference")
Link: https://patchwork.freedesktop.org/patch/414984/?series=86052&rev=1
Cc: Huang Rui <ray.huang@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Christian Koenig <christian.koenig@amd.com>
Cc: dri-devel@lists.freedesktop.org

The meta-schema recently gained a definition for the common -supply$
property, which denotes that maxItems is not a valid property. Drop this
to clear up the binding validation error.

Fixes: a46c1125 ("dt-bindings: dp-connector: add binding for DisplayPort connector")
Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: NRob Herring <robh@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210120175922.1579835-1-bjorn.andersson@linaro.org

The OneGX1 Pro has a fairly unique combination of generic strings,
but we additionally match on the BIOS date just to be safe.
Signed-off-by: NJared Baldridge <jrb@expunge.us>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/41288ccb-1012-486b-81c1-a24c31850c91@www.fastmail.com

DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT can't be used when we hold locks
since we are basically waiting for userspace to do something.

Holding a lock while doing so can trivial deadlock with page faults
etc...

So make lockdep complain when a driver tries to do this.

v2: Add lockdep_assert_none_held() macro.
v3: Add might_sleep() and also use lockdep_assert_none_held() in the
    IOCTL path.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patchwork.freedesktop.org/patch/414944/

Only initialize the DMA coherent pools if they are used.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/414957/

Useful for testing.

v2: add fs_reclaim_acquire()/_release()
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/414955/

Instead of printing this on the per device pool.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/414956/

As far as I can tell the buffer_count was never used by an
userspace application.

The number of BOs in the system is far better suited in
debugfs than sysfs and we now should be able to add other
information here as well.

v2: add that additionally to sysfs
Signed-off-by: NChristian König <christian.koenig@amd.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/414954/

Add "r5g5b5a1" which is used on the N64.
Signed-off-by: NLauri Kasanen <cand@gmx.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/20210115160102.cf4c85db9f815758716f086f@gmx.com

The info message was showing the mapped address for the framebuffer. To avoid
security problems, all virtual addresses are converted to __ptrval__, so
the message has pointless information:

simple-framebuffer 3ea9b000.framebuffer: framebuffer at 0x3ea9b000, 0x12c000 bytes, mapped to 0x(____ptrval____)

Drop the extraneous bits to clean up the message:

simple-framebuffer 3ea9b000.framebuffer: framebuffer at 0x3ea9b000, 0x12c000 bytes
Signed-off-by: NPeter Robinson <pbrobinson@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/20201228183934.1117012-1-pbrobinson@gmail.com

Also add missing description for 'refcount'

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/vmwgfx/ttm_object.c:60: error: Cannot parse struct or union!

Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Roland Scheidegger <sroland@vmware.com>
Cc: Zack Rusin <zackr@vmware.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Rob Clark <rob.clark@linaro.org>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-media@vger.kernel.org
Cc: linaro-mm-sig@lists.linaro.org
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NZack Rusin <zackr@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210115181601.3432599-30-lee.jones@linaro.org

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/vmwgfx/vmwgfx_thp.c:21: warning: Function parameter or member 'manager' not described in 'vmw_thp_manager'

Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Roland Scheidegger <sroland@vmware.com>
Cc: Zack Rusin <zackr@vmware.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NZack Rusin <zackr@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210115181601.3432599-11-lee.jones@linaro.org