>
> > -Original Message-
> > From: Intel-gfx On Behalf Of
> > Suraj Kandpal
> > Sent: Wednesday, February 15, 2023 8:47 AM
> > To: intel-gfx@lists.freedesktop.org
> > Subject: [Intel-gfx] [PATCH v10 5/7] drm/i915: Fill in native_420
> > field
>
> Append "display"
>
drm/i915/display ?
> >
> > +static int intel_dsc_slice_dimensions_valid(struct intel_crtc_state
> *pipe_config,
> > + struct drm_dsc_config *vdsc_cfg) {
> > + if (pipe_config->output_format == INTEL_OUTPUT_FORMAT_RGB ||
> > + pipe_config->output_format ==
> INTEL_OUTPUT_F
== Series Details ==
Series: Add vfio_device cdev for iommufd support (rev3)
URL : https://patchwork.freedesktop.org/series/113696/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/113696/revisions/3/mbox/ not
applied
Applying: vfio: Allocate per de
This adds ioctl for userspace to bind device cdev fd to iommufd.
VFIO_DEVICE_BIND_IOMMUFD: bind device to an iommufd, hence gain DMA
control provided by the iommufd. open_device
op is called after bind_iommufd op.
group code is not needed for vfio device cdev, so with vfio device cdev
introduced, the group infrastructures can be compiled out if only cdev
is needed.
Signed-off-by: Yi Liu
---
drivers/vfio/Kconfig | 14
drivers/vfio/Makefile | 2 +-
drivers/vfio/vfio.h | 78 +
This allows user to directly open a vfio device w/o using the legacy
container/group interface, as a prerequisite for supporting new iommu
features like nested translation.
The device fd opened in this manner doesn't have the capability to access
the device as the fops open() doesn't open the devi
VFIO group has historically allowed multi-open of the device FD. This
was made secure because the "open" was executed via an ioctl to the
group FD which is itself only single open.
However, no known use of multiple device FDs today. It is kind of a
strange thing to do because new device FDs can na
for counting the devices that are opened via the cdev path. This count
is increased and decreased by the cdev path. The group path checks it
to achieve exclusion with the cdev path. With this, only one path (group
path or cdev path) will claim DMA ownership. This avoids scenarios in
which devices w
Allow the vfio_device file to be in a state where the device FD is
opened but the device cannot be used by userspace (i.e. its .open_device()
hasn't been called). This inbetween state is not used when the device
FD is spawned from the group FD, however when we create the device FD
directly by openi
This gives hints for userspace applications on device cdev usage.
Signed-off-by: Yi Liu
---
Documentation/driver-api/vfio.rst | 125 ++
1 file changed, 125 insertions(+)
diff --git a/Documentation/driver-api/vfio.rst
b/Documentation/driver-api/vfio.rst
index 4452742
This makes the vfio file kAPIs to accepte vfio device files, also a
preparation for vfio device cdev support.
For the kvm set with vfio device file, kvm pointer is stored in struct
vfio_device_file, and use kvm_ref_lock to protect kvm set and kvm
pointer usage within VFIO. This kvm pointer will be
This adds ioctl for userspace to attach device cdev fd to and detach
from IOAS/hw_pagetable managed by iommufd.
VFIO_DEVICE_ATTACH_IOMMUFD_PT: attach vfio device to IOAS, hw_pagetable
managed by iommufd. Attach can be
undo b
This prepares for using vfio device cdev as no group fd will be opened
in device cdev usage.
vfio_file_is_device_opened() is added for checking a given vfio file is
able to be a proof for the device ownership or not. The reason is that
the cdev path has the device opened in an in-between state, in
this prepares for adding DETACH ioctl for physical VFIO devices.
Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
---
Documentation/driver-api/vfio.rst | 8 +---
drivers/vfio/fsl-mc/vfio_fsl_mc.c | 1 +
drivers/vfio/iommufd.c| 20 ++
this prepares for adding DETACH ioctl for emulated VFIO devices.
Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 1 +
drivers/s390/cio/vfio_ccw_ops.c | 1 +
drivers/s390/crypto/vfio_ap_ops.c | 1 +
drivers/vfio/iommufd.c| 18 +++
this suits more on what the code does.
Signed-off-by: Yi Liu
---
drivers/vfio/pci/vfio_pci_core.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
index 4704c1babae3..827524510f3f 100644
--- a/drivers/vfio/p
This avoids passing too much parameters in multiple functions.
Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
---
drivers/vfio/group.c | 19 +--
drivers/vfio/vfio.h | 8
drivers/vfio/vfio_main.c | 25 +++--
3 files changed, 32 insertions(+),
For the device fd opened from cdev, userspace needs to bind it to an
iommufd and attach it to IOAS managed by iommufd. With such operations,
userspace can set up a secure DMA context and hence access device.
This changes the existing vfio_iommufd_bind() to accept a pt_id pointer
as an optional inp
Meanwhile, rename related helpers. No functional change is intended.
Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
Reviewed-by: Eric Auger
---
virt/kvm/vfio.c | 115
1 file changed, 58 insertions(+), 57 deletions(-)
diff --git a/virt/kvm/vfio.c
This is preparation for adding vfio device cdev support. vfio device
cdev requires:
1) a per device file memory to store the kvm pointer set by KVM. It will
be propagated to vfio_device:kvm after the device cdev file is bound
to an iommufd
2) a mechanism to block device access through device
This defines KVM_DEV_VFIO_FILE* and make alias with KVM_DEV_VFIO_GROUP*.
Old userspace uses KVM_DEV_VFIO_GROUP* works as well.
Signed-off-by: Yi Liu
---
Documentation/virt/kvm/devices/vfio.rst | 50 -
include/uapi/linux/kvm.h| 16 ++--
virt/kvm/vfio.c
This prepares for making the below kAPIs to accept both group file
and device file instead of only vfio group file.
bool vfio_file_enforced_coherent(struct file *file);
void vfio_file_set_kvm(struct file *file, struct kvm *kvm);
bool vfio_file_has_dev(struct file *file, struct vfio_device *d
Existing VFIO provides group-centric user APIs for userspace. Userspace
opens the /dev/vfio/$group_id first before getting device fd and hence
getting access to device. This is not the desired model for iommufd. Per
the conclusion of community discussion[1], iommufd provides device-centric
kAPIs an
== Series Details ==
Series: drm/i915: Init DDI ports in VBT order (rev2)
URL : https://patchwork.freedesktop.org/series/114200/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12764_full -> Patchwork_114200v2_full
Summary
--
== Series Details ==
Series: drm/i915: Init DDI ports in VBT order (rev2)
URL : https://patchwork.freedesktop.org/series/114200/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12764 -> Patchwork_114200v2
Summary
---
*
== Series Details ==
Series: drm/i915: Get HDR DPCD refresh timeout from VBT (rev2)
URL : https://patchwork.freedesktop.org/series/114196/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12763_full -> Patchwork_114196v2_full
== Series Details ==
Series: drm/i915: Init DDI ports in VBT order (rev2)
URL : https://patchwork.freedesktop.org/series/114200/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
From: Ville Syrjälä
Make HSW/BDW use the new VBT child device driven output
probing as well. To achieve that the strap checks are
moved into intel_ddi_init() itself.
I have one HSW ULT laptop here which declares all the ports
A-D in the VBT, so in order to avoid assert_port_valid() tripping
on D
From: Ville Syrjälä
Try to deal with duplicate child devices for the same DDI port
by attempting to initialize them in VBT defined order The first
on to succeed for a specific DDI port will be the one we use.
TODO: DSI dual link handling is sketchy at best
Signed-off-by: Ville Syrjälä
---
dri
From: Ville Syrjälä
Instead of listing every platform's possible DDI outputs
in intel_setup_outputs() just loop over the new port_mask
to achieve the same thing.
HSW/BDW were left as is since they still look at the straps
as well.
DSI is still a mess. For now just check for the relevant
platfor
From: Ville Syrjälä
The SDVO code already warns when the port in question doesn't
actually support SDVO. Let's make that also bail the encoder
registration like the generic assert_port_valid() we added.
And add a similar thing for g4x HDMI, mainly because on g4x
itsefl port D only supports DP bu
From: Ville Syrjälä
Sprinkle in some BUILD_BUG_ON()s to make sure some of
the bitmasks used in the device info have enough bits.
Do we have a better place for this sort of stuff?
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_device_info.c | 4
1 file changed, 4 insertions(+
From: Ville Syrjälä
Sprinkle some asserts to catch any mishaps in the port_mask
vs. output init.
For DDI/DP/HDMI/SDVO I decided that we want to bail out for
an invalid port since those are the encoder types where
we might want consider driving the whole thing from the VBT
child device list, and
From: Ville Syrjälä
Declare the available DVO/SDVO/HDMI/DP/DDI ports in the
device info. The other outputs (LVDS/TV/DSI/VGA) are left
out since for most of them we don't consider them as "ports".
DSI we should probably perhaps include somehow in the device
info. Just not sure how. Or we just int
From: Ville Syrjälä
HSW/BDW don't have DDI-F so don't go looking for one.
Seems to have been accidentally left behind when the
skl+ stuff got split out in commit 097d9e902068
("drm/i915/display: remove strap checks from gen 9").
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/in
From: Ville Syrjälä
Now that we have encoder->devdata everwhere we don't need
the intel_bios_is_port_dp_dual_mode() wrapper any more.
And while at it let's include it in the child device log
dump as well since the logic in there is a bit more complex
than just DP&&HDMI.
Signed-off-by: Ville Syr
From: Ville Syrjälä
Swap the roles of the index vs. value for the VBT DDC pin
mapping tables. This is not strictly necessary for DDC pins
but it will make this work exactly like the AUX CH mapping
tables where the role reversal is necessary (or at least makes
things easier). Consistency is good.
From: Ville Syrjälä
The big switch+if statement mess in map_aux_ch() is
illegible. Split up into cleaner per-platform arrays
like we already have for the gmbus pins.
We use enum aux_ch as the index and the VBT thing as
the value. Slightly non-intuitive perhaps but if we
did it the other way arou
From: Ville Syrjälä
Currently we sanitize the child device aux_ch/ddc_pin while parsing
the ports from VBT. But that won't work when we have duplicate child
devices for the same port.
Instead let's sanitize just before initializing the encoder,
based on which resources were consumed by encoders
From: Ville Syrjälä
Add a mechanism by which we can toggle the HPD sense for
individual encoders.
This will be used during eDP probing to figure out if
anything is actually connected. The normal intel_hpd_irq_setup()
thing doesn't work since we only do that after probing the
outputs, and we only
From: Ville Syrjälä
We need to untangle the mess where some SKL machines (at least)
declare both DDI A and DDI E to be present in their VBT, and
both using AUX A. DDI A is a ghost eDP, wheres DDI E may be a
real DP->VGA converter.
Currently that is handled by checking the VBT child devices
for c
From: Ville Syrjälä
Pair each _hotplug_enables() function with
a corresponding _hotplug_mask() function so that
we can determine right bits to clear on a per hpd_pin basis.
We'll need this for turning on HPD sense for a specific
encoder rather than just all of them.
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä
The idea that ctg uses different HPD live state bits is
total nonsense, at least on my machine (Dell Latitude
E5400).
The only reason DP-B even works on my ctg is that DP-D
live state is stuck high, even though there is no physical
DP-D port. So when the detect checks DP-B li
From: Ville Syrjälä
SKL doesn't have any north DE hotplug stuff. Currently we're
trying to read DDI A live state from the BDW north DE bit,
instead of the approproate south DE bit. Fix it.
And for good measure clear the pointer to the north hpd
pin array, so that we'll actually notice if some ot
From: Ville Syrjälä
We'll need dig_port->connected() to be there for a HPD live
state check during eDP connector probing. Reorder intel_ddi_init()
accordingly. g4x_dp_init() is already fine.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 40
From: Ville Syrjälä
I just wanted to init DDI ports in VBT child device order
without any up front assumptions about which conflicting
child device defition is valid. That is pretty much what
we need to do for the ADL laptops with the phantom eDP vs.
native HDMI on DDI B.
However that approach
> -Original Message-
> From: Intel-gfx On Behalf Of Swati
> Sharma
> Sent: Tuesday, February 14, 2023 4:33 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani
> Subject: [Intel-gfx] [v11] drm/i915/dsc: Add debugfs entry to validate DSC
> output
> formats
>
> DSC_Output_Format
> -Original Message-
> From: Intel-gfx On Behalf Of Suraj
> Kandpal
> Sent: Tuesday, February 7, 2023 1:14 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v9 6/7] drm/i915/vdsc: Check slice design
> requirement
>
> Add function to check if slice design requireme
> -Original Message-
> From: Intel-gfx On Behalf Of Suraj
> Kandpal
> Sent: Wednesday, February 15, 2023 8:47 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v10 5/7] drm/i915: Fill in native_420 field
Append "display"
>
> Now that we have laid the groundwork f
== Series Details ==
Series: drm/i915: Get HDR DPCD refresh timeout from VBT (rev2)
URL : https://patchwork.freedesktop.org/series/114196/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12763 -> Patchwork_114196v2
Summary
--
On Tue, Feb 14, 2023 at 12:52:57AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The DSI code has some local hacks to program TRANS_H/VBLANK on
> TGL+ (ICL DSI transcoders didn't have these registers). That
> will not work when we need to start using the delayed vblank
> (for DSB purposes
== Series Details ==
Series: drm/i915: Init DDI ports in VBT order
URL : https://patchwork.freedesktop.org/series/114200/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12763 -> Patchwork_114200v1
Summary
---
**FAILUR
> -Original Message-
> From: Shankar, Uma
> Sent: Tuesday, February 21, 2023 2:08 AM
> To: Suraj Kandpal ; intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH v9 1/7] drm/dp_helper: Add helper to check if
> the sink
> supports given format with DSC
>
>
>
> > -Origin
On 2023-02-20 at 14:24:45 +0100, Janusz Krzysztofik wrote:
> This test can work not only on render engines, as its current code
> suggests, but also on compute class engines. Add them to the set of
> engine classes supported by the test, in case a future platform has only
> those and no RCS availa
> -Original Message-
> From: Intel-gfx On Behalf Of Suraj
> Kandpal
> Sent: Tuesday, February 7, 2023 1:14 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v9 2/7] drm/i915/dp: Check if DSC supports the
> given
> output_format
>
> From: Ankit Nautiyal
>
> Go wi
== Series Details ==
Series: series starting with [1/2] drm/i915: Fix audio ELD handling for DP MST
URL : https://patchwork.freedesktop.org/series/114194/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12762_full -> Patchwork_114194v1_full
==
> -Original Message-
> From: Intel-gfx On Behalf Of Suraj
> Kandpal
> Sent: Tuesday, February 7, 2023 1:14 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v9 1/7] drm/dp_helper: Add helper to check if the
> sink
> supports given format with DSC
>
> From: Ankit N
== Series Details ==
Series: drm/i915: Init DDI ports in VBT order
URL : https://patchwork.freedesktop.org/series/114200/
State : warning
== Summary ==
Error: dim checkpatch failed
782a06c663af drm/i915: Populate dig_port->connected() before connector init
-:59: WARNING:BLOCK_COMMENT_STYLE: Bl
From: Rob Clark
v2: rebase
Signed-off-by: Rob Clark
---
drivers/gpu/drm/i915/i915_request.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 7503dcb9043b..44491e7e214c 100644
--- a/drivers
From: Rob Clark
This series adds a deadline hint to fences, so realtime deadlines
such as vblank can be communicated to the fence signaller for power/
frequency management decisions.
This is partially inspired by a trick i915 does, but implemented
via dma-fence for a couple of reasons:
1) To co
On Mon, Feb 20, 2023 at 05:53:48PM +0530, Ankit Nautiyal wrote:
> The decision to use DFP output format conversion capabilities should be
> during compute_config phase.
>
> This patch adds new member to crtc_state to represent the final
> output_format to the sink. In case of a DFP this can be dif
== Series Details ==
Series: Handle BPC for HDMI2.1 PCON without DSC1.2 sink and other fixes (rev10)
URL : https://patchwork.freedesktop.org/series/107550/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12761_full -> Patchwork_107550v10_full
== Series Details ==
Series: drm/i915/sseu: fix max_subslices array-index-out-of-bounds access
URL : https://patchwork.freedesktop.org/series/114199/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12762 -> Patchwork_114199v1
== Series Details ==
Series: drm/i915/sseu: fix max_subslices array-index-out-of-bounds access
URL : https://patchwork.freedesktop.org/series/114199/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/i915: Get HDR DPCD refresh timeout from VBT
URL : https://patchwork.freedesktop.org/series/114196/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12762 -> Patchwork_114196v1
Summary
---
On Mon, Feb 20, 2023 at 06:14:58PM +0200, Ville Syrjälä wrote:
> On Mon, Feb 20, 2023 at 05:45:45PM +0200, Lisovskiy, Stanislav wrote:
> > On Tue, Feb 14, 2023 at 04:04:05PM +0200, Ville Syrjälä wrote:
> > > On Tue, Feb 14, 2023 at 12:01:32PM +0200, Stanislav Lisovskiy wrote:
> > > > From: Jigar Bh
From: Ville Syrjälä
Try to deal with duplicate child devices for the same DDI port
by attempting to initialize them in VBT defined order The first
on to succeed for a specific DDI port will be the one we use.
TODO: DSI dual link handling is sketchy at best
Signed-off-by: Ville Syrjälä
---
dri
From: Ville Syrjälä
Make HSW/BDW use the new VBT child device driven output
probing as well. To achieve that the strap checks are
moved into intel_ddi_init() itself.
I have one HSW ULT laptop here which declares all the ports
A-D in the VBT, so in order to avoid assert_port_valid() tripping
on D
From: Ville Syrjälä
Instead of listing every platform's possible DDI outputs
in intel_setup_outputs() just loop over the new port_mask
to achieve the same thing.
HSW/BDW were left as is since they still look at the straps
as well.
DSI is still a mess. For now just check for the relevant
platfor
From: Ville Syrjälä
The SDVO code already warns when the port in question doesn't
actually support SDVO. Let's make that also bail the encoder
registration like the generic assert_port_valid() we added.
And add a similar thing for g4x HDMI, mainly because on g4x
itsefl port D only supports DP bu
From: Ville Syrjälä
Sprinkle some asserts to catch any mishaps in the port_mask
vs. output init.
For DDI/DP/HDMI/SDVO I decided that we want to bail out for
an invalid port since those are the encoder types where
we might want consider driving the whole thing from the VBT
child device list, and
From: Ville Syrjälä
Sprinkle in some BUILD_BUG_ON()s to make sure some of
the bitmasks used in the device info have enough bits.
Do we have a better place for this sort of stuff?
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_device_info.c | 4
1 file changed, 4 insertions(+
From: Ville Syrjälä
Declare the available DVO/SDVO/HDMI/DP/DDI ports in the
device info. The other outputs (LVDS/TV/DSI/VGA) are left
out since for most of them we don't consider them as "ports".
DSI we should probably perhaps include somehow in the device
info. Just not sure how. Or we just int
From: Ville Syrjälä
HSW/BDW don't have DDI-F so don't go looking for one.
Seems to have been accidentally left behind when the
skl+ stuff got split out in commit 097d9e902068
("drm/i915/display: remove strap checks from gen 9").
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/in
From: Ville Syrjälä
Swap the roles of the index vs. value for the VBT DDC pin
mapping tables. This is not strictly necessary for DDC pins
but it will make this work exactly like the AUX CH mapping
tables where the role reversal is necessary (or at least makes
things easier). Consistency is good.
From: Ville Syrjälä
Now that we have encoder->devdata everwhere we don't need
the intel_bios_is_port_dp_dual_mode() wrapper any more.
And while at it let's include it in the child device log
dump as well since the logic in there is a bit more complex
than just DP&&HDMI.
Signed-off-by: Ville Syr
From: Ville Syrjälä
The big switch+if statement mess in map_aux_ch() is
illegible. Split up into cleaner per-platform arrays
like we already have for the gmbus pins.
We use enum aux_ch as the index and the VBT thing as
the value. Slightly non-intuitive perhaps but if we
did it the other way arou
From: Ville Syrjälä
Currently we sanitize the child device aux_ch/ddc_pin while parsing
the ports from VBT. But that won't work when we have duplicate child
devices for the same port.
Instead let's sanitize just before initializing the encoder,
based on which resources were consumed by encoders
From: Ville Syrjälä
We need to untangle the mess where some SKL machines (at least)
declare both DDI A and DDI E to be present in their VBT, and
both using AUX A. DDI A is a ghost eDP, wheres DDI E may be a
real DP->VGA converter.
Currently that is handled by checking the VBT child devices
for c
From: Ville Syrjälä
Add a mechanism by which we can toggle the HPD sense for
individual encoders.
This will be used during eDP probing to figure out if
anything is actually connected. The normal intel_hpd_irq_setup()
thing doesn't work since we only do that after probing the
outputs, and we only
From: Ville Syrjälä
Pair each _hotplug_enables() function with
a corresponding _hotplug_mask() function so that
we can determine right bits to clear on a per hpd_pin basis.
We'll need this for turning on HPD sense for a specific
encoder rather than just all of them.
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä
The idea that ctg uses different HPD live state bits is
total nonsense, at least on my machine (Dell Latitude
E5400).
The only reason DP-B even works on my ctg is that DP-D
live state is stuck high, even though there is no physical
DP-D port. So when the detect checks DP-B li
From: Ville Syrjälä
We'll need dig_port->connected() to be there for a HPD live
state check during eDP connector probing. Reorder intel_ddi_init()
accordingly. g4x_dp_init() is already fine.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 40
From: Ville Syrjälä
I just wanted to init DDI ports in VBT child device order
without any up front assumptions about which conflicting
child device defition is valid. That is pretty much what
we need to do for the ADL laptops with the phantom eDP vs.
native HDMI on DDI B.
However that approach d
It seems that commit bc3c5e0809ae ("drm/i915/sseu: Don't try to store EU
mask internally in UAPI format") exposed a potential out-of-bounds
access, reported by UBSAN as following on a laptop with a gen 11 i915
card:
UBSAN: array-index-out-of-bounds in drivers/gpu/drm/i915/gt/intel_sseu.c:65:27
On Mon, Feb 20, 2023 at 8:51 AM Tvrtko Ursulin
wrote:
>
>
> On 20/02/2023 16:44, Tvrtko Ursulin wrote:
> >
> > On 20/02/2023 15:52, Rob Clark wrote:
> >> On Mon, Feb 20, 2023 at 3:33 AM Tvrtko Ursulin
> >> wrote:
> >>>
> >>>
> >>> On 17/02/2023 20:45, Rodrigo Vivi wrote:
> >
> > [snip]
> >
> >>>
On Mon, Feb 20, 2023 at 8:44 AM Tvrtko Ursulin
wrote:
>
>
> On 20/02/2023 15:52, Rob Clark wrote:
> > On Mon, Feb 20, 2023 at 3:33 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 17/02/2023 20:45, Rodrigo Vivi wrote:
>
> [snip]
>
> >> Yeah I agree. And as not all media use cases are the same, as a
On 20/02/2023 16:44, Tvrtko Ursulin wrote:
On 20/02/2023 15:52, Rob Clark wrote:
On Mon, Feb 20, 2023 at 3:33 AM Tvrtko Ursulin
wrote:
On 17/02/2023 20:45, Rodrigo Vivi wrote:
[snip]
Yeah I agree. And as not all media use cases are the same, as are not
all compute contexts someone som
From: Ville Syrjälä
Grab the HDR DPCD refresh timeout (time we need to wait after
writing the sourc OUI before the HDR DPCD registers are ready)
from the VBT.
Windows doesn't even seem to have any default value for this,
which is perhaps a bit weird since the VBT value is documented
as TGL+ and
On 20/02/2023 15:52, Rob Clark wrote:
On Mon, Feb 20, 2023 at 3:33 AM Tvrtko Ursulin
wrote:
On 17/02/2023 20:45, Rodrigo Vivi wrote:
[snip]
Yeah I agree. And as not all media use cases are the same, as are not
all compute contexts someone somewhere will need to run a series of
workloads
== Series Details ==
Series: series starting with [1/2] drm/i915: Fix audio ELD handling for DP MST
URL : https://patchwork.freedesktop.org/series/114194/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12762 -> Patchwork_114194v1
On Mon, Feb 20, 2023 at 05:45:45PM +0200, Lisovskiy, Stanislav wrote:
> On Tue, Feb 14, 2023 at 04:04:05PM +0200, Ville Syrjälä wrote:
> > On Tue, Feb 14, 2023 at 12:01:32PM +0200, Stanislav Lisovskiy wrote:
> > > From: Jigar Bhatt
> > >
> > > Display to communicate "display configuration" to Pco
== Series Details ==
Series: series starting with [1/2] drm/i915: Fix audio ELD handling for DP MST
URL : https://patchwork.freedesktop.org/series/114194/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./a
On 20/02/2023 15:45, Rob Clark wrote:
On Mon, Feb 20, 2023 at 4:22 AM Tvrtko Ursulin
wrote:
On 17/02/2023 17:00, Rob Clark wrote:
On Fri, Feb 17, 2023 at 8:03 AM Tvrtko Ursulin
wrote:
[snip]
adapted from your patches.. I think the basic idea of deadlines
(which includes "I want it NO
On Mon, Feb 20, 2023 at 3:33 AM Tvrtko Ursulin
wrote:
>
>
> On 17/02/2023 20:45, Rodrigo Vivi wrote:
> > On Fri, Feb 17, 2023 at 09:00:49AM -0800, Rob Clark wrote:
> >> On Fri, Feb 17, 2023 at 8:03 AM Tvrtko Ursulin
> >> wrote:
> >>>
> >>>
> >>> On 17/02/2023 14:55, Rob Clark wrote:
> On Fri
On 18/02/2023 21:15, Rob Clark wrote:
From: Rob Clark
Signed-off-by: Rob Clark
---
This should probably be re-written by someone who knows the i915
request/timeline stuff better, to deal with non-immediate deadlines.
But as-is I think this should be enough to handle the case where
we want s
On Tue, Feb 14, 2023 at 04:04:05PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 14, 2023 at 12:01:32PM +0200, Stanislav Lisovskiy wrote:
> > From: Jigar Bhatt
> >
> > Display to communicate "display configuration" to Pcode for more accurate
> > power accounting for DG2. Existing sequence is only sen
On Mon, Feb 20, 2023 at 4:22 AM Tvrtko Ursulin
wrote:
>
>
> On 17/02/2023 17:00, Rob Clark wrote:
> > On Fri, Feb 17, 2023 at 8:03 AM Tvrtko Ursulin
> > wrote:
>
> [snip]
>
> >>> adapted from your patches.. I think the basic idea of deadlines
> >>> (which includes "I want it NOW" ;-)) isn't cont
On 2/16/23 23:44, Jani Nikula wrote:
> Mostly this is prep work and plumbing for easier use of displayid
> structure version and primary use case for parsing the displayid blocks,
> but it can be nicely used for figuring out non-desktop too.
>
> Completely untested. :)
>
> BR,
> Jani.
>
> Cc: Ia
On Mon, Feb 20, 2023 at 5:19 AM Tvrtko Ursulin
wrote:
>
>
> On 18/02/2023 19:56, Rob Clark wrote:
> > On Thu, Feb 16, 2023 at 2:59 AM Tvrtko Ursulin
> > wrote:
> >>
> >> From: Tvrtko Ursulin
> >>
> >> Use the previously added dma-fence tracking of explicit waiters.
> >>
> >> Signed-off-by: Tvrtk
1 - 100 of 141 matches
Mail list logo
