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 delay and the resulting coherency
issue.
Similar
== Series Details ==
Series: drm/i915: Only force GGTT coherency w/a on required chipsets
URL : https://patchwork.freedesktop.org/series/46915/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2bf244cfc4ca drm/i915: Only force GGTT coherency w/a on required chipsets
-:46: WARNING:
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 delays. These platforms break our
ABI guarantee
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Thursday, July 19, 2018 9:51 PM
> To: Chauhan, Madhav
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani ;
> Zanoni, Paulo R ; Vivi, Rodrigo
>
> Subject: Re: [Intel-gfx] [PATCH v5 09/13] drm/i915/ic
== Series Details ==
Series: drm/i915: Only force GGTT coherency w/a on required chipsets
URL : https://patchwork.freedesktop.org/series/46915/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4518 -> Patchwork_9727 =
== Summary - SUCCESS ==
No regressions found.
Externa
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Thursday, July 19, 2018 9:53 PM
> To: Chauhan, Madhav
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani ;
> Zanoni, Paulo R ; Vivi, Rodrigo
>
> Subject: Re: [Intel-gfx] [PATCH v5 11/13] drm/i915/ic
== 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_4518_full -> Patchwork_9726_full =
== Summary - WARNING ==
Minor unknown changes coming with Patc
From: Tvrtko Ursulin
Restore runtime PM state (via a newly added library function) when the
test which sets it up exit. This was we avoid running all subsequent sub-
tests in the aggressive runtime PM mode.
v2:
* Skip double restore. (Chris Wilson)
* Close previously leaked fd.
Signed-off-by:
Quoting Tvrtko Ursulin (2018-07-20 10:42:55)
> From: Tvrtko Ursulin
>
> Restore runtime PM state (via a newly added library function) when the
> test which sets it up exit. This was we avoid running all subsequent sub-
> tests in the aggressive runtime PM mode.
>
> v2:
> * Skip double restore.
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 suppress the assertion to get the test re-enabled.
Testcase: igt/drv_modul
== Series Details ==
Series: drm/i915: Only force GGTT coherency w/a on required chipsets
URL : https://patchwork.freedesktop.org/series/46915/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4518_full -> Patchwork_9727_full =
== Summary - FAILURE ==
Serious unknown change
On Fri, Jul 20, 2018 at 08:59:31AM +0100, 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
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 delay and the resulting coherency
issue.
Similar
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 counter.
>
> Changes in v2:
> - updated the title and commit message
>
== 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 -> Patchwork_9728 =
== Summary - SUCCESS ==
No regressions found.
External URL:
== Series Details ==
Series: drm/i915: Only force GGTT coherency w/a on required chipsets (rev2)
URL : https://patchwork.freedesktop.org/series/46915/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
82c30cd2b761 drm/i915: Only force GGTT coherency w/a on required chipsets
-:46: W
== Series Details ==
Series: drm/i915: Only force GGTT coherency w/a on required chipsets (rev2)
URL : https://patchwork.freedesktop.org/series/46915/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4518 -> Patchwork_9729 =
== Summary - SUCCESS ==
No regressions found.
On Thu, Jul 19, 2018 at 09:21:57PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The workaround was supposed to look at the plane destination
> coordinates. Currently it's looking at some mixture of src
> and dst coordinates that doesn't make sense. Fix it up.
>
> Signed-off-by: Ville Sy
From: Ville Syrjälä
Let's store the final plane stride in the plane state. This avoids
having to pick betwen the normal vs. rotated stride during hardware
programming. And once we get GTT remapping the plane stride will
no longer match the fb stride so we'll need a place to store it
anyway.
v2:
Runtime power management acts as a type of "wakelock" that code must
hold in order to access the device. Such a lock has all the ordering
issues of a regular lock, and so it would be convenient to use lockdep
to catch violations and cyclic deadlocks.
In the long run, it will be interesting to use
On Sandybridge, we need a workaround to wait for the CPU thread to wake
up before we are sure that we have enabled the GT power well. However,
we do see the errors being reported and failed reads returning spurious
results. To try and capture more details as it fails, promote the error
into a WARN
Quoting Chris Wilson (2018-07-20 12:10:16)
> Runtime power management acts as a type of "wakelock" that code must
> hold in order to access the device. Such a lock has all the ordering
> issues of a regular lock, and so it would be convenient to use lockdep
> to catch violations and cyclic deadlock
== Series Details ==
Series: drm/i915: GTT remapping for display (rev2)
URL : https://patchwork.freedesktop.org/series/46886/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e205f0cf0cc1 drm/i915: Fix glk/cnl display w/a #1175
c6a91ca3ac1f drm/i915: s/tile_offset/aligned_offset/
== Series Details ==
Series: drm/i915: GTT remapping for display (rev2)
URL : https://patchwork.freedesktop.org/series/46886/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Fix glk/cnl display w/a #1175
Okay!
Commit: drm/i915: s/tile_offset/aligned_offset/
Okay!
== Series Details ==
Series: drm/i915: GTT remapping for display (rev2)
URL : https://patchwork.freedesktop.org/series/46886/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4518 -> Patchwork_9730 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://pa
== Series Details ==
Series: drm/i915: Mark runtime_pm as a special class of lock
URL : https://patchwork.freedesktop.org/series/46938/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Mark runtime_pm as a special class of lock
-drivers/gpu/drm/i915/selftests/../i915
Time the runtime for emitting deep dependency tree, while keeping it
full of umpteen thousand requests.
Signed-off-by: Chris Wilson
---
tests/gem_exec_schedule.c | 87 +--
1 file changed, 74 insertions(+), 13 deletions(-)
diff --git a/tests/gem_exec_schedule.
== Series Details ==
Series: drm/i915: Mark runtime_pm as a special class of lock
URL : https://patchwork.freedesktop.org/series/46938/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4518 -> Patchwork_9731 =
== Summary - FAILURE ==
Serious unknown changes coming with Patc
From: Tvrtko Ursulin
Restore runtime PM state (via a newly added library function) when the
test which sets it up exit. This was we avoid running all subsequent sub-
tests in the aggressive runtime PM mode.
v2:
* Skip double restore. (Chris Wilson)
* Close previously leaked fd.
v3:
* Refacto
Quoting Tvrtko Ursulin (2018-07-20 13:12:22)
> From: Tvrtko Ursulin
>
> Restore runtime PM state (via a newly added library function) when the
> test which sets it up exit. This was we avoid running all subsequent sub-
> tests in the aggressive runtime PM mode.
>
> v2:
> * Skip double restore.
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
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, &dmar_drhd_units, list) \
> - if (drhd->ignored) {} else
> + for_each_if (!drhd
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
> > +++ b/drivers/g
== 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.
External
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 7998e70a3174..5809366ff9f0
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 be
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
--- a/drivers/gpu/drm/i915/intel_dis
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 com
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: Micha
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
--- a/drivers/gpu/dr
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
b/drivers/gpu/drm/i915/int
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 to
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 b
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
> >
== 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 p
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:
> > >
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;
> >>> + rps_set_power(dev_
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 /sys/bus/pci/dri
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 mayb
== 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 ==
S
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
---
drivers/
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 acce
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 thes
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
---
drivers/gpu/drm/i915/i9
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
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
Sign
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 wel
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 b/drivers/gpu/dr
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 values.
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 power
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
> >
== 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 coming
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 dela
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 /sys/bus/pci/dri
== 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: P
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 tha
== 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 intel_power_d
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 suppr
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;
+ rps_s
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 sequ
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 re
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.
>
> Signed
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 delay
== 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:
https://pat
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 tha
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: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 thrash
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
>
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 del
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, D
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 V
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
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 upd
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, DOWN_STREAM_PORT
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 processor
== 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:
https://
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:
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: Dhinak
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 act
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 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
> value
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
> value
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 | 6
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 max_v
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 counter
== 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 reg
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 no
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
>
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
---
drivers/gp
1 - 100 of 130 matches
Mail list logo
