On Tue, Jul 31, 2018 at 02:07:09PM -0700, Manasi Navare wrote:
> If a eDP panel supports both PSR2 and VDSC, our HW cannot
> support both at a time. Give priority to PSR2 if a requested
> resolution can be supported without compression else enable
> VDSC and keep PSR2 disabled.
what about PSR1 on
On Fri, Aug 03, 2018 at 04:40:56PM -0700, Souza, Jose wrote:
> On Fri, 2018-08-03 at 16:27 -0700, Rodrigo Vivi wrote:
> > One more CFL ID added to spec.
> >
>
> Reviewed-by: José Roberto de Souza
thanks, pushed... and patches to the rest of stack propagated.
>
> > Cc: José Roberto de Souza
== Series Details ==
Series: series starting with [01/20] drm: Let userspace check if driver
supports modeset
URL : https://patchwork.freedesktop.org/series/47917/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4635_full -> Patchwork_9896_full =
== Summary - WARNING ==
== Series Details ==
Series: drm/i915/gvt: fix memory leak in intel_vgpu_ioctl() (rev3)
URL : https://patchwork.freedesktop.org/series/47685/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4635_full -> Patchwork_9895_full =
== Summary - WARNING ==
Minor unknown changes
== Series Details ==
Series: drm/i915: Re-apply "Perform link quality check, unconditionally during
long pulse" (rev3)
URL : https://patchwork.freedesktop.org/series/47694/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4635_full -> Patchwork_9894_full =
== Summary -
== Series Details ==
Series: drm/i915: remove the unnecessary restriction for NV12 in
intel_framebuffer_init
URL : https://patchwork.freedesktop.org/series/47909/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4635_full -> Patchwork_9893_full =
== Summary - WARNING ==
== Series Details ==
Series: series starting with [1/4] drm/i915: kill
intel_display_power_well_is_enabled()
URL : https://patchwork.freedesktop.org/series/47908/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4635_full -> Patchwork_9892_full =
== Summary - WARNING ==
On Wed, 2018-08-08 at 16:19 +0200, Maarten Lankhorst wrote:
> This will make it easier to test PSR1 on PSR2 capable eDP machines.
>
> Changes since v1:
> - Remove I915_PSR_DEBUG_FORCE_PSR2, it did nothing, not sure forcing
> PSR2 would even work.
> - Handle NULL crtc in
== Series Details ==
Series: series starting with [01/20] drm: Let userspace check if driver
supports modeset
URL : https://patchwork.freedesktop.org/series/47917/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4635 -> Patchwork_9896 =
== Summary - SUCCESS ==
No
== Series Details ==
Series: series starting with [01/20] drm: Let userspace check if driver
supports modeset
URL : https://patchwork.freedesktop.org/series/47917/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm: Let userspace check if driver supports modeset
Okay!
== Series Details ==
Series: drm/i915: Restore user forcewake domains across suspend (rev2)
URL : https://patchwork.freedesktop.org/series/47894/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4635_full -> Patchwork_9891_full =
== Summary - WARNING ==
Minor unknown
== Series Details ==
Series: series starting with [01/20] drm: Let userspace check if driver
supports modeset
URL : https://patchwork.freedesktop.org/series/47917/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
bf1ef1e800de drm: Let userspace check if driver supports modeset
This 'if's will always be false because of previous changes so let's
drop then.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_drv.c | 12 +++-
drivers/gpu/drm/i915/intel_audio.c | 3 ---
drivers/gpu/drm/i915/intel_display.c | 3 ---
cdclk and rawclk are the 2 display clocks that can now be completed
not initialized when display is disabled.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_drv.c | 9 ++---
drivers/gpu/drm/i915/intel_runtime_pm.c | 3 +++
2 files changed, 9 insertions(+), 3
Although FBC helps save power it do not belongs to power management
also the cleanup was placed in i915_driver_unload() also not a good
place. intel_modeset_init()/intel_modeset_cleanup() are better places
also this will help make easy disable features that depends in
display being enabled in
Display is disabled in the beginning of the reset and re-enabled
afterreset each engine needed but if the display is disabled we
should not do it.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_irq.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
A few line above we have another definition of intel_update_rawclk()
keeping that one as the function is implemented in intel_cdclk.c.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_drv.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h
When loading the driver
i915_load_modeset_init()->intel_modeset_setup_hw_state() do the
counter part call of intel_power_domains_init_hw() calling
intel_display_set_init_power(false).
The problem is i915_load_modeset_init() is not executed when display
is disabled, so moving it to
POWER_DOMAIN_INIT is used when doing driver initialization or cleanup
because driver will touch a lot of registers and using
POWER_DOMAIN_INIT as a shortcut to power on or down every power well.
So here skiping the call to the functions that actually power on or
down power wells when domain is
No need to run i915_load_modeset_init() when num_pipes == 0 also
kms depends on things initialized in i915_load_modeset_init() so not
initializing it too. fbdev and audio have guards against
num_pipes == 0 but lets move it to the if block to make it explicit
to readers.
Also as planes, CRTCs,
IPC(Isochronous Priority Control not Inter-process communication btw)
is a display feature, so i915_load_modeset_init() is the right place
to initialize it.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
Right now RESET_PCH_HANDSHAKE_ENABLE is enabled all the times inside
of intel_power_domains_init_hw() and if PCH is NOP it is unsed in
i915_gem_init_hw().
So making skl_pch_reset_handshake() handle both cases and calling
it for the missing gens in intel_power_domains_init_hw().
Ivybridge have a
The only thing left from *_display_core_init when display is disabled
is the skl_pch_reset_handshake() that is already handling display
enabled and disabled. And *_display_core_uninit() also was left
to disable DC.
If more power savings is required, we could disable the power wells
that BIOS
IPC was only added in SKL+(actually we don't even enable for SKL due
WA) so without this change, driver was writing to a reserved bit.
Also check for the WA in intel_init_ipc() to avoid further writes to
ipc_enabled.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_pm.c | 8
i915_load_modeset_init() is a more suitable place than
i915_driver_load() as vblank is part of modeset.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_drv.c | 20 +++-
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git
Now that modeset stuff is not being initialized when display is
disabled nothing is holding a power well or runtime pm reference
when running live selftests. And IGT runs live selftests with
display on and off, causing the below warning:
[ 473.586533] Setting dangerous option live_selftests -
i915_load_modeset_init() and intel_modeset_cleanup() was initializing
and cleaning up things that is not display only.
This will make easy initialize driver without display block.
Also moving VLV/CHV/BYT czclk as it is a core clock used as base by
several other GPU blocks not only display,
With previous patches any of this warnings shows up but lets add then
so any other patch that breaks that can be caught by CI tests.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_irq.c | 14 ++
drivers/gpu/drm/i915/intel_hotplug.c | 2 ++
2 files changed,
Instead of have the same code spread into 4 platforms lets share it.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
GPU accelerators usually don't have display block or the display
driver part can be disabled when building driver(for servers it saves
some resources) so it is important let userspace check this
capability too.
Right now we are checking
drmModeGetResources()/drm_mode_getresources() for a error to
num_pipes is set to 0 if disable_display is set inside
intel_device_info_runtime_init() but when that happen PCH will
already be set in intel_detect_pch().
i915_driver_load()
i915_driver_init_early()
...
intel_detect_pch()
...
...
All other overlay functions(almost all other functions in i915) follow
intel_overlay_verb, so renaming the ones that do not match that.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 2 +-
On Wed, 2018-08-08 at 16:19 +0200, Maarten Lankhorst wrote:
> Currently tests modify i915.enable_psr and then do a modeset cycle
> to change PSR. We can write a value to i915_edp_psr_debug to force
> a certain PSR mode without a modeset.
>
> To retain compatibility with older userspace, we also
On Thu, Jul 26, 2018 at 04:02:53PM +0300, StanLis wrote:
> From: Stanislav Lisovskiy
>
> This was inspired, by a bugs like this:
>
> Bugzilla: https://bugs.freedesktop.org/93361
>
> In short, when TV advertises 12bpc, the refresh
> rate might get inaccurate causing some playback
> issues.
>
>
== Series Details ==
Series: drm/i915/gvt: fix memory leak in intel_vgpu_ioctl() (rev3)
URL : https://patchwork.freedesktop.org/series/47685/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4635 -> Patchwork_9895 =
== Summary - SUCCESS ==
No regressions found.
External
== Series Details ==
Series: drm/i915: Re-apply "Perform link quality check, unconditionally during
long pulse" (rev3)
URL : https://patchwork.freedesktop.org/series/47694/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4635 -> Patchwork_9894 =
== Summary - SUCCESS ==
Em Qua, 2018-08-08 às 22:22 +, Patchwork escreveu:
> == Series Details ==
>
> Series: series starting with [1/4] drm/i915: kill
> intel_display_power_well_is_enabled()
> URL : https://patchwork.freedesktop.org/series/47908/
> State : warning
>
> == Summary ==
>
> $ dim checkpatch
== Series Details ==
Series: drm/i915: remove the unnecessary restriction for NV12 in
intel_framebuffer_init
URL : https://patchwork.freedesktop.org/series/47909/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4635 -> Patchwork_9893 =
== Summary - SUCCESS ==
No
Em Qua, 2018-08-08 às 15:22 -0700, Souza, Jose escreveu:
> On Wed, 2018-08-08 at 15:16 -0700, Paulo Zanoni wrote:
> > Use the same coding pattern as we use in the other functions of the
> > same file: just call lookup_power_well() directly in the only
> > caller.
> >
> > Cc: Imre Deak
> >
On Wed, 2018-08-08 at 15:16 -0700, Paulo Zanoni wrote:
> Use the nice helper function to make the implementation simpler.
>
Reviewed-by: José Roberto de Souza
> Cc: Imre Deak
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_runtime_pm.c | 9 ++---
> 1 file changed, 2
Am August 7, 2018 7:33:12 PM UTC schrieb Lyude Paul :
>On Mon, 2018-08-06 at 12:25 +0200, Jan-Marek Glogowski wrote:
>> This re-applies the workaround for "some DP sinks, [which] are a
>> little nuts" from commit 1a36147bb939 ("drm/i915: Perform link
>> quality check unconditionally during long
The 'sparse' variable may leak when return in function
intel_vgpu_ioctl(), and this patch fix this.
Signed-off-by: Yi Wang
Reviewed-by: Jiang Biao
---
v2: fix a double-free error. Thanks to Zhenyu Wang.
drivers/gpu/drm/i915/gvt/kvmgt.c | 8 ++--
1 file changed, 6 insertions(+), 2
> On 2018.08.03 08:41:19 +0800, Yi Wang wrote:
> > The 'sparse' variable may leak when return in function
> > intel_vgpu_ioctl(), and this patch fixes this.
> >
> > Signed-off-by: Yi Wang
> > Reviewed-by: Jiang Biao
> > ---
> > drivers/gpu/drm/i915/gvt/kvmgt.c | 3 +++
> > 1 file changed, 3
Hi Sean,
In my work project, we have a requirement to play HDCP protected DASH
streams on Chrome on Android phones which fails right now(presumably due to
missing HDCP support, since we can reproduce this issue only on chrome on
Linux, desktop as well as android) and was wondering if your patch
This re-applies the workaround for "some DP sinks, [which] are a
little nuts" from commit 1a36147bb939 ("drm/i915: Perform link
quality check unconditionally during long pulse").
It makes the secondary AOC E2460P monitor connected via DP to an
acer Veriton N4640G usable again.
This hunk was
== Series Details ==
Series: drm/i915: remove the unnecessary restriction for NV12 in
intel_framebuffer_init
URL : https://patchwork.freedesktop.org/series/47909/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b513210d0543 drm/i915: remove the unnecessary restriction for NV12
== Series Details ==
Series: series starting with [1/4] drm/i915: kill
intel_display_power_well_is_enabled()
URL : https://patchwork.freedesktop.org/series/47908/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4635 -> Patchwork_9892 =
== Summary - SUCCESS ==
No
== Series Details ==
Series: series starting with [1/4] drm/i915: kill
intel_display_power_well_is_enabled()
URL : https://patchwork.freedesktop.org/series/47908/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
94cddb6f9752 drm/i915: kill intel_display_power_well_is_enabled()
On Wed, 2018-08-08 at 15:16 -0700, Paulo Zanoni wrote:
> Use the same coding pattern as we use in the other functions of the
> same file: just call lookup_power_well() directly in the only caller.
>
> Cc: Imre Deak
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_runtime_pm.c |
framebuffer for NV12 requires the pitch to the multiplier of 4, instead of the
width. This patch corrects it.
For instance, a 480p video, whose width and pitch are 854 and 896 respectively,
is excluded for NV12 plane so far.
Signed-off-by: Dongseong Hwang
Cc: Chandra Konduru
Cc: Vidya Srinivas
None of the current lookup_power_well() callers are actually checking
for NULL return values, they all just use the pointer right away.
Replacing these theoretical segfaults with BUG()s at least makes our
code a little more explicit to the reader.
We can only hit this NULL/BUG() condition if we
There's no need for that forward declaration.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 32 ++--
1 file changed, 14 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
Use the nice helper function to make the implementation simpler.
Cc: Imre Deak
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
Use the same coding pattern as we use in the other functions of the
same file: just call lookup_power_well() directly in the only caller.
Cc: Imre Deak
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 20 +++-
1 file changed, 3 insertions(+), 17
== Series Details ==
Series: drm/i915: Restore user forcewake domains across suspend (rev2)
URL : https://patchwork.freedesktop.org/series/47894/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4635 -> Patchwork_9891 =
== Summary - SUCCESS ==
No regressions found.
On suspend, we cancel the automatic forcewake and clear all other sources
of forcewake so the machine can sleep before we do suspend. However, we
expose the forcewake to userspace (only via debugfs, but nevertheless we
do) and want to restore that upon resume or else our accounting will be
off and
== Series Details ==
Series: drm/i915: Restore user forcewake domains across suspend
URL : https://patchwork.freedesktop.org/series/47894/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4633_full -> Patchwork_9887_full =
== Summary - FAILURE ==
Serious unknown changes
== Series Details ==
Series: series starting with [1/2] drm/i915: Allow control of PSR at runtime
through debugfs, v5
URL : https://patchwork.freedesktop.org/series/47888/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4633_full -> Patchwork_9886_full =
== Summary -
== Series Details ==
Series: drm/i915/psr: Add PSR mode/revision to debugfs
URL : https://patchwork.freedesktop.org/series/47902/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4635 -> Patchwork_9890 =
== Summary - FAILURE ==
Serious unknown changes coming with
Quoting Chris Wilson (2018-08-08 19:53:33)
> Quoting Tvrtko Ursulin (2018-08-08 13:40:41)
> >
> > On 07/08/2018 16:02, Chris Wilson wrote:
> > > Quoting Tvrtko Ursulin (2018-08-07 10:08:28)
> > >>
> > >> On 07/08/2018 08:29, Chris Wilson wrote:
> > >>> + /*
> > >>> + * The active request
== Series Details ==
Series: drm/i915/psr: Add PSR mode/revision to debugfs
URL : https://patchwork.freedesktop.org/series/47902/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
35d0453e2699 drm/i915/psr: Add PSR mode/revision to debugfs
-:21: CHECK:PARENTHESIS_ALIGNMENT:
Log the PSR mode/revision (PSR1 or PSR2) in the debugfs file
i915_edp_psr_status.
Suggested-by: Dhinakaran Pandiyan
Signed-off-by: Azhar Shaikh
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
Quoting Tvrtko Ursulin (2018-08-08 13:40:41)
>
> On 07/08/2018 16:02, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-08-07 10:08:28)
> >>
> >> On 07/08/2018 08:29, Chris Wilson wrote:
> >>> + /*
> >>> + * The active request is now effectively the start of a new client
> >>> +
Hi Daniel,
We are in beta for v18. I expect release in September.
I don't think we have to consider users who run older Kodi versions on
systems with latest kernels. The feature the patch would disable won't
make Kodi completely unusable when absent. I'd say you can merge
the patch short after
Hi Rainer,
Awesome, thanks a lot for doing this! Any idea for when this will ship
in a release, and for how long your users are generally using older
releases? Just to have a rough indication for when we could attempt to
merge this patch here.
Cheers, Daniel
On Wed, Aug 8, 2018 at 5:35 PM,
== Series Details ==
Series: igt/drv_missed_irq: Skip if the kernel reports no rings available to
test
URL : https://patchwork.freedesktop.org/series/47873/
State : success
== Summary ==
= CI Bug Log - changes from IGT_4588_full -> IGTPW_1690_full =
== Summary - SUCCESS ==
No regressions
== Series Details ==
Series: series starting with [1/3] drm/i915: Warn if we hit the timeout for
wait-for-idle
URL : https://patchwork.freedesktop.org/series/47876/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4633_full -> Patchwork_9884_full =
== Summary - SUCCESS ==
== Series Details ==
Series: Improve crc-core driver interface (rev10)
URL : https://patchwork.freedesktop.org/series/45246/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4633 -> Patchwork_9889 =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_9889
== Series Details ==
Series: Improve crc-core driver interface (rev10)
URL : https://patchwork.freedesktop.org/series/45246/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm: crc: Introduce verify_crc_source callback
Okay!
Commit: drm: crc: Introduce get_crc_sources
Finally we removed this code from Kodi.
Regards,
Rainer
On Tue, Jun 14, 2016 at 11:02 AM, Daniel Vetter wrote:
> Somehow this escaped us, this is a KMS ioctl which should only be used
> by the master (which is the thing that's also in control of kms
> resources). Everything else is bound to
Quoting Tvrtko Ursulin (2018-08-08 16:14:24)
> From: Tvrtko Ursulin
>
> Keep the user interrupt enabled and emit intel_engine_notify tracepoint
> every time as long as it is enabled.
>
> Premise is that if someone is listening, they want to see interrupts
> logged.
>
> We use tracepoint
This patch implements get_crc_sources callback, which returns list of
all the crc sources supported by driver in current platform.
Changes Since V1:
- move sources list per-crtc
- init sources-list only for gen3
Changes Since V2:
- Adopt to driver style
- Address other review comments from
== Series Details ==
Series: drm/i915: Restore user forcewake domains across suspend
URL : https://patchwork.freedesktop.org/series/47894/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4633 -> Patchwork_9887 =
== Summary - SUCCESS ==
No regressions found.
External
== Series Details ==
Series: drm/i915/tracing: Enable user interrupts while intel_engine_notify is
active
URL : https://patchwork.freedesktop.org/series/47897/
State : failure
== Summary ==
Applying: drm/i915/tracing: Enable user interrupts while intel_engine_notify is
active
Using index
From: Tvrtko Ursulin
Keep the user interrupt enabled and emit intel_engine_notify tracepoint
every time as long as it is enabled.
Premise is that if someone is listening, they want to see interrupts
logged.
We use tracepoint (de)registration callbacks to enable user interrupts on
all devices
Normalize the variance to stddev, and remove some redundant steps in
computing the time from itself.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/perf_pmu.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/tests/perf_pmu.c
Our observation is that the systematic error is proportional to the
number of iterations we perform; the suspicion is that it directly
correlates with the number of sleeps. Reduce the number of iterations,
to try and keep the error in check.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
On suspend, we cancel the automatic forcewake and clear all other sources
of forcewake so the machine can sleep before we do suspend. However, we
expose the forcewake to userspace (only via debugfs, but nevertheless we
do) and want to restore that upon resume or else our accounting will be
off and
== Series Details ==
Series: series starting with [1/2] drm/i915: Allow control of PSR at runtime
through debugfs, v5
URL : https://patchwork.freedesktop.org/series/47888/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4633 -> Patchwork_9886 =
== Summary - SUCCESS ==
No
== Series Details ==
Series: series starting with [1/2] drm/i915: Allow control of PSR at runtime
through debugfs, v5
URL : https://patchwork.freedesktop.org/series/47888/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Allow control of PSR at runtime through
== Series Details ==
Series: series starting with [1/2] drm/i915: Allow control of PSR at runtime
through debugfs, v5
URL : https://patchwork.freedesktop.org/series/47888/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
156e45d20493 drm/i915: Allow control of PSR at runtime
Currently tests modify i915.enable_psr and then do a modeset cycle
to change PSR. We can write a value to i915_edp_psr_debug to force
a certain PSR mode without a modeset.
To retain compatibility with older userspace, we also still allow
the override through the module parameter, and add some
Quoting Tvrtko Ursulin (2018-08-08 13:57:56)
>
> On 08/08/2018 13:47, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-08-08 13:38:53)
> >>
> >> On 08/08/2018 12:31, Chris Wilson wrote:
> >>>igt_until_timeout(5) {
> >>> - struct drm_i915_gem_execbuffer2 execbuf = { };
>
This will make it easier to test PSR1 on PSR2 capable eDP machines.
Changes since v1:
- Remove I915_PSR_DEBUG_FORCE_PSR2, it did nothing, not sure forcing
PSR2 would even work.
- Handle NULL crtc in intel_psr_set_debugfs_mode. (dhnkrn)
Signed-off-by: Maarten Lankhorst
---
== Series Details ==
Series: drm/i915: Missed interrupt simulation is no more, tell the world
URL : https://patchwork.freedesktop.org/series/47875/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4632_full -> Patchwork_9883_full =
== Summary - WARNING ==
Minor unknown
== Series Details ==
Series: drm/i915: Warn if we hit the timeout for wait-for-idle (rev2)
URL : https://patchwork.freedesktop.org/series/47869/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4632_full -> Patchwork_9882_full =
== Summary - WARNING ==
Minor unknown
On 08/08/2018 13:47, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-08-08 13:38:53)
On 08/08/2018 12:31, Chris Wilson wrote:
We can keep the original batch around and avoid recreating it between
reset iterations to focus on the impact of resets.
Signed-off-by: Chris Wilson
Cc: Tvrtko
+Joonas
On 08/08/2018 13:42, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-08-08 13:13:08)
On 26/06/2018 12:48, Chris Wilson wrote:
It's just that this about the third time this has been raised in the
last couple of weeks with the other two requests being from a generic
tooling pov
On 07/08/2018 16:57, Chris Wilson wrote:
Create and export an amdgpu bo into i915 so that we can try and
invalidate the i915_bo->pages from inside the shrinker, teaching lockdep
about that linkage.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Daniel Vetter
---
Quoting Tvrtko Ursulin (2018-08-08 13:38:53)
>
> On 08/08/2018 12:31, Chris Wilson wrote:
> > We can keep the original batch around and avoid recreating it between
> > reset iterations to focus on the impact of resets.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> >
On 07/08/2018 16:44, Chris Wilson wrote:
Link a vgem dmabuf into an i915 bo and then ask the i915 shrinker to
purge/invalidate its pages. This should establish the lockdep link from
the fs_reclaim shrinker section to whatever locks are used to
acquire/release dmabuf mappings; if any are
Quoting Tvrtko Ursulin (2018-08-08 13:13:08)
>
> On 26/06/2018 12:48, Chris Wilson wrote:
> > It's just that this about the third time this has been raised in the
> > last couple of weeks with the other two requests being from a generic
> > tooling pov (Eric Anholt for gnome-shell tweaking, and
== Series Details ==
Series: ICL DSI CMD MODE
URL : https://patchwork.freedesktop.org/series/47885/
State : failure
== Summary ==
Applying: drm/i915/icl: Define utility pin ctrl register bits
Applying: drm/i915/icl: Config utility pin for DSI
error: sha1 information is lacking or useless
On 07/08/2018 16:02, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-08-07 10:08:28)
On 07/08/2018 08:29, Chris Wilson wrote:
+ /*
+ * The active request is now effectively the start of a new client
+ * stream, so give it the equivalent small priority bump to prevent
+ *
On 08/08/2018 12:31, Chris Wilson wrote:
We can keep the original batch around and avoid recreating it between
reset iterations to focus on the impact of resets.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/gem_eio.c | 30 +-
1 file changed, 17
This patch implements a helper function for enabling
or disabling TE interrupts.
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/icl_dsi.c | 20
drivers/gpu/drm/i915/intel_drv.h | 2 ++
2 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/i915/icl_dsi.c
If DSI is operating in command mode, then display
engine won't be receiving VBLANK interrupt instead
of that Tearing Event(TE) interrupt will be received.
So in this scenario, we need to enable/disable TE interrupt
rather than VBLANK interrupts.
Signed-off-by: Madhav Chauhan
---
This patch calculate HOTAL and VTOTAL value to be programmed
when DSI is operating in command mode as per BSPEC.
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/icl_dsi.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/icl_dsi.c
In DSI command mode, for sending the frame to panel
DSI controller need to issue the command unlike in
DSI video mode. This patch does the same.
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/icl_dsi.c | 20
1 file changed, 20 insertions(+)
diff --git
While enabling DSI transcoder, TE interrupts need to
be unmasked also they need to be cleared when TE interrupts
are received. This patch does same by programming DSI interrupt
specific registers.
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/i915_irq.c | 2 ++
1 - 100 of 152 matches
Mail list logo
