On Mon, Apr 6, 2020 at 7:29 PM Thomas Zimmermann wrote:
>
>
>
> Am 03.04.20 um 15:58 schrieb Daniel Vetter:
> > Also need to remove the drm_dev_put from the remove hook.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Dave Airlie
> > Cc: Gerd Hoffmann
> > Cc: virtualizat...@lists.linux-foundation.
On Fri 2020-04-03 15:00:31, Pavel Machek wrote:
> Hi!
>
> 7dc8f1143778a35b190f9413f228b3cf28f67f8d
>
> drm/i915/gem: Drop relocation slowpath
>
> Since the relocations are no longer performed under a global
> struct_mutex, or any other lock, that is also held by pagefault handle
On Mon, Apr 6, 2020 at 7:27 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 03.04.20 um 15:57 schrieb Daniel Vetter:
> > We use the baseclass pattern here, so lets to the proper (and more
> > typesafe) upcasting.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Hans de Goede
> > ---
> > drivers/gpu/drm/v
Quoting Pavel Machek (2020-04-07 08:20:47)
>
> On Fri 2020-04-03 15:00:31, Pavel Machek wrote:
> > Hi!
> >
> > 7dc8f1143778a35b190f9413f228b3cf28f67f8d
> >
> > drm/i915/gem: Drop relocation slowpath
> >
> > Since the relocations are no longer performed under a global
> > struct_
On Fri, Apr 03, 2020 at 11:40:03PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> htotal*vtotal*vrefresh ~= clock. So just say "clock" when we mean it.
Glorious.
Reviewed-by: Daniel Vetter
>
> Cc: Linus Walleij
> Cc: Sam Ravnborg
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/dp_mst: Cast
intel_connector->port as drm_dp_mst_port
URL : https://patchwork.freedesktop.org/series/75569/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8264_full -> Patchwork_17224_full
This series works for me. Thank you.
Tested-by: You-Sheng Yang
On 2020-04-07 09:11, José Roberto de Souza wrote:
> Moving the code to return the digital port of the aux channel also
> removing the intel_phy_is_tc() to make it generic.
> digital_port will be needed in icl_tc_phy_aux_power_well_en
== Series Details ==
Series: drm/i915/display: Enable DP Display Audio WA
URL : https://patchwork.freedesktop.org/series/75582/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8264 -> Patchwork_17227
Summary
---
**SUCC
== Series Details ==
Series: drm/i915/display: Enable DP Display Audio WA
URL : https://patchwork.freedesktop.org/series/75582/
State : warning
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
CHK include/generated/compile.h
Kernel: arch/x86/boot/b
We need to calculate cdclk after watermarks/ddb has been calculated
as with recent hw CDCLK needs to be adjusted accordingly to DBuf
requirements, which is not possible with current code organization.
Setting CDCLK according to DBuf BW requirements and not just rejecting
if it doesn't satisfy BW r
On Fri, Apr 03, 2020 at 11:40:04PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Replace the use of mode->private_flags with a truly private bitmaks
> in our own crtc state. We also need a copy in the crtc itself so the
> vblank code can get at it. We already have scanline_offset in there
In Gen11+ whenever we might exceed DBuf bandwidth we might need to
recalculate CDCLK which DBuf bandwidth is scaled with.
Total Dbuf bw used might change based on particular plane needs.
In intel_atomic_check_planes we try to filter out the cases when
we definitely don't need to recalculate requir
== Series Details ==
Series: series starting with [1/5] drm: report dp downstream port type as a
subconnector property
URL : https://patchwork.freedesktop.org/series/75585/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4bd9a33efdc0 drm: report dp downstream port type as a subc
We quite often need now to iterate only particular dbuf slices
in mask, whether they are active or related to particular crtc.
v2: - Minor code refactoring
Let's make our life a bit easier and use a macro for that.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_displ
On Fri, Apr 03, 2020 at 11:40:05PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> There's no reason for I915_MODE_FLAG_INHERITED to exist as a flag
> anymore. Just make it a boolean.
>
> CC: Sam Ravnborg
> Cc: Daniel Vetter
> Cc: Emil Velikov
> Signed-off-by: Ville Syrjälä
Reviewed-b
According to BSpec max BW per slice is calculated using formula
Max BW = CDCLK * 64. Currently when calculating min CDCLK we
account only per plane requirements, however in order to avoid
FIFO underruns we need to estimate accumulated BW consumed by
all planes(ddb entries basically) residing on tha
== Series Details ==
Series: series starting with [1/5] drm: report dp downstream port type as a
subconnector property
URL : https://patchwork.freedesktop.org/series/75585/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm: report dp downstream port
On Fri, Apr 03, 2020 at 11:40:06PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> gma500 only uses mode->private_flags to convey the sdvo pixel
> multiplier from the encoder .mode_fixup() hook to the encoder
> .mode_set() hook. Those always seems get called as a pair so
> let's just stuff
Hi!
> > > 7dc8f1143778a35b190f9413f228b3cf28f67f8d
> > >
> > > drm/i915/gem: Drop relocation slowpath
> > >
> > > Since the relocations are no longer performed under a global
> > > struct_mutex, or any other lock, that is also held by pagefault
> > > handlers,
> > > we can r
== Series Details ==
Series: Consider DBuf bandwidth when calculating CDCLK (rev7)
URL : https://patchwork.freedesktop.org/series/74739/
State : failure
== Summary ==
Applying: drm/i915: Decouple cdclk calculation from modeset checks
Applying: drm/i915: Force recalculate min_cdclk if planes co
== Series Details ==
Series: series starting with [1/5] drm: report dp downstream port type as a
subconnector property
URL : https://patchwork.freedesktop.org/series/75585/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8264 -> Patchwork_17228
=
== Series Details ==
Series: series starting with [1/3] drm/i915: introduce a mechanism to extend
execbuf2
URL : https://patchwork.freedesktop.org/series/75570/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8264_full -> Patchwork_17225_full
===
On 2020.04.03 10:50:33 -0700, Rodrigo Vivi wrote:
>
> +Dave and Daniel,
>
> >
> > I forgot to mention one thing for 5.7. We've fixed to change guest mem r/w
> > from KVM to use new VFIO dma r/w instead in this series:
> > https://patchwork.freedesktop.org/series/72038/
> >
> > As this depends
Enable Display Audio WA #1406928334 for 4k+VDSC usecase
on DP encoders.
v2: Fixed build failures on 32bit machine.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_audio.c | 113 +
drivers/gpu/drm/i915/i915_reg.h| 16 +++
2 files changed, 129 in
Tidy the code by casting remain to unsigned long once for the duration
of eb_relocate_vma()
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
== Series Details ==
Series: drm/i915/display: Enable DP Display Audio WA (rev2)
URL : https://patchwork.freedesktop.org/series/75582/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8264 -> Patchwork_17230
Summary
---
== Series Details ==
Series: drm/i915/display: Enable DP Display Audio WA (rev2)
URL : https://patchwork.freedesktop.org/series/75582/
State : warning
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
CHK include/generated/compile.h
Kernel: arch/x86
On 03/04/2020 10:12, Chris Wilson wrote:
If we find ourselves waiting on a MI_SEMAPHORE_WAIT, either within the
user batch or in our own preamble, the engine raises a
GT_WAIT_ON_SEMAPHORE interrupt. We can unmask that interrupt and so
respond to a semaphore wait by yielding the timeslice, if we
If we find ourselves waiting on a MI_SEMAPHORE_WAIT, either within the
user batch or in our own preamble, the engine raises a
GT_WAIT_ON_SEMAPHORE interrupt. We can unmask that interrupt and so
respond to a semaphore wait by yielding the timeslice, if we have
another context to yield to!
The only
Chris Wilson writes:
> Tidy the code by casting remain to unsigned long once for the duration
> of eb_relocate_vma()
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions
Start using device specific parameters instead of module parameters for
most things. The module parameters become the immutable initial values
for i915 parameters. The device specific parameters in i915->params
start life as a copy of i915_modparams. Any later changes are only
reflected in the debu
Only support runtime changes through the debugfs.
i915.verbose_state_checks remains an exception, and is not exposed via
debugfs.
FIXME: Before this gets applied, IGT *must* be changed to use the
debugfs for modifying the parameters. IGT changes *at least* the
following through module parameter s
The parameter only makes sense as a module parameter only.
Cc: Juha-Pekka Heikkilä
Cc: Venkata Sandeep Dhanalakota
Signed-off-by: Jani Nikula
---
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
This is still pending igt changes to switch from module param sysfs to the
device param debugfs. Posting for early review.
BR,
Jani.
Cc: Juha-Pekka Heikkilä
Cc: Venkata Sandeep Dhanalakota
Jani Nikula (3):
drm/i915/params: don't expose inject_probe_failure in debugfs
drm/i915/params: prev
== Series Details ==
Series: drm/i915/gem: Promote 'remain' to unsigned long
URL : https://patchwork.freedesktop.org/series/75600/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8264 -> Patchwork_17231
Summary
---
**S
== Series Details ==
Series: drm/i915/gem: Promote 'remain' to unsigned long
URL : https://patchwork.freedesktop.org/series/75600/
State : warning
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
CHK include/generated/compile.h
CC [M] drivers/gp
== Series Details ==
Series: series starting with [v2,1/8] drm/i915/display: Move out code to return
the digital_port of the aux ch
URL : https://patchwork.freedesktop.org/series/75576/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8264_full -> Patchwork_17226_full
==
Remove a number of inlines from .c files, and let the compiler decide
what's best.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/icl_dsi.c| 8 +++
drivers/gpu/drm/i915/display/intel_ddi.c | 7 +++---
drivers/gpu/drm/i915/display/intel_display.c | 10
..
Unused, hiding from the compiler warnings behind the inline keyword.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 011d
We need to calculate cdclk after watermarks/ddb has been calculated
as with recent hw CDCLK needs to be adjusted accordingly to DBuf
requirements, which is not possible with current code organization.
Setting CDCLK according to DBuf BW requirements and not just rejecting
if it doesn't satisfy BW r
According to BSpec max BW per slice is calculated using formula
Max BW = CDCLK * 64. Currently when calculating min CDCLK we
account only per plane requirements, however in order to avoid
FIFO underruns we need to estimate accumulated BW consumed by
all planes(ddb entries basically) residing on tha
We quite often need now to iterate only particular dbuf slices
in mask, whether they are active or related to particular crtc.
v2: - Minor code refactoring
v3: - Use enum for max slices instead of macro
Let's make our life a bit easier and use a macro for that.
Signed-off-by: Stanislav Lisovskiy
We need to calculate cdclk after watermarks/ddb has been calculated
as with recent hw CDCLK needs to be adjusted accordingly to DBuf
requirements, which is not possible with current code organization.
Setting CDCLK according to DBuf BW requirements and not just rejecting
if it doesn't satisfy BW r
In Gen11+ whenever we might exceed DBuf bandwidth we might need to
recalculate CDCLK which DBuf bandwidth is scaled with.
Total Dbuf bw used might change based on particular plane needs.
In intel_atomic_check_planes we try to filter out the cases when
we definitely don't need to recalculate requir
No need to bump up CDCLK now, as it is now correctly
calculated, accounting for DBuf BW as BSpec says.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/
On 03/04/2020 10:12, Chris Wilson wrote:
Fixes: a88b6e4cbafd ("drm/i915: Allow specification of parallel execbuf")
It looks like new uapi on the technical level, even though from a higher
level it is just an application of existing uapi across more modes, so
why fixes and who is the consume
Quoting Tvrtko Ursulin (2020-04-07 11:44:45)
>
> On 03/04/2020 10:12, Chris Wilson wrote:
> > Fixes: a88b6e4cbafd ("drm/i915: Allow specification of parallel execbuf")
>
> It looks like new uapi on the technical level, even though from a higher
> level it is just an application of existing uapi
On 03/04/2020 10:13, Chris Wilson wrote:
Let userspace know if they can trust timeslicing by including it as part
of the I915_PARAM_HAS_SCHEDULER::I915_SCHEDULER_CAP_TIMESLICING
v2: Only declare timeslicing if we can safely preempt userspace.
Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimali
Quoting Tvrtko Ursulin (2020-04-07 11:50:31)
>
> On 03/04/2020 10:13, Chris Wilson wrote:
> > Let userspace know if they can trust timeslicing by including it as part
> > of the I915_PARAM_HAS_SCHEDULER::I915_SCHEDULER_CAP_TIMESLICING
> >
> > v2: Only declare timeslicing if we can safely preempt
On 2020-04-07 at 14:20:38 +0530, Uma Shankar wrote:
> Enable Display Audio WA #1406928334 for 4k+VDSC usecase
> on DP encoders.
>
> v2: Fixed build failures on 32bit machine.
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/display/intel_audio.c | 113 +
> drivers
> -Original Message-
> From: Gupta, Anshuman
> Sent: Tuesday, April 7, 2020 4:23 PM
> To: Shankar, Uma
> Cc: intel-gfx@lists.freedesktop.org; Vehmanen, Kai
> Subject: Re: [PATCH v2] drm/i915/display: Enable DP Display Audio WA
>
> On 2020-04-07 at 14:20:38 +0530, Uma Shankar wrote:
>
On Thu, 2 Apr 2020, Jani Nikula wrote:
Convert all the DRM_* logging macros to the struct drm_device based
macros to provide device specific logging.
No functional changes.
Generated using the following semantic patch, originally written by
Wambui Karuga , with manual fixups on top:
@@
ide
On Tue, 07 Apr 2020, Uma Shankar wrote:
> Enable Display Audio WA #1406928334 for 4k+VDSC usecase
> on DP encoders.
I didn't actually read the wa, but please describe the main points here.
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/display/intel_audio.c | 110 +
On Thu, 2 Apr 2020, Jani Nikula wrote:
Convert all the DRM_* logging macros to the struct drm_device based
macros to provide device specific logging.
No functional changes.
Generated using the following semantic patch, originally written by
Wambui Karuga , with manual fixups on top:
@@
ide
On Thu, 2 Apr 2020, Jani Nikula wrote:
Convert all the DRM_* logging macros to the struct drm_device based
macros to provide device specific logging.
No functional changes.
Generated using the following semantic patch, originally written by
Wambui Karuga , with manual fixups on top:
@@
ide
== Series Details ==
Series: drm/i915/gt: Yield the timeslice if caught waiting on a user semaphore
(rev2)
URL : https://patchwork.freedesktop.org/series/72724/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8264 -> Patchwork_17232
=
On Thu, 2 Apr 2020, Jani Nikula wrote:
Convert all the DRM_* logging macros to the struct drm_device based
macros to provide device specific logging.
No functional changes.
Generated using the following semantic patch, originally written by
Wambui Karuga , with manual fixups on top:
@@
ide
On Thu, 2 Apr 2020, Jani Nikula wrote:
Convert all the DRM_* logging macros to the struct drm_device based
macros to provide device specific logging.
No functional changes.
Cc: Wambui Karuga
Signed-off-by: Jani Nikula
Reviewed-by: Wambui Karuga
---
drivers/gpu/drm/i915/display/intel_
On Thu, 2 Apr 2020, Jani Nikula wrote:
Convert all the DRM_* logging macros to the struct drm_device based
macros to provide device specific logging.
No functional changes.
Cc: Wambui Karuga
Signed-off-by: Jani Nikula
Reviewed-by: Wambui Karuga
---
drivers/gpu/drm/i915/i915_debugfs.c
If we find ourselves waiting on a MI_SEMAPHORE_WAIT, either within the
user batch or in our own preamble, the engine raises a
GT_WAIT_ON_SEMAPHORE interrupt. We can unmask that interrupt and so
respond to a semaphore wait by yielding the timeslice, if we have
another context to yield to!
The only
On Thu, 26 Mar 2020, Vipin Anand wrote:
> this patch adds hdr capabilities checks for Gen9 devices with
> lspcon support.
For a lot of the changes I don't see how you'd end up in the code paths
with LSPCON, because from the driver perspective LSPCON is DP. (We
always use PCON mode.)
There's also
On Thu, 26 Mar 2020, Lyude Paul wrote:
> On Thu, 2020-03-05 at 15:12 -0500, Sean Paul wrote:
>> From: Sean Paul
>>
>> Used to query whether an MST stream is encrypted or not.
>>
>> Signed-off-by: Sean Paul
>>
>> Link:
>> https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-14-
== Series Details ==
Series: drm/i915: from module params to device params (rev2)
URL : https://patchwork.freedesktop.org/series/54414/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f9135c748581 drm/i915/params: don't expose inject_probe_failure in debugfs
9870a0bf570a drm/i915
On Fri, 27 Mar 2020, Vipin Anand wrote:
> From: Uma Shankar
>
> Gen9 hardware supports HDMI2.0 through LSPCON chips.
> Extending HDR support for MCA LSPCON based GEN9 devices.
>
> SOC will drive LSPCON as DP and send HDR metadata as standard
> DP SDP packets. LSPCON will be set to operate in PCON
On Fri, 27 Mar 2020, Vipin Anand wrote:
> From: Uma Shankar
>
> Attach HDR property for Gen9 devices with MCA LSPCON
> chips.
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/display/intel_lspcon.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/dis
Add 2 new properties to the i915-perf open ioctl to specify an array
of GEM context handles as well as the length of the array.
This can be used by drivers using multiple GEM contexts to implement a
single GL context.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 58 ++
Make all the internal necessary changes before we flip the switch.
v2: Use an unlimited number of intel contexts (Chris)
v3: Handle GEM context with multiple RCS0 logical contexts (Chris)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 591 +++-
We want to enable performance monitoring on multiple contexts to cover
the Iris use case of using 2 GEM contexts (3D & compute).
So start by breaking the OA configuration BO which contains global &
per context register writes.
NOA muxes & OA configurations are global, while FLEXEU register
config
On Fri, 27 Mar 2020, Vipin Anand wrote:
> From: Uma Shankar
>
> Send Dynamic Range and Mastering Infoframe (DRM for HDR metadata)
> as SDP packet to LSPCON following the DP spec. LSPCON receives the
> same and sends it to HDMI sink.
>
> v2: Suppressed some warnings. No functional change.
>
> Sign
On Tue, 07 Apr 2020, Jani Nikula wrote:
> On Fri, 27 Mar 2020, Vipin Anand wrote:
>> From: Uma Shankar
>>
>> Send Dynamic Range and Mastering Infoframe (DRM for HDR metadata)
>> as SDP packet to LSPCON following the DP spec. LSPCON receives the
>> same and sends it to HDMI sink.
>>
>> v2: Suppre
On Fri, 27 Mar 2020, Vipin Anand wrote:
> From: Uma Shankar
>
> Blanking needs to be reduced to incorporate DP and HDMI timing/link
> bandwidth limitations for CEA modes (4k@60 at 10 bpp). DP can drive
> 17.28Gbs while 4k modes (VIC97 etc) at 10 bpp required 17.8 Gbps.
> This will cause mode to b
On Fri, 27 Mar 2020, Vipin Anand wrote:
> this patch adds hdr capabilities checks for Gen9 devices with
> lspcon support.
My earlier feedback to this patch holds. I don't really understand what
you're trying to achieve.
BR,
Jani.
>
> Signed-off-by: Vipin Anand
> ---
> drivers/gpu/drm/i915/dis
== Series Details ==
Series: drm/i915: from module params to device params (rev2)
URL : https://patchwork.freedesktop.org/series/54414/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8264 -> Patchwork_17233
Summary
---
Quoting Patchwork (2020-04-07 12:32:51)
> Possible regressions
>
> * igt@i915_selftest@live@execlists:
> - fi-skl-6700k2: [PASS][1] -> [DMESG-FAIL][2]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/fi-skl-6700k2/igt@i915_selftest@l...@execlists.html
>[2]
On Fri, 27 Mar 2020, Vipin Anand wrote:
> From: Uma Shankar
>
> LSPCON firmware exposes HDR capability through LPCON_CAPABILITIES
> DPCD register. LSPCON implementations capable of supporting
> HDR set HDR_CAPABILITY bit in LSPCON_CAPABILITIES to 1. This patch
> reads the same, detects the HDR ca
On Fri, 27 Mar 2020, "Shankar, Uma" wrote:
>> -Original Message-
>> From: Intel-gfx On Behalf Of Vipin
>> Anand
>> Sent: Friday, March 27, 2020 1:02 PM
>> To: intel-gfx@lists.freedesktop.org
>> Subject: [Intel-gfx] [PATCH v3 0/7] Enable HDR on Gen9 devices with lspcon
>> hdr
>> capabili
> -Original Message-
> From: Jani Nikula
> Sent: Tuesday, April 7, 2020 6:18 PM
> To: Shankar, Uma ; Anand, Vipin
> ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v3 0/7] Enable HDR on Gen9 devices with
> lspcon hdr
> capability
>
> On Fri, 27 Mar 2020, "Shankar,
On 06. 07. 18, 22:30, Rodrigo Vivi wrote:
> On Fri, Jul 06, 2018 at 03:04:24PM -0400, Peter Jones wrote:
>> This was sort of annoying me:
>>
>> random:~$ dmesg | tail -1
>> [523884.039227] [drm] Reducing the compressed framebuffer size. This may
>> lead to less power savings than a non-reduced-siz
> -Original Message-
> From: Jani Nikula
> Sent: Tuesday, April 7, 2020 4:45 PM
> To: Shankar, Uma ; intel-gfx@lists.freedesktop.org
> Cc: Vehmanen, Kai
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable DP Display Audio WA
>
> On Tue, 07 Apr 2020, Uma Shankar wrote:
> > Ena
If we find ourselves waiting on a MI_SEMAPHORE_WAIT, either within the
user batch or in our own preamble, the engine raises a
GT_WAIT_ON_SEMAPHORE interrupt. We can unmask that interrupt and so
respond to a semaphore wait by yielding the timeslice, if we have
another context to yield to!
The only
== Series Details ==
Series: series starting with [1/2] drm/i915/hdmi: remove unused
intel_hdmi_hdcp2_protocol()
URL : https://patchwork.freedesktop.org/series/75608/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8264 -> Patchwork_17234
===
== Series Details ==
Series: Consider DBuf bandwidth when calculating CDCLK (rev8)
URL : https://patchwork.freedesktop.org/series/74739/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a2d97b3a68fc drm/i915: Decouple cdclk calculation from modeset checks
9fe9c8a12e97 drm/i915: Fo
On Tue, Apr 07, 2020 at 04:02:56PM +0800, Zhenyu Wang wrote:
> On 2020.04.03 10:50:33 -0700, Rodrigo Vivi wrote:
> >
> > +Dave and Daniel,
> >
> > >
> > > I forgot to mention one thing for 5.7. We've fixed to change guest mem r/w
> > > from KVM to use new VFIO dma r/w instead in this series:
>
For certain DP VDSC bpp settings, hblank asserts before hblank_early,
leading to a bad audio state. Driver need to program "hblank early
enable" and "samples per line" parameters in AUDIO_CONFIG_BE
register.
This is Display Audio WA #1406928334 for 4k+VDSC usecase
applicable on DP encoders. Implem
== Series Details ==
Series: Consider DBuf bandwidth when calculating CDCLK (rev8)
URL : https://patchwork.freedesktop.org/series/74739/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8264 -> Patchwork_17235
Summary
---
On Tue, 07 Apr 2020, Rodrigo Vivi wrote:
> On Tue, Apr 07, 2020 at 04:02:56PM +0800, Zhenyu Wang wrote:
>> On 2020.04.03 10:50:33 -0700, Rodrigo Vivi wrote:
>> >
>> > +Dave and Daniel,
>> >
>> > >
>> > > I forgot to mention one thing for 5.7. We've fixed to change guest mem
>> > > r/w
>> > > f
On Tue, 07 Apr 2020, Uma Shankar wrote:
> For certain DP VDSC bpp settings, hblank asserts before hblank_early,
> leading to a bad audio state. Driver need to program "hblank early
> enable" and "samples per line" parameters in AUDIO_CONFIG_BE
> register.
>
> This is Display Audio WA #1406928334 f
Hi,
thanks Uma! It's good to see the implementation is this localized and
doesn't need changes elsewhere. Other reviewers already covered most
parts, but a few notes:
On Tue, 7 Apr 2020, Uma Shankar wrote:
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> + struct intel
> -Original Message-
> From: Kai Vehmanen
> Sent: Tuesday, April 7, 2020 7:42 PM
> To: Shankar, Uma
> Cc: intel-gfx@lists.freedesktop.org; Vehmanen, Kai
> Subject: Re: [Intel-gfx] [PATCH v3] drm/i915/display: Enable DP Display Audio
> WA
>
> Hi,
>
> thanks Uma! It's good to see the
On 07.04.2020 17:35, Arnaldo Carvalho de Melo wrote:
> Em Tue, Apr 07, 2020 at 11:30:14AM -0300, Arnaldo Carvalho de Melo escreveu:
>> [perf@five ~]$ type perf
>> perf is hashed (/home/perf/bin/perf)
>> [perf@five ~]$ getcap /home/perf/bin/perf
>> /home/perf/bin/perf = cap_sys_ptrace,cap_syslog,38+
== Series Details ==
Series: series starting with [v4,1/3] drm/i915/perf: break OA config buffer
object in 2
URL : https://patchwork.freedesktop.org/series/75612/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8264 -> Patchwork_17236
===
On Mon, Apr 06, 2020 at 06:11:50PM -0700, José Roberto de Souza wrote:
> Moving the code to return the digital port of the aux channel also
> removing the intel_phy_is_tc() to make it generic.
> digital_port will be needed in icl_tc_phy_aux_power_well_enable()
> so adding it as a parameter to icl_t
On Mon, Apr 06, 2020 at 06:11:51PM -0700, José Roberto de Souza wrote:
> This is a similar function to intel_aux_power_domain() but it do not
> care about TBT ports, this will be needed by ICL TC sequences.
>
> v2:
> - renamed to intel_legacy_aux_to_power_domain()
>
> Cc: Imre Deak
> Cc: Cooper
On Tue, Apr 07, 2020 at 09:38:47AM +0200, Daniel Vetter wrote:
> On Fri, Apr 03, 2020 at 11:40:04PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Replace the use of mode->private_flags with a truly private bitmaks
> > in our own crtc state. We also need a copy in the crtc itself so
On Mon, Apr 06, 2020 at 06:11:52PM -0700, José Roberto de Souza wrote:
> This is a preparation for ICL TC cold exit sequences.
>
> v2:
> - renamed new functions to hsw_power_well_enable_prepare()/complete()
>
> Signed-off-by: José Roberto de Souza
Reviewed-by: Imre Deak
> ---
> .../drm/i915/
== Series Details ==
Series: drm/i915/gt: Yield the timeslice if caught waiting on a user semaphore
(rev4)
URL : https://patchwork.freedesktop.org/series/72724/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8264 -> Patchwork_17237
=
== Series Details ==
Series: drm/i915/display: Enable DP Display Audio WA
URL : https://patchwork.freedesktop.org/series/75582/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8264_full -> Patchwork_17227_full
Summary
---
> -Original Message-
> From: Jani Nikula
> Sent: Tuesday, April 7, 2020 7:26 PM
> To: Shankar, Uma ; intel-gfx@lists.freedesktop.org
> Cc: Vehmanen, Kai ; Gupta, Anshuman
> ; Shankar, Uma
> Subject: Re: [PATCH v3] drm/i915/display: Enable DP Display Audio WA
>
> On Tue, 07 Apr 2020, U
== Series Details ==
Series: series starting with [1/5] drm: report dp downstream port type as a
subconnector property
URL : https://patchwork.freedesktop.org/series/75585/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8264_full -> Patchwork_17228_full
===
On Mon, Apr 06, 2020 at 06:11:53PM -0700, José Roberto de Souza wrote:
> This is required for legacy/static TC ports as IOM is not aware of
> the connection and will not trigger the TC cold exit.
>
> Just request PCODE to exit TCCOLD is not enough as it could enter
> again before driver makes use
1 - 100 of 195 matches
Mail list logo
