Added bandwidth calculation algorithm and checks,
similar way as it was done for ICL, some constants
were corrected according to BSpec.
Signed-off-by: Stanislav Lisovskiy
v2: Start using same icl_get_bw_info function to avoid
code duplication. Moved mpagesize to memory info
related
== Series Details ==
Series: drm/i915: Expose engine properties via sysfs
URL : https://patchwork.freedesktop.org/series/66849/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
638a5bf99d2a drm/i915: Expose engine properties via sysfs
-:36: WARNING:FILE_PATH_CHANGES: added, moved
== Series Details ==
Series: drm/i915: Lock signaler timeline while navigating (rev3)
URL : https://patchwork.freedesktop.org/series/66799/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6910_full -> Patchwork_14434_full
Subject prefix "drm/i915/display" is a fairly broad
statement. "drm/i915/color" perhaps.
Please add a commit message. See git log. We don't approve of empty
commit messages.
On Tue, 17 Sep 2019, Swati Sharma wrote:
> Signed-off-by: Swati Sharma
> ---
>
Batch buffer will be created through dsb-reg-write function which can have
single/multiple request based on usecase and once the buffer is ready
commit function will trigger the execution of the batch buffer. All
the registers will be updated simultaneously.
v1: Initial version.
v2: Optimized
Enabling DSB by setting 1 to has_dsb flag for gen12.
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Reviewed-by: Shashank Sharma
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/i915_pci.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
Gamma lut programming can be programmed using DSB
where bulk register programming can be done using indexed
register write which takes number of data and the mmio offset
to be written.
Currently enabled for 12-bit gamma LUT which is enabled by
default and later 8-bit/10-bit will be enabled in
Display State Buffer (DSB) is hardware capability which allows driver
to batch submit HW programming.
As part of initial enablement common api created which currently used
to program gamma lut proramming.
Going forwad DSB support can be added for HDR and flip related operation.
HSDES:
== Series Details ==
Series: drm/i915: Fix S0ix/S3 suspend stress issue
URL : https://patchwork.freedesktop.org/series/66839/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6911 -> Patchwork_14438
Summary
---
== Series Details ==
Series: drm/i915: Add TigerLake bandwidth checking
URL : https://patchwork.freedesktop.org/series/66817/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6910_full -> Patchwork_14433_full
Summary
---
On 16/09/2019 22:17, Umesh Nerlige Ramappa wrote:
On Sun, Sep 15, 2019 at 02:24:41PM +0300, Lionel Landwerlin wrote:
On 14/09/2019 02:06, Umesh Nerlige Ramappa wrote:
OA perf unit supports non-power of 2 report sizes. Enable support for
these sizes in the driver.
Signed-off-by: Umesh Nerlige
On Tue, Sep 17, 2019 at 04:48:51PM +0200, Michel Dänzer wrote:
> On 2019-09-17 2:09 p.m., Daniel Vetter wrote:
> > commit 4f5368b5541a902f6596558b05f5c21a9770dd32
> > Author: Daniel Vetter
> > Date: Fri Jun 14 08:17:23 2019 +0200
> >
> > drm/kms: Catch mode_object lifetime errors
> >
> >
On Tue, Sep 17, 2019 at 03:40:29PM -0400, Lyude Paul wrote:
> Reviewed-by: Lyude Paul
Thanks for taking a look, pushed to drm-misc-next.
-Daniel
>
> On Tue, 2019-09-17 at 14:09 +0200, Daniel Vetter wrote:
> > Current code is quite a mess unfortunately, so also add a todo.rst
> > entry to maybe
== Series Details ==
Series: DSB enablement. (rev7)
URL : https://patchwork.freedesktop.org/series/63013/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6912 -> Patchwork_14439
Summary
---
**SUCCESS**
No
On 2019/9/18 上午10:57, Tian, Kevin wrote:
From: Jason Wang [mailto:jasow...@redhat.com]
Sent: Tuesday, September 17, 2019 6:17 PM
On 2019/9/17 下午4:09, Tian, Kevin wrote:
From: Jason Wang
Sent: Thursday, September 12, 2019 5:40 PM
Currently, except for the crate and remove. The rest fields of
Op 18-09-2019 om 02:33 schreef Manasi Navare:
> After the state is committed, we readout the HW registers and compare
> the HW state with the SW state that we just committed.
> For Transcdoer port sync, we add master_transcoder and the
> salves bitmask to the crtc_state, hence we need to read
DSB can program large set of data through indexed register write
(opcode 0x9) in one shot. DSB feature can be used for bulk register
programming e.g. gamma lut programming, HDR meta data programming.
v1: initial version.
v2: simplified code by using ALIGN(). (Chris)
v3: ascii table added as code
This patch adds a function, which will internally get the gem buffer
for DSB engine. The GEM buffer is from global GTT, and is mapped into
CPU domain, contains the data + opcode to be feed to DSB engine.
v1: Initial version.
v2:
- removed some unwanted code. (Chris)
- Used
As per bspec check for DSB status before programming any
of its register. Inline function added to check the dsb status.
Cc: Michel Thierry
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Reviewed-by: Shashank Sharma
Signed-off-by: Animesh Manna
---
DSB support single register write through opcode 0x1. Generic
api created which accumulate all single register write in a batch
buffer and once DSB is triggered, it will program all the registers
at the same time.
v1: Initial version.
v2: Unused macro removed and cosmetic changes done. (Shashank)
Display State Buffer(DSB) is a new hardware capability, introduced
in GEN12 display. DSB allows a driver to batch-program display HW
registers.
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Reviewed-by: Shashank Sharma
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/i915_drv.h
DSB will be used for performance improvement for some special scenario.
DSB engine will be enabled based on need and after completion of its work
will be disabled. Api added for enable/disable operation by using DSB_CTRL
register.
v1: Initial version.
v2: POSTING_READ added after writing control
Added docbook info regarding Display State Buffer(DSB) which
is added from gen12 onwards to batch submit display HW programming.
v1: Initial version as RFC.
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Signed-off-by: Animesh Manna
---
Documentation/gpu/i915.rst | 9
Op 17-09-2019 om 18:37 schreef Manasi Navare:
> On Tue, Sep 17, 2019 at 05:04:28PM +0200, Maarten Lankhorst wrote:
>> Op 09-09-2019 om 05:43 schreef Manasi Navare:
>>> This clears the transcoder port sync bits of the TRANS_DDI_FUNC_CTL2
>>> register during crtc_disable().
>>>
>>> Cc: Ville Syrjälä
On Tue, Sep 03, 2019 at 10:17:14AM +0200, Daniel Vetter wrote:
> On Wed, Aug 21, 2019 at 11:50:29PM +0200, Daniel Vetter wrote:
> > We can't copy_*_user while holding reservations, that will (soon even
> > for nouveau) lead to deadlocks. And it breaks the cross-driver
> > contract around dma_resv.
== Series Details ==
Series: DSB enablement. (rev7)
URL : https://patchwork.freedesktop.org/series/63013/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915/dsb: feature flag added for display state buffer.
Okay!
Preliminary stub to add engines underneath /sys/class/drm/cardN/, so
that we can expose properties on each engine to the sysadmin.
To start with we have basic analogues of the i915_query ioctl so that we
can pretty print engine discovery from the shell, and flesh out the
directory structure.
== Series Details ==
Series: DSB enablement. (rev7)
URL : https://patchwork.freedesktop.org/series/63013/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
580c8790ff0a drm/i915/dsb: feature flag added for display state buffer.
ecc216eec06f drm/i915/dsb: DSB context creation.
Quoting Chris Wilson (2019-09-18 11:47:49)
> Quoting Tvrtko Ursulin (2019-09-18 11:26:57)
> >
> > On 18/09/2019 10:23, Chris Wilson wrote:
> > > +static struct kobject *
> > > +kobj_engine(struct kobject *dir, struct intel_engine_cs *engine)
> > > +{
> > > + struct kobj_engine *ke;
> > > +
>
On Tue, 17 Sep 2019, Swati Sharma wrote:
> For icl+, have hw read out to create hw blob of gamma
> lut values. icl+ platforms supports multi segmented gamma
> mode, add hw lut creation for this mode.
>
> This will be used to validate gamma programming using dsb
> (display state buffer) which is a
Quoting Tvrtko Ursulin (2019-09-18 11:26:57)
>
> On 18/09/2019 10:23, Chris Wilson wrote:
> > Preliminary stub to add engines underneath /sys/class/drm/cardN/, so
> > that we can expose properties on each engine to the sysadmin.
>
> Do we also envisage a need for these future things we'll expose
On 18-Sep-19 3:31 PM, Jani Nikula wrote:
On Tue, 17 Sep 2019, Swati Sharma wrote:
For icl+, have hw read out to create hw blob of gamma
lut values. icl+ platforms supports multi segmented gamma
mode, add hw lut creation for this mode.
This will be used to validate gamma programming using dsb
Chris Wilson writes:
> A few times in CI, we have detected a GPU hang on our Haswell GT2
> systems with the characteristic IPEHR of 0x780c. When the PSMI w/a
> was first introducted, it was applied to all Haswell, but later on we
> found an erratum that supposedly restricted the issue to GT1
== Series Details ==
Series: drm/i915: Expose engine properties via sysfs (rev2)
URL : https://patchwork.freedesktop.org/series/66849/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
bcb994854973 drm/i915: Expose engine properties via sysfs
-:36: WARNING:FILE_PATH_CHANGES:
Quoting Matt Roper (2019-09-17 00:32:51)
> The CMP PCH ID we have in the driver is correct for the CML-U machines we have
> in our CI system, but the CML-S and CML-H CI machines appear to use a
> different PCH ID, leading our driver to detect no PCH for them.
>
> Cc: Rodrigo Vivi
> Cc: Anusha
== Series Details ==
Series: drm/i915: Extend Haswell GT1 PSMI workaround to all
URL : https://patchwork.freedesktop.org/series/66826/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6911_full -> Patchwork_14435_full
Summary
== Series Details ==
Series: drm/i915: Add TigerLake bandwidth checking (rev2)
URL : https://patchwork.freedesktop.org/series/66817/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
250507d65db1 drm/i915: Add TigerLake bandwidth checking
-:69: CHECK:LINE_SPACING: Please don't use
== Series Details ==
Series: drm/i915/dp: Fix DP MST error after unplugging TypeC cable
URL : https://patchwork.freedesktop.org/series/66837/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6911_full -> Patchwork_14437_full
== Series Details ==
Series: drm/i915: Fix S0ix/S3 suspend stress issue
URL : https://patchwork.freedesktop.org/series/66839/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6911_full -> Patchwork_14438_full
Summary
---
== Series Details ==
Series: drm/i915: Expose engine properties via sysfs
URL : https://patchwork.freedesktop.org/series/66849/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6912 -> Patchwork_14440
Summary
---
Preliminary stub to add engines underneath /sys/class/drm/cardN/, so
that we can expose properties on each engine to the sysadmin.
To start with we have basic analogues of the i915_query ioctl so that we
can pretty print engine discovery from the shell, and flesh out the
directory structure.
On 18/09/2019 10:23, Chris Wilson wrote:
Preliminary stub to add engines underneath /sys/class/drm/cardN/, so
that we can expose properties on each engine to the sysadmin.
Do we also envisage a need for these future things we'll expose to be
per-context-engine and not just per physical
== Series Details ==
Series: drm/i915: Add TigerLake bandwidth checking (rev2)
URL : https://patchwork.freedesktop.org/series/66817/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6913 -> Patchwork_14441
Summary
---
On 18/09/2019 14:44, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-09-18 14:38:06)
On 17/09/2019 16:39, Chris Wilson wrote:
As we need to take a walk back along the signaler timeline to find the
fence before upon which we want to wait, we need to lock that timeline
to prevent it being
drmConnectorFree is called inside the loop and after. Not unsurprisingly
this leads to a use-after-free and memcorruption.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111710
Signed-off-by: Chris Wilson
Cc: Manasi Navare
---
tests/kms_dp_tiled_display.c | 28
On Wed, Sep 18, 2019 at 06:07:07PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Modern platforms allow the transcoders hdisplay/vdisplay to exceed the
> planes' max resolution. This has the nasty implication that modes on the
> connectors' mode list may not be usable when the user asks
On 17/09/2019 16:39, Chris Wilson wrote:
As we need to take a walk back along the signaler timeline to find the
fence before upon which we want to wait, we need to lock that timeline
to prevent it being modified as we walk. Similarly, we also need to
acquire a reference to the earlier fence
Added bandwidth calculation algorithm and checks,
similar way as it was done for ICL, some constants
were corrected according to BSpec.
Signed-off-by: Stanislav Lisovskiy
v2: Start using same icl_get_bw_info function to avoid
code duplication. Moved mpagesize to memory info
related
On Mon, Sep 16, 2019 at 10:11:45AM +0300, Gwan-gyeong Mun wrote:
> When BT.2020 Colorimetry output is used for DP, we should program BT.2020
> Colorimetry to MSA and VSC SDP. It adds output_colorspace to
> intel_crtc_state struct as a place holder of pipe's output colorspace.
> In order to
On Mon, Sep 16, 2019 at 10:11:49AM +0300, Gwan-gyeong Mun wrote:
> Function intel_dp_setup_hdr_metadata_infoframe_sdp handles Infoframe SDP
> header and data block setup for HDR Static Metadata. It enables writing of
> HDR metadata infoframe SDP to panel. Support for HDR video was introduced
> in
The request->timeline is only valid until the request is retired (i.e.
before it is completed). Upon retiring the request, the context may be
unpinned and freed, and along with it the timeline may be freed. We
therefore need to be very careful when chasing rq->timeline that the
pointer does not
As not only is the signal->timeline volatile, so will be acquiring the
timeline's HWSP. We must first carefully acquire the timeline from the
signaling request and then lock the timeline. With the removal of the
struct_mutex serialisation of request construction, we can have multiple
timelines
The CMP PCH ID we have in the driver is correct for the CML-U machines
we have in our CI system, but the CML-S and CML-H CI machines appear to
use a different PCH ID, leading our driver to detect no PCH for them.
Cc: Rodrigo Vivi
Cc: Anusha Srivatsa
References: 729ae330a0f2e2 ("drm/i915/cml:
== Series Details ==
Series: drm/i915: Add TigerLake bandwidth checking (rev3)
URL : https://patchwork.freedesktop.org/series/66817/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6915 -> Patchwork_14443
Summary
---
On Wed, Sep 18, 2019 at 07:28:29AM -0700, Manasi Navare wrote:
> On Thu, Sep 05, 2019 at 04:50:44PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Modern platforms allow the transcoders hdisplay/vdisplay to exceed the
> > planes' max resolution. This has the nasty implication that
On Wed, Sep 18, 2019 at 10:51:54AM +0200, Maarten Lankhorst wrote:
> Op 17-09-2019 om 18:37 schreef Manasi Navare:
> > On Tue, Sep 17, 2019 at 05:04:28PM +0200, Maarten Lankhorst wrote:
> >> Op 09-09-2019 om 05:43 schreef Manasi Navare:
> >>> This clears the transcoder port sync bits of the
== Series Details ==
Series: series starting with [1/4] drm/i915: Verify the engine after acquiring
the active.lock
URL : https://patchwork.freedesktop.org/series/66867/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915: Verify the engine after
== Series Details ==
Series: series starting with [1/4] drm/i915: Verify the engine after acquiring
the active.lock
URL : https://patchwork.freedesktop.org/series/66867/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6915 -> Patchwork_1
On Wed, Sep 18, 2019 at 12:22:01PM +0300, Stanislav Lisovskiy wrote:
> Added bandwidth calculation algorithm and checks,
> similar way as it was done for ICL, some constants
> were corrected according to BSpec.
>
> Signed-off-by: Stanislav Lisovskiy
>
> v2: Start using same icl_get_bw_info
On 17/09/2019 19:29, Daniele Ceraolo Spurio wrote:
On 9/17/2019 3:22 AM, Tvrtko Ursulin wrote:
On 16/09/2019 22:41, Daniele Ceraolo Spurio wrote:
Our assumption that the we can ask the HW to lock the SFC even if not
currently in use does not match the HW commitment. The expectation from
On Mon, 2019-07-08 at 15:53 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Allow drivers to call drm_atomic_helper_check_modeset() without
> having the crtc helper funcs specified. i915 doesn't need those
> anymore.
>
> Signed-off-by: Ville Syrjälä
> ---
>
Hi All,
A gentle ping.
Andrzej
W dniu 26.08.2019 o 21:25, Andrzej Pietrasiewicz pisze:
I'm resending the patches which have somehow got lost: one patch
from Geert and 13 patches from me.
Geert's patch updates the error message to reflect the actually
called function's name.
Most of patches
== Series Details ==
Series: drm/i915: Add TigerLake bandwidth checking (rev3)
URL : https://patchwork.freedesktop.org/series/66817/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2ff98c4e712a drm/i915: Add TigerLake bandwidth checking
-:31: WARNING:BRACES: braces {} are not
== Series Details ==
Series: series starting with [1/4] drm/i915: Verify the engine after acquiring
the active.lock
URL : https://patchwork.freedesktop.org/series/66867/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ddffe8da3c9b drm/i915: Verify the engine after acquiring the
Op 05-09-2019 om 15:50 schreef Ville Syrjala:
> From: Ville Syrjälä
>
> The officially validated plane width limit is 4k on skl+, however
> we already had people using 5k displays before we started to enforce
> the limit. Also it seems Windows allows 5k resolutions as well
> (though not sure if
From: Ville Syrjälä
Modern platforms allow the transcoders hdisplay/vdisplay to exceed the
planes' max resolution. This has the nasty implication that modes on the
connectors' mode list may not be usable when the user asks for a
fullscreen plane. Seeing as that is the most common use case it
On Thu, Sep 05, 2019 at 04:50:43PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The officially validated plane width limit is 4k on skl+, however
> we already had people using 5k displays before we started to enforce
> the limit. Also it seems Windows allows 5k resolutions as well
>
Quoting Tvrtko Ursulin (2019-09-18 14:38:06)
>
> On 17/09/2019 16:39, Chris Wilson wrote:
> > As we need to take a walk back along the signaler timeline to find the
> > fence before upon which we want to wait, we need to lock that timeline
> > to prevent it being modified as we walk. Similarly,
On Mon, Sep 16, 2019 at 10:11:46AM +0300, Gwan-gyeong Mun wrote:
> Because between HDMI and DP have different colorspaces, it renames
> drm_mode_create_colorspace_property() function to
> drm_mode_create_hdmi_colorspace_property() function for HDMI connector.
> And it adds
Op 05-09-2019 om 15:50 schreef Ville Syrjala:
> From: Ville Syrjälä
>
> Modern platforms allow the transcoders hdisplay/vdisplay to exceed the
> planes' max resolution. This has the nasty implication that modes on the
> connectors' mode list may not be usable when the user asks for a
> fullscreen
On Thu, Sep 05, 2019 at 04:50:44PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Modern platforms allow the transcoders hdisplay/vdisplay to exceed the
> planes' max resolution. This has the nasty implication that modes on the
> connectors' mode list may not be usable when the user asks
As we need to take a walk back along the signaler timeline to find the
fence before upon which we want to wait, we need to lock that timeline
to prevent it being modified as we walk. Similarly, we also need to
acquire a reference to the earlier fence while it still exists!
Though we lack the
When using virtual engines, the rq->engine is not stable until we hold
the engine->active.lock (as the virtual engine may be exchanged with the
sibling). Since commit 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy")
we may retire a request concurrently with resubmitting it to HW, we need
to be
Quoting Chris Wilson (2019-09-18 17:10:26)
> Quoting Tvrtko Ursulin (2019-09-18 16:54:36)
> >
> > On 17/09/2019 16:17, Chris Wilson wrote:
> > > Quoting Tvrtko Ursulin (2019-09-17 15:59:25)
> > >>
> > >> On 16/09/2019 12:38, Chris Wilson wrote:
> > >>> When using virtual engines, the rq->engine
On Wed, Sep 18, 2019 at 07:02:18PM +0300, Ville Syrjälä wrote:
> On Wed, Sep 18, 2019 at 11:24:09AM -0400, Sean Paul wrote:
> > On Wed, Sep 18, 2019 at 06:07:07PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Modern platforms allow the transcoders hdisplay/vdisplay to exceed
On Wed, 2019-09-18 at 11:23 +0530, Gaurav K Singh wrote:
> During S0ix/S3 suspend stress test on Cometlake chromebook,
> after few iterations we are seeing failure wrt PSR link CRC
> Error and stress test stops. This S0ix test is failing only
> when there is a CRC mismatch. In case of CRC
On Wed, Sep 18, 2019 at 07:09:43AM +0530, srinivasa...@intel.com wrote:
> From: Srinivasan S
>
> This patch avoids DP MST payload error message in dmesg, as it is trying
> to read the payload from the disconnected DP MST device. After the unplug
> the connector status is disconnected and we
Hi Dave, Daniel,
Here is a drm-misc-next-fixes PR, with two fixes that should go in
this current merge window.
Thanks!
Maxime
drm-misc-next-fixes-2019-09-18:
- One fix for the KMS object lifetime checks with DP drivers
- One revert for an ADV7511 probe breakage on older systems
The
On Wed, Sep 18, 2019 at 10:50:39AM -0700, Manasi Navare wrote:
> On Wed, Sep 18, 2019 at 07:09:43AM +0530, srinivasa...@intel.com wrote:
> > From: Srinivasan S
> >
> > This patch avoids DP MST payload error message in dmesg, as it is trying
> > to read the payload from the disconnected DP MST
Quoting Tvrtko Ursulin (2019-09-18 16:54:36)
>
> On 17/09/2019 16:17, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-09-17 15:59:25)
> >>
> >> On 16/09/2019 12:38, Chris Wilson wrote:
> >>> When using virtual engines, the rq->engine is not stable until we hold
> >>> the engine->active.lock
On 18/09/2019 17:10, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-09-18 16:54:36)
On 17/09/2019 16:17, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-09-17 15:59:25)
On 16/09/2019 12:38, Chris Wilson wrote:
When using virtual engines, the rq->engine is not stable until we hold
the
== Series Details ==
Series: series starting with [1/2] drm/i915: Bump skl+ max plane width to 5k
for linear/x-tiled (rev2)
URL : https://patchwork.freedesktop.org/series/66286/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6915 -> Patchwork_14446
On Wed, Sep 18, 2019 at 11:21:01AM +0300, Lionel Landwerlin wrote:
On 16/09/2019 22:17, Umesh Nerlige Ramappa wrote:
On Sun, Sep 15, 2019 at 02:24:41PM +0300, Lionel Landwerlin wrote:
On 14/09/2019 02:06, Umesh Nerlige Ramappa wrote:
OA perf unit supports non-power of 2 report sizes. Enable
On 17/09/2019 16:17, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-09-17 15:59:25)
On 16/09/2019 12:38, Chris Wilson wrote:
When using virtual engines, the rq->engine is not stable until we hold
the engine->active.lock (as the virtual engine may be exchanged with the
sibling). Since
== Series Details ==
Series: drm/i915/cml: Add second PCH ID for CMP (rev2)
URL : https://patchwork.freedesktop.org/series/66782/
State : failure
== Summary ==
Applying: drm/i915/cml: Add second PCH ID for CMP
Using index info to reconstruct a base tree...
M
On Wed, Sep 18, 2019 at 11:24:09AM -0400, Sean Paul wrote:
> On Wed, Sep 18, 2019 at 06:07:07PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Modern platforms allow the transcoders hdisplay/vdisplay to exceed the
> > planes' max resolution. This has the nasty implication that modes
On Wed, Sep 18, 2019 at 04:16:28PM +0100, Chris Wilson wrote:
> drmConnectorFree is called inside the loop and after. Not unsurprisingly
> this leads to a use-after-free and memcorruption.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111710
> Signed-off-by: Chris Wilson
> Cc:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110559
Cc: Tvrtko Ursulin
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
From: David Francis
With DSC, bpp can be fractional in multiples of 1/16.
Change drm_dp_calc_pbn_mode to reflect this, adding a new
parameter bool dsc. When this parameter is true, treat the
bpp parameter as having units not of bits per pixel, but
1/16 of a bit per pixel
v2: Don't add separate
From: Michel Thierry
Enable Small PL for power benefit.
Signed-off-by: Michel Thierry
Signed-off-by: Lucas De Marchi
Reviewed-by: Stuart Summers
Reviewed-by: Radhakrishna Sripada
Link:
https://patchwork.freedesktop.org/patch/msgid/20190713010940.17711-18-lucas.demar...@intel.com
Link:
On Thu, 2019-07-18 at 17:50 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Now that we have standard defines for the MSA MISC bits lets use
> them on HSW+ where we program these directly into the TRANS_MSA_MISC
> register.
>
> Signed-off-by: Ville Syrjälä
> ---
>
On Thu, 2019-07-18 at 17:50 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Since HSW the PIPECONF progressive vs. interlaced selection is done
> with just two bits instead of the earlier three. Let's not look at
> the
> extra bit on HSW+. Also gen2 doesn't support interlaced displays at
>
On Thu, 2019-07-18 at 19:45 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> crtc_state->limited_color_range only applies to RGB output but
> we're currently setting it even for YCbCr output. That will
> lead to conflicting MSA and PIPECONF settings which can mess
> up the image. Let's make
On Thu, 2019-07-18 at 17:50 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> On ILK-IVB the pipe colorspace is configured via PIPECONF
> (as opposed to PIPEMISC in BDW+). Let's configure+readout
> that stuff correctly.
>
> Enablling YCbCr 4:4:4 output will now be a simple matter of
Typo:
== Series Details ==
Series: DSB enablement. (rev7)
URL : https://patchwork.freedesktop.org/series/63013/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6912_full -> Patchwork_14439_full
Summary
---
**SUCCESS**
No
On Sat, 2019-09-14 at 00:26 -0700, Lucas De Marchi wrote:
> On Fri, Sep 13, 2019 at 3:33 PM José Roberto de Souza
> wrote:
> > It was always modifing register space of the first phy in the
> > HIP_INDEX_REG for all ports while it should shift 8 bits for each
> > port inside of HIP_INDEX_REG.
> >
On Thu, 2019-07-18 at 17:50 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add definitions for the MSA (Main Stream Attribute) MISC bits. On
> some hardware you can program these directly into a register.
>
> Signed-off-by: Ville Syrjälä
> ---
> include/drm/drm_dp_helper.h | 42
>
On Thu, 2019-07-18 at 17:50 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Looks like we're currently setting the MSA to xvYCC BT.709 instead
> of the YCbCr BT.601 claimed by the comment. But even that comment
> is wrong since we configure the CSC matrix to BT.709.
>
> Let's remove the
On Thu, 2019-07-18 at 17:50 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Pull the code for computing the limited color range
> setting into a small helper. We'll add a bit more to it
> later.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_hdmi.c | 30
On Thu, 2019-07-18 at 17:50 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> On HSW the pipe colorspace is configured via PIPECONF
> (as opposed to PIPEMISC in BDW+). Let's configure+readout
> that stuff correctly.
>
> Enablling YCbCr 4:4:4 output will now be a simple matter of
Typo:
1 - 100 of 140 matches
Mail list logo
