drm/i915/tgl: Move GTCR register to cope with GAM MMIO address remap

GAM registers located in the 0x4xxx range have been relocated to 0xCxxx;
this is to make space for global MOCS registers.

v2: Rename register and bitfield to its new name (suggested by Mika)

HSD: 399379
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190823082055.5992-2-lucas.demarchi@intel.com

drm/i915/dp: Fix DSC enable code to use cpu_transcoder instead of encoder->type

This patch fixes the intel_configure_pps_for_dsc_encoder() function to use
cpu_transcoder instead of encoder->type to select the correct DSC registers
that was wrongly used in the original patch for one DSC register isntance.

Fixes: 7182414e2530 ("drm/i915/dp: Configure i915 Picture parameter Set registers during DSC enabling")
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org> # v5.0+
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190821215950.24223-1-manasi.d.navare@intel.com

drm/dp/dsc: Add Support for all BPCs supported by TGL

DSC engine on ICL supports only 8 and 10 BPC as the input
BPC. But DSC engine in TGL supports 8, 10 and 12 BPC.
Add 12 BPC support for DSC while calculating compression
configuration.

v2: Remove the separate define TGL_DP_DSC_MAX_SUPPORTED_BPC
and use the value directly.(More such defines can be removed
as part of future patches). (Ville)

v3: Use values directly instead of accessing the defines
everytime for min and max DSC BPC.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190820223059.18052-1-anusha.srivatsa@intel.com

drm/i915: Do not unmask PSR interruption in IRQ postinstall

No need to unmask PSR interrutpion if PSR is not enabled, better move
the call to intel_psr_enable_source().

v2: Renamed intel_psr_irq_control() to psr_irq_control() (Lucas)

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190820223325.27490-3-jose.souza@intel.com

drm/i915: Add transcoder restriction to PSR2

According to PSR2_CTL definition in BSpec there is only one instance
of PSR2_CTL. Platforms gen < 12 with EDP transcoder only support PSR2
on TRANSCODER_EDP while on TGL PSR2 is only supported by
TRANSCODER_A.

Since BDW PSR is allowed on any port, but we need to restrict by
transcoder.

v8: Renamed _psr2_supported_in_trans() to psr2_supported() (Lucas)

v9: Renamed psr2_supported() to transcoder_has_psr2() (Ville)

BSpec: 7713
BSpec: 20584
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190820223325.27490-2-jose.souza@intel.com

drm/i915/psr: Make PSR registers relative to transcoders

PSR registers are a mess, some have the full address while others just
have the additional offset from psr_mmio_base.

For BDW+ psr_mmio_base is nothing more than TRANSCODER_EDP_OFFSET +
0x800 and using it makes more difficult for people with an PSR
register address or PSR register name from from BSpec as i915 also
don't match the BSpec names.
For HSW psr_mmio_base is _DDI_BUF_CTL_A + 0x800 and PSR registers are
only available in DDIA.

Other reason to make relative to transcoder is that since BDW every
transcoder have PSR registers, so in theory it should be possible to
have PSR enabled in a non-eDP transcoder.

So for BDW+ we can use _TRANS2() to get the register offset of any
PSR register in any transcoder while for HSW we have _HSW_PSR_ADJ
that will calculate the register offset for the single PSR instance,
noting that we are already guarded about trying to enable PSR in other
port than DDIA on HSW by the 'if (dig_port->base.port != PORT_A)' in
intel_psr_compute_config(), this check should only be valid for HSW
and will be changed in future.
PSR2 registers and PSR_EVENT was added after Haswell so that is why
_PSR_ADJ() is not used in some macros.

The only registers that can not be relative to transcoder are
PSR_IMR and PSR_IIR that are not relative to anything, so keeping it
hardcoded. That changed for TGL but it will be handled in another
patch.

Also removing BDW_EDP_PSR_BASE from GVT because it is not used as it
is the only PSR register that GVT have.

v5:
- Macros changed to be more explicit about HSW (Dhinakaran)
- Squashed with the patch that added the tran parameter to the
macros (Dhinakaran)

v6:
- Checking for interruption errors after module reload in the
transcoder that will be used (Dhinakaran)
- Using lowercase to the registers offsets

v7:
- Removing IS_HASWELL() from registers macros(Jani)

Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190820223325.27490-1-jose.souza@intel.com

drm/i915: Update DRIVER_DATE to 20190822

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

drm/i915: Kill the undead i915_gem_batch_pool.c

