From: Tvrtko Ursulin
We can convert engine stats from a spinlock to seqlock to ensure interrupt
processing is never even a tiny bit delayed by parallel readers.
There is a smidgen bit more cost on the write lock side, and an extremely
unlikely chance that readers will have to retry a few times i
== Series Details ==
Series: drm/i915: Use seqlock in engine stats (rev3)
URL : https://patchwork.freedesktop.org/series/38347/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4100 -> Patchwork_8806 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://
Hi,
On 4/26/2018 3:24 AM, Rodrigo Vivi wrote:
On Wed, Apr 25, 2018 at 09:46:23PM -, Patchwork wrote:
== Series Details ==
Series: Optimize use of DBuf slices (rev2)
URL : https://patchwork.freedesktop.org/series/41180/
State : failure
== Summary ==
Applying: drm/i915/icl: track dbuf s
v2 of https://patchwork.freedesktop.org/series/41215/
Jani Nikula (7):
drm/i915/dp: remove stale comment about bw constants
drm/i915/dp: move link_bw and rate_select debugging where used
drm/i915/dp: abstract dp link config computation from the rest
drm/i915/dp: move eDP VBT bpp clamping c
Keep related things together. No functional changes.
v2: Fix a typo in patch subject, fix a checkpatch alignment warning.
Reviewed-by: Manasi Navare
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
Abstract compliance test adjustments to a single function. Also make the
bpc adjustments affect the limits, actually forcing the bpc. Seems like
directly changing the pipe_bpp in the past could not have been
effective.
Reviewed-by: Manasi Navare
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i9
Also use same min/max model for bpp, and adjust debug logging while at
it.
Reviewed-by: Manasi Navare
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 57 -
1 file changed, 33 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i9
We haven't used the DP bw constants here for a while. No functional
changes.
Reviewed-by: Rodrigo Vivi
Reviewed-by: Manasi Navare
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/
For now, there's just the one link config selection, optimizing for slow
and wide link. No functional changes.
Keep the debug logging in the caller, to avoid duplication later on if
alternative link confing selection gets added.
v2: Improved commit message
Reviewed-by: Manasi Navare
Signed-off-
We call intel_dp_compute_rate() in intel_dp_compute_config() only to be
able to debug log the link_bw and rate_select parameters; we don't use
the parameters here for anything else. We call intel_dp_compute_rate()
again during link training where we actually need and use the
parameters.
Move the d
Abstract a new intel_dp_compute_link_config() from
intel_dp_compute_config(), with the parts related to link configuration,
i.e. bpp, link rate, and lane count selection. No functional changes.
v2: Fix a checkpatch warn about spacing.
Reviewed-by: Manasi Navare
Signed-off-by: Jani Nikula
---
d
No matter how you perform the clip adjustments, a small
error may push the scaling factor to the other side of
0x1. Solve this with a macro that will fixup the
scale to 0x1 if we accidentally wrap to the other side.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_rect.c | 65 +++
With the previous patch drm_atomic_helper_check_plane_state correctly
calculates clipping and the xf86-video-intel ddx is fixed to fall back
to GPU correctly when SetPlane fails, we can remove the hack where
we try to pan/zoom when out of min/max scaling range. This was already
poor behavior where
When calculating limits we want to be as pessimistic as possible,
so we have to explicitly say whether we want to round up or down
to accurately calculate whether we are below min_scale or above
max_scale.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_rect.c | 17 -
1
== Series Details ==
Series: drm/i915/dp: link config compute refactoring (rev2)
URL : https://patchwork.freedesktop.org/series/41215/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8226b468bdc1 drm/i915/dp: remove stale comment about bw constants
77ae7b48939b drm/i915/dp: move
== Series Details ==
Series: drm/i915/dp: link config compute refactoring (rev2)
URL : https://patchwork.freedesktop.org/series/41215/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915/dp: remove stale comment about bw constants
Okay!
Commit: drm/i915/dp: move link_bw
== Series Details ==
Series: drm/i915/dp: link config compute refactoring (rev2)
URL : https://patchwork.freedesktop.org/series/41215/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4100 -> Patchwork_8807 =
== Summary - FAILURE ==
Serious unknown changes coming with Patch
== Series Details ==
Series: series starting with [1/3] drm/rect: Round above 1 << 16 upwards to
correct scale calculation functions.
URL : https://patchwork.freedesktop.org/series/42317/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3e26302006d1 drm/rect: Round above 1 << 16
== Series Details ==
Series: series starting with [1/3] drm/rect: Round above 1 << 16 upwards to
correct scale calculation functions.
URL : https://patchwork.freedesktop.org/series/42317/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/rect: Round above 1 << 16 upwards t
== Series Details ==
Series: drm/i915: Use seqlock in engine stats (rev3)
URL : https://patchwork.freedesktop.org/series/38347/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4100_full -> Patchwork_8806_full =
== Summary - WARNING ==
Minor unknown changes coming with Patc
== Series Details ==
Series: series starting with [1/3] drm/rect: Round above 1 << 16 upwards to
correct scale calculation functions.
URL : https://patchwork.freedesktop.org/series/42317/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4100 -> Patchwork_8808 =
== Summary - S
Hi Dave,
And welcome back! Hope you had a good one.
We got a few -rc2 induced 3rd party bugs to CI (but that's nowadays
more the rule than an exception), but other than that the results look
solid.
Main thing are the fixes for the user reported black screen (DP MST)
and HDA codec interop issues
We can reduce our exposure to random neutrinos by resting on the kernel
context having flushed out the user contexts to system memory and
beyond. The corollary is that we then we require two passes through the
idle handler to go to sleep, which on a truly idle system involves an
extra pass through
Quoting Lionel Landwerlin (2018-04-25 14:45:21)
> From: Chris Wilson
>
> We want to allow userspace to reconfigure the subslice configuration for
> its own use case. To do so, we expose a context parameter to allow
> adjustment of the RPCS register stored within the context image (and
> currently
== Series Details ==
Series: series starting with [1/3] drm/rect: Round above 1 << 16 upwards to
correct scale calculation functions.
URL : https://patchwork.freedesktop.org/series/42317/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4100_full -> Patchwork_8808_full =
== S
Quoting Chris Wilson (2018-04-11 13:03:46)
> Even though we weren't injecting guilty requests to be reset, we could
> still fall over the issue of resetting the same request too fast -- where
> the GPU refuses to start again. (Although it is interesting to note that
> reloading the driver is suffic
Chris Wilson writes:
> The majority of the engine state dumping is too voluminous to be useful
> outside of a controlled setup, though a few do accompany severe errors.
> Keep the debug dumps next to the errors, but hide the others behind a CI
> compile flag. This becomes more useful when adding
Chris Wilson writes:
> Quoting Mika Kuoppala (2018-04-24 13:26:11)
>> Chris Wilson writes:
>>
>> > Ideally, we want to atomically flush and disable the tasklet before
>> > resetting the GPU. At present, we rely on being the only part to touch
>> > our tasklet and serialisation of the reset proc
== Series Details ==
Series: RFC drm/i915: Switch to kernel context before idling at runtime
URL : https://patchwork.freedesktop.org/series/42321/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4101 -> Patchwork_8809 =
== Summary - FAILURE ==
Serious unknown changes comin
On 26/04/18 11:00, Joonas Lahtinen wrote:
Quoting Lionel Landwerlin (2018-04-25 14:45:21)
From: Chris Wilson
We want to allow userspace to reconfigure the subslice configuration for
its own use case. To do so, we expose a context parameter to allow
adjustment of the RPCS register stored within
Quoting Mika Kuoppala (2018-04-26 11:19:14)
> Chris Wilson writes:
>
> > Quoting Mika Kuoppala (2018-04-24 13:26:11)
> >> Chris Wilson writes:
> >>
> >> > Ideally, we want to atomically flush and disable the tasklet before
> >> > resetting the GPU. At present, we rely on being the only part to
On 26/04/2018 09:16, Patchwork wrote:
== Series Details ==
Series: drm/i915: Use seqlock in engine stats (rev3)
URL : https://patchwork.freedesktop.org/series/38347/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4100 -> Patchwork_8806 =
== Summary - SUCCESS ==
No re
It's been a while since we introduced drm_dev{get/put} functions
to replace reference/unreference in drm subsystem for the
consistency purpose. So, with this patch, let's just replace
all current use cases of drm_dev_unref() with drm_dev_put and remove
the function itself.
Coccinelle was used for
The majority of the engine state dumping is too voluminous to be useful
outside of a controlled setup, though a few do accompany severe errors.
Keep the debug dumps next to the errors, but hide the others behind a CI
compile flag. This becomes more useful when adding more dumps to latency
sensitive
Quoting Patchwork (2018-04-26 11:18:58)
> == Series Details ==
>
> Series: RFC drm/i915: Switch to kernel context before idling at runtime
> URL : https://patchwork.freedesktop.org/series/42321/
> State : failure
>
> == Summary ==
>
> = CI Bug Log - changes from CI_DRM_4101 -> Patchwork_8809 =
On Wed, Apr 25, 2018 at 11:47:28AM -0700, Dhinakaran Pandiyan wrote:
> On Tue, 2018-04-17 at 14:31 +0300, Imre Deak wrote:
> > Add documentation to gen9_set_dc_state() on what enabling a given DC
> > state means and at what point HW/DMC actually enters/exits these states.
> >
> > Cc: Jani Nikula
Hi Vaishali,
Thank you for the patch.
On Thursday, 26 April 2018 13:28:19 EEST Vaishali Thakkar wrote:
> It's been a while since we introduced drm_dev{get/put} functions
> to replace reference/unreference in drm subsystem for the
> consistency purpose. So, with this patch, let's just replace
> al
Hi Dave,
This is my first pull request for v4.18. Only UAPI change is adding a generic
plane
alpha property, which replaces the driver specific ones in sun4i, rcar-du and
atmel-hclcdc.
drm-misc-next-2018-04-26:
drm-misc-next for v4.18:
UAPI Changes:
- Add support for a generic plane alpha prop
Prefer INTEL_GEN() over INTEL_INFO()->gen except in special
circumstances.
v2: don't change device info dump (Chris)
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_device_info.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
On 26/04/2018 12:35, Jani Nikula wrote:
Prefer INTEL_GEN() over INTEL_INFO()->gen except in special
circumstances.
v2: don't change device info dump (Chris)
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_device_info.c | 2 +-
1 file changed
== Series Details ==
Series: drm/i915/dp: link config compute refactoring (rev2)
URL : https://patchwork.freedesktop.org/series/41215/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e404413cc8c9 drm/i915/dp: remove stale comment about bw constants
ff040231fec8 drm/i915/dp: move
== Series Details ==
Series: drm/i915/dp: link config compute refactoring (rev2)
URL : https://patchwork.freedesktop.org/series/41215/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915/dp: remove stale comment about bw constants
Okay!
Commit: drm/i915/dp: move link_bw
== Series Details ==
Series: drm/i915/dp: link config compute refactoring (rev2)
URL : https://patchwork.freedesktop.org/series/41215/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4103 -> Patchwork_8810 =
== Summary - SUCCESS ==
No regressions found.
External URL:
h
== Series Details ==
Series: drm/core: Remove drm_dev_unref() and it's uses
URL : https://patchwork.freedesktop.org/series/42325/
State : failure
== Summary ==
Applying: drm/core: Remove drm_dev_unref() and it's uses
error: Failed to merge in the changes.
Using index info to reconstruct a base
On Thu, Apr 26, 2018 at 03:58:19PM +0530, Vaishali Thakkar wrote:
> It's been a while since we introduced drm_dev{get/put} functions
> to replace reference/unreference in drm subsystem for the
> consistency purpose. So, with this patch, let's just replace
> all current use cases of drm_dev_unref()
On Thu, 26 Apr 2018 15:58:19 +0530
Vaishali Thakkar wrote:
> It's been a while since we introduced drm_dev{get/put} functions
> to replace reference/unreference in drm subsystem for the
> consistency purpose. So, with this patch, let's just replace
> all current use cases of drm_dev_unref() with
== Series Details ==
Series: drm/i915: Compile out engine debug for release
URL : https://patchwork.freedesktop.org/series/42327/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4103 -> Patchwork_8812 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https:
On Thu, Apr 26, 2018 at 03:58:19PM +0530, Vaishali Thakkar wrote:
> It's been a while since we introduced drm_dev{get/put} functions
> to replace reference/unreference in drm subsystem for the
> consistency purpose. So, with this patch, let's just replace
> all current use cases of drm_dev_unref()
== Series Details ==
Series: drm/i915: prefer INTEL_GEN() over INTEL_INFO()->gen
URL : https://patchwork.freedesktop.org/series/42331/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4103 -> Patchwork_8813 =
== Summary - SUCCESS ==
No regressions found.
External URL:
h
On Fri, Mar 23, 2018 at 08:30:48AM +, Chris Wilson wrote:
> As we are careful not to register external interfaces before the
> internals are brought up, we are not dependent upon a synchronous
> probing and can allow ourselves to be probed from a secondary thread
> during system bootup. We alre
Reviewed-by: Stanislav Lisovskiy
Best Regards,
Lisovskiy Stanislav
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
From: Intel-gfx [intel-gfx-boun...@lists.freedesktop.org] on behalf of
Lisovskiy, Stanislav [stanislav.liso
Cc: Maarten, Ville
On Mon, 23 Apr 2018, Dave Jones wrote:
> This warning just started appearing during boot on a machine I upgraded
> to 4.17-rc2. The warning seems to have been there since 2015, but it
> has never triggered before today.
>
> Dave
>
> [1.158500] fb: switching to intel
Hi Daniel,
On Thursday, 26 April 2018 15:36:15 EEST Daniel Vetter wrote:
> On Thu, Apr 26, 2018 at 03:58:19PM +0530, Vaishali Thakkar wrote:
> > It's been a while since we introduced drm_dev{get/put} functions
> > to replace reference/unreference in drm subsystem for the
> > consistency purpose. S
Quoting David Weinehall (2018-04-26 13:41:57)
> On Fri, Mar 23, 2018 at 08:30:48AM +, Chris Wilson wrote:
> > As we are careful not to register external interfaces before the
> > internals are brought up, we are not dependent upon a synchronous
> > probing and can allow ourselves to be probed f
On Thu, Apr 26, 2018 at 03:41:57PM +0300, David Weinehall wrote:
> On Fri, Mar 23, 2018 at 08:30:48AM +, Chris Wilson wrote:
> > As we are careful not to register external interfaces before the
> > internals are brought up, we are not dependent upon a synchronous
> > probing and can allow ourse
On Thu, Apr 26, 2018 at 6:15 PM, Laurent Pinchart
wrote:
> Hi Daniel,
>
> On Thursday, 26 April 2018 15:36:15 EEST Daniel Vetter wrote:
>> On Thu, Apr 26, 2018 at 03:58:19PM +0530, Vaishali Thakkar wrote:
>> > It's been a while since we introduced drm_dev{get/put} functions
>> > to replace referen
On Mon, Apr 23, 2018 at 11:27:13AM -0400, Dave Jones wrote:
> This warning just started appearing during boot on a machine I upgraded
> to 4.17-rc2. The warning seems to have been there since 2015, but it
> has never triggered before today.
Looks like we have bug open about this. I just asked for
== Series Details ==
Series: drm: Don't pass the index to drm_property_add_enum() (rev3)
URL : https://patchwork.freedesktop.org/series/40122/
State : failure
== Summary ==
Applying: drm: Don't pass the index to drm_property_add_enum()
error: patch failed: drivers/gpu/drm/drm_connector.c:1069
On Thu, Apr 26, 2018 at 10:28:20AM +0200, Maarten Lankhorst wrote:
> No matter how you perform the clip adjustments, a small
> error may push the scaling factor to the other side of
> 0x1. Solve this with a macro that will fixup the
> scale to 0x1 if we accidentally wrap to the other side.
On Wed, Apr 25, 2018 at 02:57:57PM -0700, Dhinakaran Pandiyan wrote:
> Sink crc is calculated by the sink for static frames irrespective of
> what the driver sets in TEST_SINK_START dpcd. Since PSR is the only use
> case for sink crc, we don't really need the sink_crc_{start, stop} code.
>
> The s
On Wed, Apr 25, 2018 at 07:10:09PM -0700, tarun.v...@intel.com wrote:
> From: Tarun
>
> The Display scanline counter freezes on PSR entry. Inside
> intel_pipe_update_start, once Vblank interrupts are enabled, we start
> exiting PSR, but by the time the scanline counter is read, we may not
> have
On Wed, Apr 25, 2018 at 02:55:24PM -0700, Lucas De Marchi wrote:
> This became dead code with commit 309bd8ed464f ("drm/i915: Reinstate
> GMBUS and AUX interrupts on gen4/g4x").
>
> Cc: Ville Syrjälä
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/i915_drv.h | 3 +--
> drivers/g
On Thu, Apr 26, 2018 at 3:14 PM, Alexandre Belloni
wrote:
> Hi,
>
> On 26/04/2018 15:45:44+0300, Laurent Pinchart wrote:
>> Hi Daniel,
>>
>> On Thursday, 26 April 2018 15:36:15 EEST Daniel Vetter wrote:
>> > On Thu, Apr 26, 2018 at 03:58:19PM +0530, Vaishali Thakkar wrote:
>> > > It's been a while
On Thu, Apr 26, 2018 at 10:28:20AM +0200, Maarten Lankhorst wrote:
> No matter how you perform the clip adjustments, a small
> error may push the scaling factor to the other side of
> 0x1. Solve this with a macro that will fixup the
> scale to 0x1 if we accidentally wrap to the other side.
On 2018-03-30 21:45, Daniele Ceraolo Spurio wrote:
On 30/03/18 08:42, Lis, Tomasz wrote:
On 2018-03-29 00:28, Chris Wilson wrote:
Quoting Lis, Tomasz (2018-03-28 17:06:58)
On 2018-03-28 01:27, Chris Wilson wrote:
Quoting Tomasz Lis (2018-03-27 16:17:59)
The patch adds support of preemp
== Series Details ==
Series: drm/i915/dp: link config compute refactoring (rev2)
URL : https://patchwork.freedesktop.org/series/41215/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4103_full -> Patchwork_8810_full =
== Summary - WARNING ==
Minor unknown changes coming wi
== Series Details ==
Series: drm/i915: Compile out engine debug for release
URL : https://patchwork.freedesktop.org/series/42327/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4103_full -> Patchwork_8812_full =
== Summary - WARNING ==
Minor unknown changes coming with Pa
== Series Details ==
Series: drm/i915: prefer INTEL_GEN() over INTEL_INFO()->gen
URL : https://patchwork.freedesktop.org/series/42331/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4103_full -> Patchwork_8813_full =
== Summary - WARNING ==
Minor unknown changes coming wi
On Mon, Apr 23, 2018 at 01:11:25PM +0300, Ville Syrjälä wrote:
> On Mon, Apr 23, 2018 at 10:43:47AM +0530, Nautiyal, Ankit K wrote:
> >
> >
> > On 4/20/2018 7:37 PM, Ville Syrjälä wrote:
> > > On Fri, Apr 20, 2018 at 07:01:46PM +0530, Nautiyal, Ankit K wrote:
> > >> From: Ankit Nautiyal
> > >>
>
Patches in this series were originally part of series:
https://patchwork.freedesktop.org/series/36993/
Reposting it here after rebase
use kernel types u8/u16 etc instead of uint8_t
Changes:
- Rebase the series
Mahesh Kumar (3):
drm/i915/icl: track dbuf slice-2 status
drm/i915/icl: Enable 2n
This patch adds support to start tracking status of DBUF slices.
This is foundation to introduce support for enabling/disabling second
DBUF slice dynamically for ICL.
Changes Since V1:
- use kernel type u8 over uint8_t
Signed-off-by: Mahesh Kumar
Reviewed-by: James Ausmus
---
drivers/gpu/drm/
Gen11/ICL onward ddb entry start/end mask is increased from 10 bits to
11 bits. This patch make changes to use proper mask for ICL+ during
hardware ddb value readout.
Changes since V1:
- Use _MASK & _SHIFT macro (James)
Changes since V2:
- use kernel type u8 instead of uint8_t
Changes since V3:
ICL has two slices of DBuf, each slice of size 1024 blocks.
We should not always enable slice-2. It should be enabled only if
display total required BW is > 12GBps OR more than 1 pipes are enabled.
Changes since V1:
- typecast total_data_rate to u64 before multiplication to solve any
possible
On Thu, Apr 26, 2018 at 04:10:45PM +0300, Ville Syrjälä wrote:
> On Mon, Apr 23, 2018 at 11:27:13AM -0400, Dave Jones wrote:
> > This warning just started appearing during boot on a machine I upgraded
> > to 4.17-rc2. The warning seems to have been there since 2015, but it
> > has never trigge
On Thu, Apr 26, 2018 at 10:27:19AM -0400, Dave Jones wrote:
> [1.176131] [drm:i9xx_get_initial_plane_config] pipe A/primary A with fb:
> size=800x600@32, offset=0, pitch 3200, size 0x1d4c00
> [1.176161] [drm:i915_gem_object_create_stolen_for_preallocated] creating
> preallocated stolen ob
Oscar Mateo writes:
> Inherit workarounds from previous platforms that are still valid for
> Icelake.
>
> v2: GEN7_ROW_CHICKEN2 is masked
> v3:
> - Since it has been fixed already in upstream, removed the TODO
> comment about WA_SET_BIT for WaInPlaceDecompressionHang.
> - Squashed with th
On Thu, Apr 26, 2018 at 05:56:14PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 26, 2018 at 10:27:19AM -0400, Dave Jones wrote:
> > [1.176131] [drm:i9xx_get_initial_plane_config] pipe A/primary A with
> > fb: size=800x600@32, offset=0, pitch 3200, size 0x1d4c00
> > [1.176161] [drm:i915_gem_ob
On Thu, 26 Apr 2018, Tvrtko Ursulin wrote:
> On 26/04/2018 12:35, Jani Nikula wrote:
>> Prefer INTEL_GEN() over INTEL_INFO()->gen except in special
>> circumstances.
>>
>> v2: don't change device info dump (Chris)
>>
>> Cc: Tvrtko Ursulin
>> Cc: Mika Kuoppala
>> Signed-off-by: Jani Nikula
>>
On Thu, Apr 26, 2018 at 04:43:38PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 25, 2018 at 02:55:24PM -0700, Lucas De Marchi wrote:
> > This became dead code with commit 309bd8ed464f ("drm/i915: Reinstate
> > GMBUS and AUX interrupts on gen4/g4x").
> >
> > Cc: Ville Syrjälä
> > Signed-off-by: Lucas
On Thu, 26 Apr 2018, Jani Nikula wrote:
> v2 of https://patchwork.freedesktop.org/series/41215/
And pushed the lot after the CI results. Thanks for the review!
BR,
Jani.
>
> Jani Nikula (7):
> drm/i915/dp: remove stale comment about bw constants
> drm/i915/dp: move link_bw and rate_select d
On Thu, Apr 26, 2018 at 06:16:41PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 26, 2018 at 05:56:14PM +0300, Ville Syrjälä wrote:
> > On Thu, Apr 26, 2018 at 10:27:19AM -0400, Dave Jones wrote:
> > > [1.176131] [drm:i9xx_get_initial_plane_config] pipe A/primary A with
> > > fb: size=800x600@32,
On Thu, Apr 26, 2018 at 08:22:12AM -0700, Lucas De Marchi wrote:
> On Thu, Apr 26, 2018 at 04:43:38PM +0300, Ville Syrjälä wrote:
> > On Wed, Apr 25, 2018 at 02:55:24PM -0700, Lucas De Marchi wrote:
> > > This became dead code with commit 309bd8ed464f ("drm/i915: Reinstate
> > > GMBUS and AUX inter
Oscar Mateo writes:
> The default GAPZ arbitrer priority value at power-on has been found
> to be incorrect.
>
> v2: Now renamed to Wa_1405543622
>
> v3: Rebased on top of the WA refactoring
>
I have suggested that when implementing workarounds,
authors, for example, add
References: HSDES#14055
On Thu, Apr 26, 2018 at 06:27:26PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 26, 2018 at 08:22:12AM -0700, Lucas De Marchi wrote:
> > On Thu, Apr 26, 2018 at 04:43:38PM +0300, Ville Syrjälä wrote:
> > > On Wed, Apr 25, 2018 at 02:55:24PM -0700, Lucas De Marchi wrote:
> > > > This became dead code w
On Thu, Apr 26, 2018 at 08:42:54AM -0700, Lucas De Marchi wrote:
> On Thu, Apr 26, 2018 at 06:27:26PM +0300, Ville Syrjälä wrote:
> > On Thu, Apr 26, 2018 at 08:22:12AM -0700, Lucas De Marchi wrote:
> > > On Thu, Apr 26, 2018 at 04:43:38PM +0300, Ville Syrjälä wrote:
> > > > On Wed, Apr 25, 2018 at
On Thu, Apr 26, 2018 at 06:25:13PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 26, 2018 at 06:16:41PM +0300, Ville Syrjälä wrote:
> > On Thu, Apr 26, 2018 at 05:56:14PM +0300, Ville Syrjälä wrote:
> > > On Thu, Apr 26, 2018 at 10:27:19AM -0400, Dave Jones wrote:
> > > > [1.176131] [drm:i9xx_g
On Wed, Apr 11, 2018 at 01:03:46PM +0100, Chris Wilson wrote:
> Even though we weren't injecting guilty requests to be reset, we could
> still fall over the issue of resetting the same request too fast -- where
> the GPU refuses to start again. (Although it is interesting to note that
> reloading t
From: Ville Syrjälä
During state readout we first read out the pipe src size, store
that information in the user mode h/vdisplay, but later on we overwrite
that with the actual crtc timings. That makes our read out crtc state
inconsistent with itself when the BIOS has enabled the panel fitter to
Quoting Michał Winiarski (2018-04-26 17:21:39)
> On Wed, Apr 11, 2018 at 01:03:46PM +0100, Chris Wilson wrote:
> > Even though we weren't injecting guilty requests to be reset, we could
> > still fall over the issue of resetting the same request too fast -- where
> > the GPU refuses to start again.
On Thu, 2018-04-26 at 16:41 +0300, Ville Syrjälä wrote:
> On Wed, Apr 25, 2018 at 07:10:09PM -0700, tarun.v...@intel.com wrote:
> > From: Tarun
> >
> > The Display scanline counter freezes on PSR entry. Inside
> > intel_pipe_update_start, once Vblank interrupts are enabled, we start
> > exitin
In the next patch, rings are the central timeline as requests may jump
between engines. Therefore in the future as we retire in order along the
engine timeline, we may retire out-of-order within a ring (as the ring now
occurs along multiple engines), leading to much hilarity in miscomputing
the pos
When userspace is passing around swapbuffers using DRI, we frequently
have to open and close the same object in the foreign address space.
This shows itself as the same object being rebound at roughly 30fps
(with a second object also being rebound at 30fps), which involves us
having to rewrite the
In commit 9b6586ae9f6b ("drm/i915: Keep a global seqno per-engine"), we
moved from a global inflight counter to per-engine counters in the
hope that will be easy to run concurrently in future. However, with the
advent of the desire to move requests between engines, we do need a
global counter to pr
In the future, we want to move a request between engines. To achieve
this, we first realise that we have two timelines in effect here. The
first runs through the GTT is required for ordering vma access, which is
tracked currently by engine. The second is implied by sequential
execution of commands
We don't need to track every ring for its lifetime as they are managed
by the contexts/engines. What we do want to track are the live rings so
that we can sporadically clean up requests if userspace falls behind. We
can simply restrict the gt->rings list to being only gt->live_rings.
v2: s/live/ac
We need to move to a more flexible timeline that doesn't assume one
fence context per engine, and so allow for a single timeline to be used
across a combination of engines. This means that preallocating a fence
context per engine is now a hindrance, and so we want to introduce the
singular timeline
Make life easier in upcoming patches by moving the context_pin and
context_unpin vfuncs into inline helpers.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gvt/mmio_context.c | 2 +-
drivers/gpu/drm/i915/gvt/scheduler.c | 20 ++---
drivers/gpu/drm/i915/i915_debugfs.c
No functional changes in this patch.
The SDP Header is a generic header for secondary data packets for
both eDP and DP so call it dp_sdp_header. This header gets used for
different SDP types already defined.
Also header bytes 2 and 3 are secondary data packet specific header bytes.
So change the c
On Wed, 2018-04-18 at 15:43 -0700, José Roberto de Souza wrote:
> eDP spec states that sink device will do a short pulse in HPD
> line when there is a PSR/PSR2 error that needs to be handled by
> source, this is handling the first and most simples error:
> DP_PSR_SINK_INTERNAL_ERROR.
>
> Signed
On Wed, 2018-04-18 at 15:43 -0700, José Roberto de Souza wrote:
> Sink will interrupt source when it have any problem saving or reading
> the remote frame buffer.
>
> Signed-off-by: José Roberto de Souza
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
> ---
>
> Changes from v1:
> - printing a
1 - 100 of 125 matches
Mail list logo
