From: Somalapuram Amaranath
Change the ttm_range_man_alloc() allocation from pages to size in bytes.
Fix the dependent drm_mm_nodes start and size from pages to bytes.
v2 (chk): Change the drm_mm_node usage in amdgpu as well. re-order the
patch to be independent of the resource->start
Instead of resource->start use the cursor to get this.
v2 (chk): remove changes to amdgpu_bo_gpu_offset_no_check(), that
won't work with the AGP aperture otherwise.
Signed-off-by: Somalapuram Amaranath
Reviewed-by: Christian König
Signed-off-by: Christian König
---
From: Somalapuram Amaranath
Change the parameters of ttm_range_man_init_nocheck()
size from page size to byte size.
Cleanup the PAGE_SHIFT operation on the depended caller functions.
Signed-off-by: Somalapuram Amaranath
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
Hi guys,
this is an extract from Amar's earlier patch set with quite some
re-ordering, bug fixes and separating changes into smaller patches.
Background is that we want to use GEM/TTM to manage all kind of
resources which most are not accounted in pages but rather bytes or even
arbitary units
From: Ville Syrjälä
Instead of consulting vbt.ports[] lets just go through the
whole child device list to check whether a specific port
was declared by the VBT or not.
Note that this doesn't change anything wrt. detecting duplicate
child devices with the same port as vbt.ports[] would also
== Series Details ==
Series: Fix logic to get slice_height for dp (rev3)
URL : https://patchwork.freedesktop.org/series/113594/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12735_full -> Patchwork_113594v3_full
Summary
> From: Liu, Yi L
> Sent: Tuesday, February 14, 2023 10:03 AM
>
> > From: Jason Gunthorpe
> > Sent: Tuesday, February 14, 2023 7:44 AM
> >
> > On Mon, Feb 13, 2023 at 07:13:36AM -0800, Yi Liu wrote:
> > > +static struct vfio_device *vfio_device_from_file(struct file *file)
> > > +{
> > > +
== Series Details ==
Series: PL1 power limit fixes for ATSM
URL : https://patchwork.freedesktop.org/series/113984/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12735 -> Patchwork_113984v1
Summary
---
**SUCCESS**
On 2/13/23 21:33, Ashutosh Dixit wrote:
On ATSM the PL1 power limit is disabled at power up. The previous uapi
assumed that the PL1 limit is always enabled and therefore did not have a
notion of a disabled PL1 limit. This results in erroneous PL1 limit values
when PL1 limit is disabled. For
== Series Details ==
Series: Fix logic to get slice_height for dp (rev3)
URL : https://patchwork.freedesktop.org/series/113594/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12735 -> Patchwork_113594v3
Summary
---
hwm_field_scale_and_write has a single caller hwm_power_write and is
specific to hwm_power_write but makes it appear that it is a general
function which can have multiple callers. Replace the function with
hwm_power_max_write which is specific to hwm_power_write and use that in
future patches
On ATSM the PL1 power limit is disabled at power up. The previous uapi
assumed that the PL1 limit is always enabled and therefore did not have a
notion of a disabled PL1 limit. This results in erroneous PL1 limit values
when PL1 limit is disabled. For example at power up, the disabled ATSM PL1
Previous documentation suggested that the PL1 power limit is always enabled
in HW. However we now find this not to be the case on some platforms (such
as ATSM). Therefore enable the PL1 power limit (by setting the enable bit)
when writing the PL1 limit value to HW.
Bspec: 51864
Signed-off-by:
Previous PL1 power limit implementation assumed that the PL1 limit is
always enabled in HW. However we now find this not to be the case on ATSM
where the PL1 limit is disabled at power up. This requires changes in the
previous PL1 limit implementation.
Submitting 3 patches for easier review but
According VDSC spec 1.2a Section 3.8 Options for Slice
implies that 108 lines is an optimal slice height, but any
size can be used as long as vertical active
integer multiple and maximum vertical slice count requirements are met.
Bspec: 49259
--v3
-remove previous fallback code and return
== Series Details ==
Series: drm/i915/xelpmp: Consider GSI offset when doing MCR lookups
URL : https://patchwork.freedesktop.org/series/113978/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12734_full -> Patchwork_113978v1_full
On Mon, 13 Feb 2023 13:00:49 -0800, Ashutosh Dixit wrote:
>
> On ATSM the PL1 limit is disabled at power up. The previous uapi assumed
> that the PL1 limit is always enabled and therefore did not have a notion of
> a disabled PL1 limit. This results in erroneous PL1 limit values when the
> PL1
== Series Details ==
Series: Resolve barrier tasks list related issues
URL : https://patchwork.freedesktop.org/series/113975/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12734_full -> Patchwork_113975v1_full
Summary
== Series Details ==
Series: drm/i915: Transcoder timing stuff
URL : https://patchwork.freedesktop.org/series/113974/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12734_full -> Patchwork_113974v1_full
Summary
---
> From: Alex Williamson
> Sent: Tuesday, February 14, 2023 7:22 AM
>
> On Mon, 13 Feb 2023 07:13:36 -0800
> Yi Liu wrote:
>
> > 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
> From: Jason Gunthorpe
> Sent: Tuesday, February 14, 2023 7:44 AM
>
> On Mon, Feb 13, 2023 at 07:13:36AM -0800, Yi Liu wrote:
> > +static struct vfio_device *vfio_device_from_file(struct file *file)
> > +{
> > + struct vfio_device_file *df = file->private_data;
> > +
> > + if (file->f_op !=
> From: Alex Williamson
> Sent: Tuesday, February 14, 2023 3:47 AM
>
> On Mon, 13 Feb 2023 07:13:33 -0800
> Yi Liu wrote:
>
> > 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
== Series Details ==
Series: drm/i915/xelpmp: Consider GSI offset when doing MCR lookups
URL : https://patchwork.freedesktop.org/series/113978/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12734 -> Patchwork_113978v1
== Series Details ==
Series: drm/i915/hwmon: PL1 power limit fixes for ATSM
URL : https://patchwork.freedesktop.org/series/113972/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12733_full -> Patchwork_113972v1_full
Summary
MCR range tables use the final MMIO offset of a register (including the
0x38 GSI offset when applicable). Since the i915_mcr_reg_t passed
as a parameter during steering lookup does not include the GSI offset,
we need to add it back in for GSI registers before searching the tables.
Fixes:
== Series Details ==
Series: Resolve barrier tasks list related issues
URL : https://patchwork.freedesktop.org/series/113975/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12734 -> Patchwork_113975v1
Summary
---
== Series Details ==
Series: drm/i915/wm: legacy watermark code shuffling (rev2)
URL : https://patchwork.freedesktop.org/series/113775/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12733_full -> Patchwork_113775v2_full
== Series Details ==
Series: Resolve barrier tasks list related issues
URL : https://patchwork.freedesktop.org/series/113975/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
On Mon, Feb 13, 2023 at 07:13:36AM -0800, Yi Liu wrote:
> +static struct vfio_device *vfio_device_from_file(struct file *file)
> +{
> + struct vfio_device_file *df = file->private_data;
> +
> + if (file->f_op != _device_fops)
> + return NULL;
> + return df->device;
> +}
> +
== Series Details ==
Series: drm/i915: Transcoder timing stuff
URL : https://patchwork.freedesktop.org/series/113974/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12734 -> Patchwork_113974v1
Summary
---
**SUCCESS**
On Mon, Feb 13, 2023 at 02:11:26PM +0100, Das, Nirmoy wrote:
On 2/10/2023 4:03 PM, Andi Shyti wrote:
It is becoming a strong habit to call the drm_i915_private
structures "i915", but there are still many left that are called
dev_priv.
Sometimes this makes grepping a bit challenging and anyway
== Series Details ==
Series: drm/i915: Transcoder timing stuff
URL : https://patchwork.freedesktop.org/series/113974/
State : warning
== Summary ==
Error: dim checkpatch failed
29054f91dc49 drm/i915: Rename intel_ddi_{enable, disable}_pipe_clock()
90b8f6819152 drm/i915: Flatten
On Mon, 13 Feb 2023 07:13:36 -0800
Yi Liu wrote:
> 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
On Mon, Feb 13, 2023 at 12:47:19PM -0700, Alex Williamson wrote:
> I think it's too late for v6.3 already, but given this needs at least
> one more spin, let's set expectations of this being v6.4 material. Thanks,
Please let's continue to try to get this finished during the merge
window, all
Barriers are now deleted from a barrier tasks list by temporarily removing
the list content, traversing that content with skip over the node to be
deleted, then adding the modified content back to the list. Since that
complex operation is not serialized with other concurrent uses of the
list,
Users reported oopses on list corruptions when using i915 perf with a
number of concurrently running graphics applications. Root cause analysis
pointed out to an issue in barrier processing code -- a race among perf
open / close replacing active barriers with perf requests on kernel
contexts and
Test-with: <20230213095040.13457-2-janusz.krzyszto...@linux.intel.com>
The series consist of two patches so far submitted separately, with no
changes from original versions. Together theses patches are beleived to
resolve issues related to intentionally racy way of deleting individual
barriers
On Monday, 13 February 2023 19:28:50 CET Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/active: Serialize access to barrier tasks lists
> URL : https://patchwork.freedesktop.org/series/113962/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_12732 ->
From: Ville Syrjälä
We just wrote the EDP transcoder's VTOTAL register a few lines
earlier, so instead of reading it back out again let's just
generate the same value for the transocder B/C register.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 4 ++--
1
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). Too lazy to figure out what the is going
on there, so just sprinkle
From: Ville Syrjälä
On TGL VBLANK.VBLANK_START was the mechanism by which we can
delay the pipe's internal vblank in relation to the transcoder's
vblank. On ADL+ that no longer does anything. Instead we must
now use the new TRANS_SET_CONTEXT_LATENCY register. Program it
accordingly.
And since
From: Ville Syrjälä
Define the contents of the transcoder timing registers using
REG_GENMASK() & co. For ease of maintenance let's just define
the bitmasks with the full 16bit width (also used by the
current hand rolled stuff) even though not all bits are actually
used. None of the unsued bits
From: Ville Syrjälä
Clean up the eyesore in intel_get_transcoder_timings() a
bit by adding a local 'adjusted_mode' variable.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 35 +---
1 file changed, 16 insertions(+), 19 deletions(-)
diff --git
From: Ville Syrjälä
The PSR code has no business mucking around with the
vblank delay. Currently nothing that depends on knowing
the exact vblank start scanline (eg. vblank evasion)
is aware of this and so will not work correctly.
The w/a seems to be for pre-production hw only, so let's
just
From: Ville Syrjälä
On TGL+ the normal "start of vblank" interrupt is the pipe's
(potentially delayed) version. Add the new bit for the
transcoder's "unmodified" vblank so I don't have to dig it
out from bspec every time.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
From: Ville Syrjälä
With the delayed vblank we need to start knowing where
the blanking periods start. So let's start dumping
out also the blanking start/end timings.
And while at it let's try to make that huge list of
numbers somewhat legible by indicating what each value
means. Also drop the
From: Ville Syrjälä
Rename PIPECONF to TRANSCONF to make it clear what it actually
applies to.
While the usual convention is to pick the earliers name I think
in this case it's more clear to use the later name. Especially
as even the register offset is in the wrong range (0x7 vs.
0x6)
From: Ville Syrjälä
Name the CPU transcoder timing registers TRANS_FOO rather than
just FOO. This is the modern name, after the pipe/transcoder split
happened. Makes it a bit more obvious whether you pass in a pipe or
a transcoder.
PIPESRC is a bit special as it's a pipe register, even though
From: Ville Syrjälä
Use an early return to get rid of the extra indentation level
in intel_ddi_{enable,disable}_transcoder_clock().
Also unify the platform handling in between the two while at
it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 39
From: Ville Syrjälä
What intel_ddi_{enable,disable}_pipe_clock() actually do is
enable the clock to the transcoder, not the pipe. Rename
accordingly.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_crt.c| 4 ++--
drivers/gpu/drm/i915/display/intel_ddi.c| 20
From: Ville Syrjälä
Bunch of transcoder registers stuff. Mostly fallout
from hacking on DSB.
Ville Syrjälä (12):
drm/i915: Rename intel_ddi_{enable,disable}_pipe_clock()
drm/i915: Flatten intel_ddi_{enable,disable}_transcoder_clock()
drm/i915: Give CPU transcoder timing registers TRANS_
== Series Details ==
Series: drm/i915/hwmon: PL1 power limit fixes for ATSM
URL : https://patchwork.freedesktop.org/series/113972/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12733 -> Patchwork_113972v1
Summary
---
On ATSM the PL1 limit is disabled at power up. The previous uapi assumed
that the PL1 limit is always enabled and therefore did not have a notion of
a disabled PL1 limit. This results in erroneous PL1 limit values when the
PL1 limit is disabled. For example at power up, the disabled ATSM PL1 limit
Previous documentation suggested that the PL1 power limit is always enabled
in HW. However we now find this not to be the case on some platforms (such
as ATSM). Therefore enable the PL1 power limit (by setting the enable bit)
when writing the PL1 limit value to HW.
Bspec: 51864
Signed-off-by:
hwm_field_scale_and_write has a single caller hwm_power_write and is
specific to hwm_power_write but makes it appear that it is a general
function which can have multiple callers. Replace the function with
hwm_power_max_write which is specific to hwm_power_write and use that in
future patches
Previous PL1 power limit implementation assumed that the PL1 limit is
always enabled in HW. However we now find this not to be the case on ATSM
where the PL1 limit is disabled at power up. This requires changes in the
previous PL1 implementation.
Ashutosh Dixit (3):
drm/i915/hwmon: Replace
== Series Details ==
Series: drm/i915/wm: legacy watermark code shuffling (rev2)
URL : https://patchwork.freedesktop.org/series/113775/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12733 -> Patchwork_113775v2
Summary
On Mon, Feb 13, 2023 at 10:00:02PM +0200, Jani Nikula wrote:
> The file was never really about pm types, and now it's even more
> obvious. Move under display as intel_wm_types.h.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
>
On Mon, Feb 13, 2023 at 10:00:01PM +0200, Jani Nikula wrote:
> Follow the new convention of placing debugfs with the code.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> .../drm/i915/display/intel_display_debugfs.c | 219 +
> drivers/gpu/drm/i915/display/intel_wm.c
On Mon, Feb 13, 2023 at 10:00:00PM +0200, Jani Nikula wrote:
> Move the generic sanitize_watermarks() to intel_wm.[ch] and rename as
It's not generic though. Only the ilk_ stuff uses it.
> intel_wm_sanitize(). The slightly unfortunate downside is having to
> expose intel_atomic_check() from
On Mon, Feb 13, 2023 at 09:59:59PM +0200, Jani Nikula wrote:
> Get rid of the if ladder in intel_modeset_setup_hw_state() and hide a
> number of functions by adding a .get_hw_state() hook to watermark
> functions. At least for now, combine the platform specific sanitization
> to the hw state
On Mon, Feb 13, 2023 at 09:59:58PM +0200, Jani Nikula wrote:
> Move the wrappers to call watermark hooks into intel_wm.[ch]. This
> declutters intel_display.c nicely.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
>
On Mon, Feb 13, 2023 at 09:59:57PM +0200, Jani Nikula wrote:
> Add new files intel_wm.[ch] and i9xx_wm.[ch] under display/ to hold
> generic and pre-SKL watermark code, respectively. SKL+ watermark code
> has already been split out to skl_watermark.[ch].
>
> Use the _wm.[ch] naming for brevity;
On Mon, Feb 13, 2023 at 09:59:56PM +0200, Jani Nikula wrote:
> The memory frequency detection is a bit spread out here and
> there. Consolidate to intel_dram.c.
>
> v2:
> - Remove inaccurate comment (Ville)
> - Call detect_mem_freq() unconditionally (Ville)
>
> Cc: Ville Syrjälä
>
== Series Details ==
Series: drm/i915/wm: legacy watermark code shuffling (rev2)
URL : https://patchwork.freedesktop.org/series/113775/
State : warning
== Summary ==
Error: dim checkpatch failed
f48b5db2b7e9 drm/i915: move memory frequency detection to intel_dram.c
f7c1215772b4 drm/i915/wm:
== Series Details ==
Series: Copy highest enabled wm level to disabled wm levels for gen >= 9
URL : https://patchwork.freedesktop.org/series/113961/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12732_full -> Patchwork_113961v1_full
The file was never really about pm types, and now it's even more
obvious. Move under display as intel_wm_types.h.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display_core.h | 2 +-
drivers/gpu/drm/i915/display/intel_display_types.h | 2
Follow the new convention of placing debugfs with the code.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
.../drm/i915/display/intel_display_debugfs.c | 219 +
drivers/gpu/drm/i915/display/intel_wm.c | 226 ++
drivers/gpu/drm/i915/display/intel_wm.h
Move the generic sanitize_watermarks() to intel_wm.[ch] and rename as
intel_wm_sanitize(). The slightly unfortunate downside is having to
expose intel_atomic_check() from intel_display.c, but this declutters
intel_display.c nicely.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
Get rid of the if ladder in intel_modeset_setup_hw_state() and hide a
number of functions by adding a .get_hw_state() hook to watermark
functions. At least for now, combine the platform specific sanitization
to the hw state readouts on the relevant platforms instead of adding a
separate hook for
Move the wrappers to call watermark hooks into intel_wm.[ch]. This
declutters intel_display.c nicely.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 95 -
drivers/gpu/drm/i915/display/intel_wm.c | 105 +++
The memory frequency detection is a bit spread out here and
there. Consolidate to intel_dram.c.
v2:
- Remove inaccurate comment (Ville)
- Call detect_mem_freq() unconditionally (Ville)
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/gt/intel_rps.c | 29 -
v2 of [1] rebased on top of Ville's watermark level count changes.
[1] https://patchwork.freedesktop.org/series/113775/
Jani Nikula (7):
drm/i915: move memory frequency detection to intel_dram.c
drm/i915/wm: move remaining watermark code out of intel_pm.c
drm/i915/wm: move functions to
On Mon, 13 Feb 2023 07:13:33 -0800
Yi Liu wrote:
> 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
On Wed, Feb 01, 2023 at 04:51:46PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> As the logic for selecting the register and corresponsing values grew, the
> code become a bit unsightly. Consolidate by storing the required values at
> engine init time in the engine itself, and by doing
== Series Details ==
Series: drm/i915/active: Serialize access to barrier tasks lists
URL : https://patchwork.freedesktop.org/series/113962/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12732 -> Patchwork_113962v1
Summary
On Thu, 02 Feb 2023, Suraj Kandpal wrote:
> According VDSC spec 1.2a Section 3.8 Options for Slice
> implies that 108 lines is an optimal slice height, but any
> size can be used as long as vertical active
> integer multiple and maximum vertical slice count requirements are met.
>
> Bspec: 49259
On Mon, Feb 13, 2023 at 06:44:53PM +0200, Stanislav Lisovskiy wrote:
> There was a specific SW workaround requested, which should prevent
> some watermark issues happening, which requires copying highest
> enabled wm level to those disabled wm levels(bit 31 is of course
> still needs to be
== Series Details ==
Series: drm/i915/active: Serialize access to barrier tasks lists
URL : https://patchwork.freedesktop.org/series/113962/
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: Copy highest enabled wm level to disabled wm levels for gen >= 9
URL : https://patchwork.freedesktop.org/series/113961/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12732 -> Patchwork_113961v1
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 09e41676e35ab06e4bce8870ea3bf1f191c3cb90 Add linux-next specific
files for 20230213
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202301300743.bp7dpazv-...@intel.com
https
Barriers are now deleted from a barrier tasks list by temporarily removing
the list content, traversing that content with skip over the node to be
deleted, then adding the modified content back to the list. Since that
complex operation is not serialized with other concurrent uses of the
list,
Test-with: <20230213095040.13457-2-janusz.krzyszto...@linux.intel.com>
New igt@gem_barrier_race@remote-request subtest, intended for triggering
list corruptions reported by perf users, also revealed issues potentially
related to engine barrier tasks lists handling. For example, timeouts on
On Mon, Feb 13, 2023 at 06:41:18PM +0200, Jani Nikula wrote:
> On Mon, 13 Feb 2023, Ville Syrjälä wrote:
> > On Mon, Feb 13, 2023 at 06:08:50PM +0200, Jani Nikula wrote:
> >> On Wed, 08 Feb 2023, Ville Syrjala wrote:
> >> > From: Ville Syrjälä
> >> >
> >> > Instead of consulting vbt.ports[]
There was a specific SW workaround requested, which should prevent
some watermark issues happening, which requires copying highest
enabled wm level to those disabled wm levels(bit 31 is of course
still needs to be cleared).
This is related to different subsystems like PSR and others, which
may
On Fri, 10 Feb 2023, Jani Nikula wrote:
> On Tue, 07 Feb 2023, Greg Kroah-Hartman wrote:
>> On Tue, Feb 07, 2023 at 04:33:37PM +0200, Jani Nikula wrote:
>>> From: Ville Syrjälä
>>>
>>> CONFIG_DRM_USE_DYNAMIC_DEBUG breaks debug prints for (at least modular)
>>> drm drivers. The debug prints can
On Mon, 13 Feb 2023, Ville Syrjälä wrote:
> On Mon, Feb 13, 2023 at 06:08:50PM +0200, Jani Nikula wrote:
>> On Wed, 08 Feb 2023, Ville Syrjala wrote:
>> > From: Ville Syrjälä
>> >
>> > Instead of consulting vbt.ports[] lets just go through the
>> > whole child device list to check whether a
On Mon, Feb 13, 2023 at 06:08:50PM +0200, Jani Nikula wrote:
> On Wed, 08 Feb 2023, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Instead of consulting vbt.ports[] lets just go through the
> > whole child device list to check whether a specific port
> > was declared by the VBT or not.
>
On Wed, 08 Feb 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Since we now populate encoder->devdata for all DP capable
> platforms we can consult it directly during the eDP
> connector init instead of taking a detour via some global
> list/array.
>
> Unfortunately we can't quire get rid
On Wed, 08 Feb 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Let's make encoder->devdata (the VBT informaiton for the port)
*information
> available on g4x+ platforms as well. Much easier when you can
> just grab it there instead of trying to find it from some global
> list array based
On Wed, 08 Feb 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
Subject: *registered
>
> Display WA #1178 calls us to tweak some magic bits when doing AUX
> to an external combo PHY port. Instead of looking to see if the VBT
> has declared such a port (which could in theory even alias with a
>
On Wed, 08 Feb 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We need to get rid of the vbt.ports[] array. The main
> reason being the bogus VBTs found on many ADL laptops
> that declare both eDP+HDMI child devices for the same
> port. The goal is to probe each of those in order and
>
On Wed, 08 Feb 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Instead of consulting vbt.ports[] lets just go through the
> whole child device list to check whether a specific port
> was declared by the VBT or not.
Might want to mention that this does not impact the dupe checking even
if
On Mon, 13 Feb 2023, "Das, Nirmoy" wrote:
> On 2/10/2023 4:03 PM, Andi Shyti wrote:
>> It is becoming a strong habit to call the drm_i915_private
>> structures "i915", but there are still many left that are called
>> dev_priv.
>>
>> Sometimes this makes grepping a bit challenging and anyway it
>>
== Series Details ==
Series: Add vfio_device cdev for iommufd support (rev2)
URL : https://patchwork.freedesktop.org/series/113696/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/113696/revisions/2/mbox/ not
applied
Applying: vfio: Allocate per
This adds three vfio device ioctls for userspace using iommufd to set up
secure DMA context for device access.
VFIO_DEVICE_BIND_IOMMUFD: bind device to an iommufd, hence gain DMA
control provided by the iommufd. open_device
op is
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 | 18 ++
drivers/vfio/Makefile | 2 +-
drivers/vfio/vfio.h | 78
this prepares for adding DETACH ioctl for emulated VFIO devices.
Signed-off-by: Yi Liu
---
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 ++
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
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
1 - 100 of 130 matches
Mail list logo