You have to cut it off at the neck, otherwise it just reappears in the
next merge, like it did in commit 3f866026f0ce ("Merge drm/drm-next
into drm-intel-next-queued")

References: 3f866026f0ce ("Merge drm/drm-next into drm-intel-next-queued")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190822065917.18988-1-chris@chris-wilson.co.uk

drm/i915: Replace i915_vma_put_fence()

Avoid calling i915_vma_put_fence() by using our alternate paths that
bind a secondary vma avoiding the original fenced vma. For the few
instances where we need to release the fence (i.e. on binding when the
GGTT range becomes invalid), replace the put_fence with a revoke_fence.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190822061557.18402-1-chris@chris-wilson.co.uk

drm/i915: Pull obj->userfault tracking under the ggtt->mutex

Since we want to revoke the ggtt vma from only under the ggtt->mutex, we
need to move protection of the userfault tracking from the struct_mutex
to the ggtt->mutex.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190822060914.2671-2-chris@chris-wilson.co.uk

drm/i915: Track ggtt fence reservations under its own mutex

We can reduce the locking for fence registers from the dev->struct_mutex
to a local mutex. We could introduce a mutex for the sole purpose of
tracking the fence acquisition, except there is a little bit of overlap
with the fault tracking, so use the i915_ggtt.mutex as it covers both.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190822060914.2671-1-chris@chris-wilson.co.uk

drm/i915: Generalise the clflush dma-worker

Extract the dma-fence worker used by clflush for wider use, as we
anticipate using workers coupled to dma-fences more frequently.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190821191606.17001-1-chris@chris-wilson.co.uk

Merge drm/drm-next into drm-intel-next-queued

We need the rename of reservation_object to dma_resv.

The solution on this merge came from linux-next:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 14 Aug 2019 12:48:39 +1000
Subject: [PATCH] drm: fix up fallout from "dma-buf: rename reservation_object to dma_resv"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/gpu/drm/i915/gt/intel_engine_pool.c | 8 ++++----
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pool.c b/drivers/gpu/drm/i915/gt/intel_engine_pool.c
index 03d90b49584a..4cd54c569911 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pool.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pool.c
@@ -43,12 +43,12 @@ static int pool_active(struct i915_active *ref)
 {
        struct intel_engine_pool_node *node =
                container_of(ref, typeof(*node), active);
-       struct reservation_object *resv = node->obj->base.resv;
+       struct dma_resv *resv = node->obj->base.resv;
        int err;

-       if (reservation_object_trylock(resv)) {
-               reservation_object_add_excl_fence(resv, NULL);
-               reservation_object_unlock(resv);
+       if (dma_resv_trylock(resv)) {
+               dma_resv_add_excl_fence(resv, NULL);
+               dma_resv_unlock(resv);
        }

        err = i915_gem_object_pin_pages(node->obj);

which is a simplified version from a previous one which had:
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

Merge branch 'etnaviv/next' of https://git.pengutronix.de/git/lst/linux into drm-next

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

Merge tag 'du-next-20190816' of git://linuxtv.org/pinchartl/media into drm-next

- 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/i915/selftests: Fixup a couple of missing serialisation with vma

In commit 70d6894d1456 ("drm/i915: Serialize against vma moves")
I managed to miss a couple of i915_vma_move_to_active() that had not
serialised against an async vma pinning. Add the missing
i915_request_await.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190821193851.18232-1-chris@chris-wilson.co.uk

drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest

The following call trace may exist in linux guest dmesg when guest i915
driver is unloaded.
[   90.776610] [drm:vgt_deballoon_space.isra.0 [i915]] deballoon space: range [0x0 - 0x0] 0 KiB.
[   90.776621] BUG: unable to handle kernel NULL pointer dereference at 00000000000000c0
[   90.776691] IP: drm_mm_remove_node+0x4d/0x320 [drm]
[   90.776718] PGD 800000012c7d0067 P4D 800000012c7d0067 PUD 138e4c067 PMD 0
[   90.777091] task: ffff9adab60f2f00 task.stack: ffffaf39c0fe0000
[   90.777142] RIP: 0010:drm_mm_remove_node+0x4d/0x320 [drm]
[   90.777573] Call Trace:
[   90.777653]  intel_vgt_deballoon+0x4c/0x60 [i915]
[   90.777729]  i915_ggtt_cleanup_hw+0x121/0x190 [i915]
[   90.777792]  i915_driver_unload+0x145/0x180 [i915]
[   90.777856]  i915_pci_remove+0x15/0x20 [i915]
[   90.777890]  pci_device_remove+0x3b/0xc0
[   90.777916]  device_release_driver_internal+0x157/0x220
[   90.777945]  driver_detach+0x39/0x70
[   90.777967]  bus_remove_driver+0x51/0xd0
[   90.777990]  pci_unregister_driver+0x23/0x90
[   90.778019]  SyS_delete_module+0x1da/0x240
[   90.778045]  entry_SYSCALL_64_fastpath+0x24/0x87
[   90.778072] RIP: 0033:0x7f34312af067
[   90.778092] RSP: 002b:00007ffdea3da0d8 EFLAGS: 00000206
[   90.778297] RIP: drm_mm_remove_node+0x4d/0x320 [drm] RSP: ffffaf39c0fe3dc0
[   90.778344] ---[ end trace f4b1bc8305fc59dd ]---

Four drm_mm_node are used to reserve guest ggtt space, but some of them
may be skipped and not initialised due to space constraints in
intel_vgt_balloon(). If drm_mm_remove_node() is called with
uninitialized drm_mm_node, the above call trace occurs.

This patch check drm_mm_node's validity before calling
drm_mm_remove_node().

Fixes: ff8f797557c7("drm/i915: return the correct usable aperture size under gvt environment")
Cc: stable@vger.kernel.org
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/1566279978-9659-1-git-send-email-xiong.y.zhang@intel.com

drm/i915/gtt: Add some range asserts

These should have been validated in the upper layers, but for sanity's
sake, repeat them.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190821155728.2839-2-chris@chris-wilson.co.uk

drm/i915: Do not create a new max_bpc prop for MST connectors

We're not allowed to create new properties after device registration
so for MST connectors we need to either create the max_bpc property
earlier, or we reuse one we already have. Let's do the latter apporach
since the corresponding SST connector already has the prop and its
min/max are correct also for the MST connector.

The problem was highlighted by commit 4f5368b5541a ("drm/kms:
Catch mode_object lifetime errors") which results in the following
spew:
[ 1330.878941] WARNING: CPU: 2 PID: 1554 at drivers/gpu/drm/drm_mode_object.c:45 __drm_mode_object_add+0xa0/0xb0 [drm]
...
[ 1330.879008] Call Trace:
[ 1330.879023]  drm_property_create+0xba/0x180 [drm]
[ 1330.879036]  drm_property_create_range+0x15/0x30 [drm]
[ 1330.879048]  drm_connector_attach_max_bpc_property+0x62/0x80 [drm]
[ 1330.879086]  intel_dp_add_mst_connector+0x11f/0x140 [i915]
[ 1330.879094]  drm_dp_add_port.isra.20+0x20b/0x440 [drm_kms_helper]
...

Cc: stable@vger.kernel.org
Cc: Lyude Paul <lyude@redhat.com>
Cc: sunpeng.li@amd.com
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sean Paul <sean@poorly.run>
Fixes: 5ca0ef8a56b8 ("drm/i915: Add max_bpc property for DP MST")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190820161657.9658-1-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/i915/execlists: Set priority hint prior to submission

Since we now run process_csb() outside of the engine->active.lock, we
can process a CS-event immediately upon our ELSP write. As we currently
inspect the pending queue *after* the ELSP write, there is an
opportunity for a CS-event to update the pending queue before we can
read it, making ourselves chases an invalid pointer.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111427
Fixes: df403069029d ("drm/i915/execlists: Lift process_csb() out of the irq-off spinlock")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190821142336.21609-1-chris@chris-wilson.co.uk

drm/i915: Replace PIN_NONFAULT with calls to PIN_NOEVICT

When under severe stress for GTT mappable space, the LRU eviction model
falls off a cliff. We spend all our time scanning the much larger
non-mappable area searching for something within the mappable zone we can
evict. Turn this on its head by only using the full vma for the object if
it is already pinned in the mappable zone or there is sufficient *free*
space to accommodate it (prioritizing speedy reuse). If there is not,
immediately fall back to using small chunks (tilerow for GTT mmap, single
pages for pwrite/relocation) and using random eviction before doing a full
search.

Testcase: igt/gem_concurrent_blt
References: https://bugs.freedesktop.org/show_bug.cgi?id=110848
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190821123234.19194-1-chris@chris-wilson.co.uk

drm/i915/gtt: Include asm/smp.h

We need asm/smp.h for wbinvd_on_all_cpus()

Reported-by: kbuild-all@01.org
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190821093905.7693-1-chris@chris-wilson.co.uk

drm/i915/hdmi: make hdcp2_msg_data const

It's static const data, make it so.

Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190820134019.13229-5-jani.nikula@intel.com

drm/i915/hdmi: stylistic cleanup around hdcp2_msg_data

Split struct declaration and array definition. Fix indents and
whitespace. No functional changes.

Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190820134019.13229-4-jani.nikula@intel.com

drm/i915/dp: make hdcp2_dp_msg_data const

It's static const data, make it so.

Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190820134019.13229-3-jani.nikula@intel.com

drm/i915/dp: avoid shadowing variables

Everything seems to be all right, but shadowing is to be avoided.

Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190820134019.13229-2-jani.nikula@intel.com

drm/i915/dp: stylistic cleanup around hdcp2_msg_data

Split struct declaration and array definition. Fix indents and
whitespace. No functional changes.

Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190820134019.13229-1-jani.nikula@intel.com

drm/i915/gtt: Relax assertion for pt_used

When inserting the final level PTE, we check that we are not overflowing
the page table (checking that pt_used does not exceed the size of the
table). However, we have to allow for every other PTE to be pinned by a
simultaneous removal thread (as on remove we bump the pt_used counter
before adjusting the table).

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190821042044.7354-1-chris@chris-wilson.co.uk

Merge tag 'drm-misc-next-2019-08-19' of git://anongit.freedesktop.org/drm/drm-misc into drm-next

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

drm/i915: Fix DP-MST crtc_mask

Each fake MST encoder is tied to a specific pipe. Fix the encoder's
crtc_mask to reflect that fact.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190817093902.2171-16-lucas.demarchi@intel.com

drm/i915/tgl: update DMC firmware to 2.04

2 important fixes:
  - vblank counter is now working
  - PSR1 is working

Cc: Jose Souza <jose.souza@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190817093902.2171-5-lucas.demarchi@intel.com

drm/i915/tgl: Move transcoders to pipes' powerwells

When trying to read registers from transcoder C and D while PG3 is ON it
causes unclaimed access warnings. Adding the powerwells for the pipes
fixes the issue, but doesn't match the spec.

Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190817093902.2171-4-lucas.demarchi@intel.com

drm/i915/tgl: add support for reading the timestamp frequency

There are no changes with respect to GEN11, which Paulo wrote.

This gets rid of the "Missing switch case in read_timestamp_frequency"
message at boot for Tiger Lake.

[ Lucas: BSpec: 10742 and 9024, but there's a mismatch on the values.
  Let's say a glitch in the spec. Tested locally and it works. ]

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190817093902.2171-3-lucas.demarchi@intel.com

drm/i915/tgl: disable DDIC

The current SKUs added for Tiger Lake don't have DDIC hooked up, even
though it is supported by the SoC. The current state for these SKUs is
problematic since while enabling the combo phy, PORT_COMP_DW* return
0xFFFFFFFF, which is invalid per register definition.

During initialization we check what phys are not yet enabled by reading
PHY_MISC_C and try to enable it by toggling the "DE to IO Comp Pwr Down"
bit.  But after that any read to the PORT_COMP_DW* returns invalid
results. This removes the following warning

[56997.634353] Missing case (val == 4294967295)
[56997.639241] WARNING: CPU: 5 PID: 768 at drivers/gpu/drm/i915/display/intel_combo_phy.c:54 cnl_get_procmon_ref_values+0xc9/0xf0 [i915]
[56997.639808] Modules linked in: i915(+) prime_numbers x86_pkg_temp_thermal coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel e1000e [last unloaded: prime_numbers]
[56997.639808] CPU: 5 PID: 768 Comm: insmod Tainted: G     U  W         5.2.0-demarchi+ #65
[56997.639808] Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake U DDR4 SODIMM RVP, BIOS TGLSFWI1.R00.2252.A03.1906270154 06/27/2019
[56997.639808] RIP: 0010:cnl_get_procmon_ref_values+0xc9/0xf0 [i915]
[56997.639808] Code: 2c a0 85 c9 74 e0 81 f9 00 00 00 01 75 09 48 c7 c0 0c a4 2c a0 eb cf 48 c7 c6 3c 3a 31 a0 48 c7 c7 40 3a 31 a0 e8 6b 4d ea e0 <0f> 0b 48 c7 c0 00 a4 2c a0 eb b1 48 c7 c0 24 a4 2
c a0 eb a8 e8 be
[56997.639808] RSP: 0018:ffffc9000068f8a8 EFLAGS: 00010286
[56997.639808] RAX: 0000000000000000 RBX: ffff88848fa90000 RCX: 0000000000000000
[56997.639808] RDX: ffff8884a08b5ef8 RSI: ffff8884a08a6658 RDI: 00000000ffffffff
[56997.639808] RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000
[56997.639808] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88848fa90000
[56997.639808] R13: 0000000000000000 R14: 0000000000000002 R15: 0006c00000162000
[56997.639808] FS:  00007f61ca3d12c0(0000) GS:ffff8884a0880000(0000) knlGS:0000000000000000
[56997.639808] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[56997.639808] CR2: 00007f71be6a92c0 CR3: 0000000494750006 CR4: 0000000000760ee0
[56997.639808] PKRU: 55555554
[56997.639808] Call Trace:
[56997.639808]  cnl_verify_procmon_ref_values+0x36/0xf0 [i915]
[56997.639808]  ? rcu_read_lock_sched_held+0x6f/0x80
[56997.639808]  ? gen11_fwtable_read32+0x257/0x290 [i915]
[56997.639808]  icl_combo_phy_verify_state.part.0+0x22/0xa0 [i915]
[56997.639808]  intel_combo_phy_init+0x17e/0x3e0 [i915]
[56997.639808]  ? icl_display_core_init+0x2c/0x1a0 [i915]
[56997.639808]  ? _raw_spin_unlock_irqrestore+0x4c/0x60
[56997.639808]  icl_display_core_init+0x34/0x1a0 [i915]
[56997.639808]  intel_power_domains_init_hw+0x200/0x570 [i915]
[56997.639808]  i915_driver_probe+0x103b/0x17e0 [i915]
[56997.639808]  ? printk+0x53/0x6a
[56997.639808]  i915_pci_probe+0x3b/0x190 [i915]

We may or may not need to change the implementation to account for DDIC
being available on other SKUs. For now I think the best thing to do is
to just disable the port.

Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190814235517.10032-1-lucas.demarchi@intel.com

drm/i915: Update DRIVER_DATE to 20190820

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

drm/i915/gtt: Relax pd_used assertion

The current assertion tries to make sure that we do not over count the
number of used PDE inside a page directory -- that is with an array of
512 pde, we do not expect more than 512 elements used! However, our
assertion has to take into account that as we pin an element into the
page directory, the caller first pins the page directory so the usage
count is one higher. However, this should be one extra pin per thread,
and the upper bound is that we may have one thread for each entry.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190820141218.14714-1-chris@chris-wilson.co.uk

drm/i915: Dynamically allocate s0ix struct for VLV

This is only required for a single platform so no need to reserve the
memory on all of them.

This removes the last direct dependency of i915_drv.h on i915_reg.h
(apart from the i915_reg_t definition).

v2: drop unneeded diff, keep the vlv prefix, call functions
    unconditionally (Jani), fwd declaration of the struct (Chris)

Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190820020147.5667-1-daniele.ceraolospurio@intel.com

drm/i915/tgl: Gen12 render context size

Re-use Gen11 context size for now.

[ Lucas: this is a temporary enabling patch that needs to be confirmed:
         we need to check BSpec 46255 and recompute ]

Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190817093902.2171-27-lucas.demarchi@intel.com

drm/i915/tgl: Updated Private PAT programming

Gen12 removes the target-cache and age fields from the private PAT
because MOCS now have the capability to set these itself. Only memory-type
field should be programmed in the ppat, the reminded bits are reserved.

Since now there are only 4 possible combinations, we could set only 4
PPAT and leave the reminded 4 as UC, but I left them as WB as we used
to have before.

Also these registers have been relocated to the 0x4800-0x481c range.

HSDES: 1406402661
BSpec: 31654
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190817093902.2171-33-lucas.demarchi@intel.com

drm/i915/tgl: Introduce initial Tiger Lake workarounds

Add empty workaround hooks for Tiger Lake. The workarounds will be added
on separate patches. We were already applying
WaRsForcewakeAddDelayForAck, which is indeed still valid, so also update
the comment.

Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190817093902.2171-21-lucas.demarchi@intel.com

drm/i915/tgl: Gen12 csb support

The CSB format has been reworked for Gen12 to include information on
both the context we're switching away from and the context we're
switching to. After the change, some of the events don't have their
own bit anymore and need to be inferred from other values in the csb.
One of the context IDs (0x7FF) has also been reserved to indicate
the invalid ctx, i.e. engine idle.

Note that the full context ID includes the SW counter as well, but since
we currently only care if the context is valid or not we can ignore that
part.

v2: fix mask size, fix and expand comments (Tvrtko),
    use if-ladder (Chris)

Bspec: 45555, 46144
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190820102201.29849-1-chris@chris-wilson.co.uk

drm/i915/tgl: add GEN12_MAX_CONTEXT_HW_ID

Like Gen11, Gen12 has 11 available bits for the ctx id field. However,
the last value (0x7FF) is reserved to indicate engine idle, so we
need to reduce the maximum number of contexts by 1 compared to Gen11.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190817093902.2171-29-lucas.demarchi@intel.com

drm/i915/tgl: add Gen12 default indirect ctx offset

Gen12 uses a new indirect ctx offset.

Bspec: 11740
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190817093902.2171-28-lucas.demarchi@intel.com

drm/i915/tgl: Report valid VDBoxes with SFC capability

In Gen11, only even numbered "logical" VDBoxes are hooked up to a SFC
(Scaler & Format Converter) unit. This is not the case in Tigerlake,
where each VDBox can access a SFC.

We will use this information to decide when the SFC units need to be reset
and also pass it to the GuC.

Bspec: 48077
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190731004902.34672-5-daniele.ceraolospurio@intel.com

drm/i915: Be defensive when starting vma activity

Before we acquire the vma for GPU activity, ensure that the underlying
object is not already in the process of being freed.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190820100531.8430-1-chris@chris-wilson.co.uk

drm/i915: Serialize insertion into the file->mm.request_list

Currently, we remove the from per-file request list for throttling and
retirement under a dedicated spinlock, but insertion is governed by
struct_mutex. This needs to be the same lock so that the
retirement/insertion of neighbouring requests (at the tail) doesn't
break the list.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190820080907.4665-1-chris@chris-wilson.co.uk

drm/i915: Sanitize PHY state during display core uninit

To work around a DMC/Punit issue on ICL where the driver's
ICL_PORT_COMP_DW8/IREFGEN PHY setting is lost when entering/exiting DC6
state, make sure to reinit the PHY whenever disabling DC states.
Similarly the driver's PHY/DBUF/CDCLK settings should have been preserved
across DC5/6 transitions, so check this on all platforms.

This gets rid of the following WARN during suspend:
Combo PHY A HW state changed unexpectedly

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190816095523.15800-1-imre.deak@intel.com

drm/i915: Fix HW readout for crtc_clock in HDMI mode

The conversion during HDMI HW readout from port_clock to crtc_clock was
missed when HDMI 10bpc support was added, so fix that.

v2:
- Unscrew the non-HDMI case.

Fixes: cd9e11a8bf25 ("drm/i915/icl: Add 10-bit support for hdmi")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109593
Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190808162547.7009-1-imre.deak@intel.com

drm/i915: Assume exclusive access to objects inside resume

Inside gtt_restore_mappings() we currently take the obj->resv->lock, but
in the future we need to avoid taking this fs-reclaim tainted lock as we
need to extend the coverage of the vm->mutex. Take advantage of the
single-threaded nature of the early resume phase, and do a single
wbinvd() to flush all the GTT objects en masse.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190819200705.3631-1-chris@chris-wilson.co.uk

drm/i915: Use 0 for the unordered context

Since commit 078dec3326e2 ("dma-buf: add dma_fence_get_stub") the 0
fence context became an impossible match as it is used for an always
signaled fence. We can simplify our timeline tracking by knowing that 0
always means no match.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190819184404.24200-1-chris@chris-wilson.co.uk
Link: https://patchwork.freedesktop.org/patch/msgid/20190819175109.5241-1-chris@chris-wilson.co.uk

drm/i915: i915_active.retire() is optional

Check that i915_active.retire() exists before calling.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190819075835.20065-6-chris@chris-wilson.co.uk

drm/i915/gen11: Allow usage of all GPIO pins

Our pin mapping tables for ICP and MCC currently only list the standard
GPIO pins used for various output ports.  Even through ICP's standard
pin usage only utilizes pins 1, 2, and 9-12, and MCC's standard pin
usage only uses pins 1, 2, and 9, these platforms do still have GPIO
registers to address pins in the range 1-3 and 9-14.  OEM's may remap
GPIO usage in non-standard ways (and provide the actual mapping via VBT
settings), so we shouldn't exclude pins on these platforms just because
they aren't part of the standard mappings.

TGP's standard pin tables contains all the possible pins, so let's
rename them to "icp" and use them for all PCH >= PCH_ICP.  This will
prevent intel_gmbus_is_valid_pin from rejecting non-standard pin usage
that an OEM specifies via the VBT.

Note that this will cause pin 9 to be labeled as "tc1" instead of "dpc"
in debug messages on platforms with the MCC PCH, but that may actually
help avoid confusion since the text strings will now be the same on all
gen11+ platforms instead of being different on just EHL.

v2: Drop now-unused MCC_DDC_BUS_DDI_* names.

v3: We want to compare against INTEL_PCH_TYPE, not INTEL_PCH_ID.

Bspec: 8417
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Vivek Kasireddy <vivek.kasireddy@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190817005041.20651-1-matthew.d.roper@intel.com

drm/i915: Serialize against vma moves

Make sure that when submitting requests, we always serialize against
potential vma moves and clflushes.

Time for a i915_request_await_vma() interface!

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190819112033.30638-1-chris@chris-wilson.co.uk

drm/i915: Only emit the 'send bug report' once for a GPU hang

Use a locked xchg to ensure that the global log message giving
instructions on how to send a bug report is emitted precisely once.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190819075835.20065-5-chris@chris-wilson.co.uk

drm/i915/gt: Mark up the nested engine-pm timeline lock as irqsafe

We use a fake timeline->mutex lock to reassure lockdep that the timeline
is always locked when emitting requests. However, the use inside
__engine_park() may be inside hardirq and so lockdep now complains about
the mixed irq-state of the nested locked. Disable irqs around the
lockdep tracking to keep it happy.

Fixes: 6c69a45445af ("drm/i915/gt: Mark context->active_count as protected by timeline->mutex")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190819075835.20065-3-chris@chris-wilson.co.uk

drm/i915: Always wrap the ring offset before resetting

We were passing in an unwrapped offset into intel_ring_reset() on
unpinning. Sooner or later that had to land on ring->size.

<3> [314.872147] intel_ring_reset:1237 GEM_BUG_ON(!intel_ring_offset_valid(ring, tail))
<4> [314.872272] ------------[ cut here ]------------
<2> [314.872276] kernel BUG at drivers/gpu/drm/i915/gt/intel_ringbuffer.c:1237!
<4> [314.872320] invalid opcode: 0000 [#1] PREEMPT SMP PTI
<4> [314.872331] CPU: 1 PID: 3466 Comm: i915_selftest Tainted: G     U            5.3.0-rc4-CI-Patchwork_14061+ #1
<4> [314.872346] Hardware name: Hewlett-Packard HP Compaq 8000 Elite CMT PC/3647h, BIOS 786G7 v01.02 10/22/2009
<4> [314.872477] RIP: 0010:intel_ring_reset+0x51/0x70 [i915]
<4> [314.872487] Code: 9e db 51 e0 48 8b 35 b6 c7 22 00 49 c7 c0 f8 d9 d6 a0 b9 d5 04 00 00 48 c7 c2 70 5b d4 a0 48 c7 c7 6c fc c0 a0 e8 cf be 58 e0 <0f> 0b 89 77 20 89 77 1c 89 77 24 e9 4f ed ff ff 0f 1f 44 00 00 66
<4> [314.872512] RSP: 0018:ffffc9000034fa98 EFLAGS: 00010282
<4> [314.872523] RAX: 0000000000000010 RBX: ffff8881019412c8 RCX: 0000000000000000
<4> [314.872534] RDX: 0000000000000001 RSI: 0000000000000008 RDI: 0000000000000f20
<4> [314.872545] RBP: ffff888104e0f740 R08: 0000000000000000 R09: 0000000000000f20
<4> [314.872557] R10: 0000000000000000 R11: ffff888117094518 R12: ffffffffa0d3d2c0
<4> [314.872569] R13: ffffffffa0e2a250 R14: ffffffffa0e2a1e0 R15: ffffc9000034fe88
<4> [314.872581] FS:  00007fe6d49f6e40(0000) GS:ffff888117a80000(0000) knlGS:0000000000000000
<4> [314.872595] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4> [314.872605] CR2: 000055e3283e9cc8 CR3: 0000000108842000 CR4: 00000000000406e0
<4> [314.872616] Call Trace:
<4> [314.872701]  intel_ring_unpin+0x1a/0x220 [i915]
<4> [314.872787]  ring_destroy+0x48/0xc0 [i915]
<4> [314.872870]  intel_engines_cleanup+0x24/0x40 [i915]
<4> [314.872964]  i915_gem_driver_release+0x1b/0xf0 [i915]
<4> [314.872984]  i915_driver_release+0x1c/0x80 [i915]

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190819075835.20065-2-chris@chris-wilson.co.uk

drm/xen-front: Make structure fb_funcs constant

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

drm/i915: Propagate fence errors

Errors spread like wildfire, and must eventually be returned to the
user. They need to be captured and passed along the flow of fences,
infecting each in turn with the existing error, until finally they fall
out of a user visible result.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190817232511.11391-1-chris@chris-wilson.co.uk

drm/i915/uc: Never fail on HuC firmware errors

There is no need to mark whole GPU as wedged just because
of the custom HuC fw failure as users can always verify
actual HuC firmware status using existing HUC_STATUS ioctl.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190818095204.31568-4-michal.wajdeczko@intel.com

drm/i915/uc: Don't always fail on unavailable GuC firmware

If we failed to fetch default GuC firmware and we didn't plan
to use it for the submission and we never have used GuC before
then we may continue normal driver load, no need to declare
GPU wedged (we can use execlist for submission) and it is safe
to run without the HuC (users will check HuC status anyway).

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190818095204.31568-3-michal.wajdeczko@intel.com

drm/i915/guc: Don't open log relay if GuC is not running

As we plan to continue driver load after GuC initialization
failure, we can't assume that GuC log data will be available
just because GuC was initially enabled. We must check that
GuC is still running instead.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190818095204.31568-2-michal.wajdeczko@intel.com

drm/vboxvideo: Make structure vbox_fb_helper_funcs constant

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

dma-fence: Store the timestamp in the same union as the cb_list

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

dma-fence: Simply wrap dma_fence_signal_locked with dma_fence_signal

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

dma-fence: Avoid list_del during fence->cb_list iteration

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

dma-fence: Shrink size of struct dma_fence

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

drm/panel: tpo-td043mtea1: remove redundant assignment

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/i915/uc: Never fail on uC preparation step

Let's wait with decision about importance of uC failure to
hardware initialization step.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190817131144.26884-4-michal.wajdeczko@intel.com

drm/i915/uc: Cleanup fw fetch on every GuC/HuC init failure

Be consistent and always perform fw fetch cleanup in GuC/HuC specific
init functions on every failure. Also while converting firmware
status to error, stop treating SELECTED as non-error, as long term
we should not see it.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190817131144.26884-3-michal.wajdeczko@intel.com

drm/i915/uc: Cleanup fw fetch only if it was successful

We can rely on firmware status AVAILABLE to determine if any
firmware cleanup is required. Also don't unconditionally reset
fw status to SELECTED as we will loose MISSING/ERROR codes.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190817131144.26884-2-michal.wajdeczko@intel.com

drm/i915/selftests: Check the context size

Add a redzone to our context image and check the HW does not write into
after a context save, to verify that we have the correct context size.
(This does vary with feature bits, so test with a live setup that should
match how we run userspace.)

v2: Check the redzone on every context unpin
v3: Use a kernel context to prevent loading garbage for ringbuffer
submission

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190817073711.5897-1-chris@chris-wilson.co.uk

drm/i915/gtt: Fold gen8 insertions into one

As we give page directory pointer (lvl 3) structure
for pte insertion, we can fold both versions into
one function by teaching it to get pdp regardless
of top level.

v2: naming and asserts (Chris)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190816094754.26492-1-mika.kuoppala@linux.intel.com

drm/i915/uc: Add explicit DISABLED state for firmware

We really need to have separate NOT_SUPPORTED state (for
lack of hardware support) and DISABLED state (to indicate
user decision) as we will have to take special steps even
if GuC firmware is now disabled but hardware exists and
could have been previously used.

v2: fix logic (Chris/CI)
v3: use proper check to avoid probe failure (CI)
v4: explain status transitions (Chris)

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190816205658.15020-1-michal.wajdeczko@intel.com

drm/i915: Wrappers for display register waits

To reduce the number of explicit dev_priv->uncore calls in the display
code ahead of the introduction of dev_priv->de_uncore, this patch
introduces a wrapper for one of the main usages of it, the register
waits. When we transition to the new uncore, we can just update the
wrapper to point to the appropriate structure.

Since the vast majority of waits are on a set or clear of a bit or mask,
add set & clear flavours of the wrapper to simplify the code.

Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190816012343.36433-7-daniele.ceraolospurio@intel.com

drm/i915: Move gmbus definitions out of i915_reg.h

They're not related to registers, so move them to the more appropriate
intel_gmbus.h

Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190816012343.36433-4-daniele.ceraolospurio@intel.com

drm/i915: Move engine IDs out of i915_reg.h

To remove the dependency between the GT headers and i915_reg.h, move the
definition of the engine IDs/classes to intel_engine_types.h

Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190816012343.36433-3-daniele.ceraolospurio@intel.com

drm/i915: Move i915_power_well_id out of i915_reg.h

It has nothing to do with registers, so move it to the more appropriate
intel_display_power.h

Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190816012343.36433-2-daniele.ceraolospurio@intel.com

drm/i915/execlists: Lift process_csb() out of the irq-off spinlock

If we only call process_csb() from the tasklet, though we lose the
ability to bypass ksoftirqd interrupt processing on direct submission
paths, we can push it out of the irq-off spinlock.

The penalty is that we then allow schedule_out to be called concurrently
with schedule_in requiring us to handle the usage count (baked into the
pointer itself) atomically.

As we do kick the tasklets (via local_bh_enable()) after our submission,
there is a possibility there to see if we can pull the local softirq
processing back from the ksoftirqd.

v2: Store the 'switch_priority_hint' on submission, so that we can
safely check during process_csb().

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190816171608.11760-1-chris@chris-wilson.co.uk

drm/omap: displays: Remove unused panel drivers

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

video: omapfb2: Make standard and custom panel drivers mutually exclusive

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: dc2e1e5b279966 ("drm/panel: Add driver for the Toppoly TD043MTEA1 panel")
Fixes: 415b8dd0871188 ("drm/panel: Add driver for the Toppoly TD028TTEC1 panel")
Fixes: 1c8fc3f0c5d280 ("drm/panel: Add driver for the Sony ACX565AKM panel")
Fixes: c9cf4c2a3bd35f ("drm/panel: Add driver for the Sharp LS037V7DW01 panel")
Fixes: df439abe650177 ("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

drm/i915: Markup expected timeline locks for i915_active

As every i915_active_request should be serialised by a dedicated lock,
i915_active consists of a tree of locks; one for each node. Markup up
the i915_active_request with what lock is supposed to be guarding it so
that we can verify that the serialised updated are indeed serialised.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190816121000.8507-2-chris@chris-wilson.co.uk

drm/i915/gt: Mark context->active_count as protected by timeline->mutex

We use timeline->mutex to protect modifications to
context->active_count, and the associated enable/disable callbacks.
Due to complications with engine-pm barrier there is a path where we used
a "superlock" to provide serialised protect and so could not
unconditionally assert with lockdep that it was always held. However,
we can mark the mutex as taken (noting that we may be nested underneath
ourselves) which means we can be reassured the right timeline->mutex is
always treated as held and let lockdep roam free.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190816121000.8507-1-chris@chris-wilson.co.uk

drm/i915/wopcm: Fix SPDX tag location

Move SPDX tag to first line, and update year to 2019.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190816105501.31020-6-michal.wajdeczko@intel.com

drm/i915/wopcm: Update error messages

All WOPCM error messages are device specific, so use
device specific error functions.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190816105501.31020-5-michal.wajdeczko@intel.com

drm/i915/wopcm: Try to use already locked WOPCM layout

If WOPCM layout is already locked in HW we shouldn't continue
with our own partitioning as it could be likely different and
we will be unable to enforce it and fail. Instead we should try
to reuse what is already programmed, maybe there will be a fit.

This should enable us to reload driver with slightly different
HuC firmware (or even without HuC) without need to reboot.

v2: reordered/rebased

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Winiarski <michal.winiarski@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190816105501.31020-4-michal.wajdeczko@intel.com

drm/i915/wopcm: Check WOPCM layout separately from calculations

We can do WOPCM partitioning using rough estimates and limits
and perform detailed check as separate step.

v2: oops! s/max/min
v3: consolidate overflow checks (Daniele)

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190816105501.31020-3-michal.wajdeczko@intel.com

drm/i915/uc: Move FW size sanity check back to fetch

While we need to know WOPCM size to do this sanity check, it has more to
do with FW than with WOPCM. Let's move the check to fetch phase, it's
not like WOPCM is going to grow in the meantime.

v2: rebased
v3: use __intel_uc_fw_get_upload_size (Daniele)

Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jackie Li <yaodong.li@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190816105501.31020-2-michal.wajdeczko@intel.com

drm/i915/buddy: use kmemleak_update_trace

Since nodes are cached in a free-list, and potentially marked as free
without actually being destroyed, thus allowing them to be
opportunistically re-allocated, we should apply kmemleak_update_trace
every time a node is given a new owner and marked as allocated, to aid
in debugging.

Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190816105357.14340-2-matthew.auld@intel.com

drm/i915/buddy: tidy up i915_buddy_fini

If we are leaking nodes don't hide it. Also stop trying to be
"defensive" and instead embrace Kasan et al.

Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190816105357.14340-1-matthew.auld@intel.com

drm: rcar-du: lvds: Fix bridge_to_rcar_lvds

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: c6a27fa41fab ("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: Remove bridge support from legacy helpers

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>

drm: Don't include drm/drm_encoder_slave.h when not needed

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>

dma-buf: Restore seqlock around dma_resv updates

This reverts
67c97fb79a7f ("dma-buf: add reservation_object_fences helper")
dd7a7d1ff2f1 ("drm/i915: use new reservation_object_fences helper")
0e1d8083bddb ("dma-buf: further relax reservation_object_add_shared_fence")
5d344f58da76 ("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

drm/i915: Use the associated uncore for the vm

We store the gt&uncore to use in the i915_address_space, so use it!

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190816083143.23558-1-chris@chris-wilson.co.uk

drm/i915: Extract intel_frontbuffer active tracking

Move the active tracking for the frontbuffer operations out of the
i915_gem_object and into its own first class (refcounted) object. In the
process of detangling, we switch from low level request tracking to the
easier i915_active -- with the plan that this avoids any potential
atomic callbacks as the frontbuffer tracking wishes to sleep as it
flushes.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190816074635.26062-1-chris@chris-wilson.co.uk

Merge branch 'vmwgfx-next' of git://people.freedesktop.org/~thomash/linux into drm-next

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>

drm/i915: Protect request retirement with timeline->mutex

Forgo the struct_mutex requirement for request retirement as we have
been transitioning over to only using the timeline->mutex for
controlling the lifetime of a request on that timeline.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190815205709.24285-4-chris@chris-wilson.co.uk

drm/i915/gt: Guard timeline pinning without relying on struct_mutex

In preparation for removing struct_mutex from around context retirement,
we need to make timeline pinning and unpinning safe. Since multiple
engines/contexts can share a single timeline, we cannot rely on
borrowing the context mutex (otherwise we could state that the timeline
is only pinned/unpinned inside the context pin/unpin and so guarded by
it). However, we only perform a sequence of atomic operations inside the
timeline pin/unpin and the sequence of those operations is safe for a
concurrent unpin / pin, so we can relax the struct_mutex requirement.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190815205709.24285-3-chris@chris-wilson.co.uk

drm/i915/gt: Convert timeline tracking to spinlock

Convert the active_list manipulation of timelines to use spinlocks so
that we can perform the updates from underneath a quick interrupt
callback, if need be.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190815205709.24285-2-chris@chris-wilson.co.uk

drm/i915/gt: Track timeline activeness in enter/exit

Lift moving the timeline to/from the active_list on enter/exit in order
to shorten the active tracking span in comparison to the existing
pin/unpin.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190815205709.24285-1-chris@chris-wilson.co.uk