Lucas De Marchi [Fri, 7 Jun 2019 09:12:26 +0000 (02:12 -0700)]
drm/i915/dmc: extract function to parse package_header
Like parse_csr_fw_css() this parses the package_header from firmware and
saves the relevant fields in the csr struct. In this function we also
lookup the fw_info we are interested in.
Lucas De Marchi [Fri, 7 Jun 2019 09:12:25 +0000 (02:12 -0700)]
drm/i915/dmc: extract function to parse css header
Let's start splitting the parse function, making all of them return the
number of bytes parsed - different versions of the firmware header may
require different sizes for the structures.
v2: rework remaining bytes calculation on new protection for amount of
bytes read
Lucas De Marchi [Fri, 7 Jun 2019 09:12:23 +0000 (02:12 -0700)]
drm/i915/dmc: extract fw_info and table walk from intel_package_header
Move fw_info out of struct intel_package_header to allow it to grow more
easily in future. To make a cleaner move, let's also extract a function to
search the header for the dmc_offset.
While reviewing this code I wondered why we continued the search even
after finding a suitable firmware. Add a comment to explain we will
continue to try to find a more specific firmware version, even if this
is not required by the spec.
Mika Kuoppala [Fri, 14 Jun 2019 16:43:45 +0000 (19:43 +0300)]
drm/i915/gtt: Generalize alloc_pd
Allocate all page directory variants with alloc_pd. As
the lvl3 and lvl4 variants differ in manipulation, we
need to check for existence of backing phys page before accessing
it.
Mika Kuoppala [Fri, 14 Jun 2019 16:43:42 +0000 (19:43 +0300)]
drm/i915/gtt: Use a common type for page directories
All page directories are identical in function, only the position in the
hierarchy differ. Use same base type for directory functionality.
v2: cleanup, size always 512, init to null
Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Matthew Auld <matthew.william.auld@gmail.com> Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190614164350.30415-2-mika.kuoppala@linux.intel.com
drm/i915: no need to check return value of debugfs_create functions
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190613145229.21389-1-jani.nikula@intel.com
Shashank Sharma [Wed, 12 Jun 2019 06:45:00 +0000 (12:15 +0530)]
drm/i915/icl: Add Multi-segmented gamma support
ICL introduces a new gamma correction mode in display engine, called
multi-segmented-gamma mode. This mode allows users to program the
darker region of the gamma curve with sueprfine precision. An
example use case for this is HDR curves (like PQ ST-2084).
If we plot a gamma correction curve from value range between 0.0 to 1.0,
ICL's multi-segment has 3 different sections:
- superfine segment: 9 values, ranges between 0 - 1/(128 * 256)
- fine segment: 257 values, ranges between 0 - 1/(128)
- corase segment: 257 values, ranges between 0 - 1
This patch:
- Changes gamma LUTs size for ICL/GEN11 to 262144 entries (8 * 128 * 256),
so that userspace can program with highest precision supported.
- Changes default gamma mode (non-legacy) to multi-segmented-gamma mode.
- Adds functions to program/detect multi-segment gamma.
V2: Addressed review comments from Ville
- separate function for superfine and fine segments.
- remove enum for segments.
- reuse last entry of the LUT as gc_max value.
- replace if() ....cond with switch...case in icl_load_luts.
- add an entry variable, instead of 'word'
V3: Addressed review comments from Ville
- extra newline
- s/entry/color/
- remove LUT size checks
- program ilk_lut_12p4_ldw value before ilk_lut_12p4_udw
- Change the comments in description of fine and coarse segments,
and try to make more sense.
- use 8 * 128 instead of 1024
- add 1 entry in LUT for GCMAX
V4: Addressed review comments from Ville
- Remove unused macro
- missing shift entry in blue
- pick correct entry for GCMAX
- Added Ville's R-B
Note: Tested and confirmed the programming sequence of odd/even
registers in the HW. The correct sequence should be:
ilk_lut_12p4_udw
ilk_lut_12p4_ldw
v5: Addressed Ville's review comments and renamed odd/even register
helpers to be more consistent with the values.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1560321900-18318-5-git-send-email-uma.shankar@intel.com
Uma Shankar [Wed, 12 Jun 2019 06:44:58 +0000 (12:14 +0530)]
drm/i915/icl: Add register definitions for Multi Segmented gamma
Add macros to define multi segmented gamma registers
V2: Addressed Ville's comments:
Add gen-lable before bit definition
Addressed Jani's comment
- Use REG_GENMASK() and REG_BIT()
V3: Addressed Ville's comments:
- Put comments at the end of line.
- Change the comment at start of ICL multisegmented gamma registers.
Added Ville's r-b
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1560321900-18318-3-git-send-email-uma.shankar@intel.com
Shashank Sharma [Wed, 12 Jun 2019 06:44:57 +0000 (12:14 +0530)]
drm/i915: Change gamma/degamma_lut_size data type to u32
Currently, data type of gamma_lut_size & degamma_lut_size elements
in intel_device_info is u16, which means it can accommodate maximum
64k values. In case of ICL multisegmented gamma, the size of gamma
LUT is 256K.
This patch changes the data type of both of these elements to u32.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Uma Shankar <uma.shankar@intel.com>
V4: Added Uma's r-b.
Jani Nikula [Thu, 13 Jun 2019 08:44:15 +0000 (11:44 +0300)]
drm/i915: move modesetting output/encoder code under display/
Add a new subdirectory for display code, and start off by moving
modesetting output/encoder code. Judging by the include changes, this is
a surprisingly clean operation.
v2:
- move intel_sdvo_regs.h too
- use tabs for Makefile file lists and sort them
Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190613084416.6794-2-jani.nikula@intel.com
Jani Nikula [Thu, 13 Jun 2019 10:08:18 +0000 (13:08 +0300)]
drm/i915: make intel_sdvo_regs.h self-contained
Ensure intel_sdvo_regs.h is self-contained and remains that way.
v2:
- include <linux/compiler.h> for __packed (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190613100818.24800-1-jani.nikula@intel.com
Chris Wilson [Fri, 14 Jun 2019 22:06:16 +0000 (23:06 +0100)]
drm/i915: Avoid tainting i915_gem_park() with wakeref.lock
While we need to flush the wakeref before parking, we do not need to
perform the i915_gem_park() itself underneath the wakeref lock, merely
the struct_mutex. If we rearrange the locks, we can avoid the unnecessary
tainting.
Chris Wilson [Fri, 14 Jun 2019 16:46:06 +0000 (17:46 +0100)]
drm/i915: Replace engine->timeline with a plain list
To continue the onslaught of removing the assumption of a global
execution ordering, another casualty is the engine->timeline. Without an
actual timeline to track, it is overkill and we can replace it with a
much less grand plain list. We still need a list of requests inflight,
for the simple purpose of finding inflight requests (for retiring,
resetting, preemption etc).
Chris Wilson [Fri, 14 Jun 2019 16:46:04 +0000 (17:46 +0100)]
drm/i915: Keep contexts pinned until after the next kernel context switch
We need to keep the context image pinned in memory until after the GPU
has finished writing into it. Since it continues to write as we signal
the final breadcrumb, we need to keep it pinned until the request after
it is complete. Currently we know the order in which requests execute on
each engine, and so to remove that presumption we need to identify a
request/context-switch we know must occur after our completion. Any
request queued after the signal must imply a context switch, for
simplicity we use a fresh request from the kernel context.
The sequence of operations for keeping the context pinned until saved is:
- On context activation, we preallocate a node for each physical engine
the context may operate on. This is to avoid allocations during
unpinning, which may be from inside FS_RECLAIM context (aka the
shrinker)
- On context deactivation on retirement of the last active request (which
is before we know the context has been saved), we add the
preallocated node onto a barrier list on each engine
- On engine idling, we emit a switch to kernel context. When this
switch completes, we know that all previous contexts must have been
saved, and so on retiring this request we can finally unpin all the
contexts that were marked as deactivated prior to the switch.
We can enhance this in future by flushing all the idle contexts on a
regular heartbeat pulse of a switch to kernel context, which will also
be used to check for hung engines.
Asserts aside, all the code working on this structure is in
intel_runtime_pm.c and uses the intel_ prefix, so move the
structure to intel_runtime_pm.h and adopt the same prefix.
Since all the asserts are now working on the runtime_pm structure,
bring them across as well.
v2: drop unneeded include (Chris), don't rename debugfs, rebase
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190613232156.34940-5-daniele.ceraolospurio@intel.com
Quite a few of the call points have already switched to the version
working directly on the runtime_pm structure, so let's switch over the
rest and kill the i915-based asserts.
drm/i915: prefer i915_runtime_pm in intel_runtime function
As a first step towards updating the code to work on the runtime_pm
structure instead of i915, rework all the internals to use and pass
around that.
v2: add comment for kdev (Jani), move rpm init after pdev init for
mock_device
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190613232156.34940-2-daniele.ceraolospurio@intel.com
Matt Roper [Wed, 12 Jun 2019 18:36:31 +0000 (11:36 -0700)]
drm/i915: Add Wa_1409120013:icl,ehl
This chicken bit should be set before enabling FBC to avoid screen
corruption when the plane size has odd vertical and horizontal
dimensions. It is safe to leave the bit set even when FBC is disabled.
v2:
- The bspec's name for this bit on these platforms ("Spare 14") is
pretty meaningless. Let's rename the bit definition to something
that more accurately reflects what the bit really does. (Clint)
v3:
- The chicken register was already defined (along with a few other
gen9-specific bits) farther down. Just add the new bit definition
there. (Clint)
Chris Wilson [Fri, 14 Jun 2019 07:09:46 +0000 (08:09 +0100)]
drm/i915: Refine i915_reset.lock_map
We already use a mutex to serialise i915_reset() and wedging, so all we
need it to link that into i915_request_wait() and we have our lock cycle
detection.
Chris Wilson [Fri, 14 Jun 2019 11:10:53 +0000 (12:10 +0100)]
drm/i915: Execute signal callbacks from no-op i915_request_wait
If we enter i915_request_wait() with an already completed request, but
unsignaled dma-fence, signal the fence before returning. This allows us
to execute any of the signal callbacks at the earliest opportunity.
Chris Wilson [Fri, 14 Jun 2019 11:10:52 +0000 (12:10 +0100)]
drm/i915: Discard some redundant cache domain flushes
Since commit a679f58d0510 ("drm/i915: Flush pages on acquisition"), we
flush objects on acquire their pages and as such when we create an
object for the purpose of writing into it, we do not need to manually
flush.
Chris Wilson [Thu, 13 Jun 2019 07:32:54 +0000 (08:32 +0100)]
drm/i915: Move fence register tracking from i915->mm to ggtt
As the fence registers only apply to regions inside the GGTT is makes
more sense that we track these as part of the i915_ggtt and not the
general mm. In the next patch, we will then pull the register locking
underneath the i915_ggtt.mutex.
Chris Wilson [Wed, 12 Jun 2019 15:13:11 +0000 (16:13 +0100)]
drm/i915: kerneldoc warnings squelched
drivers/gpu/drm/i915//gem/i915_gem_shrinker.c:142: warning: Function parameter or member 'shrink' not described in 'i915_gem_shrink'
drivers/gpu/drm/i915//gem/i915_gem_shrinker.c:142: warning: Excess function parameter 'flags' description in 'i915_gem_shrink'
drivers/gpu/drm/i915//intel_display.c:13443: warning: Function parameter or member '_state' not described in 'intel_atomic_check'
drivers/gpu/drm/i915//intel_display.c:13443: warning: Excess function parameter 'state' description in 'intel_atomic_check'
Chris Wilson [Wed, 12 Jun 2019 10:57:20 +0000 (11:57 +0100)]
drm/i915: Combine unbound/bound list tracking for objects
With async binding, we don't want to manage a bound/unbound list as we
may end up running before we even acquire the pages. All that is
required is keeping track of shrinkable objects, so reduce it to the
minimum list.
Ville Syrjälä [Wed, 5 Jun 2019 16:29:46 +0000 (19:29 +0300)]
drm/i915: Kill INTEL_SUBPLATFORM_AML
All AML parts are either KBL ULX or CFL ULX so there is no point
in keeping INTEL_SUBPLATFORM_AML around. As these are the only
CFL ULX parts (normal CFL didn't have Y SKUs) so we'll just
replace IS_AML_ULX with IS_CFL_ULX (it was already paired with
IS_KBL_ULX which accounts for the other half of the AML parts).
Ville Syrjälä [Tue, 4 Jun 2019 20:09:33 +0000 (23:09 +0300)]
drm/i915: Improve WRPLL reference clock readout on HSW/BDW
On non-ULT HSW the "special" WRPLL reference clock select
actually means non-SSC. Take that into account when reading
out the WRPLL state.
Also the non-SSC reference may be either 24MHz or 135MHz,
which we can read out from FUSE_STRAP3. The BDW docs actually
say: "also indicates whether the CPU and PCH are in a single
package or separate packages", so it may be that this is not
actually required and we could just assume 135 MHz (just like
the code already did). But it doesn't really hurt to read this
out as the HSW docs aren't quite so clear.
Ville Syrjälä [Tue, 4 Jun 2019 20:09:29 +0000 (23:09 +0300)]
drm/i915: Do not touch the PCH SSC reference if a PLL is using it
Our PCH refclk init code currently assumes that the PCH SSC reference
can only be used for FDI. That is not true and it can be used by
SPLL/WRPLL for eDP SSC or clock bending as well. Before we go
reconfiguring it let's make sure no PLL is currently using the PCH
SSC reference.
For some reason the hw is not particularly upset about losing
the clock if we immediately follow up with a modeset. Can't
really explain why nothing times out during the crtc disable
at least, but that's what the logs say. With fastboot the
story is quite different and we lose the entire display if
we turn off the PCH SSC reference when it's still being used.
Since we totally skip configuring the PCH SSC reference it
may not be in the proper state for FDI. Hopefully that won't
be a problem in practice.
We really should move this code to be part of the modeset seqeuence
and properly deal with the potentially conflicting requirements
imposed on PLL reference clocks. But that requires actual work.
Let's toss in a TODO for that.
v2: Pimp the commit message with the fastboot vs. not
details
Cc: Julius B. <freedesktop@blln.gr> Cc: Johannes Krampf <johannes.krampf@gmail.com> Tested-by: Johannes Krampf <johannes.krampf@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108773 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190604200933.29417-1-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Chris Wilson [Wed, 12 Jun 2019 08:52:46 +0000 (09:52 +0100)]
drm/i915: Prevent lock-cycles between GPU waits and GPU resets
We cannot allow ourselves to wait on the GPU while holding any lock as we
may need to reset the GPU. While there is not an explicit lock between
the two operations, lockdep cannot detect the dependency. So let's tell
lockdep about the wait/reset dependency with an explicit lockmap.
Lucas De Marchi [Mon, 10 Jun 2019 21:48:47 +0000 (14:48 -0700)]
drm/i915/skl: use ranges for voltage level lookup
Like was done for ICL, let's convert the voltage level lookup to use
frequency ranges rather than individual frequencies. For deciding the
voltage, the individual value doesn't really matter.
Lucas De Marchi [Mon, 10 Jun 2019 21:48:34 +0000 (14:48 -0700)]
drm/i915/cnl: use ranges for voltage level lookup
Like was done for ICL, let's convert the voltage level lookup to use
frequency ranges rather than individual frequencies. For deciding the
voltage, the individual value doesn't really matter.
Lucas De Marchi [Mon, 10 Jun 2019 21:48:19 +0000 (14:48 -0700)]
drm/i915/icl: use ranges for voltage level lookup
Spec shows voltage level 0 as 307.2, 312, or lower and suggests to use
range checks. Prepare for having other frequencies in these ranges by
not comparing the exact frequency.
v2: invert checks by comparing biggest cdclk first (suggested by Ville)
Chris Wilson [Mon, 10 Jun 2019 14:54:30 +0000 (15:54 +0100)]
drm/i915: Promote i915->mm.obj_lock to be irqsafe
The intent is to be able to update the mm.lists from inside an irqsoff
section (e.g. from a softirq rcu workqueue), ergo we need to make the
i915->mm.obj_lock irqsafe.
v2: can_discard_pages() ensures we are shrinkable
v3: Beware shadowing of 'flags'
Fixes: 3b4fa9640ccd ("drm/i915: Track the purgeable objects on a separate eviction list")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110869 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Matthew Auld <matthew.william.auld@gmail.com> Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190610145430.17717-1-chris@chris-wilson.co.uk
Chris Wilson [Mon, 10 Jun 2019 10:36:10 +0000 (11:36 +0100)]
drm/i915: Allow interrupts when taking the timeline->mutex
Before we commit ourselves to writing commands into the
ringbuffer and submitting the request, allow signals to interrupt
acquisition of the timeline mutex. We allow ourselves to be interrupted
at any time later if we need to block for space in the ring, anyway.
The size has been increased to 2MB starting from Gen11. GuC and HuC FWs
fit in 1MB so we were fine even with the legacy define, but let's still
move to the correct one before the blobs grow to avoid being caught off
guard in the future.
v2: return early if the platform doesn't have GuC, fix nits (Michal)
Bspec: 12690 Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com>
[ickle: use SZ consistently] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190606224225.14287-2-daniele.ceraolospurio@intel.com
drm/i915/guc: always use Command Transport Buffers
Now that we've moved the Gen9 GuC blobs to version 32 we have CTB
support on all gens, so no need to restrict the usage to Gen11+.
Note that MMIO communication is still required for CTB initialization.
Hans de Goede [Wed, 5 Jun 2019 18:17:35 +0000 (20:17 +0200)]
drm/i915/dsi: Read back pclk set by GOP and use that as pclk (v3)
The GOP sometimes initializes the pclk at a (slightly) different frequency
then the pclk which we've calculated.
This commit makes the DSI code read-back the pclk set by the GOP and
if that is within a reasonable margin of the calculated pclk, uses
that instead.
This fixes the first modeset being a full modeset instead of a
fast modeset on systems where the GOP pclk is different.
Changes in v2:
-Use intel_encoder_current_mode() to get the pclk setup by the GOP
Changes in v3:
-Back to the readback approach, skipping the dsi_pll.ctrl / .dev checks
in intel_pipe_config_compare() when adjust is set leads to:
[drm:pipe_config_err [i915]] *ERROR* mismatch in dsi_pll.ctrl (...)
[drm:pipe_config_err [i915]] *ERROR* mismatch in dsi_pll.div (...)
-Do the readback and pclk overriding from vlv_dsi_init(), rather then from
intel_dsi_vbt_init() as the vbt code should not be touching the hw
Hans de Goede [Wed, 5 Jun 2019 18:17:34 +0000 (20:17 +0200)]
drm/i915/dsi: Move vlv/icl_dphy_param_init call out of intel_dsi_vbt_init (v2)
The vlv/icl_dphy_param_init calls do various calculations to set dphy
parameters based on the pclk.
Move the calling of vlv/icl_dphy_param_init to vlv_dsi_init to give
vlv_dsi_init a chance to tweak the pclk before these calculations are done.
Changes in v2:
-Also moves the icl and vlv specific dphy_param_init functions from the
generic intel_dsi_vbt.c file into the icl_ and vlv_dsi.c specific files.
Note icl_dphy_param_init() and vlv_dphy_param_init() are only moved,
otherwise they are completely unchanged.
Ville Syrjälä [Wed, 10 Apr 2019 17:08:35 +0000 (20:08 +0300)]
drm/i915/sdvo: Check that we have space for the infoframe
Before we go writing the infoframe let's make sure we have
the space for it. Not that it really matters since the write
loop would just terminate early in that case.
Ville Syrjälä [Tue, 9 Apr 2019 14:40:50 +0000 (17:40 +0300)]
drm/i915: Rename SDVO_AUDIO_ENABLE to HDMI_AUDIO_ENABLE
The "audio enable" bit on the SDVO/HDMI control register is only meant
for HDMI. Audio is never delivered over the SDVO bus. Rename the define
to reflect this fact.
Ville Syrjälä [Tue, 9 Apr 2019 14:40:49 +0000 (17:40 +0300)]
drm/i915/sdvo: Implement proper HDMI audio support for SDVO
Our SDVO audio support is pretty bogus. We can't push audio over the
SDVO bus, so trying to enable audio in the SDVO control register doesn't
do anything. In fact it looks like the SDVO encoder will always mix in
the audio coming over HDA, and there's no (at least documented) way to
disable that from our side. So HDMI audio does work currently on gen4
but only by luck really. On gen3 it got broken by the referenced commit.
And what has always been missing on every platform is the ELD.
To pass the ELD to the audio driver we need to write it to magic buffer
in the SDVO encoder hardware which then gets pulled out via HDA in the
other end. Ie. pretty much the same thing we had for native HDMI before
we started to just pass the ELD between the drivers. This sort of
explains why we even have that silly hardware buffer with native HDMI.
$ cat /proc/asound/card0/eld#1.0
-monitor_present 0
-eld_valid 0
+monitor_present 1
+eld_valid 1
+monitor_name LG TV
+connection_type HDMI
+...
This also fixes our state readout since we can now query the SDVO
encoder about the state of the "ELD valid" and "presence detect"
bits. As mentioned those don't actually control whether audio
gets sent over the HDMI cable, but it's the best we can do. And with
the state checker appeased we can re-enable HDMI audio for gen3.
Cc: stable@vger.kernel.org Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: zardam@gmail.com Tested-by: zardam@gmail.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108976 Fixes: de44e256b92c ("drm/i915/sdvo: Shut up state checker with hdmi cards on gen3") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190409144054.24561-3-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
Ville Syrjälä [Tue, 9 Apr 2019 14:40:48 +0000 (17:40 +0300)]
drm/i915/sdvo: Fix AVI infoframe TX rate readout
The AVI infoframe readout code currently issues a
SDVO_CMD_GET_HBUF_TXRATE before SDVO_CMD_SET_HBUF_INDEX, which is
not the correct order for these two operations. So far this wasn't
a problem since we left the index pointing at the AVI infoframe
buffer at the end of the modeset. However once we start to write
to other buffers (namely ELD) that is no longer going to be true.
Fix up the order so that we always read out the TX rate for the
correct buffer.
Ville Syrjälä [Mon, 3 Jun 2019 14:25:00 +0000 (17:25 +0300)]
drm/i915: Fix per-pixel alpha with CCS
We forgot to set .has_alpha=true for the A+CCS formats when the code
started to consult .has_alpha. This manifests as A+CCS being treated
as X+CCS which means no per-pixel alpha blending. Fix the format
list appropriately.
Cc: stable@vger.kernel.org Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Heinrich Fink <heinrich.fink@daqri.com> Reported-by: Heinrich Fink <heinrich.fink@daqri.com> Tested-by: Heinrich Fink <heinrich.fink@daqri.com> Fixes: b20815255693 ("drm/i915: Add plane alpha blending support, v2.") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190603142500.25680-1-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Ville Syrjälä [Tue, 4 Jun 2019 14:02:14 +0000 (17:02 +0300)]
drm/i915: Drop pointless WARN_ON
intel_dp_link_down() is static and it's only called from the pre-ddi
DP functions, so having a WARN_ON(HAS_DDI) in there is quite pointless.
Remove it.
Ville Syrjälä [Tue, 4 Jun 2019 14:02:13 +0000 (17:02 +0300)]
drm/i915: Move intel_dp->prepare_link_train assignment into ddi code
It's a bit silly to go through intel_dp.c to assign the
prepare_link_train vfunc for ddi platforms when we can just
assign it directly from intel_ddi.c.
Tvrtko Ursulin [Fri, 7 Jun 2019 10:15:35 +0000 (11:15 +0100)]
drm/i915: Make Gen6/7 RING_FAULT_REG access engine centric
Similar to earlier conversions, eliminate the implicit dev_priv by
introducing some helpers which take the engine parameter (since the
register itself is per engine).
projects / kernel.git / log