Am 11.10.21 um 21:06 schrieb Nirmoy Das:
For debugfs directory, it is recommended to save the result
and pass over to next debugfs API for creating debugfs
files/directories. Error conditions are handled by debugfs APIs.
CC: Christian Koenig
CC: Huang Rui
CC: David Airlie
CC: Daniel Vetter
On 23/09/2021 10:06, Neil Armstrong wrote:
This patchset is the follow-up the v4 patchset from Benoit Parrot at [1].
This patch series adds virtual-plane support to omapdrm driver to allow the use
of display wider than 2048 pixels.
In order to do so we introduce the concept of hw_overlay which
Hi,
On 23/09/2021 10:06, Neil Armstrong wrote:
From: Benoit Parrot
We currently assume that an overlay has the same maximum width and
maximum height as the overlay manager. This assumption is incorrect. On
some variants the overlay manager maximum width is twice the maximum
width that the over
On Mon, Oct 11, 2021 at 12:51 AM Jagan Teki wrote:
>
> Hi Dave,
>
> On Fri, Oct 8, 2021 at 9:32 PM Dave Stevenson
> wrote:
> >
> > On Fri, 8 Oct 2021 at 14:37, Laurent Pinchart
> > wrote:
> > >
> > > Hello,
> > >
> > > On Fri, Oct 08, 2021 at 03:27:43PM +0200, Andrzej Hajda wrote:
> > > > Hi,
>
On Sun, 10 Oct 2021, Maíra Canal wrote:
> As requested in GPU Driver Developers Guide TODO list, replaces all
> drm_lock boilerplates for DRM_MODESET_LOCK_ALL_* helpers.
Please see [1].
Also, all i915 patches must be Cc'd to intel-gfx mailing list. Please
see MAINTAINERS file.
BR,
Jani.
[1]
On 2021-10-11 15:41, Guido Günther wrote:
> media-bus-formats.h has them in hexadecimal as well so matching with
> that file saves one conversion when debugging.
>
> Signed-off-by: Guido Günther
> Reviewed-by: Lucas Stach
> Reviewed-by: Robert Foss
Acked-by: Stefan Agner
> ---
> drivers/gpu
On 2021-10-11 15:41, Guido Günther wrote:
> If a bridge doesn't do any bus format handling MEDIA_BUS_FMT_FIXED is
> returned. Fallback to a reasonable default (MEDIA_BUS_FMT_RGB888_1X24) in
> that case.
>
> This unbreaks e.g. using mxsfb with the nwl bridge and mipi dsi panels.
>
> Reported-by: M
On 04/10/2021 23:06, Matthew Brost wrote:
Parallel submission create composite fences (dma_fence_array) for excl /
shared slots in objects. The I915_GEM_BUSY IOCTL checks these slots to
determine the busyness of the object. Prior to patch it only check if
the fence in the slot was a i915_reques
On 23/09/2021 10:06, Neil Armstrong wrote:
From: Benoit Parrot
Split out the hardware overlay specifics from omap_plane.
To start, the hw overlays are statically assigned to planes.
The goal is to eventually assign hw overlays dynamically to planes
during plane->atomic_check() based on request
On 23/09/2021 10:06, Neil Armstrong wrote:
From: Benoit Parrot
In preparation to add omap plane state specific extensions we need to
subclass drm_plane_state and add the relevant helpers.
The addition of specific extension will be done separately.
Signed-off-by: Benoit Parrot
Signed-off-by:
On 11/10/2021 21:08, Umesh Nerlige Ramappa wrote:
On Mon, Oct 11, 2021 at 12:41:19PM +0100, Tvrtko Ursulin wrote:
On 07/10/2021 23:55, Umesh Nerlige Ramappa wrote:
With GuC handling scheduling, i915 is not aware of the time that a
context is scheduled in and out of the engine. Since i915 pmu
Am 11.10.21 um 14:04 schrieb Thomas Hellström:
[SNIP]
Hmm, this looks very odd, because I remember reminding Christian as
late as this spring that both vmwgfx and i915 sets up GPU bindings
to
system buffers, as part of the review of a patch series pushing a
couple of changes to the swapout path
On 12/10/2021 09:15, Tomi Valkeinen wrote:
> On 23/09/2021 10:06, Neil Armstrong wrote:
>> This patchset is the follow-up the v4 patchset from Benoit Parrot at [1].
>>
>> This patch series adds virtual-plane support to omapdrm driver to allow the
>> use
>> of display wider than 2048 pixels.
>>
>>
On 10/11/21 19:08, Marco Elver wrote:
> On Mon, 11 Oct 2021 at 19:02, Vlastimil Babka wrote:
> [...]
>> > On the other hand, the lazy initialization mode you're introducing
>> > requires an explicit stack_depot_init() call somewhere and isn't as
>> > straightforward as before.
>> >
>> > Not sure w
On 12/10/2021 09:21, Tomi Valkeinen wrote:
> Hi,
>
> On 23/09/2021 10:06, Neil Armstrong wrote:
>> From: Benoit Parrot
>>
>> We currently assume that an overlay has the same maximum width and
>> maximum height as the overlay manager. This assumption is incorrect. On
>> some variants the overlay m
From: Guangming Cao
> Am 09.10.21 um 07:55 schrieb guangming@mediatek.com:
> From: Guangming Cao
> >
> > If dma-buf don't want userspace users to touch the dmabuf buffer,
> > it seems we should add this restriction into dma_buf_ops.mmap,
> > not in this IOCTL:DMA_BUF_SET_NAME.
> >
> > With t
Hi Alexander,
Thank you for the patch.
On Tue, Oct 12, 2021 at 08:48:43AM +0200, Alexander Stein wrote:
> VCC needs to be enabled before releasing the enable GPIO.
>
> Reviewed-by: Sam Ravnborg
> Signed-off-by: Alexander Stein
> ---
> drivers/gpu/drm/bridge/ti-sn65dsi83.c | 15 ++-
On 12/10/2021 09:59, Tomi Valkeinen wrote:
> On 23/09/2021 10:06, Neil Armstrong wrote:
>> From: Benoit Parrot
>>
>> Split out the hardware overlay specifics from omap_plane.
>> To start, the hw overlays are statically assigned to planes.
>>
>> The goal is to eventually assign hw overlays dynamica
On 10/12/2021 9:09 AM, Christian König wrote:
Am 11.10.21 um 21:06 schrieb Nirmoy Das:
For debugfs directory, it is recommended to save the result
and pass over to next debugfs API for creating debugfs
files/directories. Error conditions are handled by debugfs APIs.
CC: Christian Koenig
CC:
On 12/10/2021 10:13, Tomi Valkeinen wrote:
> On 23/09/2021 10:06, Neil Armstrong wrote:
>> From: Benoit Parrot
>>
>> In preparation to add omap plane state specific extensions we need to
>> subclass drm_plane_state and add the relevant helpers.
>>
>> The addition of specific extension will be done
On 10/12/2021 8:48 AM, Lukas Wunner wrote:
On Mon, Oct 11, 2021 at 10:24:29PM +0200, Lukas Wunner wrote:
On Mon, Oct 11, 2021 at 09:06:07PM +0200, Nirmoy Das wrote:
Debugfs APIs returns encoded error on failure so use
debugfs_lookup() instead of checking for NULL.
[...]
--- a/drivers/gpu/vg
From: Guangming Cao
> Am 08.10.21 um 09:54 schrieb guangming@mediatek.com:
> > From: Guangming Cao
> >
> > Because dma-buf.name can be freed in func: "dma_buf_set_name",
> > so, we need to acquire lock first before we read/write dma_buf.name
> > to prevent Use After Free(UAF) issue.
> >
> >
Currently, enabling CONFIG_STACKDEPOT means its stack_table will be allocated
from memblock, even if stack depot ends up not actually used. The default size
of stack_table is 4MB on 32-bit, 8MB on 64-bit.
This is fine for use-cases such as KASAN which is also a config option and
has overhead on it
On Tue, 2021-10-12 at 10:27 +0200, Christian König wrote:
> Am 11.10.21 um 14:04 schrieb Thomas Hellström:
> > [SNIP]
> > > > Hmm, this looks very odd, because I remember reminding
> > > > Christian as
> > > > late as this spring that both vmwgfx and i915 sets up GPU
> > > > bindings
> > > > to
> >
On Tue, 12 Oct 2021 at 11:06, Vlastimil Babka wrote:
> Currently, enabling CONFIG_STACKDEPOT means its stack_table will be allocated
> from memblock, even if stack depot ends up not actually used. The default size
> of stack_table is 4MB on 32-bit, 8MB on 64-bit.
>
> This is fine for use-cases suc
On 10/8/21 9:17 AM, Nirmoy Das wrote:
> Return early if dri minor root dentry is NULL.
>
> CC: Zhenyu Wang
> CC: Zhi Wang
> CC: Jani Nikula
> CC: Joonas Lahtinen
> CC: Rodrigo Vivi
> CC: David Airlie
> CC: Daniel Vetter
> Signed-off-by: Nirmoy Das
> ---
> drivers/gpu/drm/i915/gvt/debugfs
On 10/3/21 5:23 AM, Randy Dunlap wrote:
> Fix kernel-doc warnings in gtt.c:
>
> gtt.c:1152: warning: This comment starts with '/**', but isn't a kernel-doc
> comment. Refer Documentation/doc-guide/kernel-doc.rst
> * Check if can do 2M page
> gtt.c:1152: warning: missing initial short descriptio
Hi Zhi,
Please discard this patch, review
https://patchwork.freedesktop.org/patch/458554/?series=95690&rev=1 instead.
minor->debugfs_root wont be NULl as we save debugfs_create_dir()'s return value
in that.
Regards,
Nirmoy
On 10/12/2021 11:59 AM, Wang, Zhi A wrote:
On 10/8/21 9:17 AM, Ni
Hi Sam,
On Mon, Oct 11, 2021 at 06:56:00PM +0200, Sam Ravnborg wrote:
> Hi Guido,
>
> On Mon, Oct 11, 2021 at 03:41:22PM +0200, Guido Günther wrote:
> > commit b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest bridge if
> > present") added bus format probing to mxsfb this exposed several
On Tue, 7 Sep 2021 03:08:43 +0530
Uma Shankar wrote:
> This is a RFC proposal for plane color hardware blocks.
> It exposes the property interface to userspace and calls
> out the details or interfaces created and the intended
> purpose.
>
> Credits: Ville Syrjälä
> Signed-off-by: Uma Shankar
On Tuesday, October 12th, 2021 at 12:30, Pekka Paalanen
wrote:
> is there a practise of landing proposal documents in the kernel? How
> does that work, will a kernel tree carry the patch files?
> Or should this document be worded like documentation for an accepted
> feature, and then the patches
On 12/10/2021 11:30, Neil Armstrong wrote:
On 12/10/2021 09:15, Tomi Valkeinen wrote:
On 23/09/2021 10:06, Neil Armstrong wrote:
This patchset is the follow-up the v4 patchset from Benoit Parrot at [1].
This patch series adds virtual-plane support to omapdrm driver to allow the use
of display
Hi all,
In commit
654e9c18dfab ("drm/msm: Fix crash on dev file close")
Fixes tag
Fixes: 86c2a0f000c1 drm/msm: ("Small submitqueue creation cleanup")
has these problem(s):
- Subject does not match target commit subject
Just use
git log -1 --format='Fixes: %h ("%s")'
--
Che
On 23/09/2021 10:06, Neil Armstrong wrote:
From: Benoit Parrot
Global shared resources (like hw overlays) for omapdrm are implemented
as a part of atomic state using the drm_private_obj infrastructure
available in the atomic core.
omap_global_state is introduced as a drm atomic private object.
e' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Jessica-Zhang/drm-msm-dpu-Add-CRC-support-for-DPU/20211012-074357
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
64570fbc14f8d7cb3fe3995f20e26bc25ce4b2cc
c
uhh, that's on me. I will send out a patch today. I just noticed that
the config file I used for testing had WERROR disabled.
On Tue, Oct 12, 2021 at 4:18 AM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
On 12/10/2021 2:28, Jason Gunthorpe wrote:
> On Sun, Oct 10, 2021 at 09:55:49AM +0300, Gal Pressman wrote:
>> On 07/10/2021 14:40, Jason Gunthorpe wrote:
>>> On Thu, Oct 07, 2021 at 01:43:00PM +0300, Gal Pressman wrote:
>>>
@@ -1491,26 +1493,29 @@ static int efa_create_pbl(struct efa_dev *dev,
On Tue, 7 Sep 2021 03:08:45 +0530
Uma Shankar wrote:
> Add Plane Degamma Mode as an enum property. Create a helper
> function for all plane color management features.
>
> This is an enum property with values as blob_id's and exposes
> the various gamma modes supported and the lut ranges. Gettin
On Tue, 7 Sep 2021 03:08:42 +0530
Uma Shankar wrote:
> This is how a typical display color hardware pipeline looks like:
> +---+
> |RAM|
> | +--++-++-+ |
> | | FB 1 || FB 2
On Tue, 12 Oct 2021 10:35:37 +
Simon Ser wrote:
> On Tuesday, October 12th, 2021 at 12:30, Pekka Paalanen
> wrote:
>
> > is there a practise of landing proposal documents in the kernel? How
> > does that work, will a kernel tree carry the patch files?
> > Or should this document be worded
Hey all,
This is a followup to my previous RFCs [1][2], which now adds a new api
to the RDMA subsystem that allows drivers to get a pinned dmabuf memory
region without requiring an implementation of the move_notify callback.
The new api makes use of the dynamic attachment api implemented in the
RD
The pin callback does not necessarily have to move the memory to system
memory, remove the sentence from the comment.
Signed-off-by: Gal Pressman
---
include/linux/dma-buf.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
Introduce ib_umem_dmabuf_get_pinned() which allows the driver to get a
dmabuf umem which is pinned and does not require move_notify
callback implementation.
The returned umem is pinned and DMA mapped like standard cpu umems, and
is released through ib_umem_release() (incl. unpinning and unmapping).
Fix the following build/link error by adding a dependency on the CRC32
routines:
ld: drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.o: in function
`lcd_olinuxino_probe':
panel-olimex-lcd-olinuxino.c:(.text+0x303): undefined reference to `crc32_le'
Fixes: 17fd7a9d324fd ("drm/panel: Add supp
Hi Thierry,
I tried sending the patch below to Stefan Mavrodiev
(listed in MAINTAINERS for DRM DRIVER FOR OLIMEX LCD-OLINUXINO PANELS)
but it bounced with "No such user at that domain".
Will you take the patch and/or update the MAINTAINERS entry?
Thanks,
Vegard
On 10/12/21 1:52 PM, Vegard No
Hi,
On 12/10/2021 12:44, Tomi Valkeinen wrote:
> On 23/09/2021 10:06, Neil Armstrong wrote:
>> From: Benoit Parrot
>>
>> Global shared resources (like hw overlays) for omapdrm are implemented
>> as a part of atomic state using the drm_private_obj infrastructure
>> available in the atomic core.
>>
From: Colin Ian King
The assignment of pointer backup_bo dereferences pointer backup before
backup is null checked, this could lead to a null pointer dereference
issue. Fix this by only assigning backup_bo after backup has been null
checked.
Addresses-Coverity: ("Dereference before null check")
Hi,
On 12/10/2021 12:36, Tomi Valkeinen wrote:
> On 12/10/2021 11:30, Neil Armstrong wrote:
>> On 12/10/2021 09:15, Tomi Valkeinen wrote:
>>> On 23/09/2021 10:06, Neil Armstrong wrote:
This patchset is the follow-up the v4 patchset from Benoit Parrot at [1].
This patch series adds v
Fixes a compilation issue introduced because I forgot to test with WERROR
enabled.
Cc: Stephen Rothwell
Cc: DRI
Cc: nouv...@lists.freedesktop.org
Fixes: 404046cf4805 ("drm/nouveau/mmu/gp100-: drop unneeded assignment in the
if condition.")
Signed-off-by: Karol Herbst
---
drivers/gpu/drm/nouve
On 23/09/2021 10:06, Neil Armstrong wrote:
From: Benoit Parrot
(re)assign the hw overlays to planes based on required caps, and to
handle situations where we could not modify an in-use plane.
This means all planes advertise the superset of formats and properties.
Userspace must (as always) use
On 12/10/2021 16:23, Neil Armstrong wrote:
+ struct drm_private_obj glob_obj;
+
struct drm_fb_helper *fbdev;
struct workqueue_struct *wq;
@@ -88,5 +105,9 @@ struct omap_drm_private {
void omap_debugfs_init(struct drm_minor *minor);
+struct omap_global_state *__must_chec
From: Tomi Valkeinen
DSS5's maximum tv pclk rate (i.e. HDMI) is set to 186MHz, which comes
from the TRM (DPLL_HDMI_CLK1 frequency must be lower than 186 MHz). To
support DRA76's wide screen HDMI feature, we need to increase this
maximum rate.
Testing shows that the PLL seems to work fine even wi
On Tue, Oct 5, 2021 at 10:11 AM Thomas Zimmermann wrote:
>
> Allocation and pinning helpers for struct gtt_range are GEM functions,
> so move them to gem.c. No functional changes.
>
> v2:
> * keep docs for psb_gtt_{attach,detach}_pages() (Patrik)
>
Bonus point for getting rid of psb_gtt_k
On Tue, Oct 5, 2021 at 10:11 AM Thomas Zimmermann wrote:
>
> psb_gtt_attach_pages() are not GTT functions but deal with the GEM
> object's SHMEM pages. The only callers of psb_gtt_attach_pages() and
> psb_gtt_detach_pages() are the GEM pin helpers. Inline the calls and
> cleanup the resulting code
Hi
I've a question about expected behavior. I am using the "vc4" backend.
If I convert a dmabuf fd to a bo handle twice using
DRM_IOCTL_PRIME_FD_TO_HANDLE then I get the same bo handle both times -
fair enough.
If I then close it twice with DRM_IOCTL_GEM_CLOSE then the second time
fails.
Is thi
On Tue, Oct 5, 2021 at 10:11 AM Thomas Zimmermann wrote:
>
> psb_gtt_alloc_range() allocates struct gtt_range, create the GTT resource
> and performs some half-baked initialization. Inline the function into its
> only caller psb_gem_create(). For creating the GTT resource, introduce a
> new helper
On Tue, Oct 5, 2021 at 10:11 AM Thomas Zimmermann wrote:
>
> Caching of the GEM object's backing pages are unrelated to GTT
> management. Move the respective calls from GTT code to GEM code.
>
I gave suspend/resume a try and it seems fine so
Acked-by: Patrik Jakobsson
> Signed-off-by: Thomas Z
On Tue, Oct 5, 2021 at 10:11 AM Thomas Zimmermann wrote:
>
> struct gtt_range represents a GEM object and should not be used for GTT
> setup. Change psb_gtt_insert() and psb_gtt_remove() to receive all
> necessary parameters from their caller. This also eliminates possible
> failure from psb_gtt_i
On 2021-10-10 16:59, Christophe JAILLET wrote:
'destroy_workqueue()' already drains the queue before destroying it, so
there is no need to flush it explicitly.
Remove the redundant 'flush_workqueue()' calls.
This was generated with coccinelle:
@@
expression E;
@@
- flush_workqueue(E);
Hi Yunfei Dong,
W dniu 11.10.2021 o 09:02, Yunfei Dong pisze:
This series adds support for multi hardware decode into mtk-vcodec, by first
adding use of_platform_populate to manage each hardware information: interrupt,
clock, register bases and power. Secondly add core thread to deal with core
h
The link training delays are different and/or available in different
DPCD offsets depending on:
- Clock recovery vs. channel equalization
- DPRX vs. LTTPR
- 128b/132b vs. 8b/10b
- DPCD 1.4+ vs. earlier
Add helpers to get the correct delays in us, reading DPCD if
necessary. This is more straightfo
Use the new link training delay helpers, fixing the delays for
128b/132b.
For existing 8b/10b functionality, this will cause additional 1-byte
DPCD reads for LTTPR delays instead of using the cached values. It's
just too complicated to combine generic helpers with local caching in a
sensible way.
On 12/10/2021 15:34, Tomi Valkeinen wrote:
> On 23/09/2021 10:06, Neil Armstrong wrote:
>> From: Benoit Parrot
>>
>> (re)assign the hw overlays to planes based on required caps, and to
>> handle situations where we could not modify an in-use plane.
>>
>> This means all planes advertise the superse
Hi,
On 10/12/21 15:25, Colin King wrote:
From: Colin Ian King
The assignment of pointer backup_bo dereferences pointer backup before
backup is null checked, this could lead to a null pointer dereference
issue. Fix this by only assigning backup_bo after backup has been null
checked.
Addresses-
On Tue, Oct 12, 2021 at 04:47:24PM +0200, Thomas Hellström wrote:
> Hi,
>
> On 10/12/21 15:25, Colin King wrote:
> > From: Colin Ian King
> >
> > The assignment of pointer backup_bo dereferences pointer backup before
> > backup is null checked, this could lead to a null pointer dereference
> > i
On 11.10.2021 20:00, Matthew Brost wrote:
> On Mon, Oct 11, 2021 at 08:51:06PM +0530, Thanneeru Srinivasulu wrote:
>> Inject probe errors -ENXIO, -EBUSY for CT send.
>>
>> Signed-off-by: Thanneeru Srinivasulu
>> ---
>> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 8
>> 1 file changed,
Up to now s6e63m0_remove() returns zero unconditionally. Make it return
void instead which makes it easier to see in the callers that there is
no error to handle.
Also the return value of spi remove callbacks is ignored anyway.
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/panel/panel-sam
fbtft_remove_common() is only called with a non-NULL fb_info. (All
callers are in remove callbacks and the matching probe callbacks set
driver data accordingly.) So fbtft_remove_common() always returns zero.
Make it return void instead which makes it easier to see in the callers
that there is no er
Hello,
this is v2 of my quest to make spi remove callbacks return void. Today
they return an int, but the only result of returning a non-zero value is
a warning message. So it's a bad idea to return an error code in the
expectation that not freeing some resources is ok then. The same holds
true fo
On 12/10/2021 15:38, Tomi Valkeinen wrote:
> On 12/10/2021 16:23, Neil Armstrong wrote:
>
+ struct drm_private_obj glob_obj;
+
struct drm_fb_helper *fbdev;
struct workqueue_struct *wq;
@@ -88,5 +105,9 @@ struct omap_drm_private {
void omap_de
On Tue, Oct 12, 2021 at 6:40 PM Uwe Kleine-König
wrote:
>
> fbtft_remove_common() is only called with a non-NULL fb_info. (All
> callers are in remove callbacks and the matching probe callbacks set
> driver data accordingly.) So fbtft_remove_common() always returns zero.
> Make it return void inst
On Sun, Oct 10, 2021 at 7:07 AM Christophe JAILLET
wrote:
>
> 'destroy_workqueue()' already drains the queue before destroying it, so
> there is no need to flush it explicitly.
>
> Remove the redundant 'flush_workqueue()' calls.
>
> This was generated with coccinelle:
>
> @@
> expression E;
> @@
>
On Mon, 11 Oct 2021, Matthew Brost wrote:
> On Mon, Oct 11, 2021 at 08:51:03PM +0530, Thanneeru Srinivasulu wrote:
>> Replace DRM_ERROR with CT_PROBE_ERROR to report early CTB failures.
>>
>> Signed-off-by: Thanneeru Srinivasulu
>
> Reviewed-by: Matthew Brost
>
>> ---
>> drivers/gpu/drm/i915/g
On Tue, 12 Oct 2021, Jani Nikula wrote:
> On Mon, 11 Oct 2021, Matthew Brost wrote:
>> On Mon, Oct 11, 2021 at 08:51:03PM +0530, Thanneeru Srinivasulu wrote:
>>> Replace DRM_ERROR with CT_PROBE_ERROR to report early CTB failures.
>>>
>>> Signed-off-by: Thanneeru Srinivasulu
>>
>> Reviewed-by: M
On 12.10.2021 18:16, Jani Nikula wrote:
> On Mon, 11 Oct 2021, Matthew Brost wrote:
>> On Mon, Oct 11, 2021 at 08:51:03PM +0530, Thanneeru Srinivasulu wrote:
>>> Replace DRM_ERROR with CT_PROBE_ERROR to report early CTB failures.
>>>
>>> Signed-off-by: Thanneeru Srinivasulu
>>
>> Reviewed-by:
This patch series introduces MEMORY_DEVICE_COHERENT, a type of memory
owned by a device that can be mapped into CPU page tables like
MEMORY_DEVICE_GENERIC and can also be migrated like MEMORY_DEVICE_PRIVATE.
With MEMORY_DEVICE_COHERENT, we isolate the new memory type from other
subsystems as far as
From: Ralph Campbell
There are several places where ZONE_DEVICE struct pages assume a reference
count == 1 means the page is idle and free. Instead of open coding this,
add a helper function to hide this detail.
Signed-off-by: Ralph Campbell
Signed-off-by: Alex Sierra
Reviewed-by: Christoph He
From: Ralph Campbell
ZONE_DEVICE struct pages have an extra reference count that complicates the
code for put_page() and several places in the kernel that need to check the
reference count to see that a page is not being used (gup, compaction,
migration, etc.). Clean up the code so the reference
This case is used to migrate pages from device memory, back to system
memory. Device coherent type memory is cache coherent from device and CPU
point of view.
Signed-off-by: Alex Sierra
---
v2:
condition added when migrations from device coherent pages.
---
include/linux/migrate.h | 1 +
mm/migr
When CPU is connected throug XGMI, it has coherent
access to VRAM resource. In this case that resource
is taken from a table in the device gmc aperture base.
This resource is used along with the device type, which could
be DEVICE_PRIVATE or DEVICE_COHERENT to create the device
page map region.
Sig
Device memory that is cache coherent from device and CPU point of view.
This is use on platform that have an advance system bus (like CAPI or
CCIX). Any page of a process can be migrated to such memory. However,
no one should be allow to pin such memory so that it can always be
evicted.
Signed-off
Coherent device type memory on VRAM to RAM migration, has similar access
as System RAM from the CPU. This flag sets the source from the sender.
Which in Coherent type case, should be set as
MIGRATE_VMA_SELECT_DEVICE_COHERENT.
Signed-off-by: Alex Sierra
Reviewed-by: Felix Kuehling
---
drivers/gp
new ioctl cmd added to query zone device type. This will be
used once the test_hmm adds zone device coherent type.
Signed-off-by: Alex Sierra
---
lib/test_hmm.c | 15 ++-
lib/test_hmm_uapi.h | 7 +++
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/lib/test_hm
In order to configure device coherent in test_hmm, two module parameters
should be passed, which correspond to the SP start address of each
device (2) spm_addr_dev0 & spm_addr_dev1. If no parameters are passed,
private device type is configured.
Signed-off-by: Alex Sierra
---
lib/test_hmm.c
Ref counter from device pages is init to zero during memmap init zone.
The first time a new device page is allocated to migrate data into it,
its ref counter needs to be initialized to one.
Signed-off-by: Alex Sierra
---
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 3 ++-
1 file changed, 2 inserti
Device Coherent type uses device memory that is coherently accesible by
the CPU. This could be shown as SP (special purpose) memory range
at the BIOS-e820 memory enumeration. If no SP memory is supported in
system, this could be faked by setting CONFIG_EFI_FAKE_MEMMAP.
Currently, test_hmm only sup
Add two more parameters to set spm_addr_dev0 & spm_addr_dev1
addresses. These two parameters configure the start SP
addresses for each device in test_hmm driver.
Consequently, this configures zone device type as coherent.
Signed-off-by: Alex Sierra
---
tools/testing/selftests/vm/test_hmm.sh | 20
Test cases such as migrate_fault and migrate_multiple,
were modified to explicit migrate from device to sys memory
without the need of page faults, when using device coherent
type.
Snapshot test case updated to read memory device type
first and based on that, get the proper returned results
migrat
Quoting Marijn Suijten (2021-10-11 13:16:40)
> div_u64_rem provides the result of the division and additionally the
> remainder; don't use this function to solely calculate the remainder
> while calculating the division again with div_u64.
>
> A similar improvement was applied earlier to the 10nm p
Yes, this is expected behavior, even if it's not intuitive. For more
details, see:
https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/110
On Tue, 2021-10-12 at 11:10 +0200, Thomas Hellström wrote:
> On Tue, 2021-10-12 at 10:27 +0200, Christian König wrote:
> > Am 11.10.21 um 14:04 schrieb Thomas Hellström:
> >
> > > >
>
> > > So now if this is going to be changed, I think we need to
> > > understand
> > > why and think this throug
Quoting Bjorn Andersson (2021-10-09 20:04:35)
> The debugfs code is provided an array of a single drm_connector. Then to
> access the connector, the list of all connectors of the DRM device is
> traversed and all non-DisplayPort connectors are skipped, to find the
> one and only DisplayPort connect
From: Rafael J. Wysocki
The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION()
macro and the ACPI handle produced by the former comes from the
ACPI device object produced by the latter, so it is way more
straightforward to evaluate the latter directly instead of passing
the handle produc
Taking a PM reference to prevent intel_gt_wait_for_idle from short
circuiting while a deregister context H2G is in flight. To do this must
issue the deregister H2G from a worker as context can be destroyed from
an atomic context and taking GT PM ref blows up. Previously we took a
runtime PM from th
On Tue, Oct 12, 2021 at 08:53:25AM +0100, Tvrtko Ursulin wrote:
>
> On 04/10/2021 23:06, Matthew Brost wrote:
> > Parallel submission create composite fences (dma_fence_array) for excl /
> > shared slots in objects. The I915_GEM_BUSY IOCTL checks these slots to
> > determine the busyness of the ob
On Tue, 12 Oct 2021 17:33:18 +, you wrote:
>Yes, this is expected behavior, even if it's not intuitive. For more
>details, see:
>
>https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/110
Thanks - as noted in that discussion the behaviour is a bit unhelpful
but just knowing that it is exp
On Tue, 12 Oct 2021 12:12:35 -0500 Alex Sierra wrote:
> This patch series introduces MEMORY_DEVICE_COHERENT, a type of memory
> owned by a device that can be mapped into CPU page tables like
> MEMORY_DEVICE_GENERIC and can also be migrated like MEMORY_DEVICE_PRIVATE.
> With MEMORY_DEVICE_COHERENT
On Tue, Oct 12, 2021 at 11:39:57AM -0700, Andrew Morton wrote:
> On Tue, 12 Oct 2021 12:12:35 -0500 Alex Sierra wrote:
>
> > This patch series introduces MEMORY_DEVICE_COHERENT, a type of memory
> > owned by a device that can be mapped into CPU page tables like
> > MEMORY_DEVICE_GENERIC and can a
On 10/8/21 19:31, Zack Rusin wrote:
For larger (bigger than a page) and noncontiguous mobs we have
to create page tables that allow the host to find the memory.
Those page tables just used regular system memory. Unfortunately
in TTM those BO's are not allowed to be busy thus can't be
fenced and
Am 2021-10-12 um 2:39 p.m. schrieb Andrew Morton:
> On Tue, 12 Oct 2021 12:12:35 -0500 Alex Sierra wrote:
>
>> This patch series introduces MEMORY_DEVICE_COHERENT, a type of memory
>> owned by a device that can be mapped into CPU page tables like
>> MEMORY_DEVICE_GENERIC and can also be migrated l
1 - 100 of 157 matches
Mail list logo
