Move spinner start out of the steps loop. If we restart WL for each
freq step, the rapid start/stop causes SLPC algorithm to think that
GT busyness is 50% for it's evaluation interval. This leads to SLPC
not increasing the requested frequency as per the test expectation.
Fixes: 8ee2c227822e
== Series Details ==
Series: A few CT updates
URL : https://patchwork.freedesktop.org/series/99117/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_4 -> Patchwork_22044
Summary
---
**SUCCESS**
No regressions
== Series Details ==
Series: discrete card 64K page support
URL : https://patchwork.freedesktop.org/series/99119/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_4 -> Patchwork_22045
Summary
---
**FAILURE**
== Series Details ==
Series: drm/i915/wopcm: Handle pre-programmed WOPCM registers (rev3)
URL : https://patchwork.freedesktop.org/series/98910/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
0abf9917c5c0 drm/i915/wopcm: Handle pre-programmed WOPCM registers
-:14:
On 1/11/2022 08:39, Matthew Brost wrote:
Don't use the interruptable version of the timeline mutex lock in the
error path of eb_pin_timeline as the cleanup must always happen.
v2:
(John Harrison)
- Don't check for interrupt during mutex lock
v3:
(Tvrtko)
- A comment explaining why
Starting from xehpsdv, bit 0 of of the GuC shim control register has
been repurposed, while bit 2 is now reserved, so we need to avoid
setting those for their old meaning on newer platforms.
Cc: Vinay Belgaumkar
Cc: Stuart Summers
Signed-off-by: Daniele Ceraolo Spurio
---
Don't check CT descriptor status, unless CONFIG_DRM_I915_DEBUG_GUC is
set, before CT write / read as this could result in a read across the
PCIe bus thus adding latency to every CT write / read. On well behavied
systems this vaue should always read as zero. For some reason it doesn't
the CT
On Thu, Jan 20, 2022 at 06:13:47PM +, Teres Alexis, Alan Previn wrote:
> Just one nit below, (assuming that igt CI failure isnt related - kms flip not
> completing)
> Reviewed-by Alan Previn
>
> -Original Message-
> From: Ceraolo Spurio, Daniele
> Sent: Friday, January 14, 2022
On Thu, Jan 20, 2022 at 03:31:34AM +, Tolakanahalli Pradeep, Madhumitha
wrote:
On Tue, 2022-01-18 at 13:37 -0800, Lucas De Marchi wrote:
On Thu, Dec 23, 2021 at 03:18:57AM +, Tolakanahalli Pradeep,
Madhumitha wrote:
> On Fri, 2021-12-17 at 21:37 +, Yokoyama, Caz wrote:
> > On Thu,
From: Matthew Auld
For local-memory objects we need to align the GTT addresses
to 64K, both for the ppgtt and ggtt.
We need to support vm->min_alignment > 4K, depending
on the vm itself and the type of object we are inserting.
With this in mind update the GTT selftests to take this
into
From: Matthew Auld
discrete cards optimise 64K GTT pages for local-memory, since everything
should be allocated at 64K granularity. We say goodbye to sparse
entries, and instead get a compact 256B page-table for 64K pages,
which should be more cache friendly. 4K pages for local-memory
are no
From: Matthew Auld
On discrete platforms like DG2, we need to support a minimum page size
of 64K when dealing with device local-memory. This is quite tricky for
various reasons, so try to document the new implicit uapi for this.
v3: fix typos and less emphasis
v2: Fixed suggestions on
add test to check handling of misaligned offsets and sizes
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 130 ++
1 file changed, 130 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
From: Ramalingam C
Add a new platform flag, needs_compact_pt, to mark the requirement of
compact pt layout support for the ppGTT when using 64K GTT pages.
With this flag has_64k_pages will only indicate requirement of 64K
GTT page sizes or larger for device local memory access.
Suggested-by:
This series continues support for 64K pages for discrete cards.
It supersedes the 64K patches from
https://patchwork.freedesktop.org/series/95686/#rev4
Changes since that series:
- set min alignment for DG2 to 2MB in i915_address_space_init
- replace coloring with simpler 2MB VA alignment for
== Series Details ==
Series: drm/i915/guc: Update guc shim control programming on newer platforms
URL : https://patchwork.freedesktop.org/series/99125/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
0b46254f664d drm/i915/guc: Update guc shim control programming on newer
== Series Details ==
Series: discrete card 64K page support
URL : https://patchwork.freedesktop.org/series/99119/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
Don't check CT descriptor status, unless CONFIG_DRM_I915_DEBUG_GUC is
set, before CT write / read as this could result in a read across the
PCIe bus thus adding latency to every CT write / read. On well behavied
systems this vaue should always read as zero. For some reason it doesn't
the CT
A couple of minor CT updates. 1 for performance, 1 for extra debug.
Signed-off-by: Matthew Brost
Matthew Brost (2):
drm/i915/guc: Don't check CT descriptor status before CT write / read
drm/i915/guc: Print CT descriptor status in CT debug function
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
Noticed that the CT descriptor status was not printed in the CT debug
function, add that in.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
Just one nit below, (assuming that igt CI failure isnt related - kms flip not
completing)
Reviewed-by Alan Previn
-Original Message-
From: Ceraolo Spurio, Daniele
Sent: Friday, January 14, 2022 11:33 AM
To: intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org; Ceraolo
On 2022-01-20 at 16:42:52 +, Robert Beckett wrote:
>
>
> On 20/01/2022 16:21, Ramalingam C wrote:
> > Add a new platform flag, needs_compact_pt, to mark the requirement of
> > compact pt layout support for the ppGTT when using 64K GTT pages.
> >
> > With this flag has_64k_pages will only
The following changes since commit fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf:
Linux 5.16-rc1 (2021-11-14 13:56:52 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git
tags/pci-v5.17-fixes-1
for you to fetch changes up to
== Series Details ==
Series: discrete card 64K page support
URL : https://patchwork.freedesktop.org/series/99119/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2ad66084bf0b drm/i915: add needs_compact_pt flag
f2a348f85370 drm/i915: enforce min GTT alignment for discrete cards
Starting from DG2, some of the programming previously done by i915 and
the GuC has been moved to the GSC and the relevant registers are no
longer writable by either CPU or GuC. This is also referred to as GuC
deprivilege.
On the i915 side, this affects the WOPCM registers: these are no longer
== Series Details ==
Series: drm/i915/wopcm: Handle pre-programmed WOPCM registers (rev3)
URL : https://patchwork.freedesktop.org/series/98910/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_4 -> Patchwork_22046
Summary
Reviewed-by: Alan Previn
On Mon, 2022-01-10 at 17:55 -0800, Umesh Nerlige Ramappa wrote:
> All timestamps returned by GuC for GuC PMU busyness are captured from
> GUC PM TIMESTAMP. Since this timestamp does not tick when GuC goes idle,
> kmd uses RING_TIMESTAMP to measure busyness of an engine
== Series Details ==
Series: drm/i915/selftests: Don't restart WL for every frequency step
URL : https://patchwork.freedesktop.org/series/99109/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_3 -> Patchwork_22043
On 1/20/2022 11:40 AM, Patchwork wrote:
Project List - Patchwork *Patch Details*
*Series:* drm/i915/selftests: Don't restart WL for every frequency step
*URL:* https://patchwork.freedesktop.org/series/99109/
*State:*failure
*Details:*
== Series Details ==
Series: drm/i915/wopcm: Handle pre-programmed WOPCM registers (rev3)
URL : https://patchwork.freedesktop.org/series/98910/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
In this RFC I would like to ask the community their thoughts
on how we can best handle splitting architecture-specific
calls.
I would like to address the following:
1. How do we want to split architecture calls? Different object files
per platform? Separate function calls within the same object
Some x86 checks are unnecessary on arm64 systems, so they
are being split out to avoid being used. There may be
further arm64 implementations created in the future for
this area, so it's better to split this out now.
Signed-off-by: Casey Bowman
---
drivers/gpu/drm/i915/Makefile |
Hi Ramalingam,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip drm-exynos/exynos-drm-next
drm/drm-next next-20220120]
[cannot apply to tegra-drm/drm/tegra/for-next airlied/drm-next v5.16]
[If your
== Series Details ==
Series: drm/i915/dg2: Add Wa_18018781329
URL : https://patchwork.freedesktop.org/series/99128/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5 -> Patchwork_22049
Summary
---
**FAILURE**
On 1/19/2022 13:24, Matthew Brost wrote:
The G2H handler needs to be flushed during a GT reset but a G2H
indicating engine reset failure can trigger a GT reset. Add a worker to
trigger the GT when an engine reset failure is received to break this
trigger the GT reset?
circular dependency.
Hi Matthew,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip drm-exynos/exynos-drm-next
drm/drm-next tegra-drm/drm/tegra/for-next v5.16 next-20220120]
[cannot apply to airlied/drm-next
On Thu, Jan 20, 2022 at 05:36:22PM -0800, John Harrison wrote:
> On 1/19/2022 13:24, Matthew Brost wrote:
> > Now that the error capture is fully decoupled from fence signalling
> > (request retirement to free memory, which in turn depends on resets) we
> > can safely flush the G2H handler during
Allocate intel_engine_coredump_alloc with ALLOW_FAIL rather than
GFP_KERNEL to fully decouple the error capture from fence signalling.
v2:
(John Harrison)
- Fix typo in commit message (s/do/to)
Fixes: 8b91cdd4f8649 ("drm/i915: Use __GFP_KSWAPD_RECLAIM in the capture code")
Signed-off-by:
The G2H handler needs to be flushed during a GT reset but a G2H
indicating engine reset failure can trigger a GT reset. Add a worker to
trigger the GT rest when an engine reset failure is received to break
this circular dependency.
v2:
(John Harrison)
- Store engine reset mask
- Fix typo in
Now that the error capture is fully decoupled from fence signalling
(request retirement to free memory, which in turn depends on resets) we
can safely flush the G2H handler during a GT reset. This eliminates
corner cases where GuC generated G2H (e.g. engine resets) race with a GT
reset.
v2:
After a small fix to error capture code, we now can flush G2H during a
GT reset which simplifies code and seals some extreme corner case races.
v2:
(CI)
- Don't trigger GT reset from G2H handler
v3:
- Address John Harrison's comments
v4:
- Address John Harrison's comments
Signed-off-by:
== Series Details ==
Series: drm/i915/guc: Update guc shim control programming on newer platforms
URL : https://patchwork.freedesktop.org/series/99125/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_4 -> Patchwork_22047
On Wed, 2022-01-19 at 16:00 -0500, Steven Rostedt wrote:
> On Wed, 19 Jan 2022 21:25:08 +0200
> Andy Shevchenko wrote:
>
> > > I say keep it one line!
> > >
> > > Reviewed-by: Steven Rostedt (Google)
> >
> > I believe Sakari strongly follows the 80 rule, which means...
>
> Checkpatch says
== Series Details ==
Series: Splitting up platform-specific calls
URL : https://patchwork.freedesktop.org/series/99126/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
cfedaf9b9519 i915/drm: Split out x86 and arm64 functionality
-:53: WARNING:FILE_PATH_CHANGES: added, moved or
== Series Details ==
Series: Splitting up platform-specific calls
URL : https://patchwork.freedesktop.org/series/99126/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5 -> Patchwork_22048
Summary
---
**SUCCESS**
On Thu, 20 Jan 2022 17:09:28 -0800, john.c.harri...@intel.com wrote:
>
> From: John Harrison
>
> The capture tests require knowing exactly how big the test allocation
> is. Part of the test is to compare the captured size against the
> allocated size to make sure they match. That doesn't work if
== Series Details ==
Series: Splitting up platform-specific calls
URL : https://patchwork.freedesktop.org/series/99126/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: Flush G2H handler during a GT reset
URL : https://patchwork.freedesktop.org/series/99136/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
Hi Matthew,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip drm-exynos/exynos-drm-next
drm/drm-next tegra-drm/drm/tegra/for-next v5.16 next-20220121]
[cannot apply to airlied/drm-next]
[If your
== Series Details ==
Series: Flush G2H handler during a GT reset
URL : https://patchwork.freedesktop.org/series/99136/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5 -> Patchwork_22051
Summary
---
**SUCCESS**
Another fork of the DG2 design has appeared, known as "DG2-G12;" let's
add it as a new subplatform. As with G11, the GT stepping resets back
to A0 (so a DG2-G12 A0 is similar, but not identical, to a DG2-G10 C0)
but the display steppings continue to use the same numbering scheme as
G10 and G11.
== Series Details ==
Series: drm/i915: Introduce G12 subplatform of DG2
URL : https://patchwork.freedesktop.org/series/99129/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5_full -> Patchwork_22050_full
Summary
---
== Series Details ==
Series: A few CT updates
URL : https://patchwork.freedesktop.org/series/99117/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_4_full -> Patchwork_22044_full
Summary
---
**SUCCESS**
No
== Series Details ==
Series: drm/i915/wopcm: Handle pre-programmed WOPCM registers (rev3)
URL : https://patchwork.freedesktop.org/series/98910/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_4_full -> Patchwork_22046_full
== Series Details ==
Series: drm/i915: Introduce G12 subplatform of DG2
URL : https://patchwork.freedesktop.org/series/99129/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5 -> Patchwork_22050
Summary
---
== Series Details ==
Series: Splitting up platform-specific calls
URL : https://patchwork.freedesktop.org/series/99126/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5_full -> Patchwork_22048_full
Summary
---
A few more MOD registers need to be programmed on DG2.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++
drivers/gpu/drm/i915/i915_reg.h | 4
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
From: John Harrison
The capture tests require knowing exactly how big the test allocation
is. Part of the test is to compare the captured size against the
allocated size to make sure they match. That doesn't work if the
allocator creates an object of a different size than was requested
without
== Series Details ==
Series: drm/i915: Introduce G12 subplatform of DG2
URL : https://patchwork.freedesktop.org/series/99129/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
On 1/19/2022 13:24, Matthew Brost wrote:
Now that the error capture is fully decoupled from fence signalling
(request retirement to free memory, which in turn depends on resets) we
can safely flush the G2H handler during a GT reset. This is eliminates
This eliminates
John.
corner cases where
== Series Details ==
Series: drm/i915/guc: Update guc shim control programming on newer platforms
URL : https://patchwork.freedesktop.org/series/99125/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_4_full -> Patchwork_22047_full
Hi Matthew,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip drm-exynos/exynos-drm-next
drm/drm-next tegra-drm/drm/tegra/for-next v5.16 next-20220121]
[cannot apply to airlied/drm-next]
[If your
== Series Details ==
Series: drm/i915/dg2: Add Wa_18018781329
URL : https://patchwork.freedesktop.org/series/99128/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
On Thu, Jan 20, 2022 at 05:34:54PM -0800, John Harrison wrote:
> On 1/19/2022 13:24, Matthew Brost wrote:
> > The G2H handler needs to be flushed during a GT reset but a G2H
> > indicating engine reset failure can trigger a GT reset. Add a worker to
> > trigger the GT when an engine reset failure
On Fri, Jan 21, 2022 at 01:05:07AM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/dg2: Add Wa_18018781329
> URL : https://patchwork.freedesktop.org/series/99128/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_5 -> Patchwork_22049
>
On Thu, 20 Jan 2022, Matthew Brost wrote:
> Don't check CT descriptor status, unless CONFIG_DRM_I915_DEBUG_GUC is
> set, before CT write / read as this could result in a read across the
> PCIe bus thus adding latency to every CT write / read. On well behavied
> systems this vaue should always
== Series Details ==
Series: Flush G2H handler during a GT reset
URL : https://patchwork.freedesktop.org/series/99136/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5_full -> Patchwork_22051_full
Summary
---
On Thu, 20 Jan 2022, Petr Mladek wrote:
> On Wed 2022-01-19 16:16:12, Jani Nikula wrote:
>> On Wed, 19 Jan 2022, Petr Mladek wrote:
>> > On Tue 2022-01-18 23:24:47, Lucas De Marchi wrote:
>> >> d. This doesn't bring onoff() helper as there are some places in the
>> >>kernel with onoff as
...
> Yeah, and I am sorry for bikeshedding. Honestly, I do not know what is
> better. This is why I do not want to block this series when others
> like this.
>
> My main motivation is to point out that:
>
> enabledisable(enable)
>
> might be, for some people, more eye bleeding than
>
>
On Wed, 19 Jan 2022, Matt Roper wrote:
> Let's use 'struct i915_range' to express sets of b-counter and mux
> registers in the perf code. This makes the code more similar to how we
> handle things like multicast register ranges, forcewake tables, shadow
> tables, etc. and also lets us avoid
> -Original Message-
> From: Nikula, Jani
> Sent: Thursday, January 20, 2022 4:02 PM
> To: Shankar, Uma ; intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH 2/7] drm/i915/mst: abstract
> intel_dp_ack_sink_irq_esi()
>
> On Thu, 20 Jan 2022, "Shankar, Uma" wrote:
> >>
> -Original Message-
> From: Intel-gfx On Behalf Of Jani
> Nikula
> Sent: Wednesday, January 12, 2022 4:33 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani
> Subject: [Intel-gfx] [PATCH RESEND 3/7] drm/i915/mst: debug log 4 bytes of
> ESI right
> after reading
>
> For
> -Original Message-
> From: Intel-gfx On Behalf Of Jani
> Nikula
> Sent: Wednesday, January 12, 2022 4:33 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani
> Subject: [Intel-gfx] [PATCH RESEND 5/7] drm/i915/mst: read link status only
> when
> requested by sink in ESI
>
>
On Thu, 20 Jan 2022, Stephen Rothwell wrote:
> Hi all,
>
> On Fri, 15 Oct 2021 21:01:04 +1100 Stephen Rothwell
> wrote:
>>
>> After merging the drm-misc tree, today's linux-next build (htmldocs)
>> produced this warning:
>>
>> include/drm/drm_modeset_lock.h:74: warning: Function parameter or
> -Original Message-
> From: Intel-gfx On Behalf Of Jani
> Nikula
> Sent: Tuesday, January 4, 2022 11:10 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani
> Subject: [Intel-gfx] [PATCH 2/7] drm/i915/mst: abstract
> intel_dp_ack_sink_irq_esi()
>
> Smaller functions make
On Thu, 20 Jan 2022, "Shankar, Uma" wrote:
>> -Original Message-
>> From: Intel-gfx On Behalf Of Jani
>> Nikula
>> Sent: Tuesday, January 4, 2022 11:10 PM
>> To: intel-gfx@lists.freedesktop.org
>> Cc: Nikula, Jani
>> Subject: [Intel-gfx] [PATCH 2/7] drm/i915/mst: abstract
>>
> -Original Message-
> From: Intel-gfx On Behalf Of Jani
> Nikula
> Sent: Wednesday, January 12, 2022 4:33 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani
> Subject: [Intel-gfx] [PATCH RESEND 4/7] drm/i915/mst: abstract handling of
> link
> status in DP MST
>
> We'll
== Series Details ==
Series: drm/locking: fix drm_modeset_acquire_ctx kernel-doc
URL : https://patchwork.freedesktop.org/series/99090/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_1 -> Patchwork_22035
Summary
---
> -Original Message-
> From: Intel-gfx On Behalf Of Jani
> Nikula
> Sent: Wednesday, January 12, 2022 4:33 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani
> Subject: [Intel-gfx] [PATCH RESEND 7/7] drm/i915/mst: only ack the ESI we
> actually
> handled
>
> Seems odd that
On Wed, 19 Jan 2022, Matt Roper wrote:
> Several of our i915 header files, have been including i915_reg.h. This
> means that any change to i915_reg.h will trigger a full rebuild of
> pretty much every file of the driver, even those that don't have any
> kind of register access. Let's delete the
On Thu, 20 Jan 2022, Ville Syrjälä wrote:
> On Fri, Dec 17, 2021 at 05:53:57PM +0200, Ville Syrjala wrote:
>> From: Ville Syrjälä
>>
>> Quick attempt at unifying the VBT DDI parsing to all g4x+
>> platforms.
>>
>> Note that we'll still use the hardware straps as the primary
>> source of port
== Series Details ==
Series: drm/locking: fix drm_modeset_acquire_ctx kernel-doc
URL : https://patchwork.freedesktop.org/series/99090/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
Hi Dave and Daniel,
A couple display fixes for the merge window. One for EHL and one for ADL-P,
and both in the are of voltage swing programming.
Regards,
Tvrtko
---
drm-intel-next-fixes-2022-01-20:
- Latest updates for the EHL display voltage swing table (José Roberto de Souza)
-
On 19/01/2022 15:08, Daniel Vetter wrote:
On Thu, Jan 06, 2022 at 04:55:35PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Proposal to standardise the fdinfo text format as optionally output by DRM
drivers.
Idea is that a simple but, well defined, spec will enable generic
userspace
Seems odd that we clear all event status indicators if we've only
handled some. Only clear the ones we've handled.
v2: ack DOWN_REP and UP_REQ only if they were set in esi (Ville)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp.c | 20
1 file changed,
On 19/01/2022 11:12, Jani Nikula wrote:
On Wed, 05 Jan 2022, Tvrtko Ursulin wrote:
On 05/01/2022 13:18, Jani Nikula wrote:
On Wed, 05 Jan 2022, Tvrtko Ursulin wrote:
On 05/01/2022 10:32, Jani Nikula wrote:
On Wed, 05 Jan 2022, Tvrtko Ursulin wrote:
On 05/01/2022 10:05, Jani Nikula
> -Original Message-
> From: Intel-gfx On Behalf Of Jani
> Nikula
> Sent: Wednesday, January 12, 2022 4:33 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani
> Subject: [Intel-gfx] [PATCH RESEND 6/7] drm/i915/mst: ack sink irq ESI for
> link status
> changes
>
> Only
== Series Details ==
Series: Second round of i915_reg.h splitting
URL : https://patchwork.freedesktop.org/series/99079/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_1_full -> Patchwork_22034_full
Summary
---
The stack_depot member was added without kernel-doc, leading to below
warning. Fix it.
./include/drm/drm_modeset_lock.h:74: warning: Function parameter or
member 'stack_depot' not described in 'drm_modeset_acquire_ctx'
Reported-by: Stephen Rothwell
Fixes: cd06ab2fd48f ("drm/locking: add
On 19/01/2022 17:47, Thomas Hellström wrote:
In some cases we use leftover kfree() instead of i915_vma_resource_free().
Fix this.
Fixes: Fixes: 2f6b90da9192 ("drm/i915: Use vma resources for async unbinding")
Reported-by: Robert Beckett
Cc: Matthew Auld
Signed-off-by: Thomas Hellström
> -Original Message-
> From: Intel-gfx On Behalf Of Jani
> Nikula
> Sent: Tuesday, January 4, 2022 11:10 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani
> Subject: [Intel-gfx] [PATCH 1/7] drm/i915/mst: fix intel_dp_mst_hpd_irq()
> indentation
>
> Remove extra
Hi Matt,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next v5.16 next-20220120]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base
== Series Details ==
Series: drm/i915/mst: DP MST ESI handling improvements (rev2)
URL : https://patchwork.freedesktop.org/series/98479/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_1 -> Patchwork_22036
Summary
> -Original Message-
> From: Intel-gfx On Behalf Of Jani
> Nikula
> Sent: Wednesday, January 12, 2022 4:33 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani
> Subject: [Intel-gfx] [PATCH RESEND 2/7] drm/i915/mst: abstract
> intel_dp_ack_sink_irq_esi()
>
> Smaller functions
> -Original Message-
> From: Intel-gfx On Behalf Of Jani
> Nikula
> Sent: Wednesday, January 12, 2022 4:33 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani
> Subject: [Intel-gfx] [PATCH RESEND 1/7] drm/i915/mst: fix
> intel_dp_mst_hpd_irq()
> indentation
>
> Remove extra
On Thu, 20 Jan 2022, Daniel Vetter wrote:
> On Thu, Jan 20, 2022 at 10:49 AM Jani Nikula wrote:
>>
>> The stack_depot member was added without kernel-doc, leading to below
>> warning. Fix it.
>>
>> ./include/drm/drm_modeset_lock.h:74: warning: Function parameter or
>> member 'stack_depot' not
== Series Details ==
Series: drm/i915: split out i915_reg_read_ioctl() to i915_ioctl.[ch]
URL : https://patchwork.freedesktop.org/series/99096/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_1 -> Patchwork_22039
Summary
On Thu, Jan 20, 2022 at 10:49 AM Jani Nikula wrote:
>
> The stack_depot member was added without kernel-doc, leading to below
> warning. Fix it.
>
> ./include/drm/drm_modeset_lock.h:74: warning: Function parameter or
> member 'stack_depot' not described in 'drm_modeset_acquire_ctx'
>
>
> -Original Message-
> From: Nikula, Jani
> Sent: Thursday, January 20, 2022 4:32 PM
> To: Shankar, Uma ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH RESEND 7/7] drm/i915/mst: only ack the ESI we
> actually handled
>
> On Thu, 20 Jan 2022, "Shankar, Uma" wrote:
On 2022-01-18 at 17:50:37 +, Robert Beckett wrote:
> From: Matthew Auld
>
> On discrete platforms like DG2, we need to support a minimum page size
> of 64K when dealing with device local-memory. This is quite tricky for
> various reasons, so try to document the new implicit uapi for this.
>
1 - 100 of 145 matches
Mail list logo
