== Series Details ==
Series: series starting with [v6,1/2] drm: Add connector property to limit max
bpc
URL : https://patchwork.freedesktop.org/series/49825/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4835_full -> Patchwork_10208_full =
== Summary - WARNING ==
Minor
There are two copies of the same code called from long and short
pulse handlers.
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/intel_dp.c | 59 +++--
1 file changed, 22 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c
The intel_dp->detect_done flag is no more useful. Pull
intel_dp_long_pulse() into the lone caller,
Cc: Jani Nikula
Cc: Ville Syrjälä
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/intel_dp.c | 63 +---
drivers/gpu/drm/i915/intel_drv.h | 1 -
2
commit '3cf71bc9904d ("drm/i915: Re-apply "Perform link quality check,
unconditionally during long pulse"")' applies a work around for monitors
that don't signal link loss. Limit this only for external displays as
eDP features like PSR when active will have the link turned off and the
driver ends u
Comment claims link needs to be retrained because the connected sink raised
a long pulse to indicate link loss. If the sink did so,
intel_dp_hotplug() would have handled link retraining. Looking at the
logs in Bugzilla referenced in commit '3cf71bc9904d ("drm/i915: Re-apply
Perform link quality che
This way all short pulse handlers except MST are in one place.
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/intel_dp.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 123c2eafafab..03
== Series Details ==
Series: series starting with [1/5] drm/i915/dp: Fix link retraining comment in
intel_dp_long_pulse()
URL : https://patchwork.freedesktop.org/series/49827/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b03548d38052 drm/i915/dp: Fix link retraining comment i
Hi,
Here's more gvt fixes for 4.19. Two more BXT fixes from Colin,
one srcu locking fix and one fix for GGTT clear when destroy vGPU.
p.s, I'll start my vacation from tomorrow. Wang Zhi will cover for gvt pull.
Thanks
--
The following changes since commit 792fab2c0d45758ad3d187bd252570d2bb627fa
== Series Details ==
Series: series starting with [1/5] drm/i915/dp: Fix link retraining comment in
intel_dp_long_pulse()
URL : https://patchwork.freedesktop.org/series/49827/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4835 -> Patchwork_10209 =
== Summary - FAILURE ==
Quoting José Roberto de Souza (2018-09-17 22:22:44)
> All DRM_CLIENT capabilities are tied to KMS support, so returning
> -EOPNOTSUPP when KMS is not supported.
>
> v2: returning -EOPNOTSUPP(same value as posix ENOTSUP and available
> in uapi) instead of -ENOTSUPP
>
> Cc: Chris Wilson
> Signed-o
On 17/09/2018 16:52, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-09-17 16:46:18)
From: Tvrtko Ursulin
Move a really small test that invalid context is rejected under the
gem_ctx_exec umbrella.
v2:
* And actually fix the test so it does what it claims. And add more
variety in the i
Quoting Tvrtko Ursulin (2018-09-18 10:38:44)
>
> On 17/09/2018 16:52, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-09-17 16:46:18)
> >> From: Tvrtko Ursulin
> >>
> >> Move a really small test that invalid context is rejected under the
> >> gem_ctx_exec umbrella.
> >>
> >> v2:
> >> * And
On 18/09/2018 10:44, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-09-18 10:38:44)
On 17/09/2018 16:52, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-09-17 16:46:18)
From: Tvrtko Ursulin
Move a really small test that invalid context is rejected under the
gem_ctx_exec umbrella.
v2:
Quoting Tvrtko Ursulin (2018-09-18 10:59:11)
>
> On 18/09/2018 10:44, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-09-18 10:38:44)
> >>
> >> On 17/09/2018 16:52, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2018-09-17 16:46:18)
> From: Tvrtko Ursulin
>
> Move a really
Quoting Chris Wilson (2018-09-18 11:02:09)
> Quoting Tvrtko Ursulin (2018-09-18 10:59:11)
> >
> > On 18/09/2018 10:44, Chris Wilson wrote:
> > > Quoting Tvrtko Ursulin (2018-09-18 10:38:44)
> > >> Can I say it is testing the i915_execbuffer2_set_context_id as well by
> > >> knowing underlying ABI
After schedule() returns 0, we must do one last check of COND to
determine the reason for the wakeup with 0 jiffies remaining before
reporting the timeout -- otherwise we may lose the signal due to
scheduler delays.
References: https://bugs.freedesktop.org/show_bug.cgi?id=106690
Signed-off-by: Chr
Both the .enable_signaling and .release of the null syncobj fence
can be replaced by the default callbacks for a small reduction in code
size.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_syncobj.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj
On 18/09/2018 11:03, Chris Wilson wrote:
Quoting Chris Wilson (2018-09-18 11:02:09)
Quoting Tvrtko Ursulin (2018-09-18 10:59:11)
On 18/09/2018 10:44, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-09-18 10:38:44)
Can I say it is testing the i915_execbuffer2_set_context_id as well by
knowi
Quoting Tvrtko Ursulin (2018-09-18 11:33:14)
>
> On 18/09/2018 11:03, Chris Wilson wrote:
> > Quoting Chris Wilson (2018-09-18 11:02:09)
> >> Quoting Tvrtko Ursulin (2018-09-18 10:59:11)
> >>>
> >>> On 18/09/2018 10:44, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-09-18 10:38:44)
>
== Series Details ==
Series: series starting with [1/2] drm: Use default dma_fence hooks where
possible for null syncobj
URL : https://patchwork.freedesktop.org/series/49834/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4836 -> Patchwork_10210 =
== Summary - FAILURE ==
Quoting Ville Syrjala (2018-09-17 18:14:14)
> From: Ville Syrjälä
>
> Clean up some cases where we're dealing with GTT pages instead of
> system pages to use I915_GTT_PAGE_SIZE instead of PAGE_SHIT. So
> just replace the the shifts with mul/div as appropriate. These
> are the easy ones, the rest
From: Tvrtko Ursulin
Move a really small test that invalid context is rejected under the
gem_ctx_exec umbrella.
v2:
* And actually fix the test so it does what it claims. And add more
variety in the invalid context id's it tests with. (Chris Wilson)
v3:
* Rename the test as basic.
* Limit
Quoting Tvrtko Ursulin (2018-09-18 11:59:25)
> From: Tvrtko Ursulin
>
> Move a really small test that invalid context is rejected under the
> gem_ctx_exec umbrella.
>
> v2:
> * And actually fix the test so it does what it claims. And add more
>variety in the invalid context id's it tests wi
From: Tvrtko Ursulin
Move a really small test that invalid context is rejected under the
gem_ctx_exec umbrella.
v2:
* And actually fix the test so it does what it claims. And add more
variety in the invalid context id's it tests with. (Chris Wilson)
v3:
* Rename the test as basic.
* Limit
From: Ville Syrjälä
Smatch reports:
../drivers/gpu/drm/i915/intel_sprite.c:1192 skl_plane_check_fb() warn: was ||
intended here instead of &&?
Obviously smatch is correct here since we're trying to check if we're
using either of the ccs modifiers. Since we now have is_ccs_modifier()
let's use i
From: Lionel Landwerlin
Verify that the per-context dynamic SSEU uAPI works as expected.
To achieve that, in the absence of a better mechamism, we read the value
of PWR_CLK_STATE register, or use MI_SET_PREDICATE on platforms before
Cannonlake.
This register is written to by the GPU on context
== Series Details ==
Series: drm/i915: Fix logic fumble in rotation vs. ccs check
URL : https://patchwork.freedesktop.org/series/49840/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4836 -> Patchwork_10211 =
== Summary - WARNING ==
Minor unknown changes coming with Patch
From: Tvrtko Ursulin
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
r
From: Ville Syrjälä
commit 4e0b83a567e2 ("drm/i915: Extract per-platform plane->check()
functions") removed the plane max stride check for sprite planes.
I was going to add it back when introducing GTT remapping for the
display, but after further thought it seems better to re-introduce
it separat
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev5)
URL : https://patchwork.freedesktop.org/series/48194/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1edac7cf7ca4 drm/i915/execlists: Move RPCS setup to context pin
f72f696a198a drm/i915: Record the
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev5)
URL : https://patchwork.freedesktop.org/series/48194/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915/execlists: Move RPCS setup to context pin
Okay!
Commit: drm/i915: Record the sseu co
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev5)
URL : https://patchwork.freedesktop.org/series/48194/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4836 -> Patchwork_10212 =
== Summary - SUCCESS ==
No regressions found.
External URL:
h
== Series Details ==
Series: drm/i915: Fix logic fumble in rotation vs. ccs check
URL : https://patchwork.freedesktop.org/series/49840/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4836_full -> Patchwork_10211_full =
== Summary - WARNING ==
Minor unknown changes coming
On 18/09/2018 14:10, Ville Syrjala wrote:
From: Ville Syrjälä
Smatch reports:
../drivers/gpu/drm/i915/intel_sprite.c:1192 skl_plane_check_fb() warn: was || intended
here instead of &&?
Obviously smatch is correct here since we're trying to check if we're
using either of the ccs modifiers. Si
== Series Details ==
Series: drm/i915: Check fb stride against plane max stride
URL : https://patchwork.freedesktop.org/series/49844/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4837 -> Patchwork_10213 =
== Summary - SUCCESS ==
No regressions found.
External URL:
h
On Tue, Sep 18, 2018 at 04:05:58PM +0100, Tvrtko Ursulin wrote:
>
> On 18/09/2018 14:10, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Smatch reports:
> > ../drivers/gpu/drm/i915/intel_sprite.c:1192 skl_plane_check_fb() warn: was
> > || intended here instead of &&?
> >
> > Obviously sma
Did the patch this references get pushed? I saw it fly by and I thought we had
decided not to pull it in
On Tue, 2018-09-18 at 00:20 -0700, Dhinakaran Pandiyan wrote:
> commit '3cf71bc9904d ("drm/i915: Re-apply "Perform link quality check,
> unconditionally during long pulse"")' applies a work aro
On Tue, Sep 18, 2018 at 12:20:05AM -0700, Dhinakaran Pandiyan wrote:
> Comment claims link needs to be retrained because the connected sink raised
> a long pulse to indicate link loss. If the sink did so,
> intel_dp_hotplug() would have handled link retraining. Looking at the
> logs in Bugzilla ref
On Tue, Sep 18, 2018 at 11:33:24AM -0400, Lyude Paul wrote:
> Did the patch this references get pushed? I saw it fly by and I thought we had
> decided not to pull it in
ops, I created the confusion. Sorry.
What I decided that week was to not pull to drm-intel-fixes until Ville
or Jani acking. But
On Tue, Sep 18, 2018 at 03:33:49PM +0800, Zhenyu Wang wrote:
>
> Hi,
>
> Here's more gvt fixes for 4.19. Two more BXT fixes from Colin,
> one srcu locking fix and one fix for GGTT clear when destroy vGPU.
pulled, thanks.
>
> p.s, I'll start my vacation from tomorrow. Wang Zhi will cover for gv
On Sun, Sep 16, 2018 at 01:45:23PM +0530, Uma Shankar wrote:
> This is how a typical display color hardware pipeline looks like:
> +---+
> |RAM|
> | +--++-++-+ |
> | | FB 1 || FB
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev5)
URL : https://patchwork.freedesktop.org/series/48194/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4836_full -> Patchwork_10212_full =
== Summary - FAILURE ==
Serious unknown changes coming
Hi,
On Sun, Sep 16, 2018 at 01:45:25PM +0530, Uma Shankar wrote:
> Add Plane Degamma as a blob property and plane degamma size as
> a range property.
>
> v2: Rebase
>
> v3: Fixed Sean, Paul's review comments. Moved the property from
> mode_config to drm_plane. Created a helper function to instan
Use the newly added "max bpc" connector property to limit pipe bpp.
V3: Use drm_connector_state to access the "max bpc" property
V4: Initialize the drm property, add suuport to DP(Ville)
V5: Use the property in the connector and fix CI failure(Ville)
V6: Use the core function to attach max_bpc pro
At times 12bpc HDMI cannot be driven due to faulty cables, dongles
level shifters etc. To workaround them we may need to drive the output
at a lower bpc. Currently the user space does not have a way to limit
the bpc. The default bpc to be programmed is decided by the driver and
is run against conne
On Mon, Sep 17, 2018 at 09:52:08PM -0700, Radhakrishna Sripada wrote:
> At times 12bpc HDMI cannot be driven due to faulty cables, dongles
> level shifters etc. To workaround them we may need to drive the output
> at a lower bpc. Currently the user space does not have a way to limit
> the bpc. The
== Series Details ==
Series: series starting with [v7,1/2] drm: Add connector property to limit max
bpc
URL : https://patchwork.freedesktop.org/series/49857/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm: Add connector property to limit max bpc
+
Generated using make headers_install from the drm-next
tree - git://anongit.freedesktop.org/drm/drm
branch - drm-next
commit - 2dc7bad71cd310dc94d1c9907909324dd2b0618f
The changes were as follows :-
core: (drm.h, drm_fourcc.h, drm_mode.h)
- Added client capabilities for ASPECT_RATIO and WRI
== Series Details ==
Series: series starting with [v7,1/2] drm: Add connector property to limit max
bpc
URL : https://patchwork.freedesktop.org/series/49857/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4839 -> Patchwork_10214 =
== Summary - SUCCESS ==
No regressions f
$ sed -i s/I915_FORMAT_MOD_/DRM_FORMAT_MOD_INTEL_/g $(git grep -l
I915_FORMAT_MOD_)
$ git checkout include/uapi/drm/drm_fourcc.h
Signed-off-by: Eric Engestrom
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 12 +-
drivers/gpu/drm/i915/intel_display.c | 128 +++---
drivers/
On Tue, 2018-09-18 at 16:10 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Smatch reports:
> ../drivers/gpu/drm/i915/intel_sprite.c:1192 skl_plane_check_fb()
> warn: was || intended here instead of &&?
>
> Obviously smatch is correct here since we're trying to check if we're
> using eithe
== Series Details ==
Series: drm/i915: Check fb stride against plane max stride
URL : https://patchwork.freedesktop.org/series/49844/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4837_full -> Patchwork_10213_full =
== Summary - WARNING ==
Minor unknown changes coming wi
All DRM_CLIENT capabilities are tied to KMS support, so returning
-EOPNOTSUPP when KMS is not supported.
v2: returning -EOPNOTSUPP(same value as posix ENOTSUP and available
in uapi) instead of -ENOTSUPP
v3: adding comments about the feature requirement about capabilities
Cc: Chris Wilson
Signed
On Tue, Sep 18, 2018 at 10:48:09AM -0700, José Roberto de Souza wrote:
> All DRM_CLIENT capabilities are tied to KMS support, so returning
> -EOPNOTSUPP when KMS is not supported.
>
> v2: returning -EOPNOTSUPP(same value as posix ENOTSUP and available
> in uapi) instead of -ENOTSUPP
>
> v3: addin
Use the newly added "max bpc" connector property to limit pipe bpp.
V3: Use drm_connector_state to access the "max bpc" property
V4: Initialize the drm property, add suuport to DP(Ville)
V5: Use the property in the connector and fix CI failure(Ville)
V6: Use the core function to attach max_bpc pro
At times 12bpc HDMI cannot be driven due to faulty cables, dongles
level shifters etc. To workaround them we may need to drive the output
at a lower bpc. Currently the user space does not have a way to limit
the bpc. The default bpc to be programmed is decided by the driver and
is run against conne
A few line above we have another definition of intel_update_rawclk()
keeping that one as the function is implemented in intel_cdclk.c.
Reviewed-by: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_drv.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/g
Instead of have the same code spread into 4 platforms lets share it.
BXT do not have a PCH so here also handling this case by unseting
RESET_PCH_HANDSHAKE_ENABLE.
v2(Rodrigo):
- renamed to intel_pch_reset_handshake()
- added comment about why BXT need the bit to be unset
v3(Rodrigo and Ville):
-
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 removing the uncessary dev_priv->ipc_enabled = false; as now
gens without IPC will not have IPC enabled.
v2(Rodrigo):
- moved the new handling of WA #0477 to
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 dif
symmetric_memory do not change after initialization so lets just set
ipc_enabled once for this WA.
Cc: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_pm.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/inte
SKL has IPC but it should not be set according to the WA, so lets
just mark as it don't have it to simply the code and avoid
unnecessary MMIO writes at every call to intel_enable_ipc().
Cc: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_pci.c | 2 ++
drivers/gpu
On Mon, Sep 17, 2018 at 08:34:36PM +0300, Ville Syrjälä wrote:
> On Mon, Sep 17, 2018 at 10:16:05AM -0700, Rodrigo Vivi wrote:
> > On Mon, Sep 17, 2018 at 06:15:03PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > SDVO encoders can have multiple different types of outputs hangin
== Series Details ==
Series: drm: Return -EOPNOTSUPP in drm_setclientcap() when driver do not
support KMS (rev2)
URL : https://patchwork.freedesktop.org/series/49816/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4839 -> Patchwork_10215 =
== Summary - FAILURE ==
Serious
== Series Details ==
Series: series starting with [v8,1/2] drm: Add connector property to limit max
bpc
URL : https://patchwork.freedesktop.org/series/49868/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm: Add connector property to limit max bpc
+drivers/gpu/drm/drm_ato
On Tue, Sep 18, 2018 at 11:11:15AM -0700, Radhakrishna Sripada wrote:
> Use the newly added "max bpc" connector property to limit pipe bpp.
>
> V3: Use drm_connector_state to access the "max bpc" property
> V4: Initialize the drm property, add suuport to DP(Ville)
> V5: Use the property in the con
On Tue, Sep 18, 2018 at 11:11:14AM -0700, Radhakrishna Sripada wrote:
> At times 12bpc HDMI cannot be driven due to faulty cables, dongles
> level shifters etc. To workaround them we may need to drive the output
> at a lower bpc. Currently the user space does not have a way to limit
> the bpc. The
Thanks Imre for your review comments. Please find the comments below:
On Fri, Sep 14, 2018 at 01:55:00PM +0300, Imre Deak wrote:
> On Tue, Sep 11, 2018 at 05:56:01PM -0700, Manasi Navare wrote:
> > On Icelake, a separate power well PG2 is created for
> > VDSC engine used for eDP/MIPI DSI. This pat
On Tue, 2018-09-18 at 08:51 -0700, Rodrigo Vivi wrote:
> On Tue, Sep 18, 2018 at 12:20:05AM -0700, Dhinakaran Pandiyan wrote:
> > Comment claims link needs to be retrained because the connected
> > sink raised
> > a long pulse to indicate link loss. If the sink did so,
> > intel_dp_hotplug() would
On Tue, Sep 18, 2018 at 11:10:10AM -0700, José Roberto de Souza wrote:
> Instead of have the same code spread into 4 platforms lets share it.
> BXT do not have a PCH so here also handling this case by unseting
> RESET_PCH_HANDSHAKE_ENABLE.
>
> v2(Rodrigo):
> - renamed to intel_pch_reset_handshake(
== Series Details ==
Series: series starting with [v8,1/2] drm: Add connector property to limit max
bpc
URL : https://patchwork.freedesktop.org/series/49868/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4840 -> Patchwork_10216 =
== Summary - SUCCESS ==
No regressions f
On Tue, Sep 18, 2018 at 12:04:35PM -0700, Manasi Navare wrote:
> Thanks Imre for your review comments. Please find the comments below:
>
> On Fri, Sep 14, 2018 at 01:55:00PM +0300, Imre Deak wrote:
> > On Tue, Sep 11, 2018 at 05:56:01PM -0700, Manasi Navare wrote:
> > > On Icelake, a separate powe
On Tue, Sep 18, 2018 at 10:12:24PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 18, 2018 at 12:04:35PM -0700, Manasi Navare wrote:
> > Thanks Imre for your review comments. Please find the comments below:
> >
> > On Fri, Sep 14, 2018 at 01:55:00PM +0300, Imre Deak wrote:
> > > On Tue, Sep 11, 2018 at
== Series Details ==
Series: series starting with [v3,1/6] drm/i915/runtime_pm: Share code to
enable/disable PCH reset handshake
URL : https://patchwork.freedesktop.org/series/49870/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4840 -> Patchwork_10217 =
== Summary - FAILU
On Tue, 2018-09-18 at 22:04 +0300, Ville Syrjälä wrote:
> On Tue, Sep 18, 2018 at 11:10:10AM -0700, José Roberto de Souza
> wrote:
> > Instead of have the same code spread into 4 platforms lets share
> > it.
> > BXT do not have a PCH so here also handling this case by unseting
> > RESET_PCH_HANDSHA
On Tue, Sep 18, 2018 at 12:31:54PM -0700, Manasi Navare wrote:
> On Tue, Sep 18, 2018 at 10:12:24PM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 18, 2018 at 12:04:35PM -0700, Manasi Navare wrote:
> > > Thanks Imre for your review comments. Please find the comments below:
> > >
> > > On Fri, Sep 14,
+ Harry, Leo
This would definitely be useful. We ran into a lot of issues when we
enabled >8 bpc support.
On Tue, Sep 18, 2018 at 2:10 PM Radhakrishna Sripada
wrote:
>
> At times 12bpc HDMI cannot be driven due to faulty cables, dongles
> level shifters etc. To workaround them we may need to dr
On Tue, Sep 18, 2018 at 11:10:13AM -0700, José Roberto de Souza wrote:
> SKL has IPC but it should not be set according to the WA, so lets
> just mark as it don't have it to simply the code and avoid
> unnecessary MMIO writes at every call to intel_enable_ipc().
>
> Cc: Rodrigo Vivi
> Signed-off-
On Tue, Sep 18, 2018 at 11:10:14AM -0700, José Roberto de Souza wrote:
> symmetric_memory do not change after initialization so lets just set
> ipc_enabled once for this WA.
>
> Cc: Rodrigo Vivi
> Signed-off-by: José Roberto de Souza
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/int
On Tue, Sep 18, 2018 at 12:40:21PM -0700, Souza, Jose wrote:
> On Tue, 2018-09-18 at 22:04 +0300, Ville Syrjälä wrote:
> > On Tue, Sep 18, 2018 at 11:10:10AM -0700, José Roberto de Souza
> > wrote:
> > > Instead of have the same code spread into 4 platforms lets share
> > > it.
> > > BXT do not hav
SKL has IPC but it should not be set according to the WA, so lets
just mark as it don't have it to simply the code and avoid
unnecessary MMIO writes at every call to intel_enable_ipc().
Reviewed-by: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_pci.c | 2 ++
dr
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 dif
symmetric_memory do not change after initialization so lets just set
ipc_enabled once for this WA.
Reviewed-by: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_pm.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/
A few line above we have another definition of intel_update_rawclk()
keeping that one as the function is implemented in intel_cdclk.c.
Reviewed-by: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_drv.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/g
Instead of have the same code spread into 4 platforms lets share it.
BXT do not have a PCH so here also handling this case by unseting
RESET_PCH_HANDSHAKE_ENABLE.
v2(Rodrigo):
- renamed to intel_pch_reset_handshake()
- added comment about why BXT need the bit to be unset
v3(Rodrigo and Ville):
-
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 removing the uncessary dev_priv->ipc_enabled = false; as now
gens without IPC will not have IPC enabled.
v2(Rodrigo):
- moved the new handling of WA #0477 to
On Tue, Sep 18, 2018 at 10:46:46PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 18, 2018 at 12:31:54PM -0700, Manasi Navare wrote:
> > On Tue, Sep 18, 2018 at 10:12:24PM +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 18, 2018 at 12:04:35PM -0700, Manasi Navare wrote:
> > > > Thanks Imre for your review
Thanks for the patch. I have tested this on DP 1.4 sink device
and it works properly to read the DPCDs from different offset and
use the true capabilities. Without this patch, the sink behaves as a
legacy DP 1.2 sink.
So with that:
Tested-by: Manasi Navare
Acked-by: Manasi Navare
Manasi
On Thu
On Tue, Sep 18, 2018 at 02:19:17PM -0700, Manasi Navare wrote:
> Thanks for the patch. I have tested this on DP 1.4 sink device
> and it works properly to read the DPCDs from different offset and
> use the true capabilities. Without this patch, the sink behaves as a
> legacy DP 1.2 sink.
>
> So wi
On Tue, Sep 18, 2018 at 01:47:09PM -0700, José Roberto de Souza wrote:
> Instead of have the same code spread into 4 platforms lets share it.
> BXT do not have a PCH so here also handling this case by unseting
> RESET_PCH_HANDSHAKE_ENABLE.
>
> v2(Rodrigo):
> - renamed to intel_pch_reset_handshake(
On Tue, Sep 18, 2018 at 01:47:10PM -0700, José Roberto de Souza wrote:
> 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
Currently the way that we prevent userspace from performing new modesets
on MST connectors that have just been destroyed is rather broken.
There's nothing in the actual DRM DP MST topology helpers that checks
whether or not a connector still exists, instead each DRM driver does
this on it's own, us
There's two major things this patchset does:
- Add drm_dp_mst_connector_atomic_check() so drivers don't need to use
->best_encoder() to prevent modesets on zombie MST connectors. We'll
use this later for implementing MST fallback retraining as well.
- Fix DPMS on->off changes failing with l
Currently we set intel_connector->mst_port to NULL to signify that the
MST port has been removed from the system so that we can prevent further
action on the port such as connector probes, mode probing, etc.
However, we're going to need access to intel_connector->mst_port in
order to fixup ->best_e
As mentioned in the previous commit, we currently prevent new modesets
on recently-removed MST connectors by returning no encoder from our
->best_encoder() callback once the MST port has disappeared. This is
wrong however, because it prevents legacy modesetting users from being
able to disable CRTC
Since we need to be able to allow DPMS on->off prop changes after an MST
port has disappeared from the system, we need to be able to make sure we
can compute a config for the resulting atomic commit. Currently this is
impossible when the port has disappeared, since the VCPI slot searching
we try to
Currently, i915 appears to rely on blocking modesets on
no-longer-present MSTB ports by simply returning NULL for
->best_encoder(), which in turn causes any new atomic commits that don't
disable the CRTC to fail. This is wrong however, since we still want to
allow userspace to disable CRTCs on no-l
Hook this into amdgpu's atomic check for their connectors so they never
get modesets on no-longer-present MST connectors. We'll also expand on
this later once we add DP MST fallback retraining support.
As well, turns out that the only atomic DRM driver without the
->best_encoder() bug is amdgpu. C
Just a reminder, if you are still planning have gvt-next PR,
tomorrow is your day :)
Regards, Joonas
Quoting Rodrigo Vivi (2018-09-18 18:53:10)
> On Tue, Sep 18, 2018 at 03:33:49PM +0800, Zhenyu Wang wrote:
> >
> > Hi,
> >
> > Here's more gvt fixes for 4.19. Two more BXT fixes from Colin,
> > o
99 matches
Mail list logo
