On 2/16/23 08:11, Christian König wrote:
Am 15.02.23 um 20:00 schrieb Thomas Hellström:
On Wed, 2023-02-15 at 19:30 +0100, Christian König wrote:
Am 15.02.23 um 19:12 schrieb Thomas Hellström:
On Wed, 2023-02-15 at 18:42 +0100, Christian König wrote:
Am 15.02.23 um 17:13 schrieb Thomas
Am 15.02.23 um 20:00 schrieb Thomas Hellström:
On Wed, 2023-02-15 at 19:30 +0100, Christian König wrote:
Am 15.02.23 um 19:12 schrieb Thomas Hellström:
On Wed, 2023-02-15 at 18:42 +0100, Christian König wrote:
Am 15.02.23 um 17:13 schrieb Thomas Hellström:
When swapping out, we will split
Am 16.02.23 um 02:07 schrieb Thomas Weißschuh:
Since commit ee6d3dd4ed48 ("driver core: make kobj_type constant.")
the driver core allows the usage of const struct kobj_type.
Take advantage of this to constify the structure definitions to prevent
modification at runtime.
Signed-off-by: Thomas
Hi Dave, Daniel,
A couple of warning fixes for 6.2.
The following changes since commit ceaa837f96adb69c0df0397937cd74991d5d821a:
Linux 6.2-rc8 (2023-02-12 14:10:17 -0800)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
-
> 4 files changed, 11 insertions(+), 26 deletions(-)
> ---
> base-commit: 9d9019bcea1aac7eed64a1a4966282b6b7b141c8
> change-id: 20230215-sspp-scaler-version-19f221585c5e
>
> Best regards,
> --
> Marijn Suijten
>
--
With best wishes
Dmitry
On Thu, 16 Feb 2023 at 01:02, Marijn Suijten
wrote:
>
> The SSPP scaler subblk is responsible for reporting its version (via the
> .id field, feature bits on the parent SSPP block, and since recently
> also from reading a register to supersede a read-but-unset version field
> in the catalog),
Hi,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
url:
https://github.com/intel-lab-lkp/linux/commits/John-C-Harrison-Intel-com/drm-i915-Don-t-use-stolen-memory-for-ring-buffers-with-LLC/20230216-082552
base:
On Thu, 16 Feb 2023 at 01:02, Marijn Suijten
wrote:
>
> This pointer callback is never used and should be removed. The helper
> _dpu_hw_sspp_get_scaler3_ver function is retained as it is being used by
> dpu_hw_sspp_init which didn't itself compute _sspp_subblk_offset yet.
>
> Signed-off-by:
On Thu, 16 Feb 2023 at 01:02, Marijn Suijten
wrote:
>
> DPU's catalog never assigned dpu_scaler_blk::version leading to
> initialization code in dpu_hw_setup_scaler3 to wander the wrong
> codepaths. Instead of hardcoding the correct QSEED algorithm version,
> read it back from a hardware
From: John Harrison
Direction from hardware is that ring buffers should never be mapped
via the BAR on systems with LLC. There are too many caching pitfalls
due to the way BAR accesses are routed. So it is safest to just not
use it.
Signed-off-by: John Harrison
Fixes: 9d80841ea4c9 ("drm/i915:
From: John Harrison
Direction from hardware is that stolen memory should never be used for
ring buffer allocations on platforms with LLC. There are too many
caching pitfalls due to the way stolen memory accesses are routed. So
it is safest to just not use it.
Signed-off-by: John Harrison
From: John Harrison
Instruction from hardware arch is that stolen memory and BAR mappings
are unsafe for use as ring buffers. There can be issues with cache
aliasing due to the CPU access going to memory via the BAR. So, don't
do it.
v2: Dont use BAR mappings either.
Make conditional on LLC so
Since commit ee6d3dd4ed48 ("driver core: make kobj_type constant.")
the driver core allows the usage of const struct kobj_type.
Take advantage of this to constify the structure definitions to prevent
modification at runtime.
Signed-off-by: Thomas Weißschuh
---
Since commit ee6d3dd4ed48 ("driver core: make kobj_type constant.")
the driver core allows the usage of const struct kobj_type.
Take advantage of this to constify the structure definitions to prevent
modification at runtime.
Signed-off-by: Thomas Weißschuh
---
Since commit ee6d3dd4ed48 ("driver core: make kobj_type constant.")
the driver core allows the usage of const struct kobj_type.
Take advantage of this to constify the structure definitions to prevent
modification at runtime.
Signed-off-by: Thomas Weißschuh
---
From: John Harrison
Instruction from hardware arch is that stolen memory and BAR mappings
are unsafe for use as ring buffers. There can be issues with cache
aliasing due to the CPU access going to memory via the BAR. So, don't
do it.
v2: Dont use BAR mappings either.
Make conditional on LLC so
From: Daniele Ceraolo Spurio
Direction from hardware is that ring buffers should never be mapped
via the BAR on systems with LLC. There are too many caching pitfalls
due to the way BAR accesses are routed. So it is safest to just not
use it.
Signed-off-by: John Harrison
Fixes: 9d80841ea4c9
From: John Harrison
Direction from hardware is that stolen memory should never be used for
ring buffer allocations on platforms with LLC. There are too many
caching pitfalls due to the way stolen memory accesses are routed. So
it is safest to just not use it.
Signed-off-by: John Harrison
From: Rob Clark
The error path cleanup expects that chain and syncobj are either NULL or
valid pointers. But post_deps was not allocated with __GFP_ZERO.
Fixes: ab723b7a992a ("drm/msm: Add syncobj support.")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_submit.c | 5 ++---
1 file
insertions(+), 26 deletions(-)
---
base-commit: 9d9019bcea1aac7eed64a1a4966282b6b7b141c8
change-id: 20230215-sspp-scaler-version-19f221585c5e
Best regards,
--
Marijn Suijten
The SSPP scaler subblk is responsible for reporting its version (via the
.id field, feature bits on the parent SSPP block, and since recently
also from reading a register to supersede a read-but-unset version field
in the catalog), leaving this global qseed_type field logically unused.
Remove this
This pointer callback is never used and should be removed. The helper
_dpu_hw_sspp_get_scaler3_ver function is retained as it is being used by
dpu_hw_sspp_init which didn't itself compute _sspp_subblk_offset yet.
Signed-off-by: Marijn Suijten
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 4
DPU's catalog never assigned dpu_scaler_blk::version leading to
initialization code in dpu_hw_setup_scaler3 to wander the wrong
codepaths. Instead of hardcoding the correct QSEED algorithm version,
read it back from a hardware register.
Note that this register is only available starting with
> struct nouveau_led {
> struct drm_device *dev;
>
> ---
> base-commit: e1c04510f521e853019afeca2a5991a5ef8d6a5b
> change-id: 20230215-power_supply-leds-nouveau-ff4995ba0794
>
> Best regards,
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
On Wed, 15 Feb 2023 at 20:54, Harry Wentland wrote:
> On 2/15/23 06:46, Daniel Stone wrote:
> > On Tue, 14 Feb 2023 at 16:57, Harry Wentland wrote:
> >> On 2/14/23 10:49, Sebastian Wick wrote:
> >> From what I've seen recently I am inclined to favor an incremental
> >> approach more. The reason
On Wed, Feb 15, 2023 at 11:48:13AM -0800, Sripada, Radhakrishna wrote:
>
>
> > -Original Message-
> > From: dri-devel On Behalf Of Matt
> > Roper
> > Sent: Monday, February 13, 2023 4:19 PM
> > To: intel-...@lists.freedesktop.org
> > Cc: dri-devel@lists.freedesktop.org
> > Subject:
On 2/14/23 16:12, Hamza Mahfooz wrote:
Since, hot plugging eDP displays isn't supported, it is sufficient for
us to warn about the lack of a connected display once. So, use ASSERT()
in dce110_edp_wait_for_hpd_ready() instead of DC_LOG_WARNING().
Signed-off-by: Hamza Mahfooz
Reviewed-by:
On Wed, Feb 15, 2023 at 03:55:07PM -0500, Alex Deucher wrote:
On Wed, Feb 15, 2023 at 3:46 PM Sasha Levin wrote:
From: Alex Deucher
[ Upstream commit 077e9659581acab70f2dcc04b5bc799aca3a056b ]
Causes flickering or white screens in some configurations.
Disable it for now until we can fix
On Wed, Feb 15, 2023 at 3:46 PM Sasha Levin wrote:
>
> From: Alex Deucher
>
> [ Upstream commit 077e9659581acab70f2dcc04b5bc799aca3a056b ]
>
> Causes flickering or white screens in some configurations.
> Disable it for now until we can fix the issue.
>
> Bug:
On 2/15/23 06:46, Daniel Stone wrote:
> Hi,
>
> On Tue, 14 Feb 2023 at 16:57, Harry Wentland wrote:
>> On 2/14/23 10:49, Sebastian Wick wrote:
>> From what I've seen recently I am inclined to favor an incremental
>> approach more. The reason is that any API, or portion thereof, is
>> useless
From: Alex Deucher
[ Upstream commit 077e9659581acab70f2dcc04b5bc799aca3a056b ]
Causes flickering or white screens in some configurations.
Disable it for now until we can fix the issue.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2352
Cc: roman...@amd.com
Cc: yifan1.zh...@amd.com
On 2/15/23 04:40, Pekka Paalanen wrote:
> On Tue, 14 Feb 2023 15:04:52 -0500
> Harry Wentland wrote:
>
>> On 2/14/23 14:45, Sebastian Wick wrote:
>>> On Tue, Feb 14, 2023 at 5:57 PM Harry Wentland
>>> wrote:
On 2/14/23 10:49, Sebastian Wick wrote:
> On Fri, Feb
On Tue, 2023-02-14 at 13:38 -0800, Teres Alexis, Alan Previn wrote:
alan:snip
> +static int gsccs_send_message(struct intel_pxp *pxp,
> + void *msg_in, size_t msg_in_size,
> + void *msg_out, size_t msg_out_size_max,
> +
> -Original Message-
> From: dri-devel On Behalf Of Matt
> Roper
> Sent: Monday, February 13, 2023 4:19 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Subject: [PATCH] drm/i915/xelpmp: Consider GSI offset when doing MCR
> lookups
>
> MCR range tables
On Mon, 13 Feb 2023 13:10:11 +0100, Konrad Dybcio wrote:
> Add a compatible for the DSI on SM6115.
>
> Signed-off-by: Konrad Dybcio
> ---
> .../devicetree/bindings/display/msm/dsi-controller-main.yaml| 2 ++
> 1 file changed, 2 insertions(+)
>
Acked-by: Rob Herring
On Mon, 13 Feb 2023 13:10:04 +0100, Konrad Dybcio wrote:
> The qcom, prefix was missed previously. Fix it.
>
> Fixes: 0c0f65c6dd44 ("dt-bindings: msm: dsi-controller-main: Add compatible
> strings for every current SoC")
> Signed-off-by: Konrad Dybcio
> ---
>
On Wed, 2023-02-15 at 19:30 +0100, Christian König wrote:
> Am 15.02.23 um 19:12 schrieb Thomas Hellström:
> > On Wed, 2023-02-15 at 18:42 +0100, Christian König wrote:
> > > Am 15.02.23 um 17:13 schrieb Thomas Hellström:
> > > > When swapping out, we will split multi-order pages both in
> > > >
On Wed, 2023-02-15 at 19:26 +0100, Christian König wrote:
> Am 15.02.23 um 19:02 schrieb Thomas Hellström:
> > On Wed, 2023-02-15 at 18:31 +0100, Christian König wrote:
> > > Am 15.02.23 um 17:13 schrieb Thomas Hellström:
> > > > When hitting an error, the error path forgot to unmap dma
> > > >
Am 15.02.23 um 19:19 schrieb Thomas Hellström:
On Wed, 2023-02-15 at 18:39 +0100, Christian König wrote:
Am 15.02.23 um 17:13 schrieb Thomas Hellström:
Update the TTM swapout interfaces for better compatibility with a
shrinker.
- Replace number-of-pages int return with a long to better match
Am 15.02.23 um 19:12 schrieb Thomas Hellström:
On Wed, 2023-02-15 at 18:42 +0100, Christian König wrote:
Am 15.02.23 um 17:13 schrieb Thomas Hellström:
When swapping out, we will split multi-order pages both in order to
move them to the swap-cache and to be able to return memory to the
swap
Am 15.02.23 um 19:02 schrieb Thomas Hellström:
On Wed, 2023-02-15 at 18:31 +0100, Christian König wrote:
Am 15.02.23 um 17:13 schrieb Thomas Hellström:
When hitting an error, the error path forgot to unmap dma mappings
and
I don't see where this happens?
From what I can tell,
On Fri, 10 Feb 2023 19:00:13 +0100, Uwe Kleine-König wrote:
> Modify the existing (fb-like) binding to support the drm-like binding in
> parallel.
>
> Signed-off-by: Uwe Kleine-König
> ---
> .../bindings/display/imx/fsl,imx-lcdc.yaml| 46 ++-
> 1 file changed, 45
On Wed, 2023-02-15 at 18:39 +0100, Christian König wrote:
> Am 15.02.23 um 17:13 schrieb Thomas Hellström:
> > Update the TTM swapout interfaces for better compatibility with a
> > shrinker.
> > - Replace number-of-pages int return with a long to better match
> > the
> > kernel's shrinker
On Wed, 2023-02-15 at 18:42 +0100, Christian König wrote:
> Am 15.02.23 um 17:13 schrieb Thomas Hellström:
> > When swapping out, we will split multi-order pages both in order to
> > move them to the swap-cache and to be able to return memory to the
> > swap cache as soon as possible on a
On Wed, 2023-02-15 at 18:31 +0100, Christian König wrote:
> Am 15.02.23 um 17:13 schrieb Thomas Hellström:
> > When hitting an error, the error path forgot to unmap dma mappings
> > and
>
> I don't see where this happens?
From what I can tell, ttm_pool_page_allocated() maps the page for dma,
If
Am 15.02.23 um 17:13 schrieb Thomas Hellström:
When swapping out, we will split multi-order pages both in order to
move them to the swap-cache and to be able to return memory to the
swap cache as soon as possible on a page-by-page basis.
By reducing the page max order to the system PMD size, we
Am 15.02.23 um 17:13 schrieb Thomas Hellström:
Update the TTM swapout interfaces for better compatibility with a shrinker.
- Replace number-of-pages int return with a long to better match the
kernel's shrinker interface.
- The gfp_flags parameter to ttm_xx_swapout() currently only takes the
Am 15.02.23 um 17:13 schrieb Thomas Hellström:
New code is recommended to use the BIT macro instead of the explicit
shifts. Change the older defines so that we can keep the style consistent
with upcoming changes.
Signed-off-by: Thomas Hellström
---
include/drm/ttm/ttm_tt.h | 10 +-
Am 15.02.23 um 17:13 schrieb Thomas Hellström:
When hitting an error, the error path forgot to unmap dma mappings and
I don't see where this happens?
could call set_pages_wb() on already uncached pages.
Yeah, but what's the problem?
Regards,
Christian.
Fix this by introducing a common
Am 15.02.23 um 17:13 schrieb Thomas Hellström:
The LRU mechanism may look up a resource in the process of being removed
from an object. The locking rules here are a bit unclear but it looks
currently like res->bo assignment is protected by the LRU lock, whereas
bo->resource is protected by the
On Wed, Feb 15, 2023 at 08:24:51AM -0800, Dixit, Ashutosh wrote:
> On Wed, 15 Feb 2023 07:37:30 -0800, Jani Nikula wrote:
> >
> > On Wed, 08 Feb 2023, Rodrigo Vivi wrote:
> > > On Wed, Feb 08, 2023 at 11:03:12AM -0800, Ashutosh Dixit wrote:
> > >> This reverts commit
On Wednesday, February 15th, 2023 at 14:41, Pekka Paalanen
wrote:
> I didn't know it was at all possible to have different GEM handles
> pointing to the same object. DMABUF import is guaranteed to return the
> existing GEM handle, right? Why is GETFB2 different? Why does it not
> have the same
On Wed, 15 Feb 2023 07:37:30 -0800, Jani Nikula wrote:
>
> On Wed, 08 Feb 2023, Rodrigo Vivi wrote:
> > On Wed, Feb 08, 2023 at 11:03:12AM -0800, Ashutosh Dixit wrote:
> >> This reverts commit 0349c41b05968befaffa5fbb7e73d0ee6004f610.
> >>
> >> 0349c41b0596 ("drm/i915/hwmon: Enable PL1 power
Remove the external i915 TTM shmem pool and replace it with the
normal TTM page allocation. Also provide a callback for the TTM
shrinker functionality.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_object.h| 6 -
.../gpu/drm/i915/gem/i915_gem_object_types.h | 6
Use fault-injection to test partial TTM swapout and interrupted swapin.
Return -EINTR for swapin to test the callers ability to handle and
restart the swapin, and on swapout perform a partial swapout to test that
the swapin and release_shrunken functionality.
Signed-off-by: Thomas Hellström
---
The cirrus driver maintains plane state, format and pitch, in it's
device structure. Introduce a plane state for the primary plane to
store the values.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/cirrus.c | 59 ++-
1 file changed, 58 insertions(+),
Provide a helper to be used by the driver bo_shrink() callback to either
insert the pages of a struct ttm_tt into the swap-cache or to purge them
if the struct ttm_tt is purgeable. For pages with write-combined or
uncached linear kernel map, that linear kernel map is first changed to
cached.
The DRM core implements a size check against the mode config's
limits when creating a framebuffer. [1] Remove the unnecessary
test from cirrus_fb_create() and remove the now-empty function.
Create framebuffers with drm_gem_fb_create_with_dirty().
Signed-off-by: Thomas Zimmermann
Link:
Inline the framebuffer size check into the primary plane's atomic_check
cirrus_primary_plane_atomic_check(). No functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/cirrus.c | 26 ++
1 file changed, 10 insertions(+), 16 deletions(-)
diff --git
The hardware settings for color format and pitch are state of the
primary plane. Store the values in the primary plane's state structure
struct cirrus_primary_plane_state. Adapt all callers.
All fields in struct cirrus_device are now considered immutable after
initialization. Plane updates
Test a display mode against the available amount of video memory in
struct drm_mode_config_funcs.mode_valid, which cirrus implements in
cirrus_mode_config_mode_valid(). This helper tests display modes against
device-wide limits. Remove the now-obsolete per-CRTC test.
Signed-off-by: Thomas
Set the VGA bit for unblanking with macro constants instead of magic
values. No functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/cirrus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tiny/cirrus.c
Inline cirrus_fb_blit_rect into its only caller. While at it, update
the code to use IOSYS_MAP_INIT_OFFSET(), which is the ideomatic way
of initializing struct iosys_map with an offset.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/cirrus.c | 22 ++
1 file
Replace simple-KMS helpers with DRM's regular helpers for atomic
modesetting. Avoids the mid-layer and the additional wrappers around
GEM's shadow-plane helpers.
Most of the simple-KMS code is just wrappers around regular atomic
helpers. The conversion is therefore equivalent to pulling the
GPU drivers have traditionally used shmem to back up GPU buffer contents
for swap on physical memory shortage. Some integrated GPU drivers use
shmem files as the backing storage for their GPU buffers, other drivers,
in particular drivers that need a Write-Combining caching strategy on
system
Enable damage clipping on the primary plane and iterate over small
areas of reported framebuffer damage. Avoid the overhead of permanent
full-screen updates that cirrus currently implements.
This problem is indicated by the warning
drm_plane_enable_fb_damage_clips() not called
in the kernel's
When swapping in, or under memory pressure ttm_tt_populate() may sleep
for a substantiable amount of time. Allow interrupts during the sleep.
This will also allow us to inject -EINTR errors during swapin in upcoming
patches.
Also avoid returning VM_FAULT_OOM, since that will confuse the core
mm,
The DRM core implements a format check when setting a framebuffer
for a plane. [1] Remove the unnecessary test from cirrus_fb_create().
Signed-off-by: Thomas Zimmermann
Link:
https://elixir.bootlin.com/linux/v6.1/source/drivers/gpu/drm/drm_atomic.c#L629
# [1]
---
drivers/gpu/drm/tiny/cirrus.c
Move the primary plane's format and modifier arrays within the
source file and adapt naming slightly. No functional changes.
Done in preparation of converting cirrus to regular atomic helpers.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/cirrus.c | 28 ++--
Split cirrus_mode_set() into smaller functions that set the display
mode, color format and scnaline pitch individually. Better reflects
the design of the DRM modesetting pipeline.
Done in preparation of converting cirrus to regular atomic helpers.
Signed-off-by: Thomas Zimmermann
---
Integrate the connector with the rest of the pipeline setup code.
Move some helpers within the file and adapt naming slightly. No
functional changes.
Done in preparation of converting cirrus to regular atomic helpers.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/cirrus.c | 80
In the absence of free swap space, a shrinker could still efficiently
free memory the content of which is no longer needed, and graphics
drivers typically has an interface to mark buffer object content as
no longer needed.
Add a possibility to propagate this to TTM, so that the shrinker
Cirrus' blit helper reimplements code from the shared blit helper
drm_fb_blit(). Use the helper instead.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/cirrus.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/tiny/cirrus.c
Call drm_dev_enter() and drm_dev_exit() immediately after entering
cirrus' DRM helper functions. Remove these calls from other functions.
Each enter/exit block in the DRM helpers covers the full hardware
update. No functional changes.
Signed-off-by: Thomas Zimmermann
---
Using components per pixel to describe a color format is obsolete.
Use the format info and 4CC value instead.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/cirrus.c | 50 ++-
1 file changed, 26 insertions(+), 24 deletions(-)
diff --git
The calculation for the scanout-buffer blit offset is independent
from the color format. In the one case where the current code uses
fb->pitches[0] instead of cirrus->pitch, their values are identical.
Hence merge all into a single line.
Signed-off-by: Thomas Zimmermann
---
Update the cirrus driver to follow current best practices. While the
driver's hardware is obsolete, the cirrus driver is still one of the
go-to modules to learn about writing a DRM driver. So keep it in good
shape.
Patches 1 to 3 simplify blitting and convert it to the DRM's current
helpers.
Pinned bos aren't shinkable and needs to be removed from the shrinkable
accounting. Do that, and in the process constify the tt argument to
ttm_tt_is_populated.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/ttm/ttm_bo.c | 7 +++
drivers/gpu/drm/ttm/ttm_tt.c | 22
Since pages are not immediately freed by the TTM shrinker but rather
inserted into the swap cache, the system will keep on calling the
shrinker rapidly filling the swap cache which has a negative impact
on system performance.
When shrinking, throttle on the number of pages present in the swap
Register a TTM system memory-backed object shrinker and add
accounting for shrinkable and purgeable pages. For the shrinker to work,
the driver needs to register the bo_shrink callback which is responsible
for unbinding from GPU and the dma layer if needed. Helpers for that
callback to actually
When swapping out, we will split multi-order pages both in order to
move them to the swap-cache and to be able to return memory to the
swap cache as soon as possible on a page-by-page basis.
By reducing the page max order to the system PMD size, we can be nicer
to the system and avoid splitting
Clarify the meaning of the ttm_tt pages_limit watermarks as the max
number of pages not accessible by shrinkers, and update accordingly so that
memory allocated by TTM devices that support shrinking is not
accounted against those limits. In particular this means that devices
using the dma_alloc
Unexport ttm_global_swapout() since it is not used outside of TTM.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/ttm/ttm_device.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c
index 7eadea07027f..a3cac42bb456 100644
Update the TTM swapout interfaces for better compatibility with a shrinker.
- Replace number-of-pages int return with a long to better match the
kernel's shrinker interface.
- The gfp_flags parameter to ttm_xx_swapout() currently only takes the
GFP_KERNEL value and shouldn't really be needed
New code is recommended to use the BIT macro instead of the explicit
shifts. Change the older defines so that we can keep the style consistent
with upcoming changes.
Signed-off-by: Thomas Hellström
---
include/drm/ttm/ttm_tt.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
When hitting an error, the error path forgot to unmap dma mappings and
could call set_pages_wb() on already uncached pages.
Fix this by introducing a common __ttm_pool_free() function that
does the right thing.
Fixes: d099fc8f540a ("drm/ttm: new TT backend allocation pool v3")
Cc: Christian
The LRU mechanism may look up a resource in the process of being removed
from an object. The locking rules here are a bit unclear but it looks
currently like res->bo assignment is protected by the LRU lock, whereas
bo->resource is protected by the object lock, while *clearing* of
bo->resource is
This series introduces a TTM shrinker.
Currently the TTM subsystem allows a certain watermark fraction of
system memory to be pinned by GPUs. Any allocation beyond that will
cause TTM to attempt to copy memory to shmem objects for possible
later swapout so that that fraction is fulfilled. That
On 2/14/2023 4:08 AM, Jacek Lawrynowicz wrote:
Hi,
Thank you for the review.
On 06.02.2023 16:41, Jeffrey Hugo wrote:
The Qualcomm Cloud AI 100 (AIC100) device is an Artificial Intelligence
accelerator PCIe card. It contains a number of components both in the
SoC and on the card which
On Wed, 08 Feb 2023, Rodrigo Vivi wrote:
> On Wed, Feb 08, 2023 at 11:03:12AM -0800, Ashutosh Dixit wrote:
>> This reverts commit 0349c41b05968befaffa5fbb7e73d0ee6004f610.
>>
>> 0349c41b0596 ("drm/i915/hwmon: Enable PL1 power limit") is incorrect and
>> caused a major regression on ATSM. The
Am 15.02.23 um 14:52 schrieb Paul Cercueil:
Le mercredi 15 février 2023 à 14:46 +0100, Christian König a écrit :
Am 15.02.23 um 14:24 schrieb Paul Cercueil:
Hi Christian,
Le mercredi 15 février 2023 à 13:58 +0100, Christian König a
écrit :
Hi Paul,
Am 15.02.23 um 11:48 schrieb Paul
Le mercredi 15 février 2023 à 14:46 +0100, Christian König a écrit :
> Am 15.02.23 um 14:24 schrieb Paul Cercueil:
> > Hi Christian,
> >
> > Le mercredi 15 février 2023 à 13:58 +0100, Christian König a
> > écrit :
> > > Hi Paul,
> > >
> > > Am 15.02.23 um 11:48 schrieb Paul Cercueil:
> > > > Hi,
Am 15.02.23 um 14:24 schrieb Paul Cercueil:
Hi Christian,
Le mercredi 15 février 2023 à 13:58 +0100, Christian König a écrit :
Hi Paul,
Am 15.02.23 um 11:48 schrieb Paul Cercueil:
Hi,
I am working on adding support for DMABUFs in the IIO subsystem.
One thing we want there, is the ability
On Wed, 15 Feb 2023 12:42:00 +
Simon Ser wrote:
> There are two important details missing from the docs:
>
> - If the memory object backing the FB already has a GEM handle,
> it's not re-used, a new one is generated.
> - Aliased planes will return the same GEM handle.
>
> Signed-off-by:
Hi Christian,
Le mercredi 15 février 2023 à 13:58 +0100, Christian König a écrit :
> Hi Paul,
>
> Am 15.02.23 um 11:48 schrieb Paul Cercueil:
> > Hi,
> >
> > I am working on adding support for DMABUFs in the IIO subsystem.
> >
> > One thing we want there, is the ability to specify the number
On Sat, Dec 17, 2022 at 2:30 AM Liu Ying wrote:
> On Fri, 2022-12-16 at 22:07 +0100, Lucas Stach wrote:
> > Add a simple wrapper driver for the DWC HDMI bridge driver that
> > implements the few bits that are necessary to abstract the i.MX8MP
> > SoC integration.
> >
> > Signed-off-by: Lucas
Le mercredi 15 février 2023 à 13:13 +0100, Maarten Lankhorst a écrit :
>
> On 2023-02-15 13:00, Paul Cercueil wrote:
> > Hi Maarten,
> >
> > Le mercredi 15 février 2023 à 12:52 +0100, Maarten Lankhorst a
> > écrit :
> > > Hey,
> > >
> > > On 2023-02-15 12:47, Paul Cercueil wrote:
> > > > Hi
Hi Paul,
Am 15.02.23 um 11:48 schrieb Paul Cercueil:
Hi,
I am working on adding support for DMABUFs in the IIO subsystem.
One thing we want there, is the ability to specify the number of bytes
to transfer (while still defaulting to the DMABUF size).
Since dma_buf_map_attachment() returns a
There are two important details missing from the docs:
- If the memory object backing the FB already has a GEM handle,
it's not re-used, a new one is generated.
- Aliased planes will return the same GEM handle.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Pekka Paalanen
---
On 15/02/2023 01:56, Ceraolo Spurio, Daniele wrote:
On 2/14/2023 3:48 PM, john.c.harri...@intel.com wrote:
From: John Harrison
Direction from hardware is that stolen memory should never be used for
ring buffer allocations. There are too many caching pitfalls due to the
way stolen memory
1 - 100 of 124 matches
Mail list logo
