Hi Rodrigo,
It's probably a bug fix that unveils the link errors.
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: 20532651221ed29af16e2db0a7ec8b9bd482c994
commit: 315fade0d9f3edbf2592599056c8defbdd95a3ab [7/8] Merge remote-tracking
branch 'drm-intel/topic/core-for-CI' into
On Mon, 16 Jul 2018 13:50:58 +0200 Michal Hocko wrote:
> From: Michal Hocko
>
> There are several blockable mmu notifiers which might sleep in
> mmu_notifier_invalidate_range_start and that is a problem for the
> oom_reaper because it needs to guarantee a forward progress so it cannot
> depend
>-Original Message-
>From: Vivi, Rodrigo
>Sent: Friday, July 20, 2018 3:59 PM
>To: Srivatsa, Anusha
>Cc: intel-gfx@lists.freedesktop.org; Navare, Manasi D
>
>Subject: Re: [v3] drm/i915/dsc: Add missing _MMIO() from PPS registers
>
>On Fri, Jul 20, 2018 at 02:42:42PM -0700, Anusha
On Tue, 17 Jul 2018 10:12:01 +0200 Michal Hocko wrote:
> > Any suggestions regarding how the driver developers can test this code
> > path? I don't think we presently have a way to fake an oom-killing
> > event? Perhaps we should add such a thing, given the problems we're
> > having with that
On Fri, Jul 20, 2018 at 02:42:42PM -0700, Anusha Srivatsa wrote:
> This patch fixes the commit -
> <2efbb2f099fb> ("i915/dp/dsc: Add DSC PPS register definitions"),
> which did not have _MMIO() for DSCA and DSCC.
>
> v2: Fix typos. (manasi)
>
> v3: Change the commit message (Rodrigo)
>
> Cc:
== Series Details ==
Series: drm/i915/dsc: Add missing _MMIO() from PPS registers (rev3)
URL : https://patchwork.freedesktop.org/series/46979/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4521 -> Patchwork_9741 =
== Summary - SUCCESS ==
No regressions found.
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/dp: Limit link training clock
recovery loop
URL : https://patchwork.freedesktop.org/series/46992/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4521 -> Patchwork_9740 =
== Summary - SUCCESS ==
No
This patch fixes the commit -
<2efbb2f099fb> ("i915/dp/dsc: Add DSC PPS register definitions"),
which did not have _MMIO() for DSCA and DSCC.
v2: Fix typos. (manasi)
v3: Change the commit message (Rodrigo)
Cc: Rodrigi Vivi
Cc: Manasi Navare
Signed-off-by: Anusha Srivatsa
Reviewed-by: Manasi
From: Nathan Ciobanu
Limit the link training clock recovery loop to 10 attempts at
LANEx_CR_DONE per DP 1.4 spec section 3.5.1.2.2 and 80 attempts for
pre-DP 1.4 (4 voltage levels x 4 preemphasis levels x
x 5 identical voltages tries). Some faulty USB-C MST hubs can
cause us to get stuck in this
From: Nathan Ciobanu
Changes the type and renames the max_vswing_tries variable
which was declared as an integer but used as a boolean
making it easy to be confused with a counter.
Changes in v2:
- updated the title and commit message
- left the loop exit point in place
v3: fix typo in
On Fri, Jul 20, 2018 at 11:01:38PM +0200, Marcin Owsiany wrote:
>2018-07-20 22:22 GMT+02:00 Rodrigo Vivi <[1]rodrigo.v...@intel.com>:
>
>On Thu, Jul 19, 2018 at 11:31:19PM +0200, Marcin Owsiany wrote:
>> $ xrandr --fb 8960x2880
>> xrandr: screen cannot be larger than
On Fri, 2018-07-20 at 10:41 -0700, Rodrigo Vivi wrote:
> Instead of using a backchannel if some dpcd read failed we
> can show that directly on debugfs output.
>
> We are not returning an error because we might still want
> to know if sub-sequent reads works,
We can print partial ( and
On Fri, 2018-07-20 at 10:38 -0700, Rodrigo Vivi wrote:
> On Thu, Jul 19, 2018 at 06:52:00PM -0700, Dhinakaran Pandiyan wrote:
> >
> > On Thu, 2018-07-19 at 17:31 -0700, Rodrigo Vivi wrote:
> > >
> > > First of all don't try to read dpcd if PSR is not even supported.
> > >
> > > But also, if
2018-07-20 22:22 GMT+02:00 Rodrigo Vivi :
> On Thu, Jul 19, 2018 at 11:31:19PM +0200, Marcin Owsiany wrote:
> > $ xrandr --fb 8960x2880
> > xrandr: screen cannot be larger than 8192x8192 (desired size
> >8960x2880)
>
> I'm afraid that it is a hardware limitation that you won't be able
On Fri, Jul 20, 2018 at 01:28:44PM -0700, Rodrigo Vivi wrote:
> On Fri, Jul 20, 2018 at 01:15:59PM -0700, Nathan Ciobanu wrote:
> > Limit the link training clock recovery loop to 10 attempts at
> > LANEx_CR_DONE per DP 1.4 spec section 3.5.1.2.2 and 80 attempts for
> > pre-DP 1.4 (4 voltage levels
>-Original Message-
>From: Vivi, Rodrigo
>Sent: Friday, July 20, 2018 1:37 PM
>To: Srivatsa, Anusha
>Cc: Navare, Manasi D ; intel-
>g...@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [v2] drm/i915/dsc: Add missing _MMIO() from PPS
>registers
>
>On Fri, Jul 20, 2018 at 08:28:01PM
On Fri, Jul 20, 2018 at 08:28:01PM +, Srivatsa, Anusha wrote:
>
>
> >-Original Message-
> >From: Navare, Manasi D
> >Sent: Friday, July 20, 2018 1:29 PM
> >To: Vivi, Rodrigo
> >Cc: Srivatsa, Anusha ; intel-
> >g...@lists.freedesktop.org
> >Subject: Re: [Intel-gfx] [v2] drm/i915/dsc:
On Thu, Jul 19, 2018 at 06:13:54PM +0200, Jamesie Pic wrote:
>Hello everybody !
>Sorry but I'm really a noob and I got nowhere to turn to.
>I have a lenevo thinkpad x270 on an ultra-dock with 3 external
>monitors:
>00:02.0 VGA compatible controller: Intel Corporation HD
>-Original Message-
>From: Navare, Manasi D
>Sent: Friday, July 20, 2018 1:29 PM
>To: Vivi, Rodrigo
>Cc: Srivatsa, Anusha ; intel-
>g...@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [v2] drm/i915/dsc: Add missing _MMIO() from PPS
>registers
>
>On Fri, Jul 20, 2018 at 01:13:07PM
On Fri, Jul 20, 2018 at 01:15:59PM -0700, Nathan Ciobanu wrote:
> Limit the link training clock recovery loop to 10 attempts at
> LANEx_CR_DONE per DP 1.4 spec section 3.5.1.2.2 and 80 attempts for
> pre-DP 1.4 (4 voltage levels x 4 preemphasis levels x
> x 5 identical voltages tries). Some faulty
On Fri, Jul 20, 2018 at 01:13:07PM -0700, Rodrigo Vivi wrote:
> On Fri, Jul 20, 2018 at 12:25:47PM -0700, Manasi Navare wrote:
> > Looks good to me now and also tested with the patches that use these
> > registers.
> >
> > Reviewed-by: Manasi Navare
> >
> > Manasi
> >
> > On Fri, Jul 20, 2018
On Fri, Jul 20, 2018 at 12:22:15PM -0700, Rodrigo Vivi wrote:
> On Thu, Jul 19, 2018 at 02:47:38PM -0700, Nathan Ciobanu wrote:
> > Limit the link training clock recovery loop to 10 attempts at
> > LANEx_CR_DONE per DP 1.4 spec section 3.5.1.2.2 and 80 attempts for
> > pre-DP 1.4 (4 voltage levels
Limit the link training clock recovery loop to 10 attempts at
LANEx_CR_DONE per DP 1.4 spec section 3.5.1.2.2 and 80 attempts for
pre-DP 1.4 (4 voltage levels x 4 preemphasis levels x
x 5 identical voltages tries). Some faulty USB-C MST hubs can
cause us to get stuck in this loop indefinitely
On Thu, Jul 19, 2018 at 11:31:19PM +0200, Marcin Owsiany wrote:
>Hello,
>TL;DR: how can I set a 8960x2880 screen (not display) size on a T580? A
>patch for i915 that I found on the internets does not seem to work.
>Full story:
>I'm a rather happy user of ThinkPad T580 which
On Fri, Jul 20, 2018 at 12:25:47PM -0700, Manasi Navare wrote:
> Looks good to me now and also tested with the patches that use these
> registers.
>
> Reviewed-by: Manasi Navare
>
> Manasi
>
> On Fri, Jul 20, 2018 at 12:10:39PM -0700, Anusha Srivatsa wrote:
> > FIXME: This fixes the patch:
== Series Details ==
Series: drm/i915/dsc: Add missing _MMIO() from PPS registers (rev2)
URL : https://patchwork.freedesktop.org/series/46979/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4521 -> Patchwork_9739 =
== Summary - WARNING ==
Minor unknown changes coming
Looks good to me now and also tested with the patches that use these registers.
Reviewed-by: Manasi Navare
Manasi
On Fri, Jul 20, 2018 at 12:10:39PM -0700, Anusha Srivatsa wrote:
> FIXME: This fixes the patch:
> Link:
>
On Thu, Jul 19, 2018 at 02:47:38PM -0700, Nathan Ciobanu wrote:
> Limit the link training clock recovery loop to 10 attempts at
> LANEx_CR_DONE per DP 1.4 spec section 3.5.1.2.2 and 80 attempts for
> pre-DP 1.4 (4 voltage levels x 4 preemphasis levels x
> x 5 identical voltages tries). Some faulty
== Series Details ==
Series: drm/i915: Show debugfs dpcd read failure directly
URL : https://patchwork.freedesktop.org/series/46977/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4521 -> Patchwork_9737 =
== Summary - SUCCESS ==
No regressions found.
External URL:
== Series Details ==
Series: series starting with [v5] drm/i915/dp: Refactor max_vswing_tries
variable (rev3)
URL : https://patchwork.freedesktop.org/series/46897/
State : failure
== Summary ==
Applying: drm/i915/dp: Refactor max_vswing_tries variable
error: sha1 information is lacking or
FIXME: This fixes the patch:
Link:
https://patchwork.freedesktop.org/patch/msgid/1531861861-10950-2-git-send-email-anusha.sriva...@intel.com
Which did not have _MMIO() for DSCA and DSCC.
v2: Fix typos. (manasi)
Cc: Rodrigi Vivi
Cc: Manasi Navare
Signed-off-by: Anusha Srivatsa
---
On Fri, Jul 20, 2018 at 11:23:43AM -0700, Nathan Ciobanu wrote:
> Changes the type and renames the max_vswing_tries variable
> which was declared as an integer but used as a boolean
> making it easy to be confused with a counter.
>
> Changes in v2:
> - updated the title and commit message
>
There are more typos in this patch as below that need to be fixed:
On Fri, Jul 20, 2018 at 11:04:38AM -0700, Anusha Srivatsa wrote:
> FIXME: This fixes the patch:
> Link:
> https://patchwork.freedesktop.org/patch/msgid/1531861861-10950-2-git-send-email-anusha.sriva...@intel.com
>
> Which did
== Series Details ==
Series: series starting with [1/2] drm/dp: add extended receiver capability
field present bit
URL : https://patchwork.freedesktop.org/series/46965/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4521 -> Patchwork_9736 =
== Summary - SUCCESS ==
No
On Fri, Jul 20, 2018 at 01:19:02PM +0300, Ville Syrjälä wrote:
> On Thu, Jul 19, 2018 at 02:48:07PM -0700, Nathan Ciobanu wrote:
> > Changes the type and renames the max_vswing_tries variable
> > which was declared as an integer but used as a boolean
> > making it easy to be confused with a
Changes the type and renames the max_vswing_tries variable
which was declared as an integer but used as a boolean
making it easy to be confused with a counter.
Changes in v2:
- updated the title and commit message
- left the loop exit point in place
v3: fix typo in title
v4: renamed
FIXME: This fixes the patch:
Link:
https://patchwork.freedesktop.org/patch/msgid/1531861861-10950-2-git-send-email-anusha.sriva...@intel.com
Which did not have _MMIO() for DSCA and DSCC.
Cc: Rodrigi Vivi
Cc: Manasi Navare
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/i915_reg.h |
On Fri, Jul 20, 2018 at 09:18:12AM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood
>
> According to DP spec (2.9.3.1 of DP 1.4) if
> EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT is set the addresses in DPCD
> 02200h through 0220Fh shall contain the DPRX's true capability. These
>
On Fri, Jul 20, 2018 at 09:18:12AM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood
>
> According to DP spec (2.9.3.1 of DP 1.4) if
> EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT is set the addresses in DPCD
> 02200h through 0220Fh shall contain the DPRX's true capability. These
>
On Fri, Jul 20, 2018 at 09:18:11AM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood
>
> This bit was added to DP Training Aux RD interval with DP 1.3. Via
> descriptiion of the spec this field indicates the panels true
> capabilities are described in DPCD address space 02200h through
On Thu, Jul 19, 2018 at 05:56:33PM -0700, Nathan Ciobanu wrote:
> On Thu, Jul 19, 2018 at 05:16:03PM -0700, Nathan Ciobanu wrote:
> > On Thu, Jul 19, 2018 at 04:42:17PM -0700, Rodrigo Vivi wrote:
> > > Just a small clean-up with no functional change, only
> > > removing a variable that is never
Instead of using a backchannel if some dpcd read failed we
can show that directly on debugfs output.
We are not returning an error because we might still want
to know if sub-sequent reads works, but we shouldn't
need to check 2 places to see why reg is not on the list.
Cc: Jani Nikula
Cc:
On Thu, Jul 19, 2018 at 06:52:00PM -0700, Dhinakaran Pandiyan wrote:
> On Thu, 2018-07-19 at 17:31 -0700, Rodrigo Vivi wrote:
> > First of all don't try to read dpcd if PSR is not even supported.
> >
> > But also, if read failed return -EIO instead of reporting via a
> > backchannel.
> >
> > v2:
== Series Details ==
Series: drm/i915: Fix psr sink status report. (rev3)
URL : https://patchwork.freedesktop.org/series/46831/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4519 -> Patchwork_9735 =
== Summary - SUCCESS ==
No regressions found.
External URL:
Quoting Tvrtko Ursulin (2018-07-20 16:13:14)
>
> On 20/07/2018 11:19, Chris Wilson wrote:
> > +/*
> > + * Once upon a time we supposed that writes through the GGTT would be
> > + * immediately in physical memory (once flushed out of the CPU path).
> > However,
> > + * on a few different
From: Matt Atwood
This bit was added to DP Training Aux RD interval with DP 1.3. Via
descriptiion of the spec this field indicates the panels true
capabilities are described in DPCD address space 02200h through 022FFh.
v2: version comment update
v3: version comment correction, commit message
From: Matt Atwood
According to DP spec (2.9.3.1 of DP 1.4) if
EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT is set the addresses in DPCD
02200h through 0220Fh shall contain the DPRX's true capability. These
values will match 0h through Fh, except for DPCD_REV,
MAX_LINK_RATE,
Hello everybody !
Sorry but I'm really a noob and I got nowhere to turn to.
I have a lenevo thinkpad x270 on an ultra-dock with 3 external monitors:
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 620 (rev
02)
Since last week's updates in Arch linux, I'm having issues with the
Hello,
*TL;DR*: how can I set a 8960x2880 screen (not display) size on a T580? A
patch for i915 that I found on the internets does not seem to work.
Full story:
I'm a rather happy user of ThinkPad T580 which comes with a
high-density 3840x2160 LCD, and the following graphics hardware.
00:02.0
On Wed 2018-07-18 19:49:10, Andy Shevchenko wrote:
> On Tue, Jul 17, 2018 at 3:59 AM, Dmitry Safonov wrote:
> > I would be glad if someone helps/bothers to review the change :C
> >
>
> Perhaps Petr and / or Steven can help you.
> > Thanks,
> > Dmitry
> >
> > On Tue, 2018-07-03 at 23:56 +0100,
On 20/07/2018 09:07, Chris Wilson wrote:
We test map_gtt coherency (whether or not a write via the mmap_gtt is
immediately visible in the backing storage to a read via mmap_cpu) but
we know that several platforms are inherently incorrect and require some
form of hammer to workaround internal
On Fri, 2018-07-20 at 17:09 +0200, Petr Mladek wrote:
> > > On Tue, 2018-07-03 at 23:56 +0100, Dmitry Safonov wrote:
> > > > Currently ratelimit_state is protected with spin_lock. If the
> > > > .lock
> > > > is
> > > > taken at the moment of ___ratelimit() call, the message is
> > > > suppressed
Quoting Tvrtko Ursulin (2018-07-20 16:27:20)
>
> On 20/07/2018 16:21, Chris Wilson wrote:
> > My only plan is for igt to know when the tests are expected to fail.
> > Real userspace should not be using GTT, it is slow (even slower than
> > intended ;) and constrained, so subject to aperture
On 20/07/2018 16:21, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-07-20 16:13:14)
On 20/07/2018 11:19, Chris Wilson wrote:
Not all chipsets have an internal buffer delaying the visibility of
writes via the GGTT being visible by other physical paths, but we use a
very heavy workaround for
Quoting Tvrtko Ursulin (2018-07-20 16:13:14)
>
> On 20/07/2018 11:19, Chris Wilson wrote:
> > Not all chipsets have an internal buffer delaying the visibility of
> > writes via the GGTT being visible by other physical paths, but we use a
> > very heavy workaround for all. We only need to apply
== Series Details ==
Series: drm/i915: Clean up power well descriptors
URL : https://patchwork.freedesktop.org/series/46952/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4518 -> Patchwork_9734 =
== Summary - SUCCESS ==
No regressions found.
External URL:
On 20/07/2018 11:19, Chris Wilson wrote:
Not all chipsets have an internal buffer delaying the visibility of
writes via the GGTT being visible by other physical paths, but we use a
very heavy workaround for all. We only need to apply that workarounds to
the chipsets we know suffer from the
On Fri, Jul 20, 2018 at 03:33:51PM +0200, Jakub Bartmiński wrote:
> It would appear that the calculated GuC pin bias was larger than it
> should be, as the GuC address space does NOT contain the "HW contexts RSVD"
> part of the WOPCM. Thus, the GuC pin bias is simply the GuC WOPCM size.
>
>
Quoting Tvrtko Ursulin (2018-07-20 15:58:51)
> True, it only catches the imbalance in one direction quickly. If suspend
> idea works go with that, but what's so bad about some log messages?
> Assuming leak towards the overflow direction on each flip it could be
> reached in ~18 hours which is
Quoting Michał Winiarski (2018-07-20 15:57:49)
> On Fri, Jul 20, 2018 at 10:51:44AM +0100, Chris Wilson wrote:
> > Another step in the drv_module_reload fault-injection saga, is that we
> > try to disable the guc twice. Probably. It's a little unclear exactly
> > what is going on in the unload
On 20/07/2018 14:59, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-07-20 14:29:52)
On 20/07/2018 14:02, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-07-20 13:49:09)
On 12/07/2018 18:38, Chris Wilson wrote:
+ if (rps->interactive)
+ new_power = HIGH_POWER;
+
On Fri, Jul 20, 2018 at 10:51:44AM +0100, Chris Wilson wrote:
> Another step in the drv_module_reload fault-injection saga, is that we
> try to disable the guc twice. Probably. It's a little unclear exactly
> what is going on in the unload sequence that catches us out, so for the
> time being
== Series Details ==
Series: drm/i915: Clean up power well descriptors
URL : https://patchwork.freedesktop.org/series/46952/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915/icl: Fix power well anonymous union initializers
Okay!
Commit: drm/i915: Rename
Quoting Lis, Tomasz (2018-07-20 15:41:33)
>
>
> On 2018-07-20 12:19, Chris Wilson wrote:
> > Not all chipsets have an internal buffer delaying the visibility of
> > writes via the GGTT being visible by other physical paths, but we use a
> > very heavy workaround for all. We only need to apply
== Series Details ==
Series: drm/i915: Clean up power well descriptors
URL : https://patchwork.freedesktop.org/series/46952/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b6af654513ed drm/i915/icl: Fix power well anonymous union initializers
-:7: WARNING:COMMIT_LOG_LONG_LINE:
From: Tvrtko Ursulin
1.
It seems that on many systems the hardcoded PCI path in
igt_pm_audio_setup_runtime_pm is not correct.
Add some more paths to work around the issue. More robust solution would
be to look for a symlink of a specific format and use that, such as:
# ls -ld
On 2018-07-20 12:19, Chris Wilson wrote:
Not all chipsets have an internal buffer delaying the visibility of
writes via the GGTT being visible by other physical paths, but we use a
very heavy workaround for all. We only need to apply that workarounds to
the chipsets we know suffer from the
== Series Details ==
Series: drm/i915: Suppress assertion for i915_ggtt_disable_guc
URL : https://patchwork.freedesktop.org/series/46930/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4518_full -> Patchwork_9728_full =
== Summary - WARNING ==
Minor unknown changes
On Fri, Jul 20, 2018 at 03:03:09PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjälä (2018-07-20 14:50:25)
> > On Fri, Jul 20, 2018 at 02:38:32PM +0100, Chris Wilson wrote:
> > > Quoting Ville Syrjälä (2018-07-20 14:32:40)
> > > > Another question is what happens where there are parallel flips
>
Atm, we determine the control/status flag offsets within the PUNIT
control/status registers based on the power well's ID. Since the power
well ID enum is global across all platforms, the associated macros to
get the flag offsets involves some magic. This makes checking the
register/bit definitions
intel_power_domains_fini() rolls back what was done in
intel_power_domains_init_hw(), so rename and move it accordingly. This
allows us adding a cleanup function later for intel_power_domains_init()
in a cleaner way.
No functional change.
Cc: Ville Syrjala
Cc: Paulo Zanoni
Cc: Jani Nikula
Paulo noted that the complexity in the macros for determining the power
well register and request/status HW flag offsets is overly complicated.
This patchset improves on that by removing the dependence on the power
well ID enum when determining these and instead defining the
correpsonding power
There is no need for separate IDs for power wells on a new platform with
the same functionality as an other power well on a previous platform, we
can just reuse the ID from the previous platform. This is only possible
after the previous patches where we removed dependence on the actual
enum
The format for the ID names is _DISP_PW_* so rename the IDs
not following this accordingly. Leave BXT_DPIO_CMN_BC as-is since we'll
change that to use another existing ID in the next patch.
Cc: Ville Syrjala
Cc: Paulo Zanoni
Cc: Jani Nikula
Signed-off-by: Imre Deak
---
Similarly to the previous patch use a separate request/status HW flag
index defined right after the corresponding control registers instead of
depending for this on the power well IDs. Since the set of
control/status registers varies among the different power wells (on a
single platform), also add
On ICL there are 5 fused power gates, so add the two missing ones for
clarity.
Cc: Ville Syrjala
Cc: Paulo Zanoni
Cc: Jani Nikula
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
Now that we removed dependence on the power well IDs to determine the
control register and request/status flag offsets the only purpose of
power well IDs is to look up power wells directly bypassing the power
domains framework. However this direct lookup isn't needed for most of
the exisiting
The callbacks these asserts are called from are used from a single power
well, so not much point in checking that. The check also requires a unique
power well ID that we would need to keep around only for this purpose.
(A follow-up patch removes power well IDs not needed for direct power
well
It makes sense to keep unchanging data const. Extract such fields from
the i915_power_well struct into a new i915_power_well_desc struct that
we initialize during compile time. For the rest of the dynamic
fields allocate an array of i915_power_well objects in i915 dev_priv,
and link to each of
Similarly to
0a445945be6d ("drm/i915: Work around GCC anonymous union initialization bug")
we need to initialize anonymous unions inside extra braces to work
around a GCC4.4 build error.
Cc: Chris Wilson
Cc: Ville Syrjala
Cc: Paulo Zanoni
Cc: Jani Nikula
Signed-off-by: Imre Deak
---
== Series Details ==
Series: series starting with [v4,1/5] drm/i915/guc: Avoid wasting memory on
incorrect GuC pin bias
URL : https://patchwork.freedesktop.org/series/46949/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4518 -> Patchwork_9733 =
== Summary - FAILURE ==
From: Tvrtko Ursulin
1.
It seems that on many systems the hardcoded PCI path in
igt_pm_audio_setup_runtime_pm is not correct.
Add some more paths to work around the issue. More robust solution would
be to look for a symlink of a specific format and use that, such as:
# ls -ld
Quoting Ville Syrjälä (2018-07-20 14:50:25)
> On Fri, Jul 20, 2018 at 02:38:32PM +0100, Chris Wilson wrote:
> > Quoting Ville Syrjälä (2018-07-20 14:32:40)
> > > Another question is what happens where there are parallel flips
> > > happening? One could undo the boost from the other AFAICS. But
Quoting Tvrtko Ursulin (2018-07-20 14:29:52)
>
> On 20/07/2018 14:02, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-07-20 13:49:09)
> >>
> >> On 12/07/2018 18:38, Chris Wilson wrote:
> >>> + if (rps->interactive)
> >>> + new_power = HIGH_POWER;
> >>> +
On Fri, Jul 20, 2018 at 02:38:32PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjälä (2018-07-20 14:32:40)
> > On Fri, Jul 20, 2018 at 02:14:11PM +0100, Chris Wilson wrote:
> > > Quoting Ville Syrjälä (2018-07-20 14:07:31)
> > > > On Fri, Jul 20, 2018 at 02:02:34PM +0100, Chris Wilson wrote:
> >
== Series Details ==
Series: series starting with [v4,1/5] drm/i915/guc: Avoid wasting memory on
incorrect GuC pin bias
URL : https://patchwork.freedesktop.org/series/46949/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915/guc: Avoid wasting memory on incorrect GuC
Quoting Ville Syrjälä (2018-07-20 14:32:40)
> On Fri, Jul 20, 2018 at 02:14:11PM +0100, Chris Wilson wrote:
> > Quoting Ville Syrjälä (2018-07-20 14:07:31)
> > > On Fri, Jul 20, 2018 at 02:02:34PM +0100, Chris Wilson wrote:
> > > Doing this kind of global thing from the plane hooks seems a bit
> >
Removing the pin bias from GuC allows us to not check for GuC every time
we pin a context, which fixes the assertion error on unresolved GuC
platform default in mock contexts selftest.
It also seems that we were using uninitialized WOPCM variables when
setting the GuC pin bias. The pin bias has
Since ggtt_offset_bias is now stored in ggtt.pin_bias, it is duplicated
inside i915_gem_context, and can instead be accessed directly from ggtt.
v3:
Added a helper function to retrieve the ggtt.pin_bias from the vma.
v4:
Moved the helper function to the previous patch in the series.
Dropped the
From: Michal Wajdeczko
Signed-off-by: Michal Wajdeczko
---
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 aebe0469ddaa..3e4e128237ac 100644
---
v4:
Move the injection inside the WOPCM init.
Signed-off-by: Jakub Bartmiński
Cc: Chris Wilson
Cc: Michał Winiarski
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/intel_wopcm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_wopcm.c
It would appear that the calculated GuC pin bias was larger than it
should be, as the GuC address space does NOT contain the "HW contexts RSVD"
part of the WOPCM. Thus, the GuC pin bias is simply the GuC WOPCM size.
Signed-off-by: Jakub Bartmiński
Cc: Chris Wilson
Cc: Michał Winiarski
Cc:
On Fri, Jul 20, 2018 at 02:14:11PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjälä (2018-07-20 14:07:31)
> > On Fri, Jul 20, 2018 at 02:02:34PM +0100, Chris Wilson wrote:
> > Doing this kind of global thing from the plane hooks seems a bit
> > strange. How about just doing this directly from
On 20/07/2018 14:02, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-07-20 13:49:09)
On 12/07/2018 18:38, Chris Wilson wrote:
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7998e70a3174..5809366ff9f0 100644
---
Quoting Ville Syrjälä (2018-07-20 14:07:31)
> On Fri, Jul 20, 2018 at 02:02:34PM +0100, Chris Wilson wrote:
> Doing this kind of global thing from the plane hooks seems a bit
> strange. How about just doing this directly from commit_tail()
> etc.?
We want it upfront in prepare (so that it's set
On Fri, Jul 20, 2018 at 02:02:34PM +0100, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-07-20 13:49:09)
> >
> > On 12/07/2018 18:38, Chris Wilson wrote:
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index
== Series Details ==
Series: drm/i915: Show stack (by WARN) for hitting forcewake errors
URL : https://patchwork.freedesktop.org/series/46939/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4518 -> Patchwork_9732 =
== Summary - SUCCESS ==
No regressions found.
Quoting Tvrtko Ursulin (2018-07-20 13:49:09)
>
> On 12/07/2018 18:38, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 7998e70a3174..5809366ff9f0 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++
On Mon, Jul 09, 2018 at 10:36:43AM +0200, Daniel Vetter wrote:
> #define for_each_active_drhd_unit(drhd)
> \
> list_for_each_entry_rcu(drhd, _drhd_units, list) \
> - if (drhd->ignored) {} else
> + for_each_if
On 12/07/2018 18:38, Chris Wilson wrote:
RPS provides a feedback loop where we use the load during the previous
evaluation interval to decide whether to up or down clock the GPU
frequency. Our responsiveness is split into 3 regimes, a high and low
plateau with the intent to keep the gpu clocked
1 - 100 of 131 matches
Mail list logo
