Imre Deak [Tue, 30 Jan 2018 14:29:39 +0000 (16:29 +0200)]
drm/i915/bxt, glk: Avoid long atomic poll during CDCLK change
There is no requirement for doing the PCODE request polling atomically,
so do that only for a short time switching to sleeping poll afterwards.
The specification requires a 150usec timeout for the change notification,
so let's use that for the atomic poll. Do the extra 2ms poll - needed as
a workaround on BXT/GLK - in sleeping mode.
v2:
- rebase on v2 of patchset dropping the sandybridge_pcode_read/write
refactoring (Chris)
Imre Deak [Tue, 30 Jan 2018 14:29:38 +0000 (16:29 +0200)]
drm/i915/bxt, glk: Increase PCODE timeouts during CDCLK freq changing
Currently we see sporadic timeouts during CDCLK changing both on BXT and
GLK as reported by the Bugzilla: ticket. It's easy to reproduce this by
changing the frequency in a tight loop after blanking the display. The
upper bound for the completion time is 800us based on my tests, so
increase it from the current 500us to 2ms; with that I couldn't trigger
the problem either on BXT or GLK.
Note that timeouts happened during both the change notification and the
voltage level setting PCODE request. (For the latter one BSpec doesn't
require us to wait for completion before further HW programming.)
This issue is similar to
commit 2c7d0602c815 ("drm/i915/gen9: Fix PCODE polling during CDCLK
change notification")
but there the PCODE request does complete (as shown by the mbox
busy flag), only the reply we get from PCODE indicates a failure.
So there we keep resending the request until a success reply, here we
just have to increase the timeout for the one PCODE request we send.
Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.4+ Acked-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103326 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180130142939.17983-1-imre.deak@intel.com
Michal Wajdeczko [Wed, 31 Jan 2018 17:32:39 +0000 (17:32 +0000)]
drm/i915/guc: Don't try to create log runtime if there is no log
In case of GuC initialization failure we may continue with driver
load, but we wrongly assume that GuC is fully functional. This
leads to the BUG as we attempt to access non-existing log vma.
Michal Wajdeczko [Wed, 31 Jan 2018 17:32:37 +0000 (17:32 +0000)]
drm/i915/guc: Don't forget to free GuC error log
We're freeing GuC error log in uc_fini_hw() that matches
corresponding uc_init_hw() but we missed the point that this
log object is copied on error path and in case of failure in
uc_init_hw() we will leak this object as uc_fini_hw() is
never called.
If we free this log object as part of the late uC cleanup, where
we also release other firmware objects, we can avoid this BUG:
[70841.001413] BUG drm_i915_gem_object (Tainted: G U W ): Objects remaining in drm_i915_gem_object on __kmem_cache_shutdown()
[70841.001436] INFO: Slab 0x00000000c94e41af objects=21 used=1 fp=0x000000001d60c40a flags=0x8000000000008100
Chris Wilson [Wed, 31 Jan 2018 21:44:39 +0000 (21:44 +0000)]
drm/i915/ppgtt: Pin page directories before allocation
Commit e2b763caa6eb ("drm/i915: Remove bitmap tracking for used-pdpes")
believed that because it did not insert its freshly allocated page
directory into the pd tree, it was safe from the shrinker. I failed to
heed the lesson learnt from commit dd19674bacba ("drm/i915: Remove bitmap
tracking for used-ptes") that we need to pin all the levels in the tree
before hitting the shrinker or else the shrinker may free an upper layer
as we proceed to allocate the tree. Thus leaving dangling pointers
everywhere and a GPF should we hit direct reclaim at just the wrong
moment.
Kelvin Gardiner [Tue, 30 Jan 2018 13:49:17 +0000 (11:49 -0200)]
drm/i915/icl: Set graphics mode register for gen11
This patch clears a single bit. The bit is 0 by default but expected
not to be set. Explicitly clearing the bit in this patch is intended
to indicate some thinking has occurred, and that we want this bit
cleared and we are not just excepting the default value.
We also stop setting GFX_RUN_LIST_ENABLE, which is correct since that
bit is gone.
James Ausmus [Tue, 30 Jan 2018 13:49:16 +0000 (11:49 -0200)]
drm/i915/icl: Handle expanded PLANE_CTL_FORMAT field
ICL+ adds changes the PLANE_CTL_FORMAT field from [27:24] to [27:23],
however, all existing PLANE_CTL_FORMAT_* definitions still map to the
correct values. Add an ICL_PLANE_CTL_FORMAT_MASK definition, and use
that for masking for the conversion to fourcc.
v2: No changes
v3: Change new definition name, drop comment (Rodrigo)
Mahesh Kumar [Tue, 30 Jan 2018 13:49:13 +0000 (11:49 -0200)]
drm/i915/icl: NV12 y-plane ddb is not in same plane
We don't have planar pixel format support implemented for ICL yet.
ICL require 2 display planes to be allocated for Planar formats unlike
previous GEN. So ICL/GEN11 doesn't require to write Y-plane ddb data in
NV12_BUF_CFG register and PLANE_NV12_BUF_CFG register is removed in ICL.
This patch removes the PLANE_NV12_BUF_CFG write for ICL.
Changes Since V1:
- Improve commit message as per Paulo's comment
Mahesh Kumar [Tue, 30 Jan 2018 13:49:12 +0000 (11:49 -0200)]
drm/i915/icl: Fail flip if ddb allocated are less than min display buffer needed
ICL require DDB allocation of plane to be more than "minimum display
buffer needed" for each level in order to enable WM level.
This patch implements and consider the same while allocating DDB
and enabling WM.
Changes Since V1:
- rebase
Changes Since V2:
- Remove extra parentheses
- Use FP16.16 only when absolutely necessary (Paulo)
Changes Since V3:
- Rebase
Changes since v4 (from Paulo):
- Coding style issue.
Changes since v5 (from Paulo):
- Do the final checks according to BSpec.
Mahesh Kumar [Tue, 30 Jan 2018 13:49:11 +0000 (11:49 -0200)]
drm/i915/icl: Do not fix dbuf block size to 512
GEN9/10 had fixed DBuf block size of 512. Dbuf block size is not a
fixed number anymore in GEN11, it varies according to bits per pixel
and tiling. If 8bpp & Yf-tile surface, block size = 256 else block
size = 512
This patch addresses the same.
v2 (from Paulo):
- Make it compile.
- Fix a few coding style issues.
v3:
- Rebase on top of upstream patches
v4 (from Paulo):
- Bikeshed if statements (James).
Mahesh Kumar [Tue, 30 Jan 2018 13:49:10 +0000 (11:49 -0200)]
drm/i915/icl: Don't allocate fixed bypass path blocks for ICL
GEN9 onwards bypass path allocation of 4 blocks was needed, as per
hardware design. ICL doesn't require bypass path allocation of 4 DDB
blocks, handling the same in this patch.
v2 (from Paulo):
- No need for a comment that says what the code already says.
Chris Wilson [Tue, 30 Jan 2018 16:44:57 +0000 (16:44 +0000)]
drm/i915: Flush ggtt writes through the old fenced vma before changing fences
This is a precautionary measure as I have no evidence to suggest we've
hit a bug here (I was hoping this might explain gdg's odd behaviour, but
alas), but given that we have a function to flush the ggtt writes it
seems prudent to use it prior to changing the fence register. Due to the
intrinsic nature of the GTT often operating as an independent mmio path,
we should not just rely on the write to the fence acting as a full flush
for GTT writes.
drm/i915/guc: Fix return from guc_log_relay_file_create
guc_log_relay_file_create will return -EEXIST if we invoke
relay_late_setup_files multiple times as part of i915_guc_log_control.
However this is to be not cosidered as fail and need to return 0.
This was mistakenly introduced in the below commit. Fix it.
Fixes: 70deeaddc6e6 "drm/i915/guc: Fix lockdep due to log relay channel handling under struct_mutex" Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1517379279-12967-1-git-send-email-sagar.a.kamble@intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson [Mon, 29 Jan 2018 14:41:04 +0000 (14:41 +0000)]
drm/i915: Always run hangcheck while the GPU is busy
Previously, we relied on only running the hangcheck while somebody was
waiting on the GPU, in order to minimise the amount of time hangcheck
had to run. (If nobody was watching the GPU, nobody would notice if the
GPU wasn't responding -- eventually somebody would care and so kick
hangcheck into action.) However, this falls apart from around commit 4680816be336 ("drm/i915: Wait first for submission, before waiting for
request completion"), as not all waiters declare themselves to hangcheck
and so we could switch off hangcheck and miss GPU hangs even when
waiting under the struct_mutex.
If we enable hangcheck from the first request submission, and let it run
until the GPU is idle again, we forgo all the complexity involved with
only enabling around waiters. We just have to remember to be careful that
we do not declare a GPU hang when idly waiting for the next request to
be come ready, as we will run hangcheck continuously even when the
engines are stalled waiting for external events. This should be true
already as we should only be tracking requests submitted to hardware for
execution as an indicator that the engine is busy.
Fixes: 4680816be336 ("drm/i915: Wait first for submission, before waiting for request completion"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104840 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180129144104.3921-1-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Rodrigo Vivi [Mon, 29 Jan 2018 23:22:23 +0000 (15:22 -0800)]
drm/i915/cnl: Fix DP max rate for Cannonlake with port F.
On CNL SKUs that uses port F, max DP rate is 8.1G for all
ports when we have the elevated voltage (higher than 0.85V).
v2: Make commit message more generic.
v3: Move conditions to a helper to get easier to read. (Ville).
v4: Add a mention to the numerical voltage on commit
message per Manasi request.
v5: Thanks CI! "error: control reaches end of non-void function"
Rodrigo Vivi [Mon, 29 Jan 2018 23:22:22 +0000 (15:22 -0800)]
drm/i915/cnl: Enable DDI-F on Cannonlake.
Now let's finish the Port-F support by adding the
proper port F detection, irq and power well support.
v2: Rebase
v3: Use BIT_ULL
v4: Cover missed case on ddi init.
v5: Update commit message.
v6: Rebase on top of display headers rework.
v7: Squash power-well handling related to DDI F to this
patch to avoid warns as pointed out by DK.
v8: Introduce DDI_F_LANES to PG2. (DK)
v9: Squash in the PORT_F case for enabling DP MST encoder. (DK)
Rodrigo Vivi [Mon, 29 Jan 2018 23:22:21 +0000 (15:22 -0800)]
drm/i915/cnl: Add HPD support for Port F.
On CNP boards that are using DDI F,
bit 25 (SDE_PORTE_HOTPLUG_SPT) is representing
the Digital Port F hotplug line when the Digital
Port F hotplug detect input is enabled.
v2: Reuse all existent structure instead of adding a
new HPD_PORT_F pointing to pin of port E.
v3: Use IS_CNL_WITH_PORT_F so we can start upstreaming
this right now. If that SKU ever get a proper name
we come back and update it.
v4: Rebase on top of digital connected port using encoder
instead of port.
v5: Moved IS_CNL_WITH_PORT_F definition to the PCI IDs patch.
Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180129232223.766-8-rodrigo.vivi@intel.com
Rodrigo Vivi [Mon, 29 Jan 2018 23:22:20 +0000 (15:22 -0800)]
drm/i915: For HPD connected port use hpd_pin instead of port.
Let's try to simplify this mapping to hpd_pin -> bit
instead using port.
So for CNL with port F where we have this port using
hdp_pin and bits of other ports we don't need to duplicated
the mapping.
But for now this is only a re-org with no functional change
expected.
v2: Add missing lines and nuke @port reference from code
documentation. (Ville)
Cc: Lucas De Marchi <lucas.demarchi@intel.com> Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180129232223.766-7-rodrigo.vivi@intel.com
Rodrigo Vivi [Mon, 29 Jan 2018 23:22:18 +0000 (15:22 -0800)]
drm/i915: Fix DPLCLKA_CFGCR0 bits for Port F.
Since when it got introduced with commit '555e38d27317
("drm/i915/cnl: DDI - PLL mapping")' the support for Port F
was wrong, because Port F bits are far from bits used
for A to E.
Since Port F is not used so far we don't need to propagate
Fixes back there.
v2: Reuse _SHIFT definition to avoid complicated duplication (DK).
Rodrigo Vivi [Mon, 29 Jan 2018 23:22:15 +0000 (15:22 -0800)]
drm/i915/cnl: Add AUX-F support
On some Cannonlake SKUs we have a dedicated Aux for port F,
that is only the full split between port A and port E.
There is still no Aux E for Port E, as in previous platforms,
because port_E still means shared lanes with port A.
v2: Rebase.
v3: Add couple missed PORT_F cases on intel_dp.
v4: Rebase and fix commit message.
v5: Squash Imre's "drm/i915: Add missing AUX_F power well string"
v6: Rebase on top of display headers rework.
v7: s/IS_CANNONLAKE/IS_CNL_WITH_PORT_F (DK)
v8: Fix Aux bits for Port F (DK)
v9: Fix VBT definition of Port F (DK).
v10: Squash power well addition to this patch to avoid
warns as pointed by DK.
v11: Clean up squashed commit message. (David)
v12: Remove unnecessary handling for older platforms (DK)
Adding AUX_F to PG2 following other existent ones. (DK)
Cc: David Weinehall <david.weinehall@linux.intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: David Weinehall <david.weinehall@linux.intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180129232223.766-2-rodrigo.vivi@intel.com
Rodrigo Vivi [Mon, 29 Jan 2018 23:22:14 +0000 (15:22 -0800)]
drm/i915/cnl: Add Cannonlake PCI IDs for another SKU.
The only difference is that this SKUs has the full
Port A/E split named as Port F.
But since SKUs differences don't matter on the platform
definition group and ids, let's merge all off them together.
v2: Really include the PCI IDs to the picidlist[];
v3: Add the PCI Id for another SKU (Anusha).
v4: Update IDs, really include to pciidlists again.
v5: Unify all GT2 IDs.
v6: Unify in a way that we don't break early-quirks.c
v7: Remove GT reference since it doesn't matter here (Paulo)
Also move IS_CNL_WITH_PORT_F macro to this patch to
make it easier for review this part and also to get
used sooner.
v8: Rebased on top of commit 5db47e37b387 ("Revert "drm/i915:
mark all device info struct with __initconst"")
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180129232223.766-1-rodrigo.vivi@intel.com
Imre Deak [Tue, 16 Jan 2018 11:24:15 +0000 (13:24 +0200)]
drm/i915: Add WA for planes ending close to left screen edge
While running the kms_plane clipping test I noticed a similar problem to
the one described in Display WA #1175. In this case, similarly for
planes other than the cursor, with 1 or 3 pixels visible from the left
edge of the screen to the end of the plane and an odd plane X offset
used for clipping causes the same kind of underflow and display
corruption as described for WA #1175. Fix this in a similar way as that
WA rejecting planes ending <4 pixels from the left screen edge.
Imre Deak [Tue, 16 Jan 2018 11:24:14 +0000 (13:24 +0200)]
drm/i915: Add display WA #1175 for planes ending close to right screen edge
As described in the WA on GLK and CNL planes on the right edge of the
screen that have less than 4 pixels visible from the beginning of the
plane to the edge of the screen can cause FIFO underflow and display
corruption.
On GLK/CNL I could trigger the problem only if the plane was at the same
time also aligned to the top edge of the screen (after clipping) and
there were exactly 2 pixels visible from the start of the plane to the
right edge of the screen (so couldn't trigger it with 1 or 3 pixels
visible). Nevertheless, to be sure, I also applied the WA for these cases.
I also couldn't see any problem with the cursor plane and later Art
confirmed that it's not affected, so the WA is applied only for the
other plane types.
Rodrigo Vivi [Thu, 25 Jan 2018 22:25:24 +0000 (14:25 -0800)]
drm/i915/cnp: Properly handle VBT ddc pin out of bounds.
If the table result is out of bounds on the array map
there is something really wrong with VBT pin so we don't
return that vbt_pin, but only return 0 instead.
This basically reverts commit 'a8e6f3888b05 ("drm/i915/cnp:
Ignore VBT request for know invalid DDC pin.")'
Also this properly fixes commit 9c3b2689d01f ("drm/i915/cnl:
Map VBT DDC Pin to BSpec DDC Pin.")
v2: Do in a way that we don't break other platforms. (Jani)
v3: Keep debug message (Jani)
v4: Don't mess with 0 mapping was noticed by Jani and
addressed with a simple solution suggested by Lucas
that makes this even simpler.
Fixes: a8e6f3888b05 ("drm/i915/cnp: Ignore VBT request for know invalid DDC pin.") Fixes: 9c3b2689d01f ("drm/i915/cnl: Map VBT DDC Pin to BSpec DDC Pin.") Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Kai Heng Feng <kai.heng.feng@canonical.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Suggested-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180125222524.22059-1-rodrigo.vivi@intel.com
Chris Wilson [Mon, 29 Jan 2018 09:49:12 +0000 (09:49 +0000)]
drm/i915: Assert that we do not try to unsubmit a completed request
Assert that we do not try to unsubmit a completed request, as should we
try to resubmit it later, the ring is already past the request's
breadcrumb and the breadcrumb will not be updated.
Chris Wilson [Mon, 29 Jan 2018 10:28:40 +0000 (10:28 +0000)]
drm/i915: Simplify guard logic for setup_scratch_page()
Older gcc is complaining it can't follow the guards and thinks that
addr may be used uninitialised
In the process, we can simplify down to one loop,
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-131 (-131)
Function old new delta
setup_scratch_page 545 414 -131
Chris Wilson [Fri, 26 Jan 2018 12:18:46 +0000 (12:18 +0000)]
drm/i915/lrc: Remove superfluous WARN_ON
Remove the WARN_ON(ce->state) inside the static function only called
when ce->state == NULL and downgrade the w/a batch setup warning into a
developer only mode (GEM_WARN_ON).
v2: Move the deferred alloc guard into the callee, eliminating the need
for the WARN_ON:
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-1 (-1)
Function old new delta
execlists_context_pin 1819 1818 -1
Chris Wilson [Thu, 25 Jan 2018 11:24:42 +0000 (11:24 +0000)]
drm/i915/lrc: Clear context restore/save inhibit flags for new contexts
CTX_CONTEXT_CONTROL (CTX_SR_CTL) operates as a masked register and so
will only apply the bits that are selected by the upper half. In the
case of selectively enabling sr inhibit, this may mean the context keeps
the current setting (so forgetting to save the context later, eventually
leading to a very upset GPU!).
Fixes: 517aaffe0c1b ("drm/i915/execlists: Inhibit context save/restore for the fake preempt context") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Winiarski <michal.winiarski@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180125112443.12745-1-chris@chris-wilson.co.uk Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Dave Airlie [Thu, 25 Jan 2018 01:42:25 +0000 (11:42 +1000)]
Merge tag 'drm-misc-next-fixes-2018-01-18' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
Fixes for 4.16:
Fixes one Kconfig issue and a enable some panels to work properly.
There is also a fix of error code return in sun4i.
* tag 'drm-misc-next-fixes-2018-01-18' of git://anongit.freedesktop.org/drm/drm-misc:
drm: Fix PANEL_ORIENTATION_QUIRKS breaking the Kconfig DRM menuconfig
drm/panel: lvds: Handle the optional regulator case properly
drm/sun4i: Fix error code in sun4i_tcon_bind()
Dave Airlie [Thu, 25 Jan 2018 01:40:54 +0000 (11:40 +1000)]
Merge branch 'drm-next-4.16' of git://people.freedesktop.org/~agd5f/linux into drm-next
A few more fixes for 4.16, nothing major.
A few more fixes for 4.16. This is on top of the pull request from
last week. Most notable change here is a fix to the link order for
the now separate from amdgpu GPU scheduler to fix crashes when the
modules are build into the kernel rather than as modules.
* 'drm-next-4.16' of git://people.freedesktop.org/~agd5f/linux:
drm: fix gpu scheduler link order
drm/amd/display: Demote error print to debug print when ATOM impl missing
drm/amdgpu: Avoid leaking PM domain on driver unbind (v2)
drm/amd/amdgpu: Add Polaris version check
drm/amdgpu: Reenable manual GPU reset from sysfs
drm/amdgpu: disable MMHUB power gating on raven
drm/ttm: Don't unreserve swapped BOs that were previously reserved
drm/ttm: Don't add swapped BOs to swap-LRU list
drm/amdgpu: only check for ECC on Vega10
drm/amd/powerplay: Fix smu_table_entry.handle type
drm/ttm: add VADDR_FLAG_UPDATED_COUNT to correctly update dma_page global count
drm/radeon: fill in rb backend map on evergreen/ni.
drm/amdgpu/gfx9: fix ngg enablement to clear gds reserved memory (v2)
drm/ttm: only free pages rather than update global memory count together
drm/amdgpu: fix CPU based VM updates
drm/amdgpu: fix typo in amdgpu_vce_validate_bo
drm/amdgpu: fix amdgpu_vm_pasid_fault_credit
drm/ttm: check the return value of register_shrinker
drm/radeon: fix sparse warning: Should it be static?
Christian König [Wed, 24 Jan 2018 10:44:49 +0000 (11:44 +0100)]
drm: fix gpu scheduler link order
It should initialize before the drivers using it.
Signed-off-by: Christian König <christian.koenig@amd.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104736 Reviewed-by: Mike Lothian <mike@fireburn.co.uk> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Harry Wentland [Wed, 3 Jan 2018 14:58:58 +0000 (09:58 -0500)]
drm/amd/display: Demote error print to debug print when ATOM impl missing
I assumed wrongfully that all relevant functions should be implemented.
Apparently this isn't the case. Demote the print to debug level for now.
Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/i915/guc: Fix comments style in intel_guc_log.c
Use consistent multi-line comment style as per guideline.
v2: Reverted comments prefix update to kernel-doc comment. (Chris)
Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: 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/1516808821-3638-5-git-send-email-sagar.a.kamble@intel.com
drm/i915/guc: Update name and prototype of i915_guc_log_control
i915_guc_log_control is GuC interface and GuC APIs that are not user
facing should be named with "intel_guc" prefix hence we change name to
intel_guc_log_control. Also changed the parameter to intel_guc struct.
v2: Move log vma check to intel_guc_log_control (Michal)
Return -ENODEV when log isn't initialized. (Chris)
Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/1516808821-3638-4-git-send-email-sagar.a.kamble@intel.com
drm/i915/guc: Fix lockdep due to log relay channel handling under struct_mutex
This patch fixes lockdep issue due to circular locking dependency of
struct_mutex, i_mutex_key, mmap_sem, relay_channels_mutex.
For GuC log relay channel we create debugfs file that requires i_mutex_key
lock and we are doing that under struct_mutex. So we introduced newer
dependency as:
&dev->struct_mutex --> &sb->s_type->i_mutex_key#3 --> &mm->mmap_sem
However, there is dependency from mmap_sem to struct_mutex. Hence we
separate the relay create/destroy operation from under struct_mutex.
Also added runtime check of relay buffer status. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
======================================================
WARNING: possible circular locking dependency detected
4.15.0-rc6-CI-Patchwork_7614+ #1 Not tainted
------------------------------------------------------
debugfs_test/1388 is trying to acquire lock:
(&dev->struct_mutex){+.+.}, at: [<00000000d5e1d915>] i915_mutex_lock_interruptible+0x47/0x130 [i915]
but task is already holding lock:
(&mm->mmap_sem){++++}, at: [<0000000029a9c131>] __do_page_fault+0x106/0x560
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
1 lock held by debugfs_test/1388:
#0: (&mm->mmap_sem){++++}, at: [<0000000029a9c131>] __do_page_fault+0x106/0x560
stack backtrace:
CPU: 2 PID: 1388 Comm: debugfs_test Not tainted 4.15.0-rc6-CI-Patchwork_7614+ #1
Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./J4205-ITX, BIOS P1.10 09/29/2016
Call Trace:
dump_stack+0x5f/0x86
print_circular_bug.isra.18+0x1d0/0x2c0
__lock_acquire+0x14ae/0x1b60
? lock_acquire+0xaf/0x200
lock_acquire+0xaf/0x200
? i915_mutex_lock_interruptible+0x47/0x130 [i915]
__mutex_lock+0x81/0x9b0
? i915_mutex_lock_interruptible+0x47/0x130 [i915]
? i915_mutex_lock_interruptible+0x47/0x130 [i915]
? i915_mutex_lock_interruptible+0x47/0x130 [i915]
i915_mutex_lock_interruptible+0x47/0x130 [i915]
? __pm_runtime_resume+0x4f/0x80
i915_gem_fault+0x201/0x790 [i915]
__do_fault+0x15/0x70
? _raw_spin_unlock+0x29/0x40
__handle_mm_fault+0x677/0xdc0
handle_mm_fault+0x14f/0x2f0
__do_page_fault+0x2d1/0x560
? page_fault+0x36/0x60
page_fault+0x4c/0x60
v2: Added lock protection to guc->log.runtime.relay_chan (Chris)
Fixed locking inside guc_flush_logs uncovered by new lockdep.
v3: Locking guc_read_update_log_buffer entirely with relay_lock. (Chris)
Prepared intel_guc_init_early. Moved relay_lock inside relay_create
relay_destroy, relay_file_create, guc_read_update_log_buffer. (Michal)
Removed struct_mutex lock around guc_log_flush and removed usage
of guc_log_has_relay() from runtime_create path as it needs
struct_mutex lock.
v4: Handle NULL relay sub buffer pointer earlier in read_update_log_buffer
(Chris). Fixed comment suffix **/. (Michal)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104693
Testcase: igt/debugfs_test/read_all_entries # with enable_guc=1 and guc_log_level=1 Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Marta Lofstedt <marta.lofstedt@intel.com> Cc: Michal Winiarski <michal.winiarski@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/1516808821-3638-3-git-send-email-sagar.a.kamble@intel.com
drm/i915/guc: Enable interrupts before resuming GuC during runtime resume
GuC log streaming needs interrupts enabled prior to GuC resume but
runtime pm interrupt setup was happening post GuC resume. Fix it.
While at it, fix the unwinding of steps in the runtime suspend path.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104695 Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Marta Lofstedt <marta.lofstedt@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/1516808821-3638-2-git-send-email-sagar.a.kamble@intel.com
drm/i915/guc: Grab RPM wakelock while disabling GuC interrupts
Disabling GuC interrupts involves access to GuC IRQ control registers
hence ensure device is RPM awake.
v1-v2: old changelog
1: Add comment about need to synchronize flush work and log runtime
destroy
2: Moved patch earlier in the series and removed comment about future
work. (Tvrtko)
v3: Added assert_rpm_wakelock_held() to gen9_*_guc_interrupts. (Chris)
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@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/1516808821-3638-1-git-send-email-sagar.a.kamble@intel.com
Ville Syrjälä [Mon, 22 Jan 2018 17:41:31 +0000 (19:41 +0200)]
drm/i915: Implement display w/a #1143
Apparently SKL/KBL/CFL need some manual help to get the
programmed HDMI vswing to stick. Implement the relevant
workaround (display w/a #1143).
Note that the relevant chicken bits live in a transcoder register
even though the bits affect a specific DDI port rather than a
specific transcoder. Hence we must pick the correct transcoder
register instance based on the port rather than based on the
cpu_transcoder.
Also note that for completeness I included support for DDI A/E
in the code even though we never have HDMI on those ports.
Chris Wilson [Wed, 24 Jan 2018 11:36:07 +0000 (11:36 +0000)]
drm/i915: Track the number of times we have woken the GPU up
By counting the number of times we have woken up, we have a very simple
means of defining an epoch, which will come in handy if we want to
perform deferred tasks at the end of an epoch (i.e. while we are going
to sleep) without imposing on the next activity cycle.
v2: No reason to specify precise number of bits here.
v3: Take Tvrtko's advice and reserve 0 as an invalid epoch.
Chris Wilson [Tue, 23 Jan 2018 21:04:12 +0000 (21:04 +0000)]
drm/i915/execlists: Inhibit context save/restore for the fake preempt context
We only use the preempt context to inject an idle point into execlists.
We never need to reference its logical state, so tell the GPU never to
load it or save it.
v2: BIT(2) for save-inhibit.
N.B. Daniele mentioned this bit mbz for ICL, and has been moved into the
submission process rather than the context image.
Suggested-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Winiarski <michal.winiarski@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180123210412.17653-1-chris@chris-wilson.co.uk
Michel Thierry [Wed, 24 Jan 2018 00:43:49 +0000 (16:43 -0800)]
drm/i915: Move LRC register offsets to a header file
Newer platforms may have subtle offset changes, which will increase the
number of defines, so it is probably better to start moving them to its
own header file. Also move the macros used while setting the reg state.
v2: Rename to intel_lrc_reg.h, to be consistent with i915_reg.h and
intel_guc_reg.h (Chris)
v3: License notice shenanigans.
v4: Documentation/process/coding-style.rst is always right (Chris)
v5: Rebase.
Signed-off-by: Michel Thierry <michel.thierry@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180124004349.22126-2-michel.thierry@intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tvrtko Ursulin [Tue, 23 Jan 2018 13:45:58 +0000 (13:45 +0000)]
drm/i915/pmu: Fix sysfs exported counter config
We need to generate the event config value using the uAPI class and not
the driver internal one.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 109ec558370f ("drm/i915/pmu: Only enumerate available counters in sysfs") Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180123134558.3222-1-tvrtko.ursulin@linux.intel.com
James Zhu [Mon, 22 Jan 2018 18:46:16 +0000 (13:46 -0500)]
drm/amd/amdgpu: Add Polaris version check
Add Polaris version check if firmware support UVD encode
Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: James Zhu <James.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
Chris Wilson [Mon, 22 Jan 2018 13:55:41 +0000 (13:55 +0000)]
drm/i915: Increase render/media power gating hysteresis for gen9+
On gen9+, after an idle period the HW will disable the entire power well
to conserve power (by preventing current leakage). It takes around a 100
microseconds to bring the power well back online afterwards. With the
current hysteresis value of 25us (really 25 * 1280ns), we do not have
sufficient time to respond to an interrupt and schedule the next execution
before the HW powers itself down. (At present, we prevent this by
grabbing the forcewake for prolonged periods of time, but that overkill
fixed in the next patch.) The minimum we want to set the power gating
hysteresis to is the length of time it takes us to service the GPU, which
across a broad spectrum of machines is about 250us.
(Note this also brings guc latency into the same ballpark as execlists.)
v2: Include some notes on where I plucked the numbers from.
Testcase: igt/gem_exec_nop/sequential Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Michal Winiarski <michal.winiarski@intel.com> Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180122135541.32222-1-chris@chris-wilson.co.uk
Tvrtko Ursulin [Fri, 19 Jan 2018 10:00:04 +0000 (10:00 +0000)]
drm/i915: Per-engine scratch VMA is mandatory
We fail engine initialization if the scratch VMA cannot be created so
there is no point in error handle it later. If the initialization ordering
gets messed up, we can explode during development just as well.
Tvrtko Ursulin [Fri, 19 Jan 2018 10:00:03 +0000 (10:00 +0000)]
drm/i915: Downgrade incorrect engine constructor usage warnings to development
Render engine constructor helpers must only be called from the render
engine constructors, but there is no need to burden the production
binaries with warnings which can only be triggered during development.
Manasi Navare [Thu, 12 Oct 2017 19:13:38 +0000 (12:13 -0700)]
drm/i915/edp: Do not do link training fallback or prune modes on EDP
In case of eDP because the panel has a fixed mode, the link rate
and lane count at which it is trained corresponds to the link BW
required to support the native resolution of the panel. In case of
panles with lower resolutions where fewer lanes are hooked up internally,
that number is reflected in the MAX_LANE_COUNT DPCD register of the panel.
So it is pointless to fallback to lower link rate/lane count in case
of link training failure on eDP connector since the lower link BW
will not support the native resolution of the panel and we cannot
prune the preferred mode on the eDP connector.
In case of Link training failure on the eDP panel, something is wrong
in the HW internally and hence driver errors out with a loud
and clear DRM_ERROR message.
v2:
* Fix the DEBUG_ERROR and add {} in else (Ville Syrjala)
Cc: Clinton Taylor <clinton.a.taylor@intel.com> Cc: Jim Bride <jim.bride@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=103369 Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1507835618-23051-1-git-send-email-manasi.d.navare@intel.com
Chris Wilson [Sun, 21 Jan 2018 17:31:43 +0000 (17:31 +0000)]
drm/i915: Protect WC stash allocation against direct reclaim
As we attempt to allocate pages for use in a new WC stash, direct
reclaim may run underneath us and fill up the WC stash. We have to be
careful then not to overflow the pvec.
Fixes: 66df1014efba ("drm/i915: Keep a small stash of preallocated WC pages")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103109 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180121173143.17090-1-chris@chris-wilson.co.uk
Michal Wajdeczko [Fri, 19 Jan 2018 12:49:26 +0000 (12:49 +0000)]
drm/i915/guc: Keep GuC log disabled by default
It looks that GuC log functionality is not fully functional yet and
causes issues when enabled by auto(-1) modparam on debug builds.
For example, but not limited to:
[ 30.062893] ======================================================
[ 30.062894] WARNING: possible circular locking dependency detected
[ 30.062895] 4.15.0-rc8-CI-CI_DRM_3648+ #1 Tainted: G U
[ 30.062896] ------------------------------------------------------
[ 30.062897] debugfs_test/1268 is trying to acquire lock:
[ 30.062898] (&dev->struct_mutex){+.+.}, at: [<00000000e4213449>] i915_mutex_lock_interruptible+0x47/0x130 [i915]
[ 30.062921]
but task is already holding lock:
[ 30.062921] (&mm->mmap_sem){++++}, at: [<00000000dd7adc93>] __do_page_fault+0x106/0x560
[ 30.062924]
which lock already depends on the new lock.
References: 0ed87953532652 ("drm/i915/guc: Redefine guc_log_level modparam values")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104693
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104694
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104695 Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Saarinen <jani.saarinen@intel.com> Cc: Tomi Sarvela <tomi.p.sarvela@intel.com> Cc: Marta Lofstedt <marta.lofstedt@intel.com> Cc: Michal Winiarski <michal.winiarski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180119124926.29844-1-michal.wajdeczko@intel.com Reviewed-by: Michal Winiarski <michal.winiarski@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tvrtko Ursulin [Thu, 11 Jan 2018 22:55:07 +0000 (14:55 -0800)]
drm/i915/icl: Gen11 render context size
Gen11 removes the Resource Streamer, which frees up a big chunk of
the context image. BSpec indicates 12544 DWORDs (13 pages), plus
one page for PPHWSP.
Please notice that, when looking at the BSpec context image table,
the right filter has to be applied as some rows are excluded for
specific GENs. Also, some rows apply per-subslice (for the
calculation above, we have supposed I915_MAX_SUBSLICES = 8).
v2: Rebase.
v3: Use the right size as per the BSpec.
v4:
- Rebased on top of the default context size (Rodrigo)
- Clarify in the commit message where the subslice calculation
comes from.
v5: s/12538/12544/ (Daniele)
BSpec: 18907
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Ben Widawsky <benjamin.widawsky@intel.com> (older version) Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1515711307-28979-2-git-send-email-oscar.mateo@intel.com
Oscar Mateo [Thu, 11 Jan 2018 22:55:06 +0000 (14:55 -0800)]
drm/i915: Return a default RCS context size
Instead of returning whatever size the latest GEN used. This is because
context sizes for new GENs can go up or down, but the only safe thing to
do for missing cases is to use the largest known one, whatever that is.
Anusha Srivatsa [Fri, 19 Jan 2018 18:48:12 +0000 (16:48 -0200)]
drm/i915/icp: Add backlight Support for ICP
ICP has two backlight controllers - similar to previous platforms like
BXT -, but we only use one controller for now, so we can just reuse
the CNP code.
v2: Remove the usage of ICP_SECOND_PPS_BACKLIGHT register.(Jani)
Reuse CNP code since it is very similar.(Ville)
v3 (from Paulo): Rebase.
v4 (from Paulo): adjust commit message (James) and comment (Rodrigo).
Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: James Ausmus <james.ausmus@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180119184812.2888-1-paulo.r.zanoni@intel.com Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Anusha Srivatsa [Thu, 11 Jan 2018 18:00:07 +0000 (16:00 -0200)]
drm/i915/icp: Add Panel Power Sequencing Support
ICP, like BXT, has has two panel power sequencers.
v2: Simplify the code. Remove unwanted register definitions.
Make code as close to BXT style as possible. (Ville)
Also, remove the use of ICP_SECOND_PPS_BACKLIGHT for now.
Moving forward, if we are sure we need to set this register,
we can access it.
v3: Use INTEL_GEN(dev_priv), make code more readeable. (Ville)
v5: Use per platform checks rather than INTEL_GEN().
v4 of this patch breaks on CoffeeLake, since CFL uses
CNP and per platform check makes sense in that case.
v6 (from Paulo):
- v5 was a patch on top of v4, not a new version. Now v6 is correctly
a new version of the original patch.
Rodrigo Vivi [Thu, 11 Jan 2018 18:00:04 +0000 (16:00 -0200)]
drm/i915/icl: Add initial Icelake definitions.
Icelake is an Intel® Processor containing an Intel® Graphics
Controller.
This is just an initial Icelake definition. PCI IDs, Icelake support
and new features coming in following patches.
v2: Add .ddb_size and .has_guc (Michal Wajdeczko).
v3: Add the ICL_FEATURES macro (Kelvin Gardiner).
v4 (from Paulo): Add missing __initconst (Paulo) and say "graphics
controller" instead of something that looks like an official marketing
name but isn't (Chris).
Rodrigo Vivi [Thu, 11 Jan 2018 18:00:03 +0000 (16:00 -0200)]
drm/i915/cnl: Add Port F definition.
Some Cannonlake SKUs will come with a full split between
port A and port E. This will be called port F although it
is not a 6th port, but only a split.
Note this patch alone is not sufficient for port F enabling,
it's just the first step.
v2: Fix size of dvo_ports found by Ander.
v3: Adding missing cases from intel_bios.c for Port_F
v4: Adding other missing cases and fix the commit message.
v5: Rebase on top of display headers rework.
v6 (from Paulo): improve commit message, bikeshed bit definitions.
Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180111180010.24357-2-paulo.r.zanoni@intel.com
Mika Kahola [Mon, 18 Dec 2017 08:04:03 +0000 (10:04 +0200)]
drm/i915: Check for fused or unused pipes
We may have fused or unused pipes in our system. Let's check that the pipe
in question is within limits of accessible pipes. In case, that we are not
able to access the pipe, we return early with a warning.
v2: Rephrasing of the commit message (Jani)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103206 Reported-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Jaswinder Singh Rajput <jaswinder@perfectintelligent.com> Suggested-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1513584243-12607-1-git-send-email-mika.kahola@intel.com
Ville Syrjälä [Fri, 22 Dec 2017 19:22:28 +0000 (21:22 +0200)]
drm/i915: Add CCS capability for sprites
Allow sprites to scan out compressed framebuffers.
Since different platforms have a different set of planes that
support CCS let's add a small helper to determine whether a
specific plane supports CCS or not. Currently that information
is spread around in many places, and not all the pieces of
code even agree with each other.
In addition to allowing sprites to scan out compressed fbs,
the other fix here is that we stop rejecting them on pipe C
on CNL.
Ville Syrjälä [Fri, 22 Dec 2017 19:22:27 +0000 (21:22 +0200)]
drm/i915: Clean up the sprite modifier checks
Split the g4x and snb cases into separate functions to match how we deal
with all other platforms. Also sort the switch cases to match the format
lists we've declared earlier, to ease comparisons.
Ville Syrjälä [Fri, 22 Dec 2017 19:22:26 +0000 (21:22 +0200)]
drm/i915: Add the missing Y/Yf modifiers for SKL+ sprites
Y/Yf were dropped out from the SKL+ sprite modifier list on account
of some watermark issues Daniel Stone was having. My subsequent testing
seemed to indicate that things work better now, so add the modifiers
back in.
v2: Update the commit message with a better explanation
Abdiel Janulgue [Fri, 15 Dec 2017 10:20:55 +0000 (12:20 +0200)]
drm/i915: Ignore TMDS clock limit for DP++ when EDID override is set
4K modes testing by using dummy EDID data has never been working
properly on boxes with DP++ (dual-mode) adaptors. The reason for
this is that those modes got pruned during hdmi mode validation.
intel_hdmi_mode_valid returns CLOCK_HIGH because the pixel clock
reported by the 4k mode is higher than dual port TMDS clock limit.
However 4k injection does work properly on machines that don't have
DP++ adapters because the mode is never validated against the DP++
TMDS clock limit.
v2: Don't detect the DP++ limits when we're testing using overridden
EDIDs. Make sure to check for the override condition after
respecting the value of drm_dp_dual_mode_detect (Jani Nikula).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101649 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171215102055.11729-1-abdiel.janulgue@linux.intel.com
Jani Nikula [Fri, 29 Dec 2017 12:55:47 +0000 (14:55 +0200)]
drm/i915: remove redundant ELD connector type update
drm_edid_to_eld() sets ELD connector type since commit 1d1c36650752
("drm/edid: set ELD connector type in drm_edid_to_eld()"). Remove the
redundant update.
(Commit c945b8c14bb7 ("drm/edid: build ELD in drm_add_edid_modes()") and
commit d471ed04b487 ("drm/drivers: drop redundant drm_edid_to_eld()
calls") are also related.)
v2: Rebase, update commit message with commit references.
Felix Kuehling [Thu, 18 Jan 2018 04:54:07 +0000 (23:54 -0500)]
drm/ttm: Don't unreserve swapped BOs that were previously reserved
If ttm_bo_swapout doesn't own the lock, don't release it. Someone
else probably depends on it still being locked.
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Felix Kuehling [Thu, 18 Jan 2018 04:52:03 +0000 (23:52 -0500)]
drm/ttm: Don't add swapped BOs to swap-LRU list
A BO that's already swapped would be added back to the swap-LRU list
for example if its validation failed under high memory pressure. This
could later lead to swapping it out again and leaking previous swap
storage.
This commit adds a condition to prevent that from happening.
v2: Check page_flags instead of swap_storage
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
Roger He [Mon, 15 Jan 2018 05:06:38 +0000 (13:06 +0800)]
drm/ttm: add VADDR_FLAG_UPDATED_COUNT to correctly update dma_page global count
add this for correctly updating global mem count in ttm_mem_zone.
before that when ttm_mem_global_alloc_page fails, we would update all
dma_page's global mem count in ttm_dma->pages_list. but actually here
we should not update for the last dma_page.
v2: only the update of last dma_page is not right
v3: use lower bits of dma_page vaddr
Signed-off-by: Roger He <Hongbo.He@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Lucas De Marchi [Tue, 28 Nov 2017 22:05:53 +0000 (14:05 -0800)]
drm/i915/cnl: apply Display WA #1178 to fix type C dongles
Display WA #1178 is meant to fix Aux channel voltage swing too low with
some type C dongles. Although it is for type C, HW engineers reported
that it can be applied to all external ports even if they are not going
to type C.
For CNL we apply the workaround every time Aux B, C and D are powering
up since they will lose the configuration when powered down.
v2: Use common tag for WA
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Arthur J Runyan <arthur.j.runyan@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171128220553.22435-1-lucas.demarchi@intel.com
Michal Wajdeczko [Thu, 11 Jan 2018 15:24:41 +0000 (15:24 +0000)]
drm/i915/guc: Change values for i915_guc_log_control
Today we have format mismatch between read/write operations
of i915_guc_log_control entry. For read we return (0, 1..4)
that represents disable/verbosity levels, but for write we
force user to follow internal structure format (0,1,9,11,13).
Let's hide internals from the user and accept same values
as we support for read and related guc_log_level modparam.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180111152441.21676-2-michal.wajdeczko@intel.com Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>