On Mon, 28 Sep 2020, Matt Roper wrote:
> On Mon, Sep 28, 2020 at 04:07:39PM -0700, Lucas De Marchi wrote:
>> On Mon, Sep 28, 2020 at 08:15:29PM +0300, Jani Nikula wrote:
>> > On Mon, 28 Sep 2020, "Surendrakumar Upadhyay, TejaskumarX"
>> > wrote:
>> > > This is a good example of a potential trap
== Series Details ==
Series: drm/i915: Avoid mixing integer types during batch copies
URL : https://patchwork.freedesktop.org/series/82165/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9067_full -> Patchwork_18584_full
Sum
== Series Details ==
Series: series starting with [CI,1/3] drm/i915: Cancel outstanding work after
disabling heartbeats on an engine
URL : https://patchwork.freedesktop.org/series/82167/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9067_full -> Patchwork_18585_full
=
Quoting Lucas De Marchi (2020-09-29 00:56:54)
> On Tue, Mar 24, 2020 at 1:45 PM Chris Wilson wrote:
> >
> > Measure and compare the energy consumed, as reported by the rapl MSR,
> > by the GPU while in RC0 and RC6 states. Throw an error if RC6 does not
> > at least halve the energy consumption of
Bypass the IGD initialization for Intel's dgfx devices with own expansion
ROM and the host/LPC bridge config space are no longer accessed.
v2: simply test if discrete or integrated gfx device
with root bus. (Alex Williamson)
Cc: Zhenyu Wang
Cc: Xiong Zhang
Cc: Hang Yuan
Cc: Stuart Summers
(+ intel-gfx for being i915 related)
(+ Chris who has looked into the issue)
Hi,
Thanks for reporting!
Could you open a bug report according to following instructions:
https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs
A full dmesg of a bad boot and git bisect logs will be
On Wed 16-09-20 23:43:02, Daniel Vetter wrote:
> I can
> then figure out whether it's better to risk not spotting issues with
> call_rcu vs slapping a memalloc_noio_save/restore around all these
> critical section which force-degrades any allocation to GFP_ATOMIC at
did you mean memalloc_noreclaim
Quoting Joonas Lahtinen (2020-09-29 09:18:34)
> (+ intel-gfx for being i915 related)
> (+ Chris who has looked into the issue)
>
> Hi,
>
> Thanks for reporting!
Fixed in commit a4d63c3732f1a0c91abcf5b7f32b4ef7dcd82025
Author: Jason A. Donenfeld
Date: Mon Sep 28 12:35:07 2020 +0200
mm: do
If we manage to hit the intel_gt_set_wedged_on_fini() while active, i.e.
module unload during a stress test, we may cancel the requests but not
clean up. This leads to a very slow module unload as we wait for
something or other to trigger the retirement flushing, or timeout and
unload with a bunch
After marking the requests on an engine as cancelled upon wedging, send
any signals for their completions.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 1 +
drivers/gpu/drm/i915/gt/intel_ring_submission.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/
Flush all the pending requests from the mock engine when they are
cancelled.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/mock_engine.c | 29 +++
1 file changed, 25 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/mock_engine.c
b/drivers/gpu
Chris Wilson writes:
> Be consistent and use unsigned long throughout the chunk copies to
> avoid the inherent clumsiness of mixing integer types of different
> widths and signs. Failing to take acount of a wider unsigned type when
> using min_t can lead to treating it as a negative, only for it
On Tue, Sep 29, 2020 at 10:19:38AM +0200, Michal Hocko wrote:
> On Wed 16-09-20 23:43:02, Daniel Vetter wrote:
> > I can
> > then figure out whether it's better to risk not spotting issues with
> > call_rcu vs slapping a memalloc_noio_save/restore around all these
> > critical section which force-d
On 2020.09.30 00:10:38 +0800, Fred Gao wrote:
> Bypass the IGD initialization for Intel's dgfx devices with own expansion
> ROM and the host/LPC bridge config space are no longer accessed.
>
> v2: simply test if discrete or integrated gfx device
> with root bus. (Alex Williamson)
>
Patch tit
Simply check that we support parsing of batches as large as the uAPI
allows.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
Try a few intermediate object sizes since CI machines do not have enough
memory to reach the upper bounds of the uAPI.
---
tests/i915/gen9_exec_parse.c | 47 +++
On Mon, Sep 28, 2020 at 01:22:13PM +0200, Christian König wrote:
> Am 28.09.20 um 09:37 schrieb Thomas Zimmermann:
> > Hi
> >
> > Am 28.09.20 um 08:50 schrieb Christian König:
> > > Am 27.09.20 um 21:16 schrieb Sam Ravnborg:
> > > > Hi Thomas.
> > > >
> > > > > > struct simap {
> > > > > >
On 9/28/2020 5:48 PM, Ville Syrjälä wrote:
On Mon, Sep 21, 2020 at 04:32:02PM +0530, Karthik B S wrote:
Without async flip support in the kernel, fullscreen apps where game
resolution is equal to the screen resolution, must perform an extra blit
per frame prior to flipping.
Asynchronous page
Am 29.09.20 um 11:14 schrieb Daniel Vetter:
On Mon, Sep 28, 2020 at 01:22:13PM +0200, Christian König wrote:
Am 28.09.20 um 09:37 schrieb Thomas Zimmermann:
Hi
Am 28.09.20 um 08:50 schrieb Christian König:
Am 27.09.20 um 21:16 schrieb Sam Ravnborg:
Hi Thomas.
struct simap {
union
Am 29.09.20 um 13:09 schrieb Christian König:
> Am 29.09.20 um 11:14 schrieb Daniel Vetter:
>> On Mon, Sep 28, 2020 at 01:22:13PM +0200, Christian König wrote:
>>> Am 28.09.20 um 09:37 schrieb Thomas Zimmermann:
Hi
Am 28.09.20 um 08:50 schrieb Christian König:
> Am 27.09.20 um
Currently we do a final scrub of the HW state upon release. However,
when rebinding the device, this is too late as the device may either
have been partially rebound or the device is no longer accessible. If
the device has been removed before release, the reset goes astray
leaving the device in an
JSL has update in vswing table for eDP
BSpec: 21257
Changes since V1 :
- IS_ELKHARTLAKE and IS_JASPERLAKE is replaced with
HAS_PCH_MCC(EHL) and HAS_PCH_JSP(JSL) respectively
- Reverted EHL/JSL PCI ids split change
Signed-off-by: Tejas Upadhyay
---
drivers/gpu/drm/i91
Quoting Christoph Hellwig (2020-09-28 15:37:41)
> On Mon, Sep 28, 2020 at 01:13:38PM +0300, Joonas Lahtinen wrote:
> > I think we have a gap that after splitting the drm-intel-next pull requests
> > into
> > two the drm-intel/for-linux-next branch is now missing material from
> > drm-intel/drm-int
On Mon, Sep 28, 2020 at 08:20:59PM +0300, Jani Nikula wrote:
> On Mon, 28 Sep 2020, Ville Syrjälä wrote:
> > On Mon, Sep 28, 2020 at 07:15:43AM -0700, James Ausmus wrote:
> >> On Mon, Sep 28, 2020 at 04:43:11PM +0300, Jani Nikula wrote:
> >> > On Mon, 28 Sep 2020, Tejas Upadhyay
> >> > wrote:
>
On Tue, Sep 29, 2020 at 05:41:27PM +0530, Tejas Upadhyay wrote:
> JSL has update in vswing table for eDP
>
> BSpec: 21257
>
> Changes since V1 :
> - IS_ELKHARTLAKE and IS_JASPERLAKE is replaced with
> HAS_PCH_MCC(EHL) and HAS_PCH_JSP(JSL) respectively
What do vswing values have
From: Ville Syrjälä
CNL+ can report DIMM sizes in .5 GB units. In order to not trauncate
away the .5 GB let's switch to storing the DIMM size in Gb units.
Cc: Swati Sharma
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dram.c | 23 ---
1 file changed, 12 inser
-Original Message-
From: Ville Syrjälä
Sent: 29 September 2020 18:23
To: Surendrakumar Upadhyay, TejaskumarX
Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Ausmus,
James ; Roper, Matthew D ;
Souza, Jose ; De Marchi, Lucas
; Pandey, Hariom
Subject: Re: [PATC
Chris Wilson writes:
> Simply check that we support parsing of batches as large as the uAPI
> allows.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
> ---
> Try a few intermediate object sizes since CI machines do not have enough
> memory to reach the upper bo
On 10.09.20 20:18, Deucher, Alexander wrote:
> [AMD Public Use]
>
>
>
>> -Original Message-
>> From: amd-gfx On Behalf Of
>> Daniel Vetter
>> Sent: Monday, September 7, 2020 3:15 AM
>> To: Jan Kiszka ; amd-gfx list > g...@lists.freedesktop.org>; Wentland, Harry ;
>> Kazlauskas, Nicholas
>
On Tue 29-09-20 11:00:03, Daniel Vetter wrote:
> On Tue, Sep 29, 2020 at 10:19:38AM +0200, Michal Hocko wrote:
> > On Wed 16-09-20 23:43:02, Daniel Vetter wrote:
> > > I can
> > > then figure out whether it's better to risk not spotting issues with
> > > call_rcu vs slapping a memalloc_noio_save/re
== Series Details ==
Series: series starting with [1/3] drm/i915/gt: Signal cancelled requests
URL : https://patchwork.freedesktop.org/series/82189/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: series starting with [1/3] drm/i915/gt: Signal cancelled requests
URL : https://patchwork.freedesktop.org/series/82189/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9073 -> Patchwork_18588
Summ
Hi,
On Fri, 25 Sep 2020 at 09:46, Daniel Vetter wrote:
> Hopefully we'll have the drm crash recorder RSN, but meanwhile
> compositors would like to know a bit better why they get an EBUSY.
Thanks a lot, this is super helpful! Both patches are:
Reviewed-by: Daniel Stone
Cheers,
Daniel
_
On Tue, Sep 15, 2020 at 02:30:38AM +0530, Uma Shankar wrote:
> Gen9 hardware supports HDMI2.0 through LSPCON chips.
> Extending HDR support for MCA LSPCON based GEN9 devices.
>
> SOC will drive LSPCON as DP and send HDR metadata as standard
> DP SDP packets. LSPCON will be set to operate in PCON m
On Tue, Sep 15, 2020 at 02:30:39AM +0530, Uma Shankar wrote:
> Attach HDR property for Gen9 devices with MCA LSPCON
> chips.
>
> v2: Cleaned HDR property attachment logic based on capability
> as per Jani Nikula's suggestion.
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/display/i
On Tue, Sep 15, 2020 at 02:30:40AM +0530, Uma Shankar wrote:
> Enable Colorspace as BT2020 if driving HDR content.Sending Colorimetry
> data for HDR using AVI infoframe. LSPCON firmware expects this and though
> SOC drives DP, for HDMI panel AVI infoframe is sent to the LSPCON device
> which transf
On Tue, Sep 15, 2020 at 02:30:41AM +0530, Uma Shankar wrote:
> Enable HDR for LSPCON based on Parade along with MCA.
>
> Signed-off-by: Uma Shankar
> Signed-off-by: Vipin Anand
> ---
> drivers/gpu/drm/i915/display/intel_lspcon.c | 19 ---
> 1 file changed, 8 insertions(+), 11 de
On Tue, Sep 15, 2020 at 02:30:42AM +0530, Uma Shankar wrote:
> Implemented Infoframes enabled readback for LSPCON devices.
> This will help align the implementation with state readback
> infrastructure.
>
> v2: Added proper bitmask of enabled infoframes as per Ville's
> recommendation.
>
> Signed
On Tue, Sep 15, 2020 at 02:30:43AM +0530, Uma Shankar wrote:
> Implement Read back of HDR metadata infoframes i.e Dynamic Range
> and Mastering Infoframe for LSPCON devices.
>
> v2: Added proper bitmask of enabled infoframes as per Ville's
> recommendation.
>
> Signed-off-by: Uma Shankar
> ---
>
== Series Details ==
Series: drm/i915/gt: Scrub HW state on remove
URL : https://patchwork.freedesktop.org/series/82201/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
dcd9a08264c1 drm/i915/gt: Scrub HW state on remove
-:15: WARNING:TYPO_SPELLING: 'reseting' may be misspelled -
== Series Details ==
Series: drm/i915/gt: Scrub HW state on remove
URL : https://patchwork.freedesktop.org/series/82201/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9074 -> Patchwork_18589
Summary
---
**SUCCESS**
== Series Details ==
Series: drm/i915/edp/jsl: Update vswing table for HBR and HBR2
URL : https://patchwork.freedesktop.org/series/82206/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
548dfee5bc0f drm/i915/edp/jsl: Update vswing table for HBR and HBR2
-:83: WARNING:UNNECESSARY_
== Series Details ==
Series: drm/i915/edp/jsl: Update vswing table for HBR and HBR2
URL : https://patchwork.freedesktop.org/series/82206/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9075 -> Patchwork_18590
Summary
---
== Series Details ==
Series: drm/i915: Read DIMM size in Gb rather than GB
URL : https://patchwork.freedesktop.org/series/82210/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9075 -> Patchwork_18591
Summary
---
**SUC
== Series Details ==
Series: vfio/pci: Refine Intel IGD OpRegion support (rev2)
URL : https://patchwork.freedesktop.org/series/79293/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9071_full -> Patchwork_18587_full
Summary
-
Thank you for the reply. And in regards to digging into it further,
thanks for requesting that I do some more due diligence here :)
Also if you did get around to it, thanks for double-checking with
Bill! Let me know if you'd like me to reach out instead, or if
anything else needs to be done in thi
On Tue, 2020-09-29 at 17:41 +0530, Tejas Upadhyay wrote:
> JSL has update in vswing table for eDP
Would be nice to mention in the commit description why PCH is being used, that
would avoid Ville's question.
>
> BSpec: 21257
>
> Changes since V1 :
> - IS_ELKHARTLAKE and IS_JASPERLAKE is
On Tue, Sep 29, 2020 at 07:33:45PM +, Souza, Jose wrote:
> On Tue, 2020-09-29 at 17:41 +0530, Tejas Upadhyay wrote:
> > JSL has update in vswing table for eDP
>
> Would be nice to mention in the commit description why PCH is being used,
> that would avoid Ville's question.
If the thing has n
On Sun, Sep 27, 2020 at 09:46:47AM +0300, Leon Romanovsky wrote:
> @@ -296,11 +223,17 @@ static struct ib_umem *__ib_umem_get(struct ib_device
> *device,
> goto umem_release;
>
> cur_base += ret * PAGE_SIZE;
> - npages -= ret;
> -
> -
On Tue, Sep 29, 2020 at 8:31 AM Jan Kiszka wrote:
>
> On 10.09.20 20:18, Deucher, Alexander wrote:
> > [AMD Public Use]
> >
> >
> >
> >> -Original Message-
> >> From: amd-gfx On Behalf Of
> >> Daniel Vetter
> >> Sent: Monday, September 7, 2020 3:15 AM
> >> To: Jan Kiszka ; amd-gfx list >
On Tue, 2020-09-29 at 23:02 +0300, Ville Syrjälä wrote:
> On Tue, Sep 29, 2020 at 07:33:45PM +, Souza, Jose wrote:
> > On Tue, 2020-09-29 at 17:41 +0530, Tejas Upadhyay wrote:
> > > JSL has update in vswing table for eDP
> >
> > Would be nice to mention in the commit description why PCH is bei
On Tue, Sep 29, 2020 at 08:20:22PM +, Souza, Jose wrote:
> On Tue, 2020-09-29 at 23:02 +0300, Ville Syrjälä wrote:
> > On Tue, Sep 29, 2020 at 07:33:45PM +, Souza, Jose wrote:
> > > On Tue, 2020-09-29 at 17:41 +0530, Tejas Upadhyay wrote:
> > > > JSL has update in vswing table for eDP
> > >
On Tue, 2020-09-29 at 23:30 +0300, Ville Syrjälä wrote:
> On Tue, Sep 29, 2020 at 08:20:22PM +, Souza, Jose wrote:
> > On Tue, 2020-09-29 at 23:02 +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 29, 2020 at 07:33:45PM +, Souza, Jose wrote:
> > > > On Tue, 2020-09-29 at 17:41 +0530, Tejas Upad
On Tue, Sep 29, 2020 at 11:30:22PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 29, 2020 at 08:20:22PM +, Souza, Jose wrote:
> > On Tue, 2020-09-29 at 23:02 +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 29, 2020 at 07:33:45PM +, Souza, Jose wrote:
> > > > On Tue, 2020-09-29 at 17:41 +0530, Tej
On Tue, Sep 29, 2020 at 02:01:44PM -0700, Matt Roper wrote:
> On Tue, Sep 29, 2020 at 11:30:22PM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 29, 2020 at 08:20:22PM +, Souza, Jose wrote:
> > > On Tue, 2020-09-29 at 23:02 +0300, Ville Syrjälä wrote:
> > > > On Tue, Sep 29, 2020 at 07:33:45PM +000
Child min_brightness is obsolete from VBT 234+, instead the new
min_brightness field in the main structure should be used.
This new field is 16 bits wide, so backlight_precision_bits is needed
to check if value needs to be scaled down but it is only available in
VBT 236+ so working around it by us
This will be used in future but already adding to VBT so we are
updated with VBT changes.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
b/drivers/gpu/drm/i9
This will remove the "Expected child device config size for VBT
version 235 not known" debug message seen in TGL, although this is not
fixing anything it good to keep our VBT parser updated.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_bios.c | 2 +-
1 file changed
On Wed, Sep 30, 2020 at 12:11:48AM +0300, Ville Syrjälä wrote:
> On Tue, Sep 29, 2020 at 02:01:44PM -0700, Matt Roper wrote:
> > On Tue, Sep 29, 2020 at 11:30:22PM +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 29, 2020 at 08:20:22PM +, Souza, Jose wrote:
> > > > On Tue, 2020-09-29 at 23:02 +030
On Wed, 30 Sep 2020 00:10:38 +0800
Fred Gao wrote:
> Bypass the IGD initialization for Intel's dgfx devices with own expansion
> ROM and the host/LPC bridge config space are no longer accessed.
>
> v2: simply test if discrete or integrated gfx device
> with root bus. (Alex Williamson)
>
> C
== Series Details ==
Series: series starting with [1/3] drm/i915/vbt: Fix backlight parsing for VBT
234+
URL : https://patchwork.freedesktop.org/series/82227/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9075 -> Patchwork_18592
===
Child min_brightness is obsolete from VBT 234+, instead the new
min_brightness field in the main structure should be used.
This new field is 16 bits wide, so backlight_precision_bits is needed
to check if value needs to be scaled down but it is only available in
VBT 236+ so working around it by us
This will remove the "Expected child device config size for VBT
version 235 not known" debug message seen in TGL, although this is not
fixing anything it good to keep our VBT parser updated.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_bios.c | 2 +-
1 file changed
This will be used in future but already adding to VBT so we are
updated with VBT changes.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
b/drivers/gpu/drm/i9
== Series Details ==
Series: series starting with [v2,1/3] drm/i915/vbt: Fix backlight parsing for
VBT 234+
URL : https://patchwork.freedesktop.org/series/82229/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9075 -> Patchwork_18593
From: Ville Syrjälä
Another attempt at plumbing the crtc state to the depths of
the link training code. This time I tried to preserve the
PHY test stuff in a somewhat working condition.
The DDI buf trans stuff also started to bug me again so had
to toss in a few cleanups in that area. Still pre
From: Ville Syrjälä
intel_dp_process_phy_request() has no business being externally
visible. Make it static.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
drivers/gpu/drm/i915/display/intel_dp.h | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --g
From: Ville Syrjälä
Make the mess inside the buf trans funcs a bit more manageable by
splitting along the lines of output type.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 83 ++--
1 file changed, 49 insertions(+), 34 deletions(-)
diff --git
From: Ville Syrjälä
I managed to fumble some functions names. Fix them.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/i
From: Ville Syrjälä
Make the mess inside the buf trans funcs a bit more manageable by
splitting along the lines of output type.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 63 +++-
1 file changed, 41 insertions(+), 22 deletions(-)
diff --git
From: Ville Syrjälä
Doing nay kind modeset stuff from the short hpd handler is
verboten. The ad-hoc PHY test modeset code violates this. And
by calling various link training related functions it's now
blocking further work to plumb the crtc state down into the
link training code.
Let's hack arou
From: Ville Syrjälä
intel_dp_enable_port() is called during the enable sequence,
so there is nothing old about the passed in crtc state.
Rename it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/d
From: Ville Syrjälä
Make the mess inside the buf trans funcs a bit more manageable by
splitting along the lines of output type.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 31 ++--
1 file changed, 23 insertions(+), 8 deletions(-)
diff --git
From: Ville Syrjälä
Make the mess inside the buf trans funcs a bit more manageable by
splitting along the lines of output type.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 31 ++--
1 file changed, 23 insertions(+), 8 deletions(-)
diff --git
From: Ville Syrjälä
Get rid of mode crtc->config usage, and some ad-hoc intel_dp state
usage by plumbing the crtc state all the way down to the link training
code.
Unfortunately we do have to keep some cached state in intel_dp so
that we can do the "does the link need retraining?" checks from
th
From: Ville Syrjälä
Now that we've plumbed the crtc state all the way down we can
eliminate the DP_TP_{CTL,STATUS} register offsets from intel_dp,
and instead we derive them directly from the crtc state.
And thus we can get rid of the nasty hack in intel_ddi_get_config()
which mutates intel_dp d
From: Ville Syrjälä
Make the mess inside the buf trans funcs a bit more manageable by
splitting along the lines of output type.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 42 +++-
1 file changed, 33 insertions(+), 9 deletions(-)
diff --git
On Wed, Sep 30, 2020 at 12:59:58AM +0300, Ville Syrjälä wrote:
> On Wed, Sep 30, 2020 at 12:11:48AM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 29, 2020 at 02:01:44PM -0700, Matt Roper wrote:
> > > On Tue, Sep 29, 2020 at 11:30:22PM +0300, Ville Syrjälä wrote:
> > > > On Tue, Sep 29, 2020 at 08:20:
== Series Details ==
Series: drm/i915: Plumb crtc state to link training code (rev3)
URL : https://patchwork.freedesktop.org/series/76993/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e1b9ea43cc51 drm/i915: s/pre_empemph/preemph/
099b31ec3c93 drm/i915: s/old_crtc_state/crtc_st
== Series Details ==
Series: drm/i915: Plumb crtc state to link training code (rev3)
URL : https://patchwork.freedesktop.org/series/76993/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+drivers/g
== Series Details ==
Series: drm/i915: Plumb crtc state to link training code (rev3)
URL : https://patchwork.freedesktop.org/series/76993/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9075 -> Patchwork_18594
Summary
--
On Tue, 2020-09-29 at 16:13 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä <
> ville.syrj...@linux.intel.com
> >
>
> CNL+ can report DIMM sizes in .5 GB units. In order to not trauncate
> away the .5 GB let's switch to storing the DIMM size in Gb units.
>
Reviewed-by: José Roberto de Souza
Add DG1 DPLL Enable register macro and use the macro to enable the
correct DPLL based on PLL id. Although we use
_MG_PLL1_ENABLE/_MG_PLL2_ENABLE these are rather combo phys.
While at it, fix coding style: wrong newlines and use if/else chain
v2: Rewrite original patch from Aditya Swarup based on
From: Matt Roper
DG1 always uses a 38.4 MHz rawclk rather than the 19.2/24 MHz
frequencies on CNP+. Note that register bits associated with this
frequency confusingly use 37 for the divider field rather than 38 as you
might expect.
For simplicity, let's just assume that this 38.4 MHz frequency
From: Uma Shankar
Most of TGL power wells are re-used for DG1. However, AUDIO Power
Domain is moved from PG3 to PG0. Handle the change and initialize
power wells with the new power well structure.
Some of the Audio Streaming logic still remains in PW3 so still
it needs to be enabled.
DDIA, DDIB
v6:
- Remove already applied patches and rebase the rest, particularly on
top of DPLL and hotplug changes
- Add new workarounds
- Reword commit messages regarding DDIA, DDIB, TC1 and TC2 ports
- Colletc R-b
The DPLL and hotplug changes are not tested as testing depends on
the lmem patches. They
From: Aditya Swarup
DG1 has 4 DPLLs where DPLL0 and DPLL1 drive DDIA/B and
DPLL2 and DPLL3 drive DDI-TC1/DDI-TC2.
Introduce DG1_DPLL_CFCRx() helper macros to configure
DPLL registers.
Bspec: 50288, 50299
Cc: Matt Roper
Signed-off-by: Aditya Swarup
Signed-off-by: Lucas De Marchi
Reviewed-by:
From: Aditya Swarup
Add entries for dg1 plls and setup dg1_pll_mgr to reuse ICL callbacks.
Initial setup for shared dplls DPLL0/1 for DDIA/DDIB and DPLL2/3 for
DDI-TC1/DDI-TC2. Configure dpll cfgcrx registers to drive the plls on
DG1.
v2 (Lucas): Reword commit message and add missing update_ref_
From: Clinton A Taylor
HPD pins are inverted for DG1 platform.
Bspec: 49956
Cc: José Roberto de Souza
Cc: Matt Roper
Signed-off-by: Clinton A Taylor
Reviewed-by: Lucas De Marchi
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_irq.c | 9 +
drivers/gpu/drm/i915/i915_reg.
From: Matt Atwood
Add support to load DMC v2.0.2 on DG1
While we're at it, make TGL use the same GEN12 firmware size definition
and remove obsolete comment.
Bpec: 49230
v2: do not replace GEN12_CSR_MAX_FW_SIZE (from José)
and replace stale comment
Cc: Matt Roper
Signed-off-by: Matt Atwoo
From: Matt Roper
The only bit we use in PHY_MISC is DE_IO_COMP_PWR_DOWN, and the bspec
details for that bit tell us that it need only be set for PHY-A and
PHY-B. It also turns out that there isn't even an instance of the
PHY_MISC register for PHY-D on this platform. Let's extend the EHL/RKL
log
From: Matt Roper
As with RKL, DG1's PHY C acts as a comp master for PHY D.
Bspec: 49291
Signed-off-by: Matt Roper
Signed-off-by: Lucas De Marchi
Reviewed-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_combo_phy.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --g
From: Anshuman Gupta
DC6 is not supported on DG1, so change the allowed DC mask for DG1.
Cc: Uma Shankar
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_display_power.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/in
DG1 has a new MOCS table. We still use the old definition of the table,
but as for any dgfx card it doesn't contain the control_value values
(these values don't matter as we won't program them).
Bspec: 45101
v2: Reword the comment to state that the last few entries are reserved
instead of "th
From: Matt Roper
DG1's vswing tables are the same for eDP and HDMI but have slight
differences from ICL/TGL for DP.
Bspec: 49291
Cc: Clinton Taylor
Cc: José Roberto de Souza
Cc: Radhakrishna Sripada
Signed-off-by: Matt Roper
Signed-off-by: Lucas De Marchi
Reviewed-by: José Roberto de Souza
From: Anshuman Gupta
DGFX devices have different DMC_DEBUG* counter MMIO address
offset. Incorporate these changes in i915_reg.h for DG1
and handle i915_dmc_info accordingly.
Cc: Uma Shankar
Signed-off-by: Anshuman Gupta
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_d
DG1 has one more combo phy port, no TC and all irq handling goes through
SDE, like for MCC.
v2: Also change intel_hpd_pin_default() to include DG1 mapping
v3: Rebase on hpd refactor
Cc: Ville Syrjälä
Cc: Anshuman Gupta
Cc: José Roberto de Souza
Cc: Imre Deak
Signed-off-by: Lucas De Marchi
--
From: Michel Thierry
While we do lack the faster shared LLC, we should still have support
for snooping over PCIe.
Signed-off-by: Michel Thierry
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_pci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_pci.c
Synchronize with the current list of DG1 PCI IDs.
Signed-off-by: Lucas De Marchi
---
include/drm/i915_pciids.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 7eeecb07c9a1..095463ff7cb9 100644
--- a/include/drm/i
From: Matt Roper
DG1 does some additional pcode/uncore handshaking at
boot time; this handshaking must complete before various other pcode
commands are effective and before general work is submitted to the GPU.
We need to poll a new pcode mailbox during startup until it reports that
this handshak
For DG1 we have a little of mix up wrt to DDI/port names and indexes.
Bspec refers to the ports as DDIA, DDIB, DDI USBC1 and DDI USBC2
(besides the DDIA, DDIB, DDIC, DDID), but the previous naming is the
most unambiguous one. This means that for any register on Display Engine
we should use the inde
1 - 100 of 106 matches
Mail list logo
