Hi Chris,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip drm-exynos/exynos-drm-next
linus/master next-20200203]
[cannot apply to tegra-drm/drm/tegra/for-next drm/drm-next v5.5]
[if your patch is
Hi Chris,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip drm-exynos/exynos-drm-next
linus/master next-20200203]
[cannot apply to tegra-drm/drm/tegra/for-next drm/drm-next v5.5]
[if your patch is
On Wed, 2020-01-29 at 13:42 +0200, Ville Syrjälä wrote:
> On Tue, Jan 28, 2020 at 03:52:41PM -0800, José Roberto de Souza
> wrote:
> > From: Radhakrishna Sripada
> >
> > dgfx platforms do not support CPU fence and FBC host tracking so
> > lets avoid write to removed registers.
> >
> > Cc: Rodrig
On Wed, 2020-01-29 at 13:58 +0200, Ville Syrjälä wrote:
> On Wed, Jan 29, 2020 at 01:44:49PM +0200, Ville Syrjälä wrote:
> > On Tue, Jan 28, 2020 at 03:52:40PM -0800, José Roberto de Souza
> > wrote:
> > > dGFX have local memory so it do not have aperture and do not
> > > support
> > > CPU fences b
On gen11 we only needed to program MBus credits into MBUS_ABOX_CTL
during display initialization, but on gen12 we're now supposed to
program the same values into MBUS_ABOX1_CTL and MBUS_ABOX2_CTL as well.
v2:
- Program registers with rmw to preserve contents of unrelated bits.
- Switch to the ne
It wasn't terribly clear from the bspec's wording, but after discussion
with the hardware folks, it turns out that we need to preserve the
pre-existing contents of the MBUS ABOX control register when
initializing a few specific bits.
Bspec: 49213
Bspec: 50096
Fixes: 4cb4585e5a7f ("drm/i915/icl: in
Since the pipe->transcoder mapping is not expected to change unless
there is either eDP or DSI connectors present, check the VBT to confirm
their presence in addition to checking TRANS_DDI_FUNC_CTL(transcoder).
This additional check is needed on platforms like Elkhart Lake because
we cannot just re
To be able to differentiate the before and after of our commitment to
GuC submission, which will be used in follow-up patches to early set-up
the submission structures.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 12
dr
In a follow up patch we will rely on the fact that the status always
moves away from "SELECTED" after the fetch is attempted to decide what
to do with the GuC.
v2: Split this change to its own patch (Michal)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: John Harrison
Cc: Matth
We are quite trigger happy in cleaning up the firmware blobs, as we do
so from several error/fini paths in GuC/HuC/uC code. We do have the
__uc_cleanup_firmwares cleanup function, which unwinds
__uc_fetch_firmwares and is already called both from the error path of
gem_init and from gem_driver_relea
We want to map uC-level checks to GuC/HuC-level ones. The mapping from
the uC state to the GuC/HuC one follows the same pattern for all the
functions:
uc_xxx_guc() -> guc_is_yyy()
So we can easily use a macro to autogenerate the functions via macros by
passing in the 2 mapped states.
v2: Split
Now that we can differentiate wants vs uses GuC/HuC, intel_uc_init is
restricted to running only if we have successfully fetched the required
blob(s) and are committed to using the microcontroller(s).
The only remaining thing that can go wrong in uc_init is the allocation
of GuC/HuC related objects
use intel_uc_uses_guc() directly instead, to be consistent in the way we
check what we want to do with the GuC.
v2: split guc_log_info changes to their own patch (Michal)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: John Harrison
Cc: Matthew Brost
---
drivers/gpu/drm/i915/g
To be able to setup GuC submission functions during engine init we need
to commit to using GuC as soon as possible.
Currently, the only thing that can stop us from using the
microcontrollers once we've fetched the blobs is a fundamental
error (e.g. OOM); given that if we hit such an error we can't
The log struct is the only thing the function needs (apart from
the seq_file), so we can pass just that instead of the whole dev_priv.
v2: Split this change to its own patch (Michal)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: John Harrison
Cc: Matthew Brost
---
drivers/gp
use intel_uc_uses_guc_submission() directly instead, to be consistent in
the way we check what we want to do with the GuC.
v2: do not go through ctx->vm->gt, use i915->gt instead
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: John Harrison
Cc: Matthew Brost
Reviewed-by: Michal
Main difference from v1 is that I've dropped the patch to start the
re-org of guc submission setup (I plan to re-send that as part of [1],
after Chris' intel_lrc.c split patches land) and added a patch to be
less aggressive in cleaning up the firmware objects.
Some chunks have also be split to the
To enable GuC and HuC loading on all gen9+ CI machines.
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/i915_params.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index cb16410c2ada..7f
It adds code to read the DP SDPs from the video DIP and unpack them into
the crtc state.
It adds routines that read out DP VSC SDP and DP HDR Metadata Infoframe SDP
In order to unpack DP VSC SDP, it adds intel_dp_vsc_sdp_unpack() function.
It follows DP 1.4a spec. [Table 2-116: VSC SDP Header Byte
Dump out the HDMI Dynamic Range and Mastering (DRM) infoframe in the
normal crtc state dump.
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/display/intel_display.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915
Dump out the DP VSC SDP in the normal crtc state dump
v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp
Use drm core's DP VSC SDP logging function
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/display/intel_display.c | 13 +
1 file changed, 13 insert
Added state readout for DP VSC SDP and enabled state validation
for DP VSC SDP.
v2: Minor style fix
v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
drivers/gpu/drm/i915/display/intel_dis
It adds routines that write DP VSC SDP and DP HDR Metadata Infoframe SDP.
In order to pack DP VSC SDP, it adds intel_dp_vsc_sdp_pack() function.
It follows DP 1.4a spec. [Table 2-116: VSC SDP Header Bytes] and
[Table 2-117: VSC SDP Payload for DB16 through DB18]
In order to pack DP HDR Metadata In
Call intel_dp_set_infoframes(false) function on intel_ddi_post_disable_dp()
to make sure not to send VSC SDP and HDR Metadata Infoframe SDP.
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/display/intel_ddi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/disp
Dump out the DP HDR Metadata Infoframe SDP in the normal crtc state dump.
HDMI Dynamic Range and Mastering (DRM) infoframe and DP HDR Metadata
Infoframe SDP use the same member variable in infoframes of crtc state.
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/display/intel_display.c
It stores computed dp hdr metadata infoframe sdp to infoframes.drm of
crtc state. It referenced intel_hdmi_compute_drm_infoframe().
While computing, we'll also fill out the inforames.enable bitmask
appropriately.
v2: Wrap a long line.
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/dis
When receiving video it is very useful to be able to log DP VSC SDP.
This greatly simplifies debugging.
v2: Minor style fix
v3: Move logging functions to drm core [Jani N]
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/drm_dp_helper.c | 174
include/drm/drm_
It adds an unpack only function for DRM infoframe for dynamic range and
mastering infoframe readout.
It unpacks the information data block contained in the binary buffer into
a structured frame of the HDMI Dynamic Range and Mastering (DRM)
information frame.
In contrast to hdmi_drm_infoframe_unpac
In order to use computed config for DP SDPs (DP VSC SDP and DP HDR Metadata
Infoframe SDP), it replaces intel_dp_vsc_enable() function and
intel_dp_hdr_metadata_enable() function to intel_dp_set_infoframes()
function.
Before applying it, routines of program SDP always calculated configs when
they
Call intel_dp_set_infoframes() function on pipe updates to make sure
that we send VSC SDP and HDR Metadata Infoframe SDP (when applicable)
on fastsets.
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/
Added state readout for DP HDR Metadata Infoframe SDP.
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/display/intel_ddi.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 374ab6a3757c..
In order to use a common VSC SDP Colorimetry calculating code on PSR,
it uses a new psr vsc sdp compute routine.
Because PSR routine has its own scenario and timings of writing a VSC SDP,
the current PSR routine needs to have its own drm_dp_vsc_sdp structure
member variable on struct i915_psr.
In
In order to use a common VSC SDP Colorimetry calculating code on PSR,
it adds a compute routine for PSR VSC SDP.
As PSR routine can not use infoframes.vsc of crtc state, it also adds new
writing of DP SDPs (Secondary Data Packet) for PSR.
PSR routine has its own scenario and timings of writing a VS
It adds new enumeration definitions for VSC SDP Payload for Pixel
Encoding/Colorimetry Format.
And it adds a new drm data structure for DP VSC SDP.
enum dp_colorspace and enum dp_colorimetry correspond "Pixel Encoding and
Colorimetry Formats". enum dp_dynamic_range corresponds "Dynamic Range".
And
In order to support state readout for DP VSC SDP, we need to have a
structure which holds DP VSC SDP payload data such as
"union hdmi_infoframe drm" which is used for DRM infoframe.
It adds a struct drm_dp_vsc_sdp vsc to intel_crtc_state.infoframes.
And it stores computed dp vsc sdp to infoframes.
In order to readout DP SDPs (Secondary Data Packet: DP HDR Metadata
Infoframe SDP, DP VSC SDP), it refactors handling DP SDPs codes.
It adds new compute routines for DP HDR Metadata Infoframe SDP
and DP VSC SDP.
And new writing routines of DP SDPs (Secondary Data Packet) that uses
computed configs
On Sat, 2020-02-01 at 14:43 +0200, Jani Nikula wrote:
> On Fri, 31 Jan 2020, Gwan-gyeong Mun
> wrote:
> > When receiving video it is very useful to be able to log DP VSC
> > SDP.
> > This greatly simplifies debugging.
>
> Seems like a lot of the functions should really be in drm core.
>
> BR,
>
TGL is suffering of timeouts and fifo underruns when disabling
transcoder in MST mode, this is fixed by set TRANS_DDI_MODE_SELECT to
0(HDMI mode) when clearing DDI select.
Although BSpec disable sequence don't require this step, it is a
harmless change and it is also done by Windows driver.
Anyhow
On 03/02/20 13:45, Chris Wilson wrote:
The gtt/readonly tests are nothing to do with execution and engines;
they are strictly checking the copy-from-user of the ioctl arguments.
Drop the silly per-engine tests.
Signed-off-by: Chris Wilson
Cc: Antonio Argenziano
LGTM.
Reviewed-by: Antonio
On 03/02/20 14:18, Chris Wilson wrote:
Quoting Antonio Argenziano (2020-02-03 22:15:26)
On 03/02/20 13:45, Chris Wilson wrote:
@@ -121,30 +43,29 @@ igt_main
igt_fixture {
fd = drm_open_driver(DRIVER_INTEL);
- igt_require_gem(fd);
-
+ /* ig
Quoting Antonio Argenziano (2020-02-03 22:15:26)
>
>
> On 03/02/20 13:45, Chris Wilson wrote:
> > @@ -121,30 +43,29 @@ igt_main
> >
> > igt_fixture {
> > fd = drm_open_driver(DRIVER_INTEL);
> > - igt_require_gem(fd);
> > -
> > + /* igt_require_gem(fd
On 03/02/20 13:45, Chris Wilson wrote:
The gtt/readonly tests are nothing to do with execution and engines;
they are strictly checking the copy-from-user of the ioctl arguments.
Drop the silly per-engine tests.
Signed-off-by: Chris Wilson
Cc: Antonio Argenziano
---
tests/i915/gem_exec_bas
On Sun, Feb 2, 2020 at 12:16 PM Chris Wilson wrote:
>
> The drm_pci_alloc routines have been a thin wrapper around the core dma
> coherent routines. Remove the crutch of a wrapper and the exported
> symbols, marking it for only internal legacy use.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Al
On Sun, Feb 2, 2020 at 12:16 PM Chris Wilson wrote:
>
> drm_pci_alloc is a thin wrapper over dma_coherent_alloc. Ditch the
> wrapper and just use the dma routines directly.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/r128/ati_pcigart.c | 32 +++---
> drivers/g
On Sun, Feb 2, 2020 at 12:16 PM Chris Wilson wrote:
>
> Internally for "consistent" maps, we create a temporary struct
> drm_dma_handle in order to user our own dma_alloc_coherent wrapper then
> destroy the temporary wrap. Simplify our logic by removing the temporary
> wrapper!
>
> Signed-off-by:
On Sun, Feb 2, 2020 at 12:16 PM Chris Wilson wrote:
>
> drm_pci_alloc/drm_pci_free are very thin wrappers around the core dma
> facilities, and we have no special reason within the drm layer to behave
> differently. In particular, since
>
> commit de09d31dd38a50fdce106c15abd68432eebbd014
> Author:
The gtt/readonly tests are nothing to do with execution and engines;
they are strictly checking the copy-from-user of the ioctl arguments.
Drop the silly per-engine tests.
Signed-off-by: Chris Wilson
Cc: Antonio Argenziano
---
tests/i915/gem_exec_basic.c | 109 +
Hi Jerry,
First of all, thanks for your patch. You can see some comments inline,
just simple things.
On 01/31, Jerry (Fangzhi) Zuo wrote:
> Unlike DP 1.2 edid corruption test, DP 1.4 requires to calculate
> real CRC value of the last edid data block, and write it back.
> Current edid CRC calculat
On Thu, Jan 23, 2020 at 9:00 AM Thomas Zimmermann wrote:
>
> VBLANK callbacks in struct drm_driver are deprecated in favor of
> their equivalents in struct drm_crtc_funcs. Convert amdgpu over.
>
> v2:
> * don't wrap existing functions; change signature instead
>
> Signed-off-by: Thomas Zim
On Thu, Jan 23, 2020 at 9:00 AM Thomas Zimmermann wrote:
>
> The callback struct drm_driver.get_scanout_position() is deprecated in
> favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert
> amdgpu over.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Alex Deucher
> ---
> dri
On Thu, Jan 23, 2020 at 9:00 AM Thomas Zimmermann wrote:
>
> The callback struct drm_driver.get_scanout_position() is deprecated in
> favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert
> radeon over.
>
> v4:
> * 80-character line fixes
>
> Signed-off-by: Thomas Zimmerman
> -Original Message-
> From: Intel-gfx On Behalf Of Alex
> Deucher
> Sent: Tuesday, January 28, 2020 4:09 AM
> To: Ville Syrjala
> Cc: Intel Graphics Development ; Maling list
> - DRI
> developers
> Subject: Re: [Intel-gfx] [PATCH 8/8] drm/edid: Dump bogus 18 byte descriptors
>
> On
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjälä
> Sent: Tuesday, January 28, 2020 5:19 PM
> To: Alex Deucher
> Cc: Intel Graphics Development ; Maling list
> - DRI
> developers
> Subject: Re: [Intel-gfx] [PATCH 7/8] drm/edid: Constify lots of things
>
> On Mon,
The current rc6 threshold is larger than the evaluation interval on
Ivybridge; it never enters rc6. Remove the special casing so it behaves
like the other gen6/gen7, and we see rc6 residencies before we manually
park the system.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1114
Testcase
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Saturday, January 25, 2020 1:32 AM
> To: dri-de...@lists.freedesktop.org
> Cc: intel-gfx@lists.freedesktop.org; Andres Rodriguez
> Subject: [Intel-gfx] [PATCH 6/8] drm/edid: Add a FIXME about DispID CEA data
>
> -Original Message-
> From: dri-devel On Behalf Of Ville
> Syrjälä
> Sent: Tuesday, January 28, 2020 5:14 PM
> To: Alex Deucher
> Cc: Intel Graphics Development ; Andres
> Rodriguez
> ; Maling list - DRI developers de...@lists.freedesktop.org>
> Subject: Re: [PATCH 5/8] drm/edid: D
> -Original Message-
> From: Intel-gfx On Behalf Of Alex
> Deucher
> Sent: Tuesday, January 28, 2020 3:58 AM
> To: Ville Syrjala
> Cc: Intel Graphics Development ; Maling list
> - DRI
> developers
> Subject: Re: [Intel-gfx] [PATCH 4/8] drm/i915: Clear out spurious whitespace
>
> Titl
> -Original Message-
> From: Intel-gfx On Behalf Of Alex
> Deucher
> Sent: Tuesday, January 28, 2020 4:06 AM
> To: Ville Syrjala
> Cc: Allen Chen ; Intel Graphics Development g...@lists.freedesktop.org>; Maling list - DRI developers de...@lists.freedesktop.org>
> Subject: Re: [Intel-g
> -Original Message-
> From: Intel-gfx On Behalf Of Alex
> Deucher
> Sent: Tuesday, January 28, 2020 4:06 AM
> To: Ville Syrjala
> Cc: Allen Chen ; Intel Graphics Development g...@lists.freedesktop.org>; Maling list - DRI developers de...@lists.freedesktop.org>
> Subject: Re: [Intel-g
> -Original Message-
> From: dri-devel On Behalf Of Alex
> Deucher
> Sent: Tuesday, January 28, 2020 4:04 AM
> To: Ville Syrjala
> Cc: Allen Chen ; Intel Graphics Development g...@lists.freedesktop.org>; Maling list - DRI developers de...@lists.freedesktop.org>
> Subject: Re: [PATCH 1
Shrink the strncpy bounds to ensure the NUL-terminator can fit within
the embedded array:
In file included from drivers/gpu/drm/i915/gem/i915_gem_context.c:2475:
drivers/gpu/drm/i915/gem/selftests/mock_context.c: In function ‘mock_context’:
drivers/gpu/drm/i915/gem/selftests/mock_context.c:40:3: e
Exercise the seqno wrap paths on the kernel context to provide a small
amount of sanity checking and ensure that they are visible to lockdep.
Signed-off-by: Chris Wilson
Cc: Maarten Lankhorst
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/selftest_timeline.c | 187
Quoting Matthew Auld (2020-02-03 17:32:29)
> On 03/02/2020 09:41, Chris Wilson wrote:
> > + for (i = 0; i < ARRAY_SIZE(rq); i++) {
> > + rq[i] = i915_request_create(ce);
> > + if (IS_ERR(rq[i])) {
> > + err = PTR_ERR(rq
On Thu, Jan 30, 2020 at 11:31:07AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Enable FtrPerCtxtPreemptionGranularityControl bit and whitelist
> GEN8_CS_CHICKEN1 so WaEnablePreemptionGranularityControlByUMD is
> implemented.
I may be misremembering, but wasn't this a "fake" workaroun
On 03/02/2020 09:41, Chris Wilson wrote:
Exercise the seqno wrap paths on the kernel context to provide a small
amount of sanity checking and ensure that they are visible to lockdep.
Signed-off-by: Chris Wilson
Cc: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/selftest_timeline.c | 177 +
Quoting Mika Kuoppala (2020-02-03 16:33:12)
> We have switched from tail manipulation to forced context restore
> to implement WaIdleLiteRestore. Remove the useless defines and comments.
We still use the wa_tail as the first pass to avoid having to do
WaIdleLiteRestore. And we do need to reset the
We have switched from tail manipulation to forced context restore
to implement WaIdleLiteRestore. Remove the useless defines and comments.
References: f26a9e959a7b ("drm/i915/gt: Detect if we miss WaIdleLiteRestore")
Cc: Tvrtko Ursulin
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/
== Series Details ==
Series: Add support for mipi dsi cmd mode (rev6)
URL : https://patchwork.freedesktop.org/series/69290/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
___
Intel-gfx mailing list
Intel-gfx@lists.f
== Series Details ==
Series: Add support for mipi dsi cmd mode (rev6)
URL : https://patchwork.freedesktop.org/series/69290/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ea615cb735b1 drm/i915/dsi: Configure transcoder operation for command mode.
385e5a8e53ff drm/i915/dsi: Add v
== Series Details ==
Series: series starting with [1/2] drm: Add a detailed DP HDMI branch info on
debugfs
URL : https://patchwork.freedesktop.org/series/72914/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7859 -> Patchwork_16392
=
== Series Details ==
Series: drm/i915/dsb: Enable lmem for dsb
URL : https://patchwork.freedesktop.org/series/72818/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7850_full -> Patchwork_16355_full
Summary
---
**SUCCE
On Fri, 31 Jan 2020 at 10:46, Chris Wilson wrote:
>
> Lift the routines to emit a request to update the SSEU on the
> intel_context out of i915_gem_context.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@
== Series Details ==
Series: drm/i915/guc: Stop using mutex while sending CTB messages (rev4)
URL : https://patchwork.freedesktop.org/series/72827/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7859 -> Patchwork_16391
Summa
From: Ville Syrjälä
Stash the downstream facing port max bpc away during
intel_dp_set_edid(). We'll soon need the EDID in there so
we can't figure this out so easily during .compute_config() anymore.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_types.h| 5 +
dri
From: Ville Syrjälä
Account for the TMDS clock limits declared by the DFP/DP++ dongle
when determining what color depth we're going to use.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 67 ---
drivers/gpu/drm/i915/display/intel_hdmi.c | 50 ++
From: Ville Syrjälä
w/a #1139 is only needed for pre-production GLK. Nuke it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.
From: Ville Syrjälä
DP 1.3 adds some extra control knobs for DP->HDMI protocol conversion.
Let's use that to configure the "HDMI mode" (ie. infoframes vs. not)
based on the capabilities of the sink.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
drivers/gpu/d
From: Ville Syrjälä
Use the new helpers to extract the TMDS clock limits from
the downstream facing port and check them in .mode_valid().
TODO: we should check these in .compute_config() too to eg.
determine if we can do deep color on the HDMI side or not
Signed-off-by: Ville Syrjälä
---
.../
From: Ville Syrjälä
Decouple the DP dual mode adaptor stuff from the HDMI code so that
we can try to use it for DP branch downstream facing HDMI ports as
well.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 6 +-
.../drm/i915/display/intel_display_types.h
From: Ville Syrjälä
Use drm_dp_downstream_mode() to get a suitable mode for downstream
facing ports which don't have an EDID.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu
From: Ville Syrjälä
To save a bit of power let's try to power down the TMDS buffers on
DP++ dongles hooked to downstream facing DP++ ports.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 6 ++
drivers/gpu/drm/i915/display/intel_dp.c | 25 +
From: Ville Syrjälä
Add helpers to determine whether the DFP supports
YCbCr 4:2:0 passthrough or YCbCr 4:4:4->4:2:0 conversion.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_dp_helper.c | 44 +
include/drm/drm_dp_helper.h | 8 ++
2 files changed,
From: Ville Syrjälä
In order to get accurate TMDS clocks limits for the DP++ ports we
can try to probe the DP dual mode adapter registers. Unfortunately
I've not yet seen a DP->DP++ branch device that would actually
forward these i2c accesses to the dual mode dongle downstream.
But we don't lose
From: Ville Syrjälä
The downstream facing port caps in the DPCD can give us a hint
as to what kind of display mode the sink can use if it doesn't
have an EDID. Use that information to pick a suitable mode.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_dp_helper.c | 54 ++
From: Ville Syrjälä
Pull the "do we want to enable audio?" computation into a small helper
to make intel_hdmi_compute_config() less messy. Will make it easier to
add more checks for this later (eg. we should actually be checking
at the hblank is long enough for audio transmission).
Signed-off-by
From: Ville Syrjälä
For platforms that can't do native 4:2:0 outout we may still be
able to do it by getting the DP->HDMI protocol converter to
perform the 4:4:4->4:2:0 downsamling for us. In this case we
have to configure our hardware to output YCbCr 4:4:4, which we've
already hooked up so all w
From: Ville Syrjälä
Deal with more cases in drm_dp_downstream_max_bpc():
- DPCD 1.0 -> assume 8bpc for non-DP
- DPCD 1.1+ DP (or DP++ with DP sink) -> allow anything
- DPCD 1.1+ TMDS -> check the caps, assume 8bpc if the value is crap
- anything else -> assume 8bpc
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä
Move the downstream facing port dotclock check into a new function
(intel_dp_mode_valid_downstream()) so that we have a nice future
place where we can collect other related checks.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_types.h| 1 +
driver
From: Ville Syrjälä
Add helpers to get the TMDS clock limits for HDMI/DVI downstream
facing ports.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_dp_helper.c | 116
include/drm/drm_dp_helper.h | 6 ++
2 files changed, 122 insertions(+)
diff --git a
From: Ville Syrjälä
It helps when the logs have a dump of the DFP capabilities.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
ind
From: Ville Syrjälä
We want to differentiate between the DFP dotclock and TMDS clock
limits. Let's convert the current thing to just give us the
dotclock limit.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_dp_helper.c | 42 ++---
drivers/gpu/drm/i915/display
From: Ville Syrjälä
Non-HDMI sinks shouldn't be sent infoframes. Check for that when
using LSPCON.
FIXME: How do we turn off infoframes once enabled? Do we even
have to?
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 10 --
drivers/gpu/drm
From: Ville Syrjälä
DP 1.3 and 1.4 introduced some new registers for DP->HDMI protocol
converters. Define those.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_dp_helper.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.
From: Ville Syrjälä
Add a few helpers to let us better identify which kind of DFP
we're dealing with.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_dp_helper.c | 60 +
include/drm/drm_dp_helper.h | 5 +++
2 files changed, 65 insertions(+)
diff --git
From: Ville Syrjälä
Detect GLK pre-production steppings. Not 100% of A2 being pre-prod
since the spec is a bit of a mess but feels more or less correct.
Suggested-by: Chris Wilson
Acked-by: Chris Wilson
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i
From: Ville Syrjälä
TGL+ supposedly do not need Wa_1405510057 so limit it to
gen11 only.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/d
From: Ville Syrjälä
Our definitions for the DPCD DFP capabilities are lacking.
Add the missing bits.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_dp_helper.h | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
From: Ville Syrjälä
To make it easier to figure out what caused a particular debug
message let's print out aux->name.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_dp_helper.c | 44 +++--
1 file changed, 25 insertions(+), 19 deletions(-)
diff --git a/drivers
From: Ville Syrjälä
WaDDIIOTimeout is only for A1 (pre-prod) glk steppings. Nuke it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a2d2407af
From: Ville Syrjälä
Attempt to deal with DP downstream facing ports (DFP) more
thoroughly. This involves reading more of the port caps
and dealing with various clock/bpc limitations.
Also we try to hook up the DP dual mode dongles into the
mix (unfortunately I've not yet seen a DP++ DFP that wou
1 - 100 of 176 matches
Mail list logo
