The sequence for Source DP PHY CTS automation is [2][1]:
1- Emulate successful Link Training(LT)
2- Short HPD and change link rates and number of lanes by LT.
(This is same flow for Link Layer CTS)
3- Short HPD and change PHY test pattern and swing/pre-emphasis
levels (This step should not trigger
On Tue, 23 Aug 2022 13:41:53 -0700, Umesh Nerlige Ramappa wrote:
>
> If a drm client is killed, then hw contexts used by the client are reset
> immediately. This reset clears the EU flex counter configuration. If an
> OA use case is running in parallel, it would start seeing zeroed eu
> counter
On Tue, 23 Aug 2022 13:41:52 -0700, Umesh Nerlige Ramappa wrote:
>
Hi Umesh,
> OA reports in the OA buffer contain an OA timestamp field that helps
> user calculate delta between 2 OA reports. The calculation relies on the
> CS timestamp frequency to convert the timestamp value to nanoseconds.
>
== Series Details ==
Series: Initial Meteorlake Support (rev10)
URL : https://patchwork.freedesktop.org/series/106786/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12144 -> Patchwork_106786v10
Summary
---
== Series Details ==
Series: Initial Meteorlake Support (rev10)
URL : https://patchwork.freedesktop.org/series/106786/
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: Split GAM and MSLICE steering
URL : https://patchwork.freedesktop.org/series/108627/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12144 -> Patchwork_108627v1
Summary
---
== Series Details ==
Series: drm/i915: Split GAM and MSLICE steering
URL : https://patchwork.freedesktop.org/series/108627/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
From: José Roberto de Souza
Expand the current stepping convention to accommodate the GMD
stepping info. Typically GMD step maps to letter stepping
by "A + step %4" and number to "A + step /4" i.e, GMD step
0 maps to STEP_A0, 1 to _A1, 2 to _A2, 3 to _A3, 4 to STEP_B0...
Future platforms might
From: Matt Roper
The part of the media and blitter engine contexts that we care about for
setting up an initial state are the same on MTL as they were on DG2
(and PVC), so we need to update the driver conditions to re-use the DG2
context table.
For render/compute engines, the part of the
From: Matt Roper
Going forward, the hardware teams no longer consider new platforms to
have a "generation" in the way we've defined it for past platforms.
Instead, each IP block (graphics, media, display) will have their own
architecture major.minor versions and stepping ID's which should be
The PCI Id's and platform definition are posted earlier.
Handful of early enablement patches including support for
display power wells, VBT and AUX Channel mapping, PCH and
gmbus support, dbus, mbus, sagv and memory bandwidth support
got merged.
This series adds the support for a new way to read
Although the bspec lists several MMIO ranges as "MSLICE," it turns out
that a subset of these are of a "GAM" subclass that has unique rules and
doesn't followed regular mslice steering behavior.
* Xe_HP SDV: GAM ranges must always be steered to 0,0. These
registers share the regular
On Tue, 23 Aug 2022 13:41:51 -0700, Umesh Nerlige Ramappa wrote:
>
> Disable Clock gating in EU when gathering the events so that EU events
> are not lost.
Reviewed-by: Ashutosh Dixit
On Tue, 23 Aug 2022 13:41:50 -0700, Umesh Nerlige Ramappa wrote:
>
> DG2 introduces 64 bit counters and OA reports that have 64 bit values
> for fields in the report header - report_id, timestamp, context_id and
> gpu ticks. i915 uses report_id, timestamp and context_id to check for
> valid
On Tue, 23 Aug 2022 13:41:49 -0700, Umesh Nerlige Ramappa wrote:
>
> On DG2 A0, the OAR report format is buggy. Workaround is to not use it
> for A0. For A0, remove the OAR format from the bitmask of supported
> formats.
Are we going to support A0 upstream? If we are this is:
Reviewed-by:
Hi Lucas,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on bb4f6b2281b11b009210f62eecd291f7b75c1e85]
url:
https://github.com/intel-lab-lkp/linux/commits/Lucas-De-Marchi/drm-i915-Improvements-to-stolen-memory-setup/20220916-044155
base:
On Tue, 23 Aug 2022 13:41:48 -0700, Umesh Nerlige Ramappa wrote:
>
Hi Umesh,
> @@ -740,23 +802,19 @@ static int gen8_append_oa_reports(struct
> i915_perf_stream *stream,
> u8 *report = oa_buf_base + head;
> u32 *report32 = (void *)report;
> u32 ctx_id;
Hi Lucas,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on bb4f6b2281b11b009210f62eecd291f7b75c1e85]
url:
https://github.com/intel-lab-lkp/linux/commits/Lucas-De-Marchi/drm-i915-Improvements-to-stolen-memory-setup/20220916-044155
base:
== Series Details ==
Series: Further multi-gt handling (rev2)
URL : https://patchwork.freedesktop.org/series/108577/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12143 -> Patchwork_108577v2
Summary
---
**SUCCESS**
== Series Details ==
Series: Further multi-gt handling (rev2)
URL : https://patchwork.freedesktop.org/series/108577/
State : warning
== Summary ==
Error: dim checkpatch failed
7b4382364d95 drm/i915/gt: Cleanup partial engine discovery failures
-:34: CHECK:COMPARISON_TO_NULL: Comparison to
== Series Details ==
Series: drm/i915: Improvements to stolen memory setup (rev2)
URL : https://patchwork.freedesktop.org/series/108620/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12143 -> Patchwork_108620v2
Summary
On Thu, Sep 15, 2022 at 03:25:15PM +0300, Jani Nikula wrote:
> On Wed, 14 Sep 2022, Matt Roper wrote:
> > Now that MTL is going to start providing two GTs, there are a few more
> > places in the driver that need to iterate over each GT instead of
> > operating directly on gt0. Also some more
From: Tvrtko Ursulin
This, along with the changes already landed in commit 1c66a12ab431
("drm/i915: Handle each GT on init/release and suspend/resume") makes
engines from all GTs actually known to the driver.
To accomplish this we need to sprinkle a lot of for_each_gt calls around
but is
Now that MTL is going to start providing two GTs, there are a few more
places in the driver that need to iterate over each GT instead of
operating directly on gt0. Also some more deliberate cleanup is needed,
in cases where we fail GT/engine initialization after the first GT has
been fully setup.
From: Chris Wilson
If we abort driver initialisation in the middle of gt/engine discovery,
some engines will be fully setup and some not. Those incompletely setup
engines only have 'engine->release == NULL' and so will leak any of the
common objects allocated.
v2:
- Drop the
From: Tvrtko Ursulin
Walk all GTs from i915_gem_resume when resuming engines.
Cc: Andi Shyti
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Matt Roper
Reviewed-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_pm.c | 22 --
1 file changed, 20 insertions(+), 2
From: Tvrtko Ursulin
Walk all GTs when suspending.
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Matt Roper
Reviewed-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_pm.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git
== Series Details ==
Series: drm/i915: Improvements to stolen memory setup (rev2)
URL : https://patchwork.freedesktop.org/series/108620/
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: Improvements to stolen memory setup (rev2)
URL : https://patchwork.freedesktop.org/series/108620/
State : warning
== Summary ==
Error: dim checkpatch failed
265abcb34854 drm/i915: Move dsm assignment to be after adjustment
7dcfafdbc554 drm/i915: Add
On Wed, Sep 14, 2022 at 04:13:41PM -0700, Umesh Nerlige Ramappa wrote:
On Wed, Sep 14, 2022 at 03:26:15PM -0700, Umesh Nerlige Ramappa wrote:
On Tue, Sep 06, 2022 at 09:39:33PM +0300, Lionel Landwerlin wrote:
On 06/09/2022 20:39, Umesh Nerlige Ramappa wrote:
On Tue, Sep 06, 2022 at 05:33:00PM
Add some helpers: adjust_stolen(), request_smem_stolen_() and
init_reserved_stolen() that are now called by i915_gem_init_stolen() to
initialize each part of the Data Stolen Memory region. Main goal is to
split the reserved part, also known as WOPCM, as its calculation changes
often per platform.
On Thu, Sep 15, 2022 at 09:18:39PM +, Patchwork wrote:
== Series Details ==
Series: drm/i915: Improvements to stolen memory setup
URL : https://patchwork.freedesktop.org/series/108620/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12143 -> Patchwork_108620v1
Hi Jani,
On Thu, Sep 15, 2022 at 03:25:15PM +0300, Jani Nikula wrote:
> On Wed, 14 Sep 2022, Matt Roper wrote:
> > Now that MTL is going to start providing two GTs, there are a few more
> > places in the driver that need to iterate over each GT instead of
> > operating directly on gt0. Also
Hi Matt,
On Wed, Sep 14, 2022 at 03:04:26PM -0700, Matt Roper wrote:
> From: Tvrtko Ursulin
>
> Walk all GTs when suspending.
>
> Signed-off-by: Tvrtko Ursulin
> Signed-off-by: Matt Roper
I had this as well... thanks again!
Reviewed-by: Andi Shyti
Andi
Hi Matt,
On Wed, Sep 14, 2022 at 03:04:25PM -0700, Matt Roper wrote:
> From: Tvrtko Ursulin
>
> Walk all GTs from i915_gem_resume when resuming engines.
>
> Cc: Andi Shyti
> Signed-off-by: Tvrtko Ursulin
> Signed-off-by: Matt Roper
I had this (and others) in my multi-gt branch from a long
== Series Details ==
Series: drm/i915: Improvements to stolen memory setup
URL : https://patchwork.freedesktop.org/series/108620/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12143 -> Patchwork_108620v1
Summary
---
== Series Details ==
Series: drm/i915: Improvements to stolen memory setup
URL : https://patchwork.freedesktop.org/series/108620/
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: Improvements to stolen memory setup
URL : https://patchwork.freedesktop.org/series/108620/
State : warning
== Summary ==
Error: dim checkpatch failed
90b79b3a0c3f drm/i915: Move dsm assignment to be after adjustment
060045222786 drm/i915: Add missing
> On Wed, Sep 14, 2022 at 04:51:03PM +, Winkler, Tomas wrote:
> > >
> > > On DG2, HuC loading is performed by the GSC, via a PXP command. The
> > > load operation itself is relatively simple (just send a message to
> > > the GSC with the physical address of the HuC in LMEM), but there are
>
== Series Details ==
Series: Delay disabling GuC scheduling of an idle context
URL : https://patchwork.freedesktop.org/series/108587/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12139_full -> Patchwork_108587v1_full
There is no reason to consider the setup of Data Stolen Memory fatal on
dgfx and non-fatal on integrated. Move the debug and error propagation
around so both have the same behavior: non-fatal. Before this change,
loading i915 on a system with TGL + DG2 would result in just TGL
succeeding the
Add some helpers: adjust_stolen(), request_smem_stolen_() and
init_reserved_stolen() that are now called by i915_gem_init_stolen() to
initialize each part of the Data Stolen Memory region. Main goal is to
split the reserved part, also known as WOPCM, as its calculation changes
often per platform.
DSMBASE register is defined so BDSM bitfield contains the bits 63 to 20
of the base address of stolen. For the supported platforms bits 0-19 are
zero but that may not be true in future. Add the missing mask.
Signed-off-by: Lucas De Marchi
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
: bb4f6b2281b11b009210f62eecd291f7b75c1e85
change-id: 20220915-stolen-7aa0e407368f
Best regards,
--
Lucas De Marchi
Reduce possible side effects of assigning the region and bailing out due
to errors.
Signed-off-by: Lucas De Marchi
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index acc561c0f0aa..42f4769bb4ac 100644
---
On 9/15/2022 01:59, Tvrtko Ursulin wrote:
Hi,
On 15/09/2022 00:46, john.c.harri...@intel.com wrote:
From: John Harrison
Going forwards, the intention is for GuC firmware files to be named
for their major version only and HuC firmware files to have no version
number in the name at all. This
== Series Details ==
Series: New GuC and new GuC/HuC names
URL : https://patchwork.freedesktop.org/series/108582/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12139_full -> Patchwork_108582v1_full
Summary
---
== Series Details ==
Series: Further multi-gt handling
URL : https://patchwork.freedesktop.org/series/108577/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12139_full -> Patchwork_108577v1_full
Summary
---
On Thu, Sep 15, 2022 at 09:23:52AM +0100, Tvrtko Ursulin wrote:
On 15/09/2022 09:09, Lucas De Marchi wrote:
On Thu, Sep 15, 2022 at 08:53:16AM +0100, Tvrtko Ursulin wrote:
On 14/09/2022 21:35, Lucas De Marchi wrote:
This reverts commit 58f44e349cfc10a4f2208fd806829c8fd046480b.
To be
On Thu, Sep 15, 2022 at 02:18:19PM +, Patchwork wrote:
== Series Details ==
Series: Revert "drm/i915: Force compilation with intel-iommu for CI validation"
URL : https://patchwork.freedesktop.org/series/108576/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12136_full ->
== Series Details ==
Series: drm/i915/gem: Really move i915_gem_context.link under ref protection
(rev3)
URL : https://patchwork.freedesktop.org/series/105975/
State : failure
== Summary ==
Error: make failed
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
On 15/09/2022 11:33, Anshuman Gupta wrote:
If i915 gem obj lies in lmem, then i915_gem_object_pin_map
need to grab a rpm wakeref to make sure gfx PCIe endpoint
function stays in D0 state during any access to mapping
returned by i915_gem_object_pin_map().
Subsequently i915_gem_object_upin_map
From: Chris Wilson
i915_perf assumes that it can use the i915_gem_context reference to
protect its i915->gem.contexts.list iteration. However, this requires
that we do not remove the context from the list until after we drop the
final reference and release the struct. If, as currently, we remove
Due to i915_perf assuming that it can use the i915_gem_context reference
to protect its i915->gem.contexts.list iteration, we need to defer removal
of the context from the list until last reference to the context is put.
However, there is a risk of triggering kernel warning on contexts list not
i915_perf assumes that it can use the i915_gem_context reference to
protect its i915->gem.contexts.list iteration. However, this requires
that we do not remove the context from the list until after we drop the
final reference and release the struct. If, as currently, we remove the
context from the
> -Original Message-
> From: Tvrtko Ursulin
> Sent: Thursday, September 15, 2022 7:48 PM
> To: Gupta, Anshuman ; intel-
> g...@lists.freedesktop.org
> Cc: Auld, Matthew ; Vivi, Rodrigo
>
> Subject: Re: [Intel-gfx] [RFC 1/1] drm/i915/dgfx: Handling of pin_map against
> rpm
>
>
> On
> -Original Message-
> From: Tvrtko Ursulin
> Sent: Thursday, September 15, 2022 8:03 PM
> To: Gupta, Anshuman ; intel-
> g...@lists.freedesktop.org
> Cc: Auld, Matthew ; Vivi, Rodrigo
>
> Subject: Re: [Intel-gfx] [RFC 1/1] drm/i915/dgfx: Handling of pin_map against
> rpm
>
>
> On
On 15/09/2022 15:54, Rodrigo Vivi wrote:
On Thu, Sep 15, 2022 at 10:40:59PM +0800, Daniel J Blueman wrote:
On Thu, 15 Sept 2022 at 22:09, Rodrigo Vivi wrote:
On Thu, Sep 15, 2022 at 09:08:08PM +0800, Daniel J Blueman wrote:
Dear Intel et al,
With a HP Spectre x360 16 16-f1xxx/891D (Intel
On Thu, Sep 15, 2022 at 10:40:59PM +0800, Daniel J Blueman wrote:
> On Thu, 15 Sept 2022 at 22:09, Rodrigo Vivi wrote:
> > On Thu, Sep 15, 2022 at 09:08:08PM +0800, Daniel J Blueman wrote:
> > > Dear Intel et al,
> > >
> > > With a HP Spectre x360 16 16-f1xxx/891D (Intel i7-1260P) with an Arc
> >
Quoting Anshuman Gupta (2022-09-14 19:13:29)
> DG1 and DG2 has lmem, and cpu can access the lmem objects
> via mmap and i915 internal i915_gem_object_pin_map() for
> i915 own usages. Both of these methods has pre-requisite
> requirement to keep GFX PCI endpoint in D0 for a supported
> iomem
On Thu, 15 Sept 2022 at 22:09, Rodrigo Vivi wrote:
> On Thu, Sep 15, 2022 at 09:08:08PM +0800, Daniel J Blueman wrote:
> > Dear Intel et al,
> >
> > With a HP Spectre x360 16 16-f1xxx/891D (Intel i7-1260P) with an Arc
> > A370M GPU [1] running the latest Ubuntu 22.10 5.19.0-15-generic
> > kernel,
On 29-08-2022 23:00, Dixit, Ashutosh wrote:
On Thu, 25 Aug 2022 06:21:13 -0700, Badal Nilawar wrote:
From: Riana Tauro
Use i915 HWMON subsystem to display current input voltage.
A couple of suggestions to improve comments in this patch below and after
addressing those this patch is:
On 15/09/2022 11:33, Anshuman Gupta wrote:
If i915 gem obj lies in lmem, then i915_gem_object_pin_map
need to grab a rpm wakeref to make sure gfx PCIe endpoint
function stays in D0 state during any access to mapping
returned by i915_gem_object_pin_map().
Subsequently i915_gem_object_upin_map
== Series Details ==
Series: Revert "drm/i915: Force compilation with intel-iommu for CI validation"
URL : https://patchwork.freedesktop.org/series/108576/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12136_full -> Patchwork_108576v1_full
On 15/09/2022 11:33, Anshuman Gupta wrote:
If i915 gem obj lies in lmem, then i915_gem_object_pin_map
need to grab a rpm wakeref to make sure gfx PCIe endpoint
function stays in D0 state during any access to mapping
returned by i915_gem_object_pin_map().
Subsequently i915_gem_object_upin_map
On Thu, Sep 15, 2022 at 09:08:08PM +0800, Daniel J Blueman wrote:
> Dear Intel et al,
>
> With a HP Spectre x360 16 16-f1xxx/891D (Intel i7-1260P) with an Arc
> A370M GPU [1] running the latest Ubuntu 22.10 5.19.0-15-generic
> kernel, we see:
>
> i915 :03:00.0: Your graphics device 5693 is
Hi Dave and Daniel,
Nothing that big for this round, but a couple targeting stable.
Here goes drm-intel-fixes-2022-09-15:
- Revert a display patch around max DP source rate now
that the proper WaEdpLinkRateDataReload is in place. (Ville)
- Fix perf limit reasons bit position. (Ashutosh)
- Fix
== Series Details ==
Series: Revert "HAX iommu/intel: Ignore igfx_off"
URL : https://patchwork.freedesktop.org/series/108575/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12136_full -> Patchwork_108575v1_full
Summary
>-Original Message-
>From: Dmitry Osipenko
>Sent: Tuesday, September 13, 2022 3:28 PM
>To: David Airlie ; Gerd Hoffmann ;
>Gurchetan Singh ; Chia-I Wu
>; Daniel Vetter ; Daniel Almeida
>; Gert Wollny ;
>Gustavo Padovan ; Daniel Stone
>; Tomeu Vizoso ;
>Maarten Lankhorst ; Maxime Ripard
>;
Dear Intel et al,
With a HP Spectre x360 16 16-f1xxx/891D (Intel i7-1260P) with an Arc
A370M GPU [1] running the latest Ubuntu 22.10 5.19.0-15-generic
kernel, we see:
i915 :03:00.0: Your graphics device 5693 is not properly supported
by the driver in this kernel version. To force driver
== Series Details ==
Series: drm/i915: move i915_fence_{context_, }timeout() to i915_sw_fence.[ch]
URL : https://patchwork.freedesktop.org/series/108571/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12136_full -> Patchwork_108571v1_full
On Thu, Sep 01, 2022 at 03:47:06PM +0300, Jani Nikula wrote:
> Prefer the parsed results for is_hdmi in display info over calling
> drm_detect_hdmi_monitor().
>
> Cc: Thierry Reding
> Cc: linux-te...@vger.kernel.org
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/tegra/hdmi.c | 9
On Wed, 14 Sep 2022, Matt Roper wrote:
> Now that MTL is going to start providing two GTs, there are a few more
> places in the driver that need to iterate over each GT instead of
> operating directly on gt0. Also some more deliberate cleanup is needed,
> in cases where we fail GT/engine
Hi Dave and Daniel,
this is the drm-misc-fixes PR for this week.
Best regards
Thomas
drm-misc-fixes-2022-09-15:
Short summary of fixes pull:
* gma500: Locking and IRQ fixes
* meson: OSD1 display fixes
* panel-edp: Fix Innolux timings
* rockchip: DP/HDMI fixes
The following changes since
On Mon, 29 Aug 2022, Jani Nikula wrote:
> Hi Dave & Daniel -
>
> drm-intel-next-2022-08-29:
> drm/i915 feature pull for v6.1:
Hey, I started making another pull request, but realized you haven't
pulled this one yet. Anything the matter, or just fell between the
cracks?
BR,
Jani.
>
> Features
== Series Details ==
Series: drm/i915: move i915_coherent_map_type() to i915_gem_pages.c and
un-inline
URL : https://patchwork.freedesktop.org/series/108569/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12135_full -> Patchwork_108569v1_full
== Series Details ==
Series: DGFX pin_map with rpm
URL : https://patchwork.freedesktop.org/series/108596/
State : failure
== Summary ==
Error: make failed
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/generated/compile.h
CC
Hi Matt,
On Thursday, 15 September 2022 00:04:24 CEST Matt Roper wrote:
> From: Chris Wilson
>
> If we abort driver initialisation in the middle of gt/engine discovery,
> some engines will be fully setup and some not. Those incompletely setup
> engines only have 'engine->release == NULL' and so
If i915 gem obj lies in lmem, then i915_gem_object_pin_map
need to grab a rpm wakeref to make sure gfx PCIe endpoint
function stays in D0 state during any access to mapping
returned by i915_gem_object_pin_map().
Subsequently i915_gem_object_upin_map will put the wakref as well.
Cc: Matthew Auld
As per PCIe Spec Section 5.3.1.4.1
When a PCIe function is in d3hot state,
Configuration and Message requests are the only TLPs accepted by a
Function in the D3hot state. All other received Requests must be
handled as Unsupported Requests, and all received Completions
may optionally be handled
== Series Details ==
Series: drm/i915/DG{1, 2}: FIXME Temporary hammer to disable rpm (rev3)
URL : https://patchwork.freedesktop.org/series/108477/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12134_full -> Patchwork_108477v3_full
Hi,
On 15/09/2022 00:46, john.c.harri...@intel.com wrote:
From: John Harrison
Going forwards, the intention is for GuC firmware files to be named
for their major version only and HuC firmware files to have no version
number in the name at all. This patch adds those entries for all
platforms
On 15/09/2022 03:12, Alan Previn wrote:
From: Matthew Brost
Add a delay, configurable via debugfs (default 34ms), to disable
scheduling of a context after the pin count goes to zero. Disable
scheduling is a costly operation as it requires synchronizing with
the GuC. So the idea is that a
On 15/09/2022 09:09, Lucas De Marchi wrote:
On Thu, Sep 15, 2022 at 08:53:16AM +0100, Tvrtko Ursulin wrote:
On 14/09/2022 21:35, Lucas De Marchi wrote:
This reverts commit 58f44e349cfc10a4f2208fd806829c8fd046480b.
To be removed from the topic/core-for-CI branch. If CI's config is
setting
On Thu, Sep 15, 2022 at 08:53:16AM +0100, Tvrtko Ursulin wrote:
On 14/09/2022 21:35, Lucas De Marchi wrote:
This reverts commit 58f44e349cfc10a4f2208fd806829c8fd046480b.
To be removed from the topic/core-for-CI branch. If CI's config is
setting that, it just shouldn't do it. Looking at a
On 14/09/2022 21:35, Lucas De Marchi wrote:
This reverts commit 58f44e349cfc10a4f2208fd806829c8fd046480b.
To be removed from the topic/core-for-CI branch. If CI's config is
setting that, it just shouldn't do it. Looking at a random current CI
execution, the command line is:
Command line:
On 14/09/2022 17:35, Jani Nikula wrote:
The inline function has no place in i915_drv.h. Move it away, un-inline,
and untangle some header dependencies while at it.
Cc: Matthew Auld
Cc: Tvrtko Ursulin
Signed-off-by: Jani Nikula
---
I don't know where this belongs, I just know it doesn't
On 14/09/2022 17:59, Jani Nikula wrote:
Maybe there was a grand plan with i915_fence_timeout() and
i915_fence_context_timeout() and i915_config.c, but that seems to have
been lost a bit.
Just move the functions to i915_sw_fence.[ch] from i915_drv.h and
i915_config.c, and remove the latter.
On Tue, 13 Sep 2022, Nathan Chancellor wrote:
> On Tue, Sep 13, 2022 at 01:55:27PM -0700, Nathan Huckleberry wrote:
>> All of the functions used for intel_dvo_dev_ops.mode_valid have a return
>> type of enum drm_mode_status, but the mode_valid field in the struct
>> definition has a return type
On 14/09/2022 17:11, Dixit, Ashutosh wrote:
On Wed, 14 Sep 2022 02:56:26 -0700, Nilawar, Badal wrote:
On 13-09-2022 13:17, Tvrtko Ursulin wrote:
On 13/09/2022 01:09, Dixit, Ashutosh wrote:
On Mon, 12 Sep 2022 04:29:38 -0700, Nilawar, Badal wrote:
diff --git
> -Original Message-
> From: Joonas Lahtinen
> Sent: Thursday, September 15, 2022 12:17 PM
> To: Gupta, Anshuman ; intel-
> g...@lists.freedesktop.org
> Cc: Vivi, Rodrigo ; Nilawar, Badal
> ; Ewins, Jon ;
> andi.sh...@linux.intel.com; Gupta, Anshuman ;
> Auld, Matthew
> Subject: Re:
== Series Details ==
Series: Revert "iommu/dma: Fix race condition during iova_domain initialization"
URL : https://patchwork.freedesktop.org/series/108557/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12134_full -> Patchwork_108557v1_full
On the patch subject, could we aim to be a bit more readable and
concise. Something like:
"drm/i915: Temporarily disable RPM on DG1/DG2"
The patch title definitely should not have a FIXME in it if we're going
to merge it in that form.
There's nothing to be fixed about the patch itself, we are
> -Original Message-
> From: Dixit, Ashutosh
> Sent: Tuesday, September 13, 2022 8:49 PM
> To: Gupta, Anshuman
> Cc: Nilawar, Badal ; intel-gfx@lists.freedesktop.org;
> Tauro, Riana ; Ewins, Jon ;
> linux-hw...@vger.kernel.org
> Subject: Re: [PATCH 2/7] drm/i915/hwmon: Add HWMON
On Wed, Sep 14, 2022 at 09:58:59PM +, Srivatsa, Anusha wrote:
>
>
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: Wednesday, September 14, 2022 2:43 PM
> > To: Srivatsa, Anusha
> > Cc: intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH 1/4]
95 matches
Mail list logo
