Am 16.06.22 um 16:06 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Rudimentary vendor agnostic example of how lib_igt_drm_clients can be used
to display a sorted by card and usage list of processes using GPUs.
Borrows a bit of code from intel_gpu_top but for now omits the fancy
features like in
Hi Dave and Daniel,
here's the PR for drm-misc-next. AFAICT it contains mostly fixes and
cleanups. There's is one new driver for the LogiCVC display controller.
Best regards
Thomas
drm-misc-next-2022-06-17:
drm-misc-next for v5.20:
UAPI Changes:
Cross-subsystem Changes:
* dma-buf: Add sync-f
On 6/16/2022 5:12 PM, priyanka.dandam...@intel.com wrote:
From: Priyanka Dandamudi
For testing purposes, support forcing the lmem_bar_size through a new
modparam. In CI we only have a limited number of configurations for DG2,
but we still need to be reasonably sure we get a usable device (als
On 16/06/2022 23:13, Nerlige Ramappa, Umesh wrote:
From: John Harrison
GuC provides engine_id and last_switch_in ticks for an active context in
the pphwsp. The context image provides a 32 bit total ticks which is the
accumulated by the context (a.k.a. context[CTX_TIMESTAMP]). This
information
On 16/06/2022 15:19, Umesh Nerlige Ramappa wrote:
On Thu, Jun 16, 2022 at 03:00:56PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Stop displaying engine classes with no engines - it is not a huge problem
if they are shown, since the values will correctly be all zeroes, but it
does count
On Thu, 16 Jun 2022, priyanka.dandam...@intel.com wrote:
> From: Akeem G Abodunrin
>
> Add support for the local memory PICe resizable bar, so that
> local memory can be resized to the maximum size supported by the device,
> and mapped correctly to the PCIe memory bar. It is usual that GPU
> devic
On Thu, Jun 16, 2022 at 04:52:09PM -0700, Nicolin Chen wrote:
> + ret = vfio_unpin_pages(&vgpu->vfio_device, gfn << PAGE_SHIFT, npage);
> + drm_WARN_ON(&i915->drm, ret != npage);
The shifting of gfn seems to happen bother here and in the callers.
Also this is the only caller that does any
On Thu, Jun 16, 2022 at 04:52:11PM -0700, Nicolin Chen wrote:
> The pinned PFN list returned from vfio_pin_pages() is simply converted
> using page_to_pfn() without protection, so direct access via memcpy()
> will crash on S390 if the PFN is an IO PFN. Instead, the pages should
> be touched using k
Instead of always falling back to memcpy_fromio() for any size, prefer
using read{b,w,l}(). When reading struct members it's common to read
individual integer variables individually. Going through memcpy_fromio()
for each of them poses a high penalty.
Employ a similar trick as __seqprop() by using
Like was done for read, provide the equivalent for write. Even if
current users are not in the hot path, this should future-proof it.
v2:
- Remove default from _Generic() - callers wanting to write more
than u64 should use iosys_map_memcpy_to()
- Add WRITE_ONCE() cases dereferencing the po
There is a bunch of code an comments in the iommu type1 code that
suggest we can pin memory that is not page backed.
> int vfio_pin_pages(struct vfio_device *device, dma_addr_t iova,
> +int npage, int prot, struct page **phys_page)
I don't think phys_page makes much sense as an
On Thu, 16 Jun 2022, Ville Syrjälä wrote:
> On Thu, Jun 16, 2022 at 12:48:10PM +0300, Jani Nikula wrote:
>> v2 of [1]. Address review comments, drop crtc state compare move, add hw
>> state readout&sanitization split, and sprinkle some struct
>> drm_i915_private *i915 cleanups on top.
>>
>> BR,
>
From: Tvrtko Ursulin
We need some coverage of the virtual engines.
v2:
* Mark contexts as "allow hang". (Umesh)
* Fix destruction order in virtual_all.
Signed-off-by: Tvrtko Ursulin
Cc: Umesh Nerlige Ramappa
Reviewed-by: Umesh Nerlige Ramappa
---
tests/i915/drm_fdinfo.c | 293
> -Original Message-
> From: Jani Nikula
> Sent: Thursday, June 16, 2022 8:02 PM
> To: Gupta, Anshuman ; intel-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Wilson, Chris P ; Vivi, Rodrigo
>
> Subject: Re: [Intel-gfx] [PATCH v2 7/9] drm/i915/rpm: Enable D3Cold VR
> -Original Message-
> From: Nikula, Jani
> Sent: Thursday, June 16, 2022 6:26 PM
> To: Gupta, Anshuman ; intel-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Roper, Matthew D ; Nilawar, Badal
> ; Ewins, Jon ; Vivi, Rodrigo
> ; Ursulin, Tvrtko ; Tangudu,
> Tilak ;
Split out the modeset hardware state readout and sanitize, or state
setup, to a separate file.
Do some drive-by checkpatch fixes while at it.
v2: Rebase
Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä # v1
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/d
Pass struct drm_i915_private * instead of struct drm_device *, and
rename dev_priv to i915.
v2: Rebase
Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä # v1
---
drivers/gpu/drm/i915/display/intel_display.c | 4 +-
.../drm/i915/display/intel_modeset_setup.c| 194 +-
On 17/06/2022 08:20, Christian König wrote:
Am 16.06.22 um 16:06 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Rudimentary vendor agnostic example of how lib_igt_drm_clients can be
used
to display a sorted by card and usage list of processes using GPUs.
Borrows a bit of code from intel_gpu
On 05/04/2022 11:59, Thomas Hellström wrote:
When DMAR / VT-d is enabled, the display engine uses overfetching,
presumably to deal with the increased latency. To avoid display engine
errors and DMAR faults, as a workaround the GGTT is populated with scatch
PTEs when VT-d is enabled. However start
Hi Team,
This is Mitul Golani from OSGC bangalore team. Please add me to intel-gfx
mailing list to see/post message to all the list members.
Regards,
Mitul Golani
== Series Details ==
Series: series starting with [1/3] drm/i915/display: Add smem fallback
allocation for dpt (rev5)
URL : https://patchwork.freedesktop.org/series/104983/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11772_full -> Patchwork_104983v5_full
===
On Fri, 17 Jun 2022 at 11:15, Golani, Mitulkumar Ajitkumar
wrote:
>
> Hi Team,
>
> This is Mitul Golani from OSGC bangalore team. Please add me to intel-gfx
> mailing list to see/post message to all the list members.
You should be able to subscribe here:
https://lists.freedesktop.org/mailman/lis
Sure. Done.
Regards,
Mitul Golani
-Original Message-
From: Matthew Auld
Sent: 17 June 2022 15:51
To: Golani, Mitulkumar Ajitkumar
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] Access to Intel-gfx
On Fri, 17 Jun 2022 at 11:15, Golani, Mitulkumar Ajitkumar
wrote:
>
> Hi
On 16/06/2022 23:49, Lucas De Marchi wrote:
Exporting the symbols like intel_gtt_* creates some confusion inside
i915 that has symbols named similarly. In an attempt to isolate
platforms needing intel-gtt.ko, commit 7a5c922377b4 ("drm/i915/gt: Split
intel-gtt functions by arch") moved way too m
Each LFP may have different panel type which is stored in LFP data
data block. Based on the child device index respective panel-type/
panel-type2 field will be used.
v1: Initial rfc verion.
v2: Based on review comments from Jani,
- Used panel-type instead addition panel-index variable.
- DEVICE_HA
On 16/06/2022 23:49, Lucas De Marchi wrote:
Re-do what was attempted in commit 7a5c922377b4 ("drm/i915/gt: Split
intel-gtt functions by arch"). The goal of that commit was to split the
handlers for older hardware that depend on intel-gtt.ko so i915 can
be built for non-x86 archs, after some mor
On 6/17/2022 9:54 AM, Das, Nirmoy wrote:
On 6/16/2022 5:12 PM, priyanka.dandam...@intel.com wrote:
From: Priyanka Dandamudi
For testing purposes, support forcing the lmem_bar_size through a new
modparam. In CI we only have a limited number of configurations for DG2,
but we still need to be
Starting with TGL the disabling order of HDMI transcoder clock vs. DDI
BUF has swapped, fix this. There hasn't been any issues seen related to
this, but let's follow the spec.
Reported-by: Sandeep K Lakkakula
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_ddi.c | 6 +-
1 fi
Am 17.06.22 um 12:09 schrieb Tvrtko Ursulin:
On 17/06/2022 08:20, Christian König wrote:
Am 16.06.22 um 16:06 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Rudimentary vendor agnostic example of how lib_igt_drm_clients can
be used
to display a sorted by card and usage list of processes usin
== Series Details ==
Series: drm/i915/guc: Check for ct enabled while waiting for response
URL : https://patchwork.freedesktop.org/series/105258/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11773_full -> Patchwork_105258v1_full
===
Hi Lakshmi,
here would be another false positive from ci. My changes are not
affecting this error with busyness on skl with igt@kms_flip@busy-flip@a-edp1
/Juha-Pekka
On 17.6.2022 13.19, Patchwork wrote:
*Patch Details*
*Series:* series starting with [1/3] drm/i915/display: Add smem fallback
For some platfroms we use stop_machine version of
gen8_ggtt_insert_page/gen8_ggtt_insert_entries to avoid a
concurrent GGTT access bug but this causes a circular locking
dependency warning:
Possible unsafe locking scenario:
CPU0CPU1
---
== Series Details ==
Series: i915/pmu: Wire GuC backend to per-client busyness (rev3)
URL : https://patchwork.freedesktop.org/series/105085/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11773_full -> Patchwork_105085v3_full
On 5/25/22 20:43, Matthew Auld wrote:
A non-recoverable context must be used if the user wants proper error
capture on discrete platforms. In the future the kernel may want to blit
the contents of some objects when later doing the capture stage.
Testcase: igt@gem_exec_capture@capture-recoverab
== Series Details ==
Series: series starting with [1/2] agp/intel: Rename intel-gtt symbols
URL : https://patchwork.freedesktop.org/series/105261/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11773_full -> Patchwork_105261v1_full
==
== Series Details ==
Series: series starting with [1/2] iosys-map: Add per-word read
URL : https://patchwork.freedesktop.org/series/105273/
State : warning
== Summary ==
Error: dim checkpatch failed
59710fe2242f iosys-map: Add per-word read
-:87: ERROR:SPACING: spaces required around that ':'
== Series Details ==
Series: tests/drm_fdinfo: Test virtual engines
URL : https://patchwork.freedesktop.org/series/105278/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/105278/revisions/1/mbox/ not
applied
Applying: tests/drm_fdinfo: Test virtual
== Series Details ==
Series: series starting with [1/2] iosys-map: Add per-word read
URL : https://patchwork.freedesktop.org/series/105273/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11775 -> Patchwork_105273v1
Summary
-
== Series Details ==
Series: series starting with [1/2] drm/i915/display: split out hw state readout
and sanitize
URL : https://patchwork.freedesktop.org/series/105281/
State : warning
== Summary ==
Error: dim checkpatch failed
4bf73e0fb102 drm/i915/display: split out hw state readout and san
== Series Details ==
Series: series starting with [1/2] drm/i915/display: split out hw state readout
and sanitize
URL : https://patchwork.freedesktop.org/series/105281/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked s
== Series Details ==
Series: series starting with [1/2] drm/i915/display: split out hw state readout
and sanitize
URL : https://patchwork.freedesktop.org/series/105281/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11775 -> Patchwork_105281v1
=
On 5/25/22 20:43, Matthew Auld wrote:
Skip capturing any lmem pages that can't be copied using the CPU. This
in now only best effort on platforms that have small BAR.
Testcase: igt@gem-exec-capture@capture-invisible
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc:
On 5/25/22 20:43, Matthew Auld wrote:
If set, force the allocation to be placed in the mappable portion of
I915_MEMORY_CLASS_DEVICE. One big restriction here is that system memory
(i.e I915_MEMORY_CLASS_SYSTEM) must be given as a potential placement for the
object, that way we can always spill
== Series Details ==
Series: drm/i915/bios: calculate panel type as per child device index in VBT
(rev2)
URL : https://patchwork.freedesktop.org/series/104943/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11775 -> Patchwork_104943v2
==
== Series Details ==
Series: drm/i915/tgl+: Fix HDMI transcoder clock vs. DDI BUF disabling order
URL : https://patchwork.freedesktop.org/series/105290/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11775 -> Patchwork_105290v1
==
== Series Details ==
Series: series starting with [1/3] drm/i915/display: Add smem fallback
allocation for dpt (rev5)
URL : https://patchwork.freedesktop.org/series/104983/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11772_full -> Patchwork_104983v5_full
===
Issue is related to #5726. Updated the filters.
-Original Message-
From: Juha-Pekka Heikkila
Sent: Friday, June 17, 2022 4:36 AM
To: intel-gfx@lists.freedesktop.org; Vudum, Lakshminarayana
Subject: Re: ✗ Fi.CI.IGT: failure for series starting with [1/3]
drm/i915/display: Add smem fall
From: Ville Syrjälä
Now that we no longer fuzz M/N during fastset these should
match exctly.
In order to get a match with what the BIOS does we need to round
M/N down. And we do the opposite rounding when doing the readback.
That gets us pretty much the same thing back.
There can still be sligh
From: Ville Syrjälä
Shuffle some PLL functions around a bit to avoid ugle
forward declarations later on. No functional changes.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 176 +-
1 file changed, 88 insertions(+), 88 deletions(-)
diff --git
From: Ville Syrjälä
Now that we backfeed the actual DPLL frequency into the
compute crtc state all our clocks should come out exact.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 19 ---
1 file changed, 4 insertions(+)
From: Ville Syrjälä
To make the fastboot checks at least somewhat sensible let's mark
the expected DPLL as the active one right after we finished the
state computation. Otherwise intel_pipe_config_compare() will
always be comparing things against NULL/0.
TODO: This is still not really right. If
From: Ville Syrjälä
intel_crtc_dotclock() is a bit misplaced. In lieu of a better
place let's just move it next to its friends in intel_display.c.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 22
drivers/gpu/drm/i915/display/intel_display
On Fri, Jun 17, 2022 at 06:57:20AM -0700, Harish Chegondi wrote:
> On Tue, Jun 14, 2022 at 05:10:19PM -0700, Matt Roper wrote:
> > Let's replace the assortment of intel_gt_* and intel_uncore_* functions
> > that operate on MCR registers with a cleaner set of interfaces:
> >
> > * intel_gt_mcr_re
On 5/25/22 20:43, Matthew Auld wrote:
No longer used.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Akeem G Abodunrin
---
drivers/gpu/drm/i915/intel_memory_regi
On 5/25/22 20:43, Matthew Auld wrote:
With the uAPI in place we should now have enough in place to ensure a
working system on small BAR configurations.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jorda
From: Ville Syrjälä
No sense in calling intel_modeset_pipe_config_late() for a disabled
pipe.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915
From: Ville Syrjälä
On BDW+ M/N are double buffered and so we can easily reprogram them
during a fastset. So for eDP panels that support seamless DRRS we
can just change these without a full modeset.
For earlier platforms we'd need to play tricks with M1/N1 vs.
M2/N2 during the fastset to make s
From: Ville Syrjälä
Add a function to get the fixed_mode with the highest clock.
The plan is to use this for the link bw calculation on seamless
DRRS panels so that we alwasy end up with the same link params
regardless of the requested refresh rate. This will allow fastset
to do seamless refresh
From: Ville Syrjälä
Windows/BIOS always uses fixed N values. Let's match that
behaviour.
Allows us to also get rid of that constant_n quirk stuff.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 36 +---
drivers/gpu/drm
When DMAR / VT-d is enabled, the display engine uses overfetching,
presumably to deal with the increased latency. To avoid display engine
errors and DMAR faults, as a workaround the GGTT is populated with scatch
PTEs when VT-d is enabled. However starting with gen10, Write-combined
writing of scrat
Missed the fdo issue ref:
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5595
On 6/17/2022 1:55 PM, Nirmoy Das wrote:
For some platfroms we use stop_machine version of
gen8_ggtt_insert_page/gen8_ggtt_insert_entries to avoid a
concurrent GGTT access bug but this causes a circular lock
On Fri, Jun 17, 2022 at 01:52:03AM -0700, Lucas De Marchi wrote:
Instead of always falling back to memcpy_fromio() for any size, prefer
using read{b,w,l}(). When reading struct members it's common to read
individual integer variables individually. Going through memcpy_fromio()
for each of them po
From: Ville Syrjälä
We have a couple of places that want to make distinction between
double buffered M/N registers vs. the split M1/N1+M2/N2 registers.
Add a helper for that.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 7 ++-
drivers/gpu/drm/i915/display
From: Ville Syrjälä
Fill port_clock and hw.adjusted_mode.crtc_clock with the actual
frequency we're going to be getting from the hardware. This will
let us accurately compute all derived state that depends on those.
v2: Reintroduce iCLKIP WARN
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrj
Hi,
On Thu, Jun 16, 2022 at 05:31:05PM +0530, Anshuman Gupta wrote:
> From: Tvrtko Ursulin
>
> Store a pointer to respective local memory region in intel_gt so it can be
> used when memory local to a GT needs to be allocated.
>
> Cc: Andi Shyti
> Signed-off-by: Tvrtko Ursulin
> Signed-off-by:
From: Ville Syrjälä
Do the DPLL computation before fastset checks. This should
allow us to get rid of all that horrible fuzzy clock handling
for fastsets. Who knows how many bugs there are caused by our
state not actually matching what the hardware will generate.
Reviewed-by: Jani Nikula
Signed
From: Ville Syrjälä
We currently fail to reconstruct the bw related cdclk limits
during readout, which triggers a cdclk reclaculation during
fastboot, which is then likely forces a full modeset anyway.
Reconstruct some of the missing state so that we can skip
the cdclk recomputation and thus hav
On Fri, 17 Jun 2022, Animesh Manna wrote:
> Each LFP may have different panel type which is stored in LFP data
> data block. Based on the child device index respective panel-type/
> panel-type2 field will be used.
>
> v1: Initial rfc verion.
> v2: Based on review comments from Jani,
> - Used panel
From: Ville Syrjälä
And with fastset made to not suck we can consider allowing
seameless M/N changes on eDP panels that support such things.
I've given that a quick test here on a TGL and it seemed to work
OK.
The rough parts:
- The DPLL stuff is kinda messy still, a lot of which is due to
the
From: Ville Syrjälä
Currently we calculate a lot of things (pixel rate, watermarks,
cdclk) trusting that the DPLL can generate the exact frequency
we ask it. In practice that is not true and there can be
certain amount of rounding involved.
To allow us to eventually get accurate numbers for all
From: Ville Syrjälä
Use round-to-nearest behavour when calculating the TMDS clock.
Matches what we do for most other clock related things.
Acked-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdmi.c
On Tue, Jun 14, 2022 at 05:10:19PM -0700, Matt Roper wrote:
> Let's replace the assortment of intel_gt_* and intel_uncore_* functions
> that operate on MCR registers with a cleaner set of interfaces:
>
> * intel_gt_mcr_read -- unicast read from specific instance
> * intel_gt_mcr_read_any[_fw]
From: Ville Syrjälä
Only reassign the pipe's DPLL if it's going through a full
.compute_config() cycle. If OTOH it's just getting modeset
eg. in order to change cdclk there doesn't seem much point in
picking a new DPLL for it.
This should also prevent .get_dplls() from seeing a funky port_clock
From: Ville Syrjälä
Now that we no longer do the fuzzy clock and M/N checks we can
get rid of the fastset state copy hacks.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 28 +++-
1 file changed, 3 insertions(+), 25 del
> Who did you find is doing the sampling in the real world use case? AFAIR
> if one one is querying busyness, I thought there would only be the GuC
> ping worker which runs extremely infrequently (to avoid some counter
> overflow).
>
> Regards,
>
> Tvrtko
>
> >
Hi Tvrtko, the case where we
== Series Details ==
Series: drm/i915: Fix a lockdep warning at error capture
URL : https://patchwork.freedesktop.org/series/105291/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11776 -> Patchwork_105291v1
Summary
---
Cc'ing intel-pci, lkml, Bjorn
On Fri, Jun 17, 2022 at 11:32:37AM +0300, Jani Nikula wrote:
On Thu, 16 Jun 2022, priyanka.dandam...@intel.com wrote:
From: Akeem G Abodunrin
Add support for the local memory PICe resizable bar, so that
local memory can be resized to the maximum size supported by
== Series Details ==
Series: drm/i915: Improve on suspend / resume time with VT-d enabled (rev2)
URL : https://patchwork.freedesktop.org/series/102187/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
This series refactors i915's stolen memory region to use ttm.
v2: handle disabled stolen similar to legacy version.
relying on ttm to fail allocs works fine, but is dmesg noisy and causes
testing
dmesg warning regressions.
v3: rebase to latest drm-tip.
fix v2 code
Various places within the driver override the default chosen cache_level.
Before ttm, these overrides were permanent until explicitly changed again
or for the lifetime of the buffer.
TTM movement code came along and decided that it could make that
decision at that time, which is usually well after
i965G[M] cannot relocate objects above 4GiB.
Ensure ttm uses dma32 on these systems.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/intel_region_ttm.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c
b/drivers/gpu/drm/i915
During testing make can_mmap consider whether the region is private.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/selftest
By default i915_ttm_cache_level() decides I915_CACHE_LLC if HAS_SNOOP.
This is divergent from existing backends code which only considers
HAS_LLC.
Testing shows that trusting snooping on gen5- is unreliable and bsw via
ggtt mappings, so limit DGFX for now and maintain previous behaviour.
Signed-of
For situations where allocations need to fail on alloc instead of
delayed get_pages, add a new alloc flag to pin the ttm bo.
This makes sure that the resource has been allocated during buffer
creation, allowing it to fail with an error if the placement is
exhausted.
This allows existing fallback op
== Series Details ==
Series: drm/i915: Improve on suspend / resume time with VT-d enabled (rev2)
URL : https://patchwork.freedesktop.org/series/102187/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11776 -> Patchwork_102187v2
===
add callbacks for alloc and free.
this allows region creators to allocate any extra storage they may
require.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/intel_memory_region.c | 16 +---
drivers/gpu/drm/i915/intel_memory_region.h | 2 ++
2 files changed, 15 insertions(+),
ttm managed buffers start off with system resource definitions and ttm_tt
tracking structures allocated (though unpopulated).
currently this prevents clearing of buffers on first move to desired
placements.
The desired behaviour is to clear user allocated buffers and any kernel
buffers that specif
Stolen regions are not page backed or considered iomem.
Prevent flags indicating such.
This correctly prevents stolen buffers from attempting to directly map
them.
See i915_gem_object_has_struct_page() and i915_gem_object_has_iomem()
usage for where it would break otherwise.
Signed-off-by: Robert
prepare for ttm based stolen region by using ttm range manager
as the resource manager for stolen region.
Signed-off-by: Robert Beckett
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 6 ++--
drivers/gpu/drm/i915/intel_region_ttm.c | 31 +++
refactor stolen memory region to use ttm.
this necessitates using ttm resources to track reserved stolen regions
instead of drm_mm_nodes.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/display/intel_fbc.c | 78 ++--
.../gpu/drm/i915/gem/i915_gem_object_types.h | 2 -
drivers/gpu
Gem buffers could still be in use by display after i915_gem_suspend()
is executed so there is chances that i915_gem_flush_free_objects()
will be being executed at the same time that
intel_runtime_pm_driver_release() is executed printing warnings about
wakerefs will being held.
So here only calling
On Thu, Jun 16, 2022 at 03:49:43PM -0700, Lucas De Marchi wrote:
> Re-do what was attempted in commit 7a5c922377b4 ("drm/i915/gt: Split
> intel-gtt functions by arch"). The goal of that commit was to split the
> handlers for older hardware that depend on intel-gtt.ko so i915 can
> be built for non-
On Fri, Jun 17, 2022 at 12:06:29PM -0700, José Roberto de Souza wrote:
> Gem buffers could still be in use by display after i915_gem_suspend()
> is executed so there is chances that i915_gem_flush_free_objects()
> will be being executed at the same time that
> intel_runtime_pm_driver_release() is e
== Series Details ==
Series: drm/i915: Implement a bit of bw_state readout
URL : https://patchwork.freedesktop.org/series/105299/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11776 -> Patchwork_105299v1
Summary
---
== Series Details ==
Series: drm/i915: Make fastset not suck and allow seamless M/N changes (rev5)
URL : https://patchwork.freedesktop.org/series/103491/
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ä
The stuff programmed into the wm/ddb registers of planes
on disabled pipes doesn't matter. So during readout just
leave our software state tracking for those zeroed.
This should avoid us trying too hard to clean up after
whatever mess the VBIOS/GOP left in there. The actual
h
== Series Details ==
Series: drm/i915: Make fastset not suck and allow seamless M/N changes (rev5)
URL : https://patchwork.freedesktop.org/series/103491/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11776 -> Patchwork_103491v5
=
== Series Details ==
Series: drm/i915: ttm for stolen (rev2)
URL : https://patchwork.freedesktop.org/series/101396/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
We have seen multiple RC6 issues where it is useful to know
which global forcewake bits are set. Add this to the 'drpc'
debugfs output.
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --g
[+cc Christian, author of pci_resize_resource(), Sergei, author of
rebalancing patches]
Hi Lucas,
On Fri, Jun 17, 2022 at 11:44:41AM -0700, Lucas De Marchi wrote:
> Cc'ing intel-pci, lkml, Bjorn
>
> On Fri, Jun 17, 2022 at 11:32:37AM +0300, Jani Nikula wrote:
> > On Thu, 16 Jun 2022, priyanka.da
1 - 100 of 129 matches
Mail list logo
