Hi Dmitry,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20220714]
[also build test ERROR on v5.19-rc6]
[cannot apply to drm-misc/drm-misc-next drm-intel/for-linux-next
media-tree/master linus/master v5.19-rc6 v5.19-rc5 v5.19-rc4]
[If your patch is applied
Hi Linus,
This is the regular fixes pull for this week. This has a bunch of
amdgpu fixes, major one reverts the buddy allocator until it can be
tested more, otherwise just small ones, then i915 has a bunch of
fixes.
The outstanding firmware regressions reported by phoronix will
hopefully be
From: allen chen
Use i2c bus to read/write when it6505 power off will occur i2c error.
Add this check will prevent i2c error when it6505 power off.
Signed-off-by: Pin-Yen Lin
Signed-off-by: Allen Chen
Reviewed-by: Robert Foss
---
drivers/gpu/drm/bridge/ite-it6505.c | 12 ++--
1 file
From: allen chen
Speed up video clock calculation and remove redundant video debug message.
Signed-off-by: Pin-Yen Lin
Signed-off-by: Allen Chen
Reviewed-by: Robert Foss
---
drivers/gpu/drm/bridge/ite-it6505.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git
From: allen chen
Change power sequence to meet it6505 data sheet requirement when boot on.
Signed-off-by: Pin-Yen Lin
Signed-off-by: Allen Chen
Reviewed-by: Robert Foss
---
drivers/gpu/drm/bridge/ite-it6505.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: allen chen
This series fixes some it6505 driver bugs and improve computing time.
Changes in v2:
- Change committe message occure to occur.
allen chen (3):
drm/bridge: it6505: Modified power sequence
drm/bridge: it6505: Add i2c api power on check
drm/bridge: it6505: Modified
Currently any attempts to pin a device coherent page will fail. This is
because device coherent pages need to be managed by a device driver, and
pinning them would prevent a driver from migrating them off the device.
However this is no reason to fail pinning of these pages. These are
coherent and
On 7/14/2022 17:40, john.c.harri...@intel.com wrote:
From: John Harrison
A bunch of code was copy/pasted using pr_err as the default way to
report errors. However, drm_err is significantly more useful in
identifying where the error came from. So update the code to use that
instead.
The new common dma-buf locking convention will require buffer importers
to hold the reservation lock around mapping operations. Make DRM GEM core
to take the lock around the vmapping operations and update QXL and i915
drivers to use the locked functions for the case where DRM core now holds
the
The internal dma-buf lock isn't needed anymore because the updated
locking specification claims that dma-buf reservation must be locked
by importers, and thus, the internal data is already protected by the
reservation lock. Remove the obsoleted internal lock.
Signed-off-by: Dmitry Osipenko
---
Add _unlocked postfix to the dma-buf API function names in a preparation
to move all non-dynamic dma-buf users over to the dynamic locking
specification. This patch only renames API functions, preparing drivers
to the common locking convention. Later on we will make the "unlocked"
functions to
Intel i915 GPU driver uses wait-wound mutex to lock multiple GEMs on the
attachment to the i915 dma-buf. In order to let all drivers utilize shared
wait-wound context during attachment in a general way, make dma-buf core to
acquire the ww context internally for the attachment operation and update
This patch moves the non-dynamic dma-buf users over to the dynamic
locking specification. From now on all dma-buf importers are responsible
for holding dma-buf's reservation lock around operations performed over
dma-bufs. This strict locking convention prevents dead lock situation for
dma-buf
All drivers that use dma-bufs have been moved to the updated locking
specification and now dma-buf reservation is guaranteed to be locked
by importers during the mapping operations. There is no need to take
the internal dma-buf lock anymore. Remove locking from the videobuf2
memory allocators.
Hello,
This series moves all drivers to a dynamic dma-buf locking specification.
>From now on all dma-buf importers are made responsible for holding
dma-buf's reservation lock around all operations performed over dma-bufs.
This common locking convention allows us to utilize reservation lock more
From: John Harrison
A bunch of code was copy/pasted using pr_err as the default way to
report errors. However, drm_err is significantly more useful in
identifying where the error came from. So update the code to use that
instead.
Signed-off-by: John Harrison
---
On Thu, Jul 14, 2022 at 04:51:40PM -0700, Guenter Roeck wrote:
> On Fri, Jul 08, 2022 at 05:30:47PM -0300, Maíra Canal wrote:
> > Considering the current adoption of the KUnit framework, convert the
> > DRM format selftest to the KUnit API.
> >
> > Tested-by: David Gow
> > Acked-by: Daniel
On Fri, Jul 08, 2022 at 05:30:47PM -0300, Maíra Canal wrote:
> Considering the current adoption of the KUnit framework, convert the
> DRM format selftest to the KUnit API.
>
> Tested-by: David Gow
> Acked-by: Daniel Latypov
> Reviewed-by: Javier Martinez Canillas
> Signed-off-by: Maíra Canal
I assume you're probably good on review for the non-nouveau stuff, but if you
end up needing any help with that feel free to poke me!
On Tue, 2022-07-12 at 21:38 +0200, Hans de Goede wrote:
> Hi All,
>
> As mentioned in my RFC titled "drm/kms: control display brightness through
> drm_connector
On Fri, 15 Apr 2022 at 10:15, Matt Roper wrote:
>
> On Tue, Apr 12, 2022 at 03:59:55PM -0700, john.c.harri...@intel.com wrote:
> > From: John Harrison
> >
> > The latest GuC firmware drops the context descriptor pool in favour of
> > passing all creation data in the create H2G. It also greatly
Reviewed-by: Lyude Paul
You also have permission to push this to drm-misc-whatever
On Tue, 2022-07-12 at 21:38 +0200, Hans de Goede wrote:
> Before this commit when we want userspace to use the acpi_video backlight
> device we register both the GPU's native backlight device and acpi_video's
>
Remove legacy PWM interface (pwm_config, pwm_enable, pwm_disable) and
replace it for the atomic PWM API.
Reviewed-by: Uwe Kleine-König
Reviewed-by: Daniel Thompson
Signed-off-by: Maíra Canal
---
V1 -> V2: Initialize variable and simplify conditional loop
V2 -> V3: Fix assignment of NULL
On 7/12/2022 6:22 AM, Dmitry Baryshkov wrote:
Currently the DSI driver has two separate paths: one if the next device
in a chain is a bridge and another one if the panel is connected
directly to the DSI host. Simplify the code path by using panel-bridge
driver (already selected in Kconfig)
Hi Dave, Daniel,
A few more new things for 5.20.
The following changes since commit c5da61cf5bab30059f22ea368702c445ee87171a:
drm/amdgpu/display: add missing FP_START/END checks dcn32_clk_mgr.c
(2022-06-30 19:35:21 -0400)
are available in the Git repository at:
On Thu, Jul 14, 2022 at 1:58 PM Andrey Grodzovsky
wrote:
>
> On 2022-07-14 12:22, Alex Deucher wrote:
>
> > On Thu, Jul 14, 2022 at 10:14 AM Andrey Grodzovsky
> > wrote:
> >>
> >> On 2022-07-14 05:57, Dmitry Osipenko wrote:
> >>> On 7/12/22 11:56, Dmitry Osipenko wrote:
> On 7/6/22 18:46,
On 7/14/22 11:49, Melissa Wen wrote:
O 07/13, Alex Deucher wrote:
On Wed, Jul 13, 2022 at 7:09 PM Guenter Roeck wrote:
On Wed, Jul 13, 2022 at 05:20:40PM -0400, Alex Deucher wrote:
The problem is not the FPU operations, but the fact that soft-float
and hard-float compiled code is linked
Hi,
On 7/13/22 19:21, Limonciello, Mario wrote:
> [Public]
>
>
>
>> -Original Message-
>> From: Werner Sembach
>> Sent: Wednesday, July 13, 2022 12:08
>> To: Hans de Goede ; Ben Skeggs
>> ; Karol Herbst ; Lyude
>> ; Daniel Dadap ; Maarten
>> Lankhorst ; Maxime Ripard
>> ; Thomas
Add a GFXOFF section at "GPU Power Controls" file, explaining what it is
and how userspace can interact with it.
Signed-off-by: André Almeida
---
Changes from v1: file created
Documentation/gpu/amdgpu/thermal.rst | 41
1 file changed, 41 insertions(+)
diff --git
GFXOFF has two different "state" values: one to define if the GPU is
allowed/disallowed to enter GFXOFF, usually called state; and another
one to define if currently GFXOFF is being used, usually called status.
Even when GFXOFF is allowed, GPU firmware can decide to not used it
accordingly to the
O 07/13, Alex Deucher wrote:
> On Wed, Jul 13, 2022 at 7:09 PM Guenter Roeck wrote:
> >
> > On Wed, Jul 13, 2022 at 05:20:40PM -0400, Alex Deucher wrote:
> > > >
> > > > The problem is not the FPU operations, but the fact that soft-float
> > > > and hard-float compiled code is linked together.
On Tue, Jul 12, 2022 at 9:39 PM Hans de Goede wrote:
>
> Hi All,
>
> As mentioned in my RFC titled "drm/kms: control display brightness through
> drm_connector properties":
> https://lore.kernel.org/dri-devel/0d188965-d809-81b5-74ce-7d30c49fe...@redhat.com/
>
> The first step towards this is to
Found the new use case from the 5/10 of reordering CS ioctl.
Reviewed-by: Andrey Grodzovsky
Andrey
On 2022-07-14 12:26, Christian König wrote:
We need this for limiting codecs like AV1 to the first instance for VCN3.
Essentially the idea is that we first initialize the job with entity,
id
On 2022-07-14 12:22, Alex Deucher wrote:
On Thu, Jul 14, 2022 at 10:14 AM Andrey Grodzovsky
wrote:
On 2022-07-14 05:57, Dmitry Osipenko wrote:
On 7/12/22 11:56, Dmitry Osipenko wrote:
On 7/6/22 18:46, Alex Deucher wrote:
On Wed, Jul 6, 2022 at 9:49 AM Andrey Grodzovsky
wrote:
On
https://bugzilla.kernel.org/show_bug.cgi?id=216120
--- Comment #6 from mat2003...@gmail.com ---
not quite there yet, after some hours of working with latest
linus+0001-drm-amdgpu-Fix-for-drm-buddy-memory-corruption.patch (latest commit
"vf/remap: return the amount of bytes actually deduplicated")
Noticed these minor issues while trying to investigate
https://bugzilla.redhat.com/show_bug.cgi?id=2086470
While unfortunately I've been unable to confirm whether these patches
fix the specific problem in question, they're likely fixes we want to
pull in regardless.
Lyude Paul (2):
While trying to fix another issue, it occurred to me that I don't actually
think there is any situation where we want pm_runtime_put() in nouveau to
be synchronous. In fact, this kind of just seems like it would cause
issues where we may unexpectedly block a thread we don't expect to be
blocked.
Since this isn't actually a failure.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index
https://bugzilla.kernel.org/show_bug.cgi?id=216120
--- Comment #5 from mat2003...@gmail.com ---
Created attachment 301427
--> https://bugzilla.kernel.org/attachment.cgi?id=301427=edit
journal 2022-07-14
--
You may reply to this email to add a comment.
You are receiving this mail because:
You
On 7/14/22 09:29, Alex Deucher wrote:
Applied. Thanks!
On Wed, Jul 13, 2022 at 4:03 PM Harry Wentland wrote:
On 2022-07-12 18:42, Guenter Roeck wrote:
The new display engine uses floating point math, which is not supported
by KCOV. Commit 9d1d02ff3678 ("drm/amd/display: Don't build DCN1
On Thu, Jul 14, 2022 at 12:45 PM André Almeida wrote:
>
>
>
> Às 13:42 de 14/07/22, Alex Deucher escreveu:
> > On Wed, Jul 13, 2022 at 11:15 AM André Almeida
> > wrote:
> >>
> >> GFXOFF has two different "state" values: one to define if the GPU is
> >> allowed/disallowed to enter GFXOFF,
Às 13:42 de 14/07/22, Alex Deucher escreveu:
> On Wed, Jul 13, 2022 at 11:15 AM André Almeida wrote:
>>
>> GFXOFF has two different "state" values: one to define if the GPU is
>> allowed/disallowed to enter GFXOFF, usually called state; and another
>> one to define if currently GFXOFF is being
On Wed, Jul 13, 2022 at 11:15 AM André Almeida wrote:
>
> GFXOFF has two different "state" values: one to define if the GPU is
> allowed/disallowed to enter GFXOFF, usually called state; and another
> one to define if currently GFXOFF is being used, usually called status.
> Even when GFXOFF is
Applied. Thanks!
On Thu, Jul 14, 2022 at 9:50 AM André Almeida wrote:
>
> Clarify which architecture those asics acronyms refers to.
>
> Signed-off-by: André Almeida
> ---
> drivers/gpu/drm/amd/amdgpu/Kconfig | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git
Applied. Thanks!
Alex
On Thu, Jul 14, 2022 at 6:34 AM Colin Ian King wrote:
>
> There is a spelling mistake in a dml_print message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> .../gpu/drm/amd/display/dc/dml/dcn314/display_mode_vba_314.c| 2 +-
> 1 file changed, 1 insertion(+), 1
Applied. Thanks!
On Wed, Jul 13, 2022 at 4:03 PM Harry Wentland wrote:
>
> On 2022-07-12 18:42, Guenter Roeck wrote:
> > The new display engine uses floating point math, which is not supported
> > by KCOV. Commit 9d1d02ff3678 ("drm/amd/display: Don't build DCN1 when kcov
> > is enabled") tried
We need this for limiting codecs like AV1 to the first instance for VCN3.
Essentially the idea is that we first initialize the job with entity, id
etc... and before we submit it we select a new rq for the entity. In the
meantime the VCN3 inline parse will have modified the available rqs for
On Thu, Jul 14, 2022 at 10:14 AM Andrey Grodzovsky
wrote:
>
>
> On 2022-07-14 05:57, Dmitry Osipenko wrote:
> > On 7/12/22 11:56, Dmitry Osipenko wrote:
> >> On 7/6/22 18:46, Alex Deucher wrote:
> >>> On Wed, Jul 6, 2022 at 9:49 AM Andrey Grodzovsky
> >>> wrote:
> On 2022-07-06 03:07,
[WHY]
It makes more sense to have these helpers in zone specific header
file, rather than the generic mm.h
Signed-off-by: Alex Sierra
---
include/linux/memremap.h | 2 +-
include/linux/mm.h | 78 ---
include/linux/mmzone.h | 80
Às 12:06 de 14/07/22, Sebin Sebastian escreveu:
> On Tue, Jul 12, 2022 at 12:14:27PM -0300, André Almeida wrote:
>> Hi Sebin,
>>
>> Às 10:29 de 10/07/22, Sebin Sebastian escreveu:
>>> Fix two coverity warning's double free and and an uninitialized pointer
>>> read. Both tmp and new are pointing at
Can you please remind me of the use case that requires this ? I browsed
through
related mails in the past but haven't found when is that needed. For amdgpu
drm_sched_job_init and drm_sched_job_arm are called together and amdgpu
is the only one who supports modifying entity priority on the fly as
On 14.07.2022 14:06, Mauro Carvalho Chehab wrote:
> From: Prathap Kumar Valsan
>
> Add routines to interface with GuC firmware for selective TLB invalidation
> supported on XeHP.
>
> Signed-off-by: Prathap Kumar Valsan
> Cc: Matthew Brost
> Signed-off-by: Mauro Carvalho Chehab
> ---
>
>
On Tue, Jul 12, 2022 at 12:14:27PM -0300, André Almeida wrote:
> Hi Sebin,
>
> Às 10:29 de 10/07/22, Sebin Sebastian escreveu:
> > Fix two coverity warning's double free and and an uninitialized pointer
> > read. Both tmp and new are pointing at same address and both are freed
> > which leads to
Am 14.07.22 um 15:33 schrieb Alex Deucher:
On Thu, Jul 14, 2022 at 9:09 AM Christian König
wrote:
Hi Mauro,
well the last time I checked drm-tip was clean.
The revert is necessary because we had some problems with the commit
which we couldn't fix in the 5.19 cycle.
Would it be worth
On Thu, 14 Jul 2022 09:33:23 -0400
Alex Deucher wrote:
> On Thu, Jul 14, 2022 at 9:09 AM Christian König
> wrote:
> >
> > Hi Mauro,
> >
> > well the last time I checked drm-tip was clean.
> >
> > The revert is necessary because we had some problems with the commit
> > which we couldn't fix in
Hi Maxime,
On 7/13/22 11:10, Maxime Ripard wrote:
Hi Danilo,
On Wed, Jul 13, 2022 at 10:54:57AM +0200, Danilo Krummrich wrote:
This patch series converts DRM modeset object allocations from devm_*()
to drmm_*() memory allocators, or their corresponding convenience
wrappers, respectively, in
On 7/14/22 17:14, Andrey Grodzovsky wrote:
>
> On 2022-07-14 05:57, Dmitry Osipenko wrote:
>> On 7/12/22 11:56, Dmitry Osipenko wrote:
>>> On 7/6/22 18:46, Alex Deucher wrote:
On Wed, Jul 6, 2022 at 9:49 AM Andrey Grodzovsky
wrote:
> On 2022-07-06 03:07, Dmitry Osipenko wrote:
Hi Matthieu,
Thanks for your patch.
Às 11:58 de 06/07/22, Matthieu CHARETTE escreveu:
> Loading an EDID using drm.edid_firmware parameter makes resume to fail
> after firmware cache is being cleaned. This is because edid_load() use a
> temporary device to request the firmware. This cause the
On 2022-07-14 05:57, Dmitry Osipenko wrote:
On 7/12/22 11:56, Dmitry Osipenko wrote:
On 7/6/22 18:46, Alex Deucher wrote:
On Wed, Jul 6, 2022 at 9:49 AM Andrey Grodzovsky
wrote:
On 2022-07-06 03:07, Dmitry Osipenko wrote:
Hello Andrey,
On 5/17/22 17:48, Dmitry Osipenko wrote:
On
Hi Dave and Daniel,
here's the first PR for drm-misc-next-fixes for v5.20.
Best regards
Thomas
drm-misc-next-fixes-2022-07-14:
Short summary of fixes:
- dma-buf: revert change to fence handling
- mgag200: fix PCI register initialization
The following changes since commit
On 14.07.2022 14:06, Mauro Carvalho Chehab wrote:
> From: Prathap Kumar Valsan
>
> Add routines to interface with GuC firmware for TLB invalidation.
>
> Signed-off-by: Prathap Kumar Valsan
> Cc: Bruce Chang
> Cc: Michal Wajdeczko
> Cc: Matthew Brost
> Cc: Chris Wilson
> Signed-off-by:
Clarify which architecture those asics acronyms refers to.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/Kconfig | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/Kconfig
b/drivers/gpu/drm/amd/amdgpu/Kconfig
index
On Thu, Jul 14, 2022 at 01:35:35PM +0100, Russell King (Oracle) wrote:
> Hi,
>
> I don't mean to discourge test systems, but looking at this, I just go
> "meh" and delete it - it doesn't seem to contain obviously useful
> information. One has to read every damn line to see if there's something
>
On Thu, Jul 14, 2022 at 9:09 AM Christian König
wrote:
>
> Hi Mauro,
>
> well the last time I checked drm-tip was clean.
>
> The revert is necessary because we had some problems with the commit
> which we couldn't fix in the 5.19 cycle.
Would it be worth reverting the revert and applying the
Am 14.07.22 um 15:19 schrieb Mauro Carvalho Chehab:
On Thu, 14 Jul 2022 15:08:48 +0200
Christian König wrote:
Hi Mauro,
well the last time I checked drm-tip was clean.
The revert is necessary because we had some problems with the commit
which we couldn't fix in the 5.19 cycle.
I see. I
On Thu, 14 Jul 2022 15:08:48 +0200
Christian König wrote:
> Hi Mauro,
>
> well the last time I checked drm-tip was clean.
>
> The revert is necessary because we had some problems with the commit
> which we couldn't fix in the 5.19 cycle.
I see. I don't have any issues with the patch itself,
Hi Mauro,
well the last time I checked drm-tip was clean.
The revert is necessary because we had some problems with the commit
which we couldn't fix in the 5.19 cycle.
I will double check drm-tip once more.
Regards,
Christian.
Am 14.07.22 um 14:54 schrieb Mauro Carvalho Chehab:
On Fri, 8
Allocate driver structures with drm managed resource allocators in order
to cleanup/simplify the drm driver .release callback.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/virtio/virtgpu_kms.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git
Use drm managed resource allocation (drmm_universal_plane_alloc()) in
order to cleanup/simplify drm plane .destroy callback.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 30 +++---
1 file changed, 8 insertions(+), 22 deletions(-)
diff --git
This patch series converts plain memory allocations for driver structures and
planes to drm managed allocations in order to cleanup/simply the corresponding
release/destroy callbacks.
Danilo Krummrich (2):
drm/virtio: plane: use drm managed resources
drm/virtio: kms: use drm managed resources
There is a spelling mistake in the list head variable, rename it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/drm_flip_work.c | 10 +-
include/drm/drm_flip_work.h | 6 +++---
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_flip_work.c
On Fri, 8 Jul 2022 03:21:24 -0700
Arunpravin Paneer Selvam wrote:
> This reverts the following commits:
> commit 708d19d9f362 ("drm/amdgpu: move internal vram_mgr function into the C
> file")
> commit 5e3f1e7729ec ("drm/amdgpu: fix start calculation in
> amdgpu_vram_mgr_new")
> commit
Hi,
I don't mean to discourge test systems, but looking at this, I just go
"meh" and delete it - it doesn't seem to contain obviously useful
information. One has to read every damn line to see if there's something
of relevence, which I for one am not going to do.
Is there some kind of
On 2022-07-11 11:13, Liviu Dudau wrote:
[...]
But nothing worrying. It does work, though doesn't compile due to:
drivers/gpu/drm/arm/display/komeda/komeda_kms.c: In function
‘komeda_kms_atomic_commit_hw_done’:
drivers/gpu/drm/arm/display/komeda/komeda_kms.c:77:9: error: ‘for’ loop
initial
On Thu, Jul 14, 2022 at 11:04:09AM +0200, Geert Uytterhoeven wrote:
> The mode parsing code recognizes named modes only if they are explicitly
> listed in the internal whitelist, which is currently limited to "NTSC"
> and "PAL".
>
> Provide a mechanism for drivers to override this list to support
From: Chris Wilson
Prepare for supporting more TLB invalidation scenarios by moving
the current MMIO invalidation to its own file.
Signed-off-by: Chris Wilson
Cc: Fei Yang
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
Add a description for the kAPI functions inside intel_tlb.c.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v2 00/21] at:
https://lore.kernel.org/all/cover.1657800199.git.mche...@kernel.org/
From: Chris Wilson
Check if the device is powered down prior to any engine activity,
as, on such cases, all the TLBs were already invalidated, so an
explicit TLB invalidation is not needed, thus reducing the
performance regression impact due to it.
This becomes more significant with GuC, as it
From: Prathap Kumar Valsan
Add support for selective TLB invalidation, which is a platform
feature supported on XeHP.
Signed-off-by: Prathap Kumar Valsan
Cc: Niranjana Vishwanathapura
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing
Add documentation to the TLB field inside
struct drm_i915_gem_object.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v2 00/21] at:
Add a kernel-doc markup to document this new macro.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v2 00/21] at:
https://lore.kernel.org/all/cover.1657800199.git.mche...@kernel.org/
From: Prathap Kumar Valsan
For platforms supporting selective tlb invalidations, we don't need to
do a full tlb invalidation. Rather do a range based tlb invalidation for
every unbind of purged vma belongs to an active vm.
[mchehab: change moved from intel_ppgtt.c to i915_vma.c]
Signed-off-by:
From: Prathap Kumar Valsan
Add routines to interface with GuC firmware for TLB invalidation.
Signed-off-by: Prathap Kumar Valsan
Cc: Bruce Chang
Cc: Michal Wajdeczko
Cc: Matthew Brost
Cc: Chris Wilson
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of
Add documentation for the 3 new members of struct intel_guc
that are used to handle TLB cache invalidation logic.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v2 00/21] at:
TLB invalidation is a slow operation. It should not be doing lightly, as it
causes performance regressions, like this:
[178.821002] i915 :00:02.0: [drm] *ERROR* rcs0 TLB invalidation did not
complete in 4ms!
This series contain
1) some patches that makes TLB invalidation to happen only on
From: Chris Wilson
Don't flush TLBs when the buffer is only used in the GGTT under full
control of the kernel, as there's no risk of concurrent access
and stale access from prefetch.
We only need to invalidate the TLB if they are accessible by the user.
That helps to reduce the performance
From: Chris Wilson
Invalidate TLB in patch, in order to reduce performance regressions.
Currently, every caller performs a full barrier around a TLB
invalidation, ignoring all other invalidations that may have already
removed their PTEs from the cache. As this is a synchronous operation
and can
From: Chris Wilson
With multi-GT devices, the object may have been bound on each GT.
Invalidate the TLBs across all GT before releasing the pages
back to the system.
Signed-off-by: Chris Wilson
Cc: Fei Yang
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of
From: Chris Wilson
Ensure that the TLB of the OA unit is also invalidated
on gen12 HW, as just invalidating the TLB of an engine is not
enough.
Cc: sta...@vger.kernel.org
Fixes: 7938d61591d3 ("drm/i915: Flush TLBs before releasing backing store")
Signed-off-by: Chris Wilson
Cc: Fei Yang
Cc:
From: Prathap Kumar Valsan
Add an interface for GuC TLB actions, supporting both selective and
full TLB invalidations. After this change, when GuC is enabled,
tlb invalidations use GuC ct. Otherwise, use mmio interface.
Signed-off-by: Prathap Kumar Valsan
Cc: Niranjana Vishwanathapura
Cc: Fei
From: Prathap Kumar Valsan
Add routines to interface with GuC firmware for selective TLB invalidation
supported on XeHP.
Signed-off-by: Prathap Kumar Valsan
Cc: Matthew Brost
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were
Add a description for intel_guc_tlb_invalidation_type enum.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v2 00/21] at:
https://lore.kernel.org/all/cover.1657800199.git.mche...@kernel.org/
Transform the comments for intel_guc_tlb_inval_mode into a
kernel-doc markup.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v2 00/21] at:
Add documentation for the kAPI functions that do TLB cache
invalidation via GuC.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v2 00/21] at:
From: Piotr Piórkowski
Add a new way to invalidate TLB via GuC using actions 0x7002
(TLB_INVALIDATION_ALL).
Those actions will be used on upcoming patches.
Signed-off-by: Piotr Piórkowski
Cc: Michal Wajdeczko
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number
From: Chris Wilson
Skip all further TLB invalidations once the device is wedged and
had been reset, as, on such cases, it can no longer process instructions
on the GPU and the user no longer has access to the TLB's in each engine.
That helps to reduce the performance regression introduced by
TLB cache invalidation can happen on two different situations:
1. synchronously, at __vma_put_pages();
2. asynchronously.
On the first case, TLB cache invalidation happens inside
__vma_put_pages(). So, no need to do it later on.
However, on the second case, the pages will keep in memory
until
On Thu, Jul 14, 2022 at 11:04:10AM +0200, Geert Uytterhoeven wrote:
> It is fairly common for named video modes to contain dashes (e.g.
> "tt-mid" on Atari, "dblntsc-ff" on Amiga). Currently such mode names
> are not recognized, as the dash is considered to be a separator between
> mode name and
On Thu, Jul 14, 2022 at 11:04:08AM +0200, Geert Uytterhoeven wrote:
> The various mode->*specified flags are not handled in an uniform way:
> some flags are set by the corresponding drm_mode_parse_cmdline_*()
> function, some flags by the caller of the function, and some flags by
> both.
>
> Make
On Thu, Jul 14, 2022 at 11:04:07AM +0200, Geert Uytterhoeven wrote:
> Extract the code to check for a named mode parameter into its own
> function, to streamline the main parsing flow.
>
> Signed-off-by: Geert Uytterhoeven
> Reviewed-by: Hans de Goede
> Acked-by: Thomas Zimmermann
Acked-by:
Hi,
On Thu, Jul 14, 2022 at 11:04:06AM +0200, Geert Uytterhoeven wrote:
> If no mode name part was specified, mode_end is zero, and the "ret ==
> mode_end" check does the wrong thing.
>
> Fix this by skipping all named mode handling when mode_end is zero.
>
> Fixes: 7b1cce760afe38b4
1 - 100 of 173 matches
Mail list logo
