== Series Details ==
Series: RFC: console: hack up console_lock more v3 (rev3)
URL : https://patchwork.freedesktop.org/series/60467/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6072_full -> Patchwork_12998_full
Summary
--
== Series Details ==
Series: Extend BT2020 support in iCSC and fixes (rev2)
URL : https://patchwork.freedesktop.org/series/60480/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6072_full -> Patchwork_12997_full
Summary
-
Forward to i915 mailing list and post the question again so people knows
what are the key concerns.
The background is that Linux community is going to collect and report
the reserved memory ranges of an assigned device to VFIO driver, and any
mapped address will be checked against the reserved ra
== Series Details ==
Series: drm/i915/dp: Support for DP YCbCr4:2:0 outputs (rev2)
URL : https://patchwork.freedesktop.org/series/60404/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6072 -> Patchwork_13000
Summary
---
== Series Details ==
Series: drm/i915: Add support for asynchronous display power disabling (rev4)
URL : https://patchwork.freedesktop.org/series/60242/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6072_full -> Patchwork_12995_full
VSC SDP Payload for PSR is one of data block type of SDP (Secondaray Data
Packet). In order to generalize SDP packet structure name, it renames
struct edp_vsc_psr to struct dp_sdp. And each SDP data blocks have
different usages, each SDP type has different reserved data blocks and
Video_Stream_Conf
When YCBCR 4:2:0 outputs is used for DP, we should program YCBCR 4:2:0 to
MSA and VSC SDP.
As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication of Color
Encoding Format and Content Color Gamut] while sending YCBCR 420 signals
we should program MSA MISC1 fields which indicate VSC SDP for t
Bspec describes that GEN10 only supports capability of YUV 4:2:0 output to
HDMI port and GEN11 supports capability of YUV 4:2:0 output to both DP and
HDMI ports.
v2: Minor style fix.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_dp.c | 3 +++
1 fi
On Gen 11 platform, to enable resolutions like 5K@120 (or higher) we need
to use DSC (DP 1.4) or YCbCr4:2:0 (DP 1.3 or 1.4) on DP.
In order to support YCbCr4:2:0 on DP we need to program YCBCR 4:2:0
to MSA and VSC SDP.
And Link M/N values are calculated and applied based on the Full Clock
forYCbCr4
Data M/N calculations were assumed a bpp as RGB format. But when we are
using YCbCr 4:2:0 output format on DP, we should change bpp calculations
as YCbCr 4:2:0 format. The pipe_bpp value was assumed RGB format,
therefore, it was multiplied with 3. But YCbCr 4:2:0 requires a multiplier
value to 1.5.
This patch checks a support of YCBCR420 outputs on an encoder level.
If the input mode is YCBCR420-only mode then it prepares DP as an YCBCR420
output, else it continues with RGB output mode.
It set output_format to INTEL_OUTPUT_FORMAT_YCBCR420 in order to using
a pipe scaler as RGB to YCbCr 4:4:4.
Function intel_pixel_encoding_setup_vsc handles vsc header and data block
setup for pixel encoding / colorimetry format.
Setup VSC header and data block in function intel_pixel_encoding_setup_vsc
for pixel encoding / colorimetry format as per dp 1.4a spec,
section 2.2.5.7.1, table 2-119: VSC SDP H
On Wed, 2019-05-08 at 20:58 +0300, Ville Syrjälä wrote:
> On Wed, May 08, 2019 at 11:17:56AM +0300, Gwan-gyeong Mun wrote:
> > Data M/N calculations were assumed a bpp as RGB format. But when we
> > are
> > using YCbCr 4:2:0 output format on DP, we should change bpp
> > calculations
> > as YCbCr 4:
On Wed, 2019-05-08 at 20:56 +0300, Ville Syrjälä wrote:
> On Wed, May 08, 2019 at 11:17:54AM +0300, Gwan-gyeong Mun wrote:
> > Function intel_pixel_encoding_setup_vsc handles vsc header and data
> > block
> > setup for pixel encoding / colorimetry format.
> >
> > Setup VSC header and data block in
On Wed, 2019-05-08 at 20:32 +0300, Ville Syrjälä wrote:
> On Wed, May 08, 2019 at 11:17:53AM +0300, Gwan-gyeong Mun wrote:
> > SDP VSC Header and Data Block follow DP 1.4a spec, section
> > 2.2.5.7.5,
> > chapter "VSC SDP Payload for Pixel Encoding/Colorimetry Format".
> >
> > Signed-off-by: Gwan-
== Series Details ==
Series: drm/i915/icl: Handle YCbCr to RGB conversion for BT2020 case (rev2)
URL : https://patchwork.freedesktop.org/series/60473/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6072_full -> Patchwork_12994_full
==
== Series Details ==
Series: drm/i915: GTT remapping for display
URL : https://patchwork.freedesktop.org/series/60469/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6072_full -> Patchwork_12991_full
Summary
---
**SUC
== Series Details ==
Series: drm/i915: Truly bump ready tasks ahead of busywaits
URL : https://patchwork.freedesktop.org/series/60486/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6072 -> Patchwork_12999
Summary
---
In commit b7404c7ecb38 ("drm/i915: Bump ready tasks ahead of
busywaits"), I tried cutting a corner in order to not install a signal
for each of our dependencies, and only listened to requests on which we
were intending to busywait. The compromise that was made was that
instead of then being able to
== Series Details ==
Series: RFC: console: hack up console_lock more v3 (rev3)
URL : https://patchwork.freedesktop.org/series/60467/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6072 -> Patchwork_12998
Summary
---
*
== Series Details ==
Series: Extend BT2020 support in iCSC and fixes (rev2)
URL : https://patchwork.freedesktop.org/series/60480/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6072 -> Patchwork_12997
Summary
---
**SU
console_trylock, called from within printk, can be called from pretty
much anywhere. Including try_to_wake_up. Note that this isn't common,
usually the box is in pretty bad shape at that point already. But it
really doesn't help when then lockdep jumps in and spams the logs,
potentially obscuring t
Input CSC Co-efficients for BT601 and BT709 YCbCR to RGB
conversion were slightly off. Fixed the same.
v2: Fixed the co-eficients as there was issue with reference
matrix, spotted by Ville.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_sprite.c | 24
1 file
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Friday, May 10, 2019 12:54 AM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; maarten.lankho...@linux.intel.com; Sharma,
>Shashank
>Subject: Re: [PATCH 3/3] drm/i915/icl: Fixed Input CSC Co-ef
== Series Details ==
Series: Extend BT2020 support in iCSC and fixes
URL : https://patchwork.freedesktop.org/series/60480/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6072 -> Patchwork_12996
Summary
---
**SUCCESS**
On Fri, May 10, 2019 at 12:41:48AM +0530, Uma Shankar wrote:
> Input CSC Co-efficients for BT601 and BT709 YCbCR to RGB
> conversion were slightly off. Fixed the same.
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/intel_sprite.c | 24
> 1 file changed, 12 i
Currently input csc for YCbCR to RGB conversion handles only
BT601 and Bt709. Extending it to support BT2020 as well.
v2: Fixed the co-efficients for LR to FR conversion,
as suggested by Ville.
v3: Fixed Y Pre-offset in case of Full Range YCbCr as suggested
by Ville.
v4: Split the v2 and v3 chan
Input CSC Co-efficients for BT601 and BT709 YCbCR to RGB
conversion were slightly off. Fixed the same.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_sprite.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_spri
Fixed Y Pre-offset in case of Full Range YCbCr.
Reviewed-by: Ville Syrjälä
Suggested-by: Ville Syrjälä
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_sprite.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gp
This series adds support for BT2020 YCbCr to RGB conversion
using input CSC. This also fixes issues with BT601 and BT709
coefficients.
Uma Shankar (3):
drm/i915/icl: Handle YCbCr to RGB conversion for BT2020 case
drm/i915/icl: Fix Y pre-offset for Full Range YCbCr
drm/i915/icl: Fixed Input C
== Series Details ==
Series: drm/i915: Add support for asynchronous display power disabling (rev4)
URL : https://patchwork.freedesktop.org/series/60242/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6072 -> Patchwork_12995
== Series Details ==
Series: drm/i915: Add support for asynchronous display power disabling (rev4)
URL : https://patchwork.freedesktop.org/series/60242/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Add support for tracking wakerefs w/o powe
== Series Details ==
Series: drm/i915: Add support for asynchronous display power disabling (rev4)
URL : https://patchwork.freedesktop.org/series/60242/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
cf4ea8e124c3 drm/i915: Add support for tracking wakerefs w/o power-on guarantee
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Thursday, May 9, 2019 10:02 PM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville ;
>Lankhorst,
>Maarten
>Subject: Re: [Intel-gfx] [v3] drm/i915/icl: Handle YCbCr to RGB conversio
On Thu, May 09, 2019 at 08:43:25PM +0300, Souza, Jose wrote:
> On Thu, 2019-05-09 at 20:34 +0300, Imre Deak wrote:
> > The power get/put was added in
> >
> > commit 1c767b339b39 ("drm/i915: take display port power domain in DP
> > HPD handler")
> > Author: Imre Deak
> > Date: Mon Aug 18 14:42:4
On Thu, 2019-05-09 at 20:34 +0300, Imre Deak wrote:
> The power get/put was added in
>
> commit 1c767b339b39 ("drm/i915: take display port power domain in DP
> HPD handler")
> Author: Imre Deak
> Date: Mon Aug 18 14:42:42 2014 +0300
>
> to account for the HW access in ibx_digital_port_connecte
By disabling a power domain asynchronously we can restrict holding a
reference on that power domain to the actual code sequence that
requires the power to be on for the HW access it's doing, by also
avoiding unneeded on-off-on togglings of the power domain (since the
disabling happens with a delay)
This is v3 of [1] addressing the comments from Chris and Ville and
fixing some checkpatch errors.
[1] https://patchwork.freedesktop.org/series/60242/
Cc: Ville Syrjala
Cc: Chris Wilson
Cc: Rodrigo Vivi
Cc: José Roberto de Souza
Imre Deak (11):
drm/i915: Add support for tracking wakerefs w/
Make sure we print and drop the wakeref tracking info during pm_cleanup
even if there are wakeref holders (either raw-wakeref or wakelock
holders). Dropping the wakeref tracking means that a late put on the ref
will WARN since the wakeref will be unknown, but that is rightly so,
since the put is la
On ICL we have to make sure that we enable the AUX power domain in a
controlled way (corresponding to the port's actual TypeC mode). Since
the PPS lock - which takes an AUX power ref - is only needed on
eDP on all platforms and eDP/DP on VLV/CHV avoid taking it in all
other cases.
v2:
- Clarify co
There isn't a separate power domain specific to PLLs. When programming
them we require the same power domain to be enabled which is needed when
accessing other display core parts (not specific to any
pipe/port/transcoder). This corresponds to the DISPLAY_CORE domain added
previously in this patchse
We are not calling this function for eDP, so add an early assert about
this for clarity.
Cc: Ville Syrjälä
Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/inte
In a follow-up patch we will restrict holding the reference on the AUX
power domain to the AUX transfer function. To avoid the unnecessary
on-off-on power togglings drop the reference asynchronously.
There is no reason we couldn't do this in general and also put the
reference asynchronously in pps
It's useful to track runtime PM refs that don't guarantee a device
power-on state to the rest of the driver. One such case is holding a
reference that will be put asynchronously, during which normal users
without their own reference shouldn't access the HW. A follow-up patch
will add support for di
There is no reason why we couldn't verify the power domains state during
suspend in all cases, so do that. I overlooked this when originally
adding the check.
Cc: Chris Wilson
Signed-off-by: Imre Deak
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 6 +++---
1 file chan
Add an assert that we don't use TypeC ports for eDP. That may in theory
be possible on TypeC legacy ports, but I'm not sure if that's a
practical scenario, so let's deal with that only if there's a use case.
Adding support for that wouldn't be too difficult, since TypeC mode
switching is not possib
We don't need the AUX power for the whole duration of the detect, only
when we're doing AUX transfers. The AUX transfer function takes its own
reference on the AUX power domain already. The two places during detect
which access display core registers (not specific to a
pipe/port/transcoder) only ne
The power get/put was added in
commit 1c767b339b39 ("drm/i915: take display port power domain in DP HPD
handler")
Author: Imre Deak
Date: Mon Aug 18 14:42:42 2014 +0300
to account for the HW access in ibx_digital_port_connected(). This
latter call was in turn removed in
commit 7d23e3c37bb3 (
Hello,
On Tue, May 07, 2019 at 12:50:50PM -0700, Welty, Brian wrote:
> There might still be merit in having a 'device mem' cgroup controller.
> The resource model at least is then no longer mixed up with host memory.
> RDMA community seemed to have some interest in a common controller at
> least f
On Thu, May 9, 2019 at 4:56 PM Petr Mladek wrote:
>
> On Thu 2019-05-09 14:09:03, Daniel Vetter wrote:
> > console_trylock, called from within printk, can be called from pretty
> > much anywhere. Including try_to_wake_up. Note that this isn't common,
> > usually the box is in pretty bad shape at t
== Series Details ==
Series: drm/i915/icl: Handle YCbCr to RGB conversion for BT2020 case (rev2)
URL : https://patchwork.freedesktop.org/series/60473/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6072 -> Patchwork_12994
Su
On Thu, May 09, 2019 at 09:57:19PM +0530, Uma Shankar wrote:
> Currently input csc for YCbCR to RGB conversion handles only
> BT601 and Bt709. Extending it to support BT2020 as well.
>
> v2: Fixed the co-efficients for LR to FR conversion,
> as suggested by Ville.
>
> v3: Fixed Y Pre-offset in ca
On Thu, May 09, 2019 at 09:19:43AM +0300, Imre Deak wrote:
> This patchset is v2 of [1]. The main change is the rework of patch 1
> based on Chris' feedback.
>
> Cc: Ville Syrjala
> Cc: Chris Wilson
> Cc: Rodrigo Vivi
> Cc: José Roberto de Souza
>
> [1] https://patchwork.freedesktop.org/serie
== Series Details ==
Series: drm/i915/icl: Handle YCbCr to RGB conversion for BT2020 case
URL : https://patchwork.freedesktop.org/series/60473/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6072 -> Patchwork_12993
Summary
-
On Thu, May 09, 2019 at 06:57:56PM +0300, Ville Syrjälä wrote:
> On Thu, May 09, 2019 at 09:19:50AM +0300, Imre Deak wrote:
> > We don't need the AUX power for the whole duration of the detect, only
> > when we're doing AUX transfers. The AUX transfer function takes its own
> > reference on the AUX
On Thu, May 09, 2019 at 06:50:42PM +0300, Ville Syrjälä wrote:
> On Thu, May 09, 2019 at 09:19:51AM +0300, Imre Deak wrote:
> > The power get/put was added in
> >
> > commit 1c767b339b3938b19076ffdc9d70aa1e4235a45b
> > Author: Imre Deak
> > Date: Mon Aug 18 14:42:42 2014 +0300
> >
> > drm/
Currently input csc for YCbCR to RGB conversion handles only
BT601 and Bt709. Extending it to support BT2020 as well.
v2: Fixed the co-efficients for LR to FR conversion,
as suggested by Ville.
v3: Fixed Y Pre-offset in case of Full Range YCbCr as suggested
by Ville.
Signed-off-by: Uma Shankar
On Thu, May 09, 2019 at 09:19:50AM +0300, Imre Deak wrote:
> We don't need the AUX power for the whole duration of the detect, only
> when we're doing AUX transfers. The AUX transfer function takes its own
> reference on the AUX power domain already. The two places during detect
> which access disp
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Thursday, May 9, 2019 9:00 PM
>To: Shankar, Uma
>Cc: Sharma, Shashank ; intel-
>g...@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [PATCH] drm/i915/icl: Handle YCbCr to RGB conversion
>for
>BT2020 c
On Thu, May 09, 2019 at 09:19:51AM +0300, Imre Deak wrote:
> The power get/put was added in
>
> commit 1c767b339b3938b19076ffdc9d70aa1e4235a45b
> Author: Imre Deak
> Date: Mon Aug 18 14:42:42 2014 +0300
>
> drm/i915: take display port power domain in DP HPD handle
>
> to account for the H
On Thu, May 09, 2019 at 03:08:40PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> >Sent: Thursday, May 9, 2019 8:28 PM
> >To: Shankar, Uma
> >Cc: Sharma, Shashank ; intel-
> >g...@lists.freedesktop.org
> >Subject: Re:
== Series Details ==
Series: drm/i915: GTT remapping for display
URL : https://patchwork.freedesktop.org/series/60469/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6072 -> Patchwork_12991
Summary
---
**SUCCESS**
== Series Details ==
Series: RFC: console: hack up console_lock more v3 (rev2)
URL : https://patchwork.freedesktop.org/series/60467/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/generated/compile.h
On Wed 2019-05-08 10:17:12, Daniel Vetter wrote:
> On Mon, May 06, 2019 at 01:24:48PM +0200, Petr Mladek wrote:
> > On Mon 2019-05-06 11:38:13, Daniel Vetter wrote:
> > > On Mon, May 06, 2019 at 10:26:28AM +0200, Petr Mladek wrote:
> > > > On Mon 2019-05-06 10:16:14, Petr Mladek wrote:
> > > > > On
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Thursday, May 9, 2019 8:28 PM
>To: Shankar, Uma
>Cc: Sharma, Shashank ; intel-
>g...@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [PATCH] drm/i915/icl: Handle YCbCr to RGB conversion
>for
>BT2020 c
== Series Details ==
Series: drm/i915: GTT remapping for display
URL : https://patchwork.freedesktop.org/series/60469/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Add a new "remapped" gtt_view
+drivers/gpu/drm/i915/i915_gem_gtt.c:3633:34:
Currently input csc for YCbCR to RGB conversion handles only
BT601 and Bt709. Extending it to support BT2020 as well.
v2: Fixed the co-efficients for LR to FR conversion,
as suggested by Ville.
Signed-off-by: Uma Shankar
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_sprite.c |
On Thu, May 09, 2019 at 02:54:19PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> >Sent: Tuesday, May 7, 2019 9:08 PM
> >To: Shankar, Uma
> >Cc: Sharma, Shashank ; intel-
> >g...@lists.freedesktop.org
> >Subject: Re: [
On Thu 2019-05-09 14:09:03, Daniel Vetter wrote:
> console_trylock, called from within printk, can be called from pretty
> much anywhere. Including try_to_wake_up. Note that this isn't common,
> usually the box is in pretty bad shape at that point already. But it
> really doesn't help when then loc
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Tuesday, May 7, 2019 9:08 PM
>To: Shankar, Uma
>Cc: Sharma, Shashank ; intel-
>g...@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [PATCH] drm/i915/icl: Handle YCbCr to RGB conversion
>for
>BT2020 ca
== Series Details ==
Series: drm/i915: GTT remapping for display
URL : https://patchwork.freedesktop.org/series/60469/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e1a44e3ca92e drm/i915: Add a new "remapped" gtt_view
-:98: CHECK:LINE_SPACING: Please don't use multiple blank li
On Thu, May 09, 2019 at 01:05:26AM +0530, Shashank Sharma wrote:
> ICL introduces a new gamma correction mode in display engine, called
> multi-segmented-gamma mode. This mode allows users to program the
> darker region of the gamma curve with sueprfine precision. An
> example use case for this is
On Thu, May 09, 2019 at 03:06:09PM +0200, Daniel Vetter wrote:
> On Thu, May 9, 2019 at 2:31 PM Peter Zijlstra wrote:
> > On Thu, May 09, 2019 at 02:09:03PM +0200, Daniel Vetter wrote:
> > > Fix this by creating a prinkt_safe_up() which calls wake_up_process
> > > outside of the spinlock. This isn
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: c16fd9be70faf3c49a61700efd16018dd910e390
commit: 6498bf5800a302ef69e7f4914e727893f278bb2f [4/6] drm: revocation check at
drm subsystem
reproduce:
# apt-get install sparse
git checkout 6498bf5800a302ef69e7
Fixes: 6498bf5800a3 ("drm: revocation check at drm subsystem")
Signed-off-by: kbuild test robot
---
drm_hdcp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index 5e54095..dc0beb3 100644
--- a/drivers/gpu/drm/drm_hd
On Thu, May 9, 2019 at 2:31 PM Peter Zijlstra wrote:
> On Thu, May 09, 2019 at 02:09:03PM +0200, Daniel Vetter wrote:
> > Fix this by creating a prinkt_safe_up() which calls wake_up_process
> > outside of the spinlock. This isn't correct in full generality, but
> > good enough for console_lock:
>
On Thu, May 09, 2019 at 11:32:57AM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2019-05-06 08:45:53)
> > +/**
> > + * printk_safe_up - release the semaphore in console_unlock
> > + * @sem: the semaphore to release
> > + *
> > + * Release the semaphore. Unlike mutexes, up() may be called fro
On Wed, May 08, 2019 at 12:46:09PM +0200, Maarten Lankhorst wrote:
> Op 25-04-2019 om 18:29 schreef Ville Syrjala:
> > From: Ville Syrjälä
> >
> > On HSW the pipe A panel fitter lives inside the display power well,
> > and the input MUX for the EDP transcoder needs to be configured
> > appropriate
From: Ville Syrjälä
With gtt remapping plugged in we can simply raise the stride
limit on gen4+. Let's just pick the limit to match the render
engine max stride (256KiB on gen7+, 128KiB on gen4+).
No remapping CCS because the virtual address of each page actually
matters due to the new hash mode
From: Ville Syrjälä
Align dumb buffer stride to 4k if the fb will be big enough to
require gtt remapping.
v2: Leave the stride alone for buffers that look to be for the cursor
v3: Make it not a hack (Daniel)
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_gem.c
Quoting Daniel Vetter (2019-05-09 13:09:03)
> console_trylock, called from within printk, can be called from pretty
> much anywhere. Including try_to_wake_up. Note that this isn't common,
> usually the box is in pretty bad shape at that point already. But it
> really doesn't help when then lockdep
On Thu, 09 May 2019, Daniel Drake wrote:
> Hi,
>
>
> On Thu, Apr 25, 2019 at 4:27 AM Paulo Zanoni wrote:
>>
>> Em qua, 2019-04-24 às 20:58 +0100, Chris Wilson escreveu:
>> > Quoting Jian-Hong Pan (2019-04-23 10:28:10)
>> > > From: Daniel Drake
>> > >
>> > > On many (all?) the Gemini Lake systems
From: Ville Syrjälä
Reorganize some fb stride checking code a bit to prepare for
gtt remapping. And do a bit of s/pitch/stride/ renaming in the
process for a bit more uniformity (apart from the whole
fb->pitches[] thing).
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915
On Thu, May 09, 2019 at 02:09:03PM +0200, Daniel Vetter wrote:
> Fix this by creating a prinkt_safe_up() which calls wake_up_process
> outside of the spinlock. This isn't correct in full generality, but
> good enough for console_lock:
>
> - console_lock doesn't use interruptible or killable or tim
From: Ville Syrjälä
With gtt remapping in place we can use arbitrarily large
framebuffers. Let's bump the limits to 16kx16k on gen7+.
The limit was chosen to match the maximum 2D surface size
of the 3D engine.
With the remapping we could easily go higher than that for the
display engine. However
From: Ville Syrjälä
Here's a new version of the GTT remapping series.
Changes since last time:
- Split up some code shuffling from the main patch
- Made the dumb stride alignment proper
- Finished the test case
- Fixed a few bugs found in testing
The one thing I didn't do is make remapping alwa
From: Ville Syrjälä
To overcome display engine stride limits we'll want to remap the
pages in the GTT. To that end we need a new gtt_view type which
is just like the "rotated" type except not rotated.
v2: Use intel_remapped_plane_info base type
s/unused/unused_mbz/ (Chris)
Separate BUILD
From: Ville Syrjälä
The display engine stride limits are getting in our way. On SKL+
we are limited to 8k pixels, which is easily exceeded with three
4k displays. To overcome this limitation we can remap the pages
in the GTT to provide the display engine with a view of memory
with a smaller strid
From: Ville Syrjälä
Add a live selftest to excercise rotated/remapped vmas. We simply
write through the rotated/remapped vma, and confirm that the data
appears in the right page when read through the normal vma.
Not sure what the fallout of making all rotated/remapped vmas
mappable/fenceable wou
From: Ville Syrjälä
Extend the rotated vma mock selftest to cover remapped vmas as
well.
TODO: reindent the loops I guess? Left like this for now to
ease review
v2: Include the vma type in the error message (Chris)
v3: Deal with trimmed sg
v4: Drop leftover debugs
Cc: Chris Wilson
Reviewed-by
On 09/05/2019 11:51, Kahola, Mika wrote:
On Wed, 2019-04-10 at 13:11 +0100, Tvrtko Ursulin wrote:
On 10/04/2019 12:48, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-04-10 12:43:22)
@@ -754,8 +768,8 @@ static void test_flip(int i915, int vgem,
unsigned hang)
uint32_t offse
console_trylock, called from within printk, can be called from pretty
much anywhere. Including try_to_wake_up. Note that this isn't common,
usually the box is in pretty bad shape at that point already. But it
really doesn't help when then lockdep jumps in and spams the logs,
potentially obscuring t
Hi,
On Thu, Apr 25, 2019 at 4:27 AM Paulo Zanoni wrote:
>
> Em qua, 2019-04-24 às 20:58 +0100, Chris Wilson escreveu:
> > Quoting Jian-Hong Pan (2019-04-23 10:28:10)
> > > From: Daniel Drake
> > >
> > > On many (all?) the Gemini Lake systems we work with, there is frequent
> > > momentary graph
On Wed, 2019-04-10 at 13:11 +0100, Tvrtko Ursulin wrote:
> On 10/04/2019 12:48, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-04-10 12:43:22)
> > > @@ -754,8 +768,8 @@ static void test_flip(int i915, int vgem,
> > > unsigned hang)
> > > uint32_t offsets[4] = {};
> > >
On Thu, May 09, 2019 at 09:17:54AM +0100, Chris Wilson wrote:
> Quoting Imre Deak (2019-05-09 07:19:47)
> > By disabling a power domain asynchronously we can restrict holding a
> > reference on that power domain to the actual code sequence that
> > requires the power to be on for the HW access it's
Quoting Daniel Vetter (2019-05-06 08:45:53)
> +/**
> + * printk_safe_up - release the semaphore in console_unlock
> + * @sem: the semaphore to release
> + *
> + * Release the semaphore. Unlike mutexes, up() may be called from any
> + * context and even by tasks which have never called down().
> +
== Series Details ==
Series: drm/i915: Add support for asynchronous display power disabling (rev3)
URL : https://patchwork.freedesktop.org/series/60242/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6068_full -> Patchwork_12990_full
On Thu, May 9, 2019 at 11:24 AM Sergey Senozhatsky
wrote:
>
> On (05/02/19 21:42), Daniel Vetter wrote:
> [..]
> > @@ -469,6 +469,8 @@ static enum hrtimer_restart watchdog_timer_fn(struct
> > hrtimer *hrtimer)
> > add_taint(TAINT_SOFTLOCKUP, LOCKDEP_STILL_OK);
> > if (
Hi Dave & Daniel,
Still rather quiet, most issues seem to have been fixed during CI testing.
For i915, just two fixes to the request semaphore ordering code.
For GVT a couple regression and static checker fixes.
Best Regards,
Joonas
***
drm-intel-next-fixes-2019-05-09:
- Two fixes for the fr
On Thu, May 09, 2019 at 09:03:04AM +0100, Chris Wilson wrote:
> Quoting Imre Deak (2019-05-09 07:19:44)
> > It's useful to track runtime PM refs that don't guarantee a device
> > power-on state to the rest of the driver. One such case is holding a
> > reference that will be put asynchronously, duri
1 - 100 of 107 matches
Mail list logo
