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 c
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 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: 1209978241
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
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 i915_gem_object_create_
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
---
drivers/gpu/drm/i915/display/intel_d
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
Reviewed-by: Shashank Sharma
Signed-off-by: Animesh Manna
---
Documentation/gpu/i
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 code
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 r
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 futu
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 a/drivers/gpu/drm/i915/i
Added bandwidth calculation algorithm and checks,
similar way as it was done for ICL, some constants
were corrected according to BSpec 53998.
v2: Start using same icl_get_bw_info function to avoid
code duplication. Moved mpagesize to memory info
related structure as it is now dependent on
== Series Details ==
Series: DSB enablement. (rev8)
URL : https://patchwork.freedesktop.org/series/63013/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7569987ee218 drm/i915/dsb: feature flag added for display state buffer.
9c2ddae7699f drm/i915/dsb: DSB context creation.
-:63:
== Series Details ==
Series: DSB enablement. (rev8)
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!
_
== Series Details ==
Series: DSB enablement. (rev8)
URL : https://patchwork.freedesktop.org/series/63013/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6925 -> Patchwork_14468
Summary
---
**SUCCESS**
No regression
Our sanitychecks indicate that while this register is context
saved/restore, the HW does not preserve this bit within the register --
it likely doesn't exist, or one of those mythical bits that the
architects insist does something despite all appearances to the
contrary.
For reference, SAMPLER_MOD
Chris Wilson writes:
> Before we execute a batch, we must first issue any and all TLB
> invalidations so that batch picks up the new page table entries.
> Tigerlake's preparser is weakening our post-sync CS_STALL inside the
> invalidate pipe-control and allowing the loading of the batch buffer
>
Hi all:
There are hardware that can do virtio datapath offloading while having
its own control path. This path tries to implement a mdev based
unified API to support using kernel virtio driver to drive those
devices. This is done by introducing a new mdev transport for virtio
(virtio_mdev) and reg
Mdev bus only support vfio driver right now, so it doesn't implement
match method. But in the future, we may add drivers other than vfio,
one example is virtio-mdev[1] driver. This means we need to add device
class id support in bus match method to pair the mdev device and mdev
driver correctly.
S
Currently, except for the crate and remove. The rest fields of
mdev_parent_ops is just designed for vfio-mdev driver and may not help
for kernel mdev driver. So follow the device id support by previous
patch, this patch introduces device specific ops which points to
device specific ops (e.g vfio op
This patch implements basic support for mdev driver that support
virtio transport for kernel driver.
Signed-off-by: Jason Wang
---
drivers/vfio/mdev/mdev_core.c | 7 ++
include/linux/mdev.h | 3 +
include/linux/virtio_mdev.h | 141 ++
3 files change
This path introduces a new mdev transport for virtio. This is used to
use kernel virtio driver to drive the mediated device that is capable
of populating virtqueue directly.
A new virtio-mdev driver will be registered to the mdev bus, when a
new virtio-mdev device is probed, it will register the d
This sample driver creates mdev device that simulate virtio net device
over virtio mdev transport. The device is implemented through vringh
and workqueue. A device specific dma ops is to make sure HVA is used
directly as the IOVA. This should be sufficient for kernel virtio
driver to work.
No more
We want to copy from iov to buf, so the direction was wrong.
Signed-off-by: Jason Wang
---
drivers/vhost/vringh.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/vhost/vringh.c b/drivers/vhost/vringh.c
index 08ad0d1f0476..a0a2d74967ef 100644
--- a/drivers/vhost
Force bonded requests to run on distinct engines so that they cannot be
shuffled onto the same engine where timeslicing will reverse the order.
A bonded request will often wait on a semaphore signaled by its master,
creating an implicit dependency -- if we ignore that implicit dependency
and allow
When audio power domain is suspended, the display driver must
save state of AUD_FREQ_CNTRL on Tiger Lake and Ice Lake
systems. The initial value of the register is set by BIOS and
is read by driver during the audio component init sequence.
Cc: Jani Nikula
Cc: Imre Deak
Signed-off-by: Kai Vehmane
Added bandwidth calculation algorithm and checks,
similar way as it was done for ICL, some constants
were corrected according to BSpec 53998.
v2: Start using same icl_get_bw_info function to avoid
code duplication. Moved mpagesize to memory info
related structure as it is now dependent on
According to BSpec 53998, we should try to
restrict qgv points, which can't provide
enough bandwidth for desired display configuration.
Currently we are just comparing against all of
those and take minimum(worst case).
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_bw
On 19/09/2019 18:49, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-09-19 18:11:14)
On 19/09/2019 14:26, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-09-19 14:02:19)
On 19/09/2019 12:19, Chris Wilson wrote:
+static struct intel_timeline *get_timeline(struct i915_request *rq)
+{
+
== Series Details ==
Series: drm/i915/tgl: Suspend pre-parser across GTT invalidations (rev2)
URL : https://patchwork.freedesktop.org/series/66703/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6925_full -> Patchwork_14461_full
=
On Fri, 20 Sep 2019, Animesh Manna wrote:
> 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
On Fri, 20 Sep 2019, Kai Vehmanen wrote:
> When audio power domain is suspended, the display driver must
> save state of AUD_FREQ_CNTRL on Tiger Lake and Ice Lake
> systems. The initial value of the register is set by BIOS and
> is read by driver during the audio component init sequence.
>
> Cc: J
Quoting Mika Kuoppala (2019-09-20 09:14:36)
> Chris Wilson writes:
>
> > Before we execute a batch, we must first issue any and all TLB
> > invalidations so that batch picks up the new page table entries.
> > Tigerlake's preparser is weakening our post-sync CS_STALL inside the
> > invalidate pipe
== Series Details ==
Series: adding gamma state checker for icl+ platforms (rev3)
URL : https://patchwork.freedesktop.org/series/66811/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6925_full -> Patchwork_14463_full
Summary
Insert structure members names into their descriptions to follow
kernel-doc format.
Reviewed-by: Chris Wilson
Signed-off-by: Anna Karas
---
drivers/gpu/drm/i915/i915_drv.h | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_
On 20/09/2019 12:47, Anna Karas wrote:
Insert structure members names into their descriptions to follow
kernel-doc format.
Reviewed-by: Chris Wilson
Signed-off-by: Anna Karas
Acked-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 26 ++
1 file change
Quoting Chris Wilson (2019-09-20 09:12:54)
> Our sanitychecks indicate that while this register is context
> saved/restore, the HW does not preserve this bit within the register --
> it likely doesn't exist, or one of those mythical bits that the
> architects insist does something despite all appea
On Thu, 19 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 by default, add hw lut creation for this mode.
>
> This will be used to validate gamma programming using dsb
> (display state buffer)
According to BSpec 53998, we should try to
restrict qgv points, which can't provide
enough bandwidth for desired display configuration.
Currently we are just comparing against all of
those and take minimum(worst case).
v2: Fixed wrong PCode reply mask, removed hardcoded
values.
Signed-off-by
== Series Details ==
Series: Revert "drm/i915/tgl: Implement Wa_1406941453"
URL : https://patchwork.freedesktop.org/series/66986/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6927 -> Patchwork_14469
Summary
---
**SU
== Series Details ==
Series: drm/i915/dp: Support for DP HDR outputs (rev9)
URL : https://patchwork.freedesktop.org/series/65656/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6925_full -> Patchwork_14464_full
Summary
-
We are still looking at drm_crtc_state in a few places, convert those
to use intel_crtc_state instead. Look at uapi/hw where appropriate.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_display.c | 14 +++---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
d
Is there any point in having FBC enabled on half a screen?
I suppose it could still save power, but just feels wrong..
Can always be enabled later again if required.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_fbc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
I get a permanent FIFO underrun when enabling FEC with big joiner,
so for now disable it.
It seems that even at 1024x768 resolution without bigjoiner we don't
get a working configuration. Flag is set but vblank timing shows that
vblanks are delivered slightly faster, so the extra overhead we
calcu
When the clock is higher than the dotclock, try with 2 pipes enabled.
If we can enable 2, then we will go into big joiner mode, and steal
the adjacent crtc.
This only links the crtc's in software, no hardware or plane
programming is done yet. Blobs are also copied from the master's
crtc_state, so
Enabling is done in a special sequence and to be fair, so should
plane updates be. Ideally the end user never notices the second
pipe is used, so use the vblank evasion to cover both pipes.
This way ideally everything will be tear free, and updates are
really atomic as userspace expects it.
The d
We want to program slave planes with the master plane_state for
properties such as FB, rotation, coordinates, etc, but the
slave plane_state for all programming parameters.
Instead of special casing NV12 Y-planes, we make the code more
generic, Y planes are programmed with separate state from the
Similar to plane programming, we need a separate master_plane_state from
which we will read all atomic properties, and plane_state for the real
coordinates.
Although we add all planes with icl_add_linked_planes(),
icl_check_nv12_planes() may add extra Y planes on the slave CRTC.
For those planes,
It's useful to know what the actual clipped state is, rather than
the unclipped crtc properties.
This is useful when a plane is spread across 2 crtc's, where the
slave crtc has no own plane properties but derives its clipped
values from the master crtc.
Signed-off-by: Maarten Lankhorst
---
driv
A lot of delta, the main difference is that the master_plane_state is
not the same plane_state as being written to.
We read all properties like color key, crtc, fb, rotation from the
master_plane_state and coordinate properties.
The coordinate properties are different between the 2 bigjoiner plan
There was a integer wraparound when mode_clock became too high,
and we didn't correct for the FEC overhead factor when dividing,
with the calculations breaking at HBR3.
As a result our calculated bpp was way too high, and the link width
limitation never came into effect.
Print out the resulting b
Now that we can program planes from the update_slave callback, and
we have done all fb pinning correctly, it's time to program those
planes as well.
We use the update_slave callback as it allows us to use the
separate states correctly.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/displ
Can't figure out how it works, so just removing it..
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_dp_helper.c | 4 ++--
include/drm/drm_dp_helper.h | 1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helpe
Make vdsc work when no output is enabled. The big joiner needs VDSC
on the slave, so enable it and set the appropriate bits.
Also update timestamping constants, because slave crtc's are not
updated in drm_atomic_helper_update_legacy_modeset_state().
This should be enough to bring up CRTC's in a bi
Now that we separated everything into uapi and hw, it's
time to make the split definitive. Remove the union and
make a copy of the hw state on modeset and fastset.
Color blobs are copied in crtc atomic_check(), right
before color management is checked.
Signed-off-by: Maarten Lankhorst
---
drive
We had this as an optimization to not do a plane update, but we killed
it off because there are so many reasons we may have to do a plane
update or fastset that it's best to just assume everything changed.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_atomic.c|
Rename linked_plane to planar_linked_plane and slave to planar_slave,
this will make it easier to keep apart bigjoiner linking and planar plane
linking.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_atomic.c | 7 --
.../gpu/drm/i915/display/intel_atomic_plane.c |
Small changes to intel_dp_mode_valid(), allow listing modes that
can only be supported in the bigjoiner configuration, which is
not supported yet.
Also unexport a few functions only used internally in intel_dp.c
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_dp.c | 98 +
Make sure that when a plane is set in a bigjoiner mode, we will add
their counterpart to the atomic state as well. This will allow us to
make sure all state is available when planes are checked.
Because of the funny interactions with bigjoiner and planar YUV
formats, we may end up adding a lot of
We cannot switch between HQ and normal mode on GLK+, so only
add planes on platforms where it makes sense.
We could probably restrict it even more to only add when scaler
users toggles between 1 and 2, but lets just leave it for now.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/dis
This can all be done from the intel_update_crtc function. Split out the
pipe update into a separate function, just like is done for the planes.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_display.c | 124 ---
1 file changed, 52 insertions(+), 72 deleti
For bigjoiner, we cannot do drm_atomic_crtc_state_for_each_plane_state()
on the crtc, because planes don't match the drm core state.
We need a separate master_plane_state for all the properties,
and a slave_plane_state for the rectangles/visibility etc.
This is similar to how we handle the Y plane
Unfortunately I have no way to test this, but it should be correct
if the bios sets up bigjoiner in a sane way.
Skip iterating over bigjoiner slaves, only the master has the state we
care about.
Add the width of the bigjoiner slave to the reconstructed fb.
Hide the bigjoiner slave to userspace,
On Monday, 2019-09-16 16:23:13 +0300, Jani Nikula wrote:
> On Mon, 16 Sep 2019, Eric Engestrom wrote:
> > On Monday, 2019-09-16 11:53:24 +0300, Jani Nikula wrote:
> >> On Fri, 13 Sep 2019, Eric Engestrom wrote:
> >> > On Friday, 2019-09-13 14:51:39 +0300, Jani Nikula wrote:
> >> >> Add helper to
On Thu, 19 Sep 2019, Swati Sharma wrote:
> Fixed few formatting issues in multi-segmented load_lut().
>
> v3: -style nitting [Jani]
> -balanced parentheses moved from patch 2 to 1 [Jani]
> -subject prefix change [Jani]
> -added commit message [Jani]
>
> Signed-off-by: Swati Sharma
Re
== Series Details ==
Series: drm/i915/tgl: Move the SAMPLER_MODE setup into the context
URL : https://patchwork.freedesktop.org/series/66954/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6925_full -> Patchwork_14465_full
S
On Thu, 19 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 by default, add hw lut creation for this mode.
>
> This will be used to validate gamma programming using dsb
> (display state buffer)
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
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: 1209978241
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 i915_gem_object_create_
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 c
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)
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 futu
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
---
drivers/gpu/drm/i915/display/intel_d
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 code
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
Reviewed-by: Shashank Sharma
Signed-off-by: Animesh Manna
---
Documentation/gpu/i
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 a/drivers/gpu/drm/i915/i
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 r
== Series Details ==
Series: mdev based hardware virtio offloading support
URL : https://patchwork.freedesktop.org/series/66989/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
32afcef2acff mdev: class id support
8efae9b60a78 mdev: introduce device specific ops
-:309: ERROR:CODE_
On Fri, 20 Sep 2019, Animesh Manna wrote:
> 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
Since dropping the set-to-gtt-domain in commit a679f58d0510 ("drm/i915:
Flush pages on acquisition"), we no longer mark the contents as dirty on
a write fault. This has the issue of us then not marking the pages as
dirty on releasing the buffer, which means the contents are not written
out to the s
On Thu, 2019-07-18 at 17:50 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Prepare the pipe csc for YCbCr output on ilk/snb. The main difference
> to IVB+ is the lack of explicit post offsets, and instead we must
> configure the CSC info RGB->YUV mode (which takes care of offsetting
> Cb/C
Except typo, the changes look good to me.
Reviewed-by: Gwan-gyeong Mun
On Wed, 2019-09-18 at 19:03 +, Mun, Gwan-gyeong wrote:
> 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 PIP
Except typo, the changes look good to me.
Reviewed-by: Gwan-gyeong Mun
On Wed, 2019-09-18 at 19:05 +, Mun, Gwan-gyeong wrote:
> 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
Quoting Chris Wilson (2019-09-20 13:18:21)
> Since dropping the set-to-gtt-domain in commit a679f58d0510 ("drm/i915:
> Flush pages on acquisition"), we no longer mark the contents as dirty on
> a write fault. This has the issue of us then not marking the pages as
> dirty on releasing the buffer, wh
On 20/09/2019 09:36, Chris Wilson wrote:
Force bonded requests to run on distinct engines so that they cannot be
shuffled onto the same engine where timeslicing will reverse the order.
A bonded request will often wait on a semaphore signaled by its master,
creating an implicit dependency -- if w
On Thu, Sep 19, 2019 at 03:16:40PM -0700, James Ausmus wrote:
> The memory type values have changed in TGL, so we need to translate them
> differently than ICL.
>
> BSpec: 53998
>
> Cc: Ville Syrjälä
> Cc: Stanislav Lisovskiy
> Signed-off-by: James Ausmus
> ---
> drivers/gpu/drm/i915/display/
Quoting Chris Wilson (2019-09-20 13:22:13)
> Quoting Chris Wilson (2019-09-20 13:18:21)
> > Since dropping the set-to-gtt-domain in commit a679f58d0510 ("drm/i915:
> > Flush pages on acquisition"), we no longer mark the contents as dirty on
> > a write fault. This has the issue of us then not marki
== Series Details ==
Series: mdev based hardware virtio offloading support
URL : https://patchwork.freedesktop.org/series/66989/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6928 -> Patchwork_14470
Summary
---
**SUC
== Series Details ==
Series: drm/i915: Prevent bonded requests from overtaking each other on
preemption
URL : https://patchwork.freedesktop.org/series/66990/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7885378114ae drm/i915: Prevent bonded requests from overtaking each other
Quoting Tvrtko Ursulin (2019-09-20 13:24:47)
>
> On 20/09/2019 09:36, Chris Wilson wrote:
> > Force bonded requests to run on distinct engines so that they cannot be
> > shuffled onto the same engine where timeslicing will reverse the order.
> > A bonded request will often wait on a semaphore sign
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/uc: Update HuC firmware naming
convention and load latest HuC
URL : https://patchwork.freedesktop.org/series/66955/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6925_full -> Patchwork_14466_full
On Thu, 2019-07-18 at 17:50 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We're configuring the AVI infoframe quantization range bits as if
> we're always transmitting RGB pixels. Let's fix this so that we
> correctly indicate limited range YCC quantization range when
> transmitting YCbCr
== Series Details ==
Series: drm/i915: Prevent bonded requests from overtaking each other on
preemption
URL : https://patchwork.freedesktop.org/series/66990/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6928 -> Patchwork_14471
Hi all,
Any update on this series ? Last time I looked, everything looked ready
and waiting to be merged.
JJ
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Fri, Sep 20, 2019 at 01:44:13PM +0300, Stanislav Lisovskiy wrote:
> According to BSpec 53998, we should try to
> restrict qgv points, which can't provide
> enough bandwidth for desired display configuration.
>
> Currently we are just comparing against all of
> those and take minimum(worst case)
== Series Details ==
Series: drm/i915: save AUD_FREQ_CNTRL state at audio domain suspend
URL : https://patchwork.freedesktop.org/series/66991/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6928 -> Patchwork_14472
Summary
--
On Fri, Sep 20, 2019 at 03:29:06PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 19, 2019 at 03:16:40PM -0700, James Ausmus wrote:
> > The memory type values have changed in TGL, so we need to translate them
> > differently than ICL.
> >
> > BSpec: 53998
> >
> > Cc: Ville Syrjälä
> > Cc: Stanislav L
On Fri, 2019-09-20 at 16:19 +0300, Ville Syrjälä wrote:
> On Fri, Sep 20, 2019 at 01:44:13PM +0300, Stanislav Lisovskiy wrote:
> > According to BSpec 53998, we should try to
> > restrict qgv points, which can't provide
> > enough bandwidth for desired display configuration.
> >
> > Currently we ar
== Series Details ==
Series: drm/i915: Add TigerLake bandwidth checking (rev5)
URL : https://patchwork.freedesktop.org/series/66817/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6928 -> Patchwork_14473
Summary
---
*
1 - 100 of 186 matches
Mail list logo
