On Mon, Sep 13, 2021 at 08:09:23PM +0530, Vandita Kulkarni wrote:
> Each VDSC operates with 1ppc throughput, hence enable the second
> VDSC engine when moderate is higher that the current cdclk.
>
> Signed-off-by: Vandita Kulkarni
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 12 ++--
On Mon, Sep 13, 2021 at 08:09:23PM +0530, Vandita Kulkarni wrote:
> Each VDSC operates with 1ppc throughput, hence enable the second
> VDSC engine when moderate is higher that the current cdclk.
>
> Signed-off-by: Vandita Kulkarni
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 12 ++--
> -Original Message-
> From: Ville Syrjälä
> Sent: Tuesday, September 14, 2021 12:59 PM
> To: Kulkarni, Vandita
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani ;
> Navare, Manasi D
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC
> engine for higher moderates
>
> -Original Message-
> From: Lisovskiy, Stanislav
> Sent: Tuesday, September 14, 2021 12:49 PM
> To: Kulkarni, Vandita
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani ;
> Navare, Manasi D
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC
> engine for higher mode
Hi Sean,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next linus/master v5.15-rc1 next-20210914]
[cannot apply to drm-intel/for-linux-next drm/drm-next]
[If your patch
On Tue, Sep 14, 2021 at 07:31:46AM +, Kulkarni, Vandita wrote:
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: Tuesday, September 14, 2021 12:59 PM
> > To: Kulkarni, Vandita
> > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani ;
> > Navare, Manasi D
> > Subject: Re: [Intel-
On Mon, Sep 13, 2021 at 04:28:35PM +, Souza, Jose wrote:
> On Mon, 2021-09-13 at 17:44 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Disabling planes in the middle of the modeset seuqnece does not make
> > sense since userspace can anyway disable planes before the modeset
> > ev
On Tue, 2021-09-14 at 09:40 +0200, Christian König wrote:
> Am 13.09.21 um 14:41 schrieb Thomas Hellström:
> > [SNIP]
> > > > > Let's say you have a struct ttm_object_vram and a struct
> > > > > ttm_object_gtt, both subclassing drm_gem_object. Then I'd say
> > > > > a
> > > > > driver would want
On 13/09/2021 17:50, Matthew Brost wrote:
On Mon, Sep 13, 2021 at 10:24:43AM +0100, Tvrtko Ursulin wrote:
On 10/09/2021 20:49, Matthew Brost wrote:
On Fri, Sep 10, 2021 at 12:12:42PM +0100, Tvrtko Ursulin wrote:
On 20/08/2021 23:44, Matthew Brost wrote:
Add logical engine mapping. This is
Hi,
On Mon, Sep 13, 2021 at 07:45:03PM +0300, Jani Nikula wrote:
> On Tue, 31 Aug 2021, Jani Nikula wrote:
> > v2 of https://patchwork.freedesktop.org/series/94161/ with the VESA OUI
> > check and an OUI helper patch added.
>
> Maarten, Maxime, Thomas - may I have an ack for merging this via
> d
On 13/09/2021 18:12, Matthew Brost wrote:
On Mon, Sep 13, 2021 at 10:55:59AM +0100, Tvrtko Ursulin wrote:
On 20/08/2021 23:44, Matthew Brost wrote:
Taking a PM reference to prevent intel_gt_wait_for_idle from short
circuiting while a deregister context H2G is in flight.
FIXME: Move locking
From: Thomas Hellström
Break out some shmem backend utils for future reuse by the TTM backend:
shmem_alloc_st(), shmem_free_st() and __shmem_writeback() which we can
use to provide a shmem-backed TTM page pool for cached-only TTM
buffer objects.
Main functional change here is that we now compute
Add new flag to indicate special shmem based tt, which can directly
handle swapping itself, and should be visible to some shrinker.
As part of this we should skip the ttm_pages_allocated accounting, since
such tt objects should already be reachable, and potentially reclaimable
by some shrinker, if
For cached objects we can allocate our pages directly in shmem. This
should make it possible(in a later patch) to utilise the existing
i915-gem shrinker code for such objects. For now this is still disabled.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Christian König
---
drivers/gpu/d
This should let us do an accelerated copy directly to the shmem pages
when temporarily moving lmem-only objects, where the i915-gem shrinker
can later kick in to swap out the pages, if needed.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 8 -
Drop the atomic shrink_pin stuff, and just have make_{un}shrinkable
update the shrinker visible lists immediately. This at least simplifies
the next patch, and does make the behaviour more obvious. The potential
downside is that make_unshrinkable now grabs a global lock even when the
object itself
We currently just evict lmem objects to system memory when under memory
pressure. For this case we lack the usual object mm.pages, which
effectively hides the pages from the i915-gem shrinker, until we
actually "attach" the TT to the object, or in the case of lmem-only
objects it just gets migrated
Enable shmem tt backend, and enable shrinking.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index f02037a8cebd..
On Tue, Sep 14, 2021 at 10:48:46AM +0300, Ville Syrjälä wrote:
> On Tue, Sep 14, 2021 at 07:31:46AM +, Kulkarni, Vandita wrote:
> > > -Original Message-
> > > From: Ville Syrjälä
> > > Sent: Tuesday, September 14, 2021 12:59 PM
> > > To: Kulkarni, Vandita
> > > Cc: intel-gfx@lists.fre
On 9/10/21 16:10, Imran Khan wrote:
> This change is in response to discussion at [1].
> The patch has been created on top of my earlier changes [2] and [3].
> If needed I can resend all of these patches together, though my
> earlier patches have been Acked.
I think you sent those at the beginning
On Mon, 13 Sep 2021, Vasily Khoruzhick wrote:
> Panel in my Dell XPS 7590, that uses Intel's HDR backlight interface to
> control brightness, apparently needs a delay before setting brightness
> after power on. Without this delay the panel does accept the setting
> and may come up with some arbitr
In commit 4e5c8a99e1cb ("drm/i915: Drop i915_request.lock requirement
for intel_rps_boost()"), we decoupled the rps worker from the pm so
that we could avoid the synchronization penalty which makes the
assertion liable to run too early. Which makes warning invalid hence
removed.
Fixes: 4e5c8a99e1c
On Wed, 08 Sep 2021, Lucas De Marchi wrote:
> We shouldn't be using debugfs_ namespace for this functionality. Rename
> debugfs_gt.[ch] to intel_gt_debugfs.[ch] and then make functions,
> defines and structs follow suit.
>
> While at it and since we are renaming the header, sort the includes
> alp
== Series Details ==
Series: kernel/locking: Add context to ww_mutex_trylock. (rev4)
URL : https://patchwork.freedesktop.org/series/94437/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3e5b7ed1e30d kernel/locking: Add context to ww_mutex_trylock.
-:9: WARNING:COMMIT_LOG_LONG_LI
== Series Details ==
Series: kernel/locking: Add context to ww_mutex_trylock. (rev4)
URL : https://patchwork.freedesktop.org/series/94437/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10579 -> Patchwork_21036
Summary
-
== Series Details ==
Series: series starting with [v2,1/7] drm/i915/gem: Break out some shmem
backend utils
URL : https://patchwork.freedesktop.org/series/94648/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d3fcbc14d6ee drm/i915/gem: Break out some shmem backend utils
5e8ae12
== Series Details ==
Series: series starting with [v2,1/7] drm/i915/gem: Break out some shmem
backend utils
URL : https://patchwork.freedesktop.org/series/94648/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checke
== Series Details ==
Series: series starting with [v2,1/7] drm/i915/gem: Break out some shmem
backend utils
URL : https://patchwork.freedesktop.org/series/94648/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10579 -> Patchwork_21037
===
On 13/09/2021 14:16, Christian König wrote:
Simplifying the code a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/i915_request.c | 36 ++---
1 file changed, 7 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/g
On Tue, 2021-09-14 at 10:53 +0200, Christian König wrote:
> Am 14.09.21 um 10:27 schrieb Thomas Hellström:
> > On Tue, 2021-09-14 at 09:40 +0200, Christian König wrote:
> > > Am 13.09.21 um 14:41 schrieb Thomas Hellström:
> > > > [SNIP]
> > > > > > > Let's say you have a struct ttm_object_vram and
On 13/09/2021 14:16, Christian König wrote:
Abstract the complexity of iterating over all the fences
in a dma_resv object.
The new loop handles the whole RCU and retry dance and
returns only fences where we can be sure we grabbed the
right one.
Signed-off-by: Christian König
---
drivers/dm
On 14/09/2021 11:39, Christian König wrote:
Am 14.09.21 um 12:26 schrieb Tvrtko Ursulin:
On 13/09/2021 14:16, Christian König wrote:
Simplifying the code a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/i915_request.c | 36 ++---
1 file changed, 7 i
== Series Details ==
Series: drm/i915: Remove warning from the rps worker
URL : https://patchwork.freedesktop.org/series/94650/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10580 -> Patchwork_21038
Summary
---
**FAI
Am 13.09.21 um 14:41 schrieb Thomas Hellström:
[SNIP]
Let's say you have a struct ttm_object_vram and a struct
ttm_object_gtt, both subclassing drm_gem_object. Then I'd say a
driver would want to subclass those to attach identical data,
extend functionality and provide a single i915_gem_object
On Tue, 14 Sep 2021, "Lisovskiy, Stanislav"
wrote:
> On Tue, Sep 14, 2021 at 10:48:46AM +0300, Ville Syrjälä wrote:
>> On Tue, Sep 14, 2021 at 07:31:46AM +, Kulkarni, Vandita wrote:
>> > > -Original Message-
>> > > From: Ville Syrjälä
>> > > Sent: Tuesday, September 14, 2021 12:59 PM
To print stack entries into a buffer, users of stackdepot,
first get a list of stack entries using stack_depot_fetch
and then print this list into a buffer using stack_trace_snprint.
Provide a helper in stackdepot for this purpose.
Also change above mentioned users to use this helper.
Signed-off-b
Am 14.09.21 um 12:26 schrieb Tvrtko Ursulin:
On 13/09/2021 14:16, Christian König wrote:
Simplifying the code a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/i915_request.c | 36 ++---
1 file changed, 7 insertions(+), 29 deletions(-)
diff --git a/dri
On 13/9/21 6:51 pm, Vlastimil Babka wrote:
On 9/10/21 16:10, Imran Khan wrote:
To print stack entries into a buffer, users of stackdepot,
first get a list of stack entries using stack_depot_fetch
and then print this list into a buffer using stack_trace_snprint.
Provide a helper in stackdepot
Am 14.09.21 um 12:53 schrieb Tvrtko Ursulin:
On 13/09/2021 14:16, Christian König wrote:
Abstract the complexity of iterating over all the fences
in a dma_resv object.
The new loop handles the whole RCU and retry dance and
returns only fences where we can be sure we grabbed the
right one.
Sig
Changes in v2:
- Addressed review comment.
- Added Acked from Vlastimil.
- Fixed one mistake, due to which stack_trace_snprint was always
getting invoked with 0 as space value.
Changed it to make use of space argument, because users that
are printing stack entries into buffer, may
On 13/09/2021 14:16, Christian König wrote:
This is maybe even a fix since the RCU usage here looks incorrect.
What you think is incorrect? Pointless extra rcu locking?
Also, FWIW, I submitted a patch to remove this function altogether since
its IMO pretty useless, just failed in getting an
On 9/13/21 8:00 PM, Souza, Jose wrote:
On Mon, 2021-09-13 at 19:09 +0300, Gwan-gyeong Mun wrote:
On 9/10/21 7:29 PM, Souza, Jose wrote:
On Fri, 2021-09-10 at 16:38 +0300, Gwan-gyeong Mun wrote:
On 9/10/21 2:07 AM, José Roberto de Souza wrote:
Wa_16014451276 fixes the starting coordinate
Am 14.09.21 um 14:27 schrieb Tvrtko Ursulin:
On 13/09/2021 14:16, Christian König wrote:
This is maybe even a fix since the RCU usage here looks incorrect.
What you think is incorrect? Pointless extra rcu locking?
Yeah, exactly that. I also wondered for a second if rcu_read_lock() can
nest
On 13/09/2021 14:16, Christian König wrote:
Simplifying the code a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 29
1 file changed, 5 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
b/driv
On 9/13/21 7:45 PM, Souza, Jose wrote:
On Mon, 2021-09-13 at 19:03 +0300, Gwan-gyeong Mun wrote:
On 9/10/21 2:07 AM, José Roberto de Souza wrote:
drm_atomic_helper_damage_iter_init() + drm_atomic_for_each_plane_damage()
returns the full plane area in case no damaged area was set by
userspac
Op 14-09-2021 om 08:50 schreef Peter Zijlstra:
> On Mon, Sep 13, 2021 at 10:42:36AM +0200, Maarten Lankhorst wrote:
>
>>> +/**
>>> + * ww_mutex_trylock - tries to acquire the w/w mutex with optional acquire
>>> context
>>> + * @ww: mutex to lock
>>> + * @ww_ctx: optional w/w acquire context
>>> +
On 14/09/2021 13:32, Christian König wrote:
Am 14.09.21 um 14:27 schrieb Tvrtko Ursulin:
On 13/09/2021 14:16, Christian König wrote:
This is maybe even a fix since the RCU usage here looks incorrect.
What you think is incorrect? Pointless extra rcu locking?
Yeah, exactly that. I also won
Am 14.09.21 um 10:27 schrieb Thomas Hellström:
On Tue, 2021-09-14 at 09:40 +0200, Christian König wrote:
Am 13.09.21 um 14:41 schrieb Thomas Hellström:
[SNIP]
Let's say you have a struct ttm_object_vram and a struct
ttm_object_gtt, both subclassing drm_gem_object. Then I'd say
a
driver would w
Am 14.09.21 um 10:50 schrieb Matthew Auld:
Add new flag to indicate special shmem based tt, which can directly
handle swapping itself, and should be visible to some shrinker.
As part of this we should skip the ttm_pages_allocated accounting, since
such tt objects should already be reachable, and
On Tue, Sep 14, 2021 at 03:04:11PM +0300, Jani Nikula wrote:
> On Tue, 14 Sep 2021, "Lisovskiy, Stanislav"
> wrote:
> > On Tue, Sep 14, 2021 at 10:48:46AM +0300, Ville Syrjälä wrote:
> >> On Tue, Sep 14, 2021 at 07:31:46AM +, Kulkarni, Vandita wrote:
> >> > > -Original Message-
> >> >
On 14/09/2021 12:25, Christian König wrote:
Am 14.09.21 um 12:53 schrieb Tvrtko Ursulin:
On 13/09/2021 14:16, Christian König wrote:
Abstract the complexity of iterating over all the fences
in a dma_resv object.
The new loop handles the whole RCU and retry dance and
returns only fences wher
On 13/09/2021 14:16, Christian König wrote:
This makes the function much simpler since the complex
retry logic is now handled else where.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_busy.c | 30 +++-
1 file changed, 9 insertions(+), 21 deletions
On Tue, Sep 14, 2021 at 04:04:25PM +0300, Lisovskiy, Stanislav wrote:
> On Tue, Sep 14, 2021 at 03:04:11PM +0300, Jani Nikula wrote:
> > On Tue, 14 Sep 2021, "Lisovskiy, Stanislav"
> > wrote:
> > > On Tue, Sep 14, 2021 at 10:48:46AM +0300, Ville Syrjälä wrote:
> > >> On Tue, Sep 14, 2021 at 07:31
== Series Details ==
Series: Add support for querying hw info that UMDs need (rev3)
URL : https://patchwork.freedesktop.org/series/94305/
State : failure
== Summary ==
Applying: drm/i915/guc: Add fetch of hwconfig table
error: sha1 information is lacking or useless (drivers/gpu/drm/i915/Makefi
== Series Details ==
Series: lib, stackdepot: Add helper to print stack entries into buffer.
URL : https://patchwork.freedesktop.org/series/94655/
State : failure
== Summary ==
Applying: lib, stackdepot: Add helper to print stack entries into buffer.
error: sha1 information is lacking or usele
== Series Details ==
Series: Move vfio_ccw to the new mdev API (rev2)
URL : https://patchwork.freedesktop.org/series/94520/
State : failure
== Summary ==
Applying: Move vfio_ccw to the new mdev API
error: sha1 information is lacking or useless (drivers/s390/cio/vfio_ccw_fsm.c).
error: could no
On Tue, Sep 14, 2021 at 02:43:02PM +0200, Maarten Lankhorst wrote:
> Op 14-09-2021 om 08:50 schreef Peter Zijlstra:
> > On Mon, Sep 13, 2021 at 10:42:36AM +0200, Maarten Lankhorst wrote:
> >
> >>> +/**
> >>> + * ww_mutex_trylock - tries to acquire the w/w mutex with optional
> >>> acquire context
On Tue, 14 Sep 2021, "Lisovskiy, Stanislav"
wrote:
> On Tue, Sep 14, 2021 at 04:04:25PM +0300, Lisovskiy, Stanislav wrote:
>> On Tue, Sep 14, 2021 at 03:04:11PM +0300, Jani Nikula wrote:
>> > On Tue, 14 Sep 2021, "Lisovskiy, Stanislav"
>> > wrote:
>> > > On Tue, Sep 14, 2021 at 10:48:46AM +0300
On Tue, Sep 14, 2021 at 12:38:00PM +0200, Thomas Hellström wrote:
> On Tue, 2021-09-14 at 10:53 +0200, Christian König wrote:
> > Am 14.09.21 um 10:27 schrieb Thomas Hellström:
> > > On Tue, 2021-09-14 at 09:40 +0200, Christian König wrote:
> > > > Am 13.09.21 um 14:41 schrieb Thomas Hellström:
> >
On Mon, Sep 13, 2021 at 10:09:54PM -0700, Matthew Brost wrote:
> An error capture allocates memory, memory allocations depend on resets,
> and resets need to flush the G2H handlers to seal several races. If the
> error capture is done from the G2H handler this creates a circular
> dependency. To wo
On Mon, Sep 13, 2021 at 10:09:56PM -0700, Matthew Brost wrote:
> From: John Harrison
>
> When i915 receives a context reset notification from GuC, it triggers
> an error capture before resetting any outstanding requsts of that
> context. Unfortunately, the error capture is not a time bound
> oper
> -Original Message-
> From: Nikula, Jani
> Sent: Tuesday, September 14, 2021 7:33 PM
> To: Lisovskiy, Stanislav
> Cc: Ville Syrjälä ; Kulkarni, Vandita
> ; intel-gfx@lists.freedesktop.org; Navare,
> Manasi D
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Enable second VDSC
> engin
On Tue, Sep 14, 2021 at 12:16:13PM +0300, Jani Nikula wrote:
On Wed, 08 Sep 2021, Lucas De Marchi wrote:
We shouldn't be using debugfs_ namespace for this functionality. Rename
debugfs_gt.[ch] to intel_gt_debugfs.[ch] and then make functions,
defines and structs follow suit.
While at it and si
On Tue, 14 Sep 2021, Lucas De Marchi wrote:
> On Tue, Sep 14, 2021 at 12:16:13PM +0300, Jani Nikula wrote:
>>On Wed, 08 Sep 2021, Lucas De Marchi wrote:
>>> We shouldn't be using debugfs_ namespace for this functionality. Rename
>>> debugfs_gt.[ch] to intel_gt_debugfs.[ch] and then make functions
On Tue, 14 Sep 2021, "Kulkarni, Vandita" wrote:
>> -Original Message-
>> From: Nikula, Jani
>> Sent: Tuesday, September 14, 2021 7:33 PM
>> To: Lisovskiy, Stanislav
>> Cc: Ville Syrjälä ; Kulkarni, Vandita
>> ; intel-gfx@lists.freedesktop.org; Navare,
>> Manasi D
>> Subject: Re: [Intel-
On 9/14/21 4:07 PM, Daniel Vetter wrote:
On Tue, Sep 14, 2021 at 12:38:00PM +0200, Thomas Hellström wrote:
On Tue, 2021-09-14 at 10:53 +0200, Christian König wrote:
Am 14.09.21 um 10:27 schrieb Thomas Hellström:
On Tue, 2021-09-14 at 09:40 +0200, Christian König wrote:
Am 13.09.21 um 14:41
On Tue, Sep 14, 2021 at 03:04:59PM +1000, Dave Airlie wrote:
> On Tue, 14 Sept 2021 at 14:55, Matthew Brost wrote:
> >
> > From: Venkata Sandeep Dhanalakota
> >
> > Defining vma on stack can cause stack overflow, if
> > vma gets populated with new fields.
>
> Is there some higher level locking s
On Fri, Sep 10 2021, Christoph Hellwig wrote:
> On Thu, Sep 09, 2021 at 04:38:41PM -0300, Jason Gunthorpe wrote:
>> +
>> +private = kzalloc(sizeof(*private), GFP_KERNEL | GFP_DMA);
>> +if (!private)
>> +return ERR_PTR(-ENOMEM);
>
> Nit: there is no need to add GFP_KERNEL when
== Series Details ==
Series: Enable GuC submission by default on DG1 (rev6)
URL : https://patchwork.freedesktop.org/series/93325/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/
== Series Details ==
Series: Enable GuC submission by default on DG1 (rev6)
URL : https://patchwork.freedesktop.org/series/93325/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10583 -> Patchwork_21042
Summary
---
**F
== Series Details ==
Series: Do error capture async, flush G2H processing on reset (rev3)
URL : https://patchwork.freedesktop.org/series/94642/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+dr
== Series Details ==
Series: Do error capture async, flush G2H processing on reset (rev3)
URL : https://patchwork.freedesktop.org/series/94642/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10583 -> Patchwork_21043
Summary
On Mon, 13 Sep 2021, Nathan Chancellor wrote:
> On Tue, Aug 24, 2021 at 03:54:24PM -0700, Nathan Chancellor wrote:
>> Commit 46e2068081e9 ("drm/i915: Disable some extra clang warnings")
>> disabled -Wsometimes-uninitialized as noisy but there have been a few
>> fixes to clang that make the false p
On Fri, 10 Sep 2021, Dave Airlie wrote:
> From: Dave Airlie
>
> This moves one wrapper from the pm->display side, and creates
> wrappers for all the others, this should simplify things later.
>
> One thing to note is that the code checks the existance of some
> of these ptrs, so the wrappers are
On Fri, 10 Sep 2021, Dave Airlie wrote:
> From: Dave Airlie
>
> This adds wrappers around all the vtable callers so they are in
> one place.
>
> Suggested by Jani.
>
> Signed-off-by: Dave Airlie
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c| 47
On Fri, 10 Sep 2021, Dave Airlie wrote:
> From: Dave Airlie
>
> This wraps the fdi link training vfunc to make it clearer.
>
> Suggested by Jani.
>
> Signed-off-by: Dave Airlie
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 2 +-
> drivers/gpu/drm/i915/displ
On Tue, 14 Sept 2021 at 10:03, Christian König wrote:
>
> Am 14.09.21 um 10:50 schrieb Matthew Auld:
> > Add new flag to indicate special shmem based tt, which can directly
> > handle swapping itself, and should be visible to some shrinker.
> >
> > As part of this we should skip the ttm_pages_allo
On Mon, Sep 13, 2021 at 04:31:54PM -0400, Eric Farman wrote:
> > I rebased it and fixed it up here:
> >
> > https://github.com/jgunthorpe/linux/tree/vfio_ccw
> >
> > Can you try again?
>
> That does address the crash, but then why is it processing a BROKEN
> event? Seems problematic.
The stuff
Appears to match latest BSPEC
Reviewed-by: Clint Taylor
-Clint
On 9/3/21 5:35 PM, Matt Roper wrote:
From: Lucas De Marchi
Like DG1, XeHP SDV doesn't have LLC/eDRAM control values due to being a
dgfx card. XeHP SDV adds 2 more bits: L3_GLBGO to "push the Go point to
memory for L3 destined t
On Tue, Sep 14, 2021 at 09:34:08AM +0100, Tvrtko Ursulin wrote:
>
> On 13/09/2021 17:50, Matthew Brost wrote:
> > On Mon, Sep 13, 2021 at 10:24:43AM +0100, Tvrtko Ursulin wrote:
> > >
> > > On 10/09/2021 20:49, Matthew Brost wrote:
> > > > On Fri, Sep 10, 2021 at 12:12:42PM +0100, Tvrtko Ursulin
== Series Details ==
Series: Move vfio_ccw to the new mdev API (rev3)
URL : https://patchwork.freedesktop.org/series/94520/
State : failure
== Summary ==
Patch is empty.
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
On Fri, 10 Sep 2021, Dave Airlie wrote:
> From: Dave Airlie
>
> These are the watermark api between display and pm.
>
> Signed-off-by: Dave Airlie
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 35 -
> drivers/gpu/drm/i915/i915_drv.h
This is Dave's series [1] with patch 2 (drm/i915/uncore: constify the
register vtables.) dropped because it conflicts between drm-intel-next
and drm-intel-gt-next. I want to get proper CI results on this before
merging. We can do the leftover patch afterwards. Everything else is
unmodified.
BR,
Ja
From: Dave Airlie
constify it while here. drop the put function since it was never
overloaded and always has done the same thing, no point in
indirecting it for show.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_uncore.c | 70 +
From: Dave Airlie
The i845_update_wm code was always calling the i845 variant,
and the i9xx_update_wm had only a choice between i830 and i9xx
paths, hardly worth the vfunc overhead.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_d
From: Dave Airlie
The crtc was never being used here.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 10 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_pm.c
From: Dave Airlie
This moves one wrapper from the pm->display side, and creates
wrappers for all the others, this should simplify things later.
One thing to note is that the code checks the existance of some
of these ptrs, so the wrappers are a bit complicated by that.
Suggested by Jani.
v2: f
From: Dave Airlie
This wraps the fdi link training vfunc to make it clearer.
Suggested by Jani.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
drivers/gpu/drm/i915/display/intel_fdi.c | 8
From: Dave Airlie
This adds wrappers around all the vtable callers so they are in
one place.
Suggested by Jani.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_cdclk.c| 47 +++
drivers/gpu/drm/i915/dis
From: Dave Airlie
This function is only used inside intel_pm.c
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 9 ++-
drivers/gpu/drm/i915/intel_pm.c | 48 -
2 files changed, 32 insertio
From: Dave Airlie
These are the watermark api between display and pm.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 35 -
drivers/gpu/drm/i915/i915_drv.h | 24
driver
From: Dave Airlie
These are only used internally in the color module
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_color.c | 64 +++---
drivers/gpu/drm/i915/i915_drv.h| 39 +++--
2 fil
From: Dave Airlie
These are only used internally in the audio code
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_audio.c | 24 +++---
drivers/gpu/drm/i915/i915_drv.h| 19 +++--
2 f
From: Dave Airlie
This moves all the cdclk related functions into their own vtable.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 142 ++---
drivers/gpu/drm/i915/i915_drv.h| 8 +-
From: Dave Airlie
This provide a service from irq to display, so make it separate
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_hotplug.c | 4 ++--
drivers/gpu/drm/i915/i915_drv.h | 9 -
drivers/gp
From: Dave Airlie
It may make sense to merge this with display again later,
however the fdi use of the vtable is limited to only a
few generations.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_fdi.c | 8
drive
From: Dave Airlie
this single function might be possible to merge later, but
for now it's simple to just split it out.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 6 +++---
drivers/gpu/drm/i915/display/int
From: Dave Airlie
Put the vtable into ro memory.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_fdi.c | 20
drivers/gpu/drm/i915/i915_drv.h | 2 +-
2 files changed, 17 insertions(+), 5 delet
From: Dave Airlie
Use a macro to avoid mistakes, this type of macro is only used
in a couple of places.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_hotplug.c | 4 +--
drivers/gpu/drm/i915/i915_drv.h | 2
From: Dave Airlie
This clarifies quite well what functions get used on what platforms
instead of having to decipher the old tree.
v2: fixed IVB mistake (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_color.c | 138
1 - 100 of 161 matches
Mail list logo
