From: Sebastian Reichel
The Lenovo Thinkpad T14s Gen6 Snapdragon is currently sold with three
different panel versions: OLED, Low Power IPS or IPS with Touchscreen.
My Low Power IPS version had this panel and the kernel complained
about not knowing any details. I don't have any panel documentat
Add a compatible string for MediaTek MT8196 SoC
Signed-off-by: Sunny Shen
---
.../devicetree/bindings/display/mediatek/mediatek,postmask.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml
b/Documentation/devicetre
Due to the path mux design of the MT8196, the following components
need to be added to support Picture Quality (PQ) in the main display
path: CCORR0, CCORR1, DITHER0, GAMMA0, MDP_RSZ0, POSTMASK0, TDSHP0.
Signed-off-by: Sunny Shen
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 7 +++
1 file cha
Due to the path mux design of the MT8196, the following components
need to be configured into mutex and mmsys to support
Picture Quality (PQ) in the display path:CCORR0, CCORR1, DITHER0,
GAMMA0, MDP_RSZ0, POSTMASK0, TDSHP0.
Signed-off-by: Sunny Shen
---
drivers/soc/mediatek/mt8196-mmsys.h| 7
Due to the path mux design of the MT8196, the following components need to be
configured to support Picture Quality (PQ) in the display path:CCORR0, CCORR1,
DITHER0, GAMMA0, MDP_RSZ0, POSTMASK0, TDSHP0.
This patch series is based on [1]
[1] Add Mediatek Soc DRM Soc support for mt8196
- https
Add MDP-RSZ component support for MT8196.
Signed-off-by: Sunny Shen
---
drivers/gpu/drm/mediatek/mtk_ddp_comp.c | 24
drivers/gpu/drm/mediatek/mtk_ddp_comp.h | 1 +
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 ++
3 files changed, 27 insertions(+)
diff --git a/drivers/
Add MDP-RSZ hardware description for MediaTek MT8196 SoC
Signed-off-by: Sunny Shen
---
.../display/mediatek/mediatek,mdp-rsz.yaml| 46 +++
1 file changed, 46 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rsz.yaml
diff --gi
On Mon, 10 Feb 2025 14:26:16 +0100, Herve Codina wrote:
> Both the TI SN65DSI83 and SN65DSI84 bridges have an IRQ pin to signal
> errors using interrupt.
>
> This interrupt is not documented in the binding.
>
>
> [ ... ]
Reviewed-by: Maxime Ripard
Thanks!
Maxime
DRM clients expose information through usage stats as documented in
Documentation/gpu/drm-usage-stats.rst (available online at
https://docs.kernel.org/gpu/drm-usage-stats.html). Add a tool like
PMU, similar to the hwmon PMU, that exposes DRM information. For
example on a tigerlake laptop:
```
$ per
On Mon, 10 Feb 2025 20:37:57 +0100 David Hildenbrand wrote:
> Ever since commit b756a3b5e7ea ("mm: device exclusive memory access")
> we can return with a device-exclusive entry from page_vma_mapped_walk().
>
> damon_folio_mkold_one() is not prepared for that and calls
> damon_ptep_mkold() with
On Mon, 10 Feb 2025 20:37:56 +0100 David Hildenbrand wrote:
> Ever since commit b756a3b5e7ea ("mm: device exclusive memory access")
> we can return with a device-exclusive entry from page_vma_mapped_walk().
>
> damon_folio_young_one() is not prepared for that, so teach it about these
> PFN swap
On Mon, Feb 10, 2025 at 10:49:53PM +0800, Yongbang Shi wrote:
From: Baihan Li
This serdes is inited and configured for dp, and integrating them into dp
init and dp link training process.
For rate changing, we can change from 1.62-8.2Gpbs by cfg reg.
For voltage and pre-emphasis levels changi
On 30-01-2025 03:21, Rodrigo Vivi wrote:
On Wed, Jan 01, 2025 at 05:39:21PM +0200, Alexander Usyskin wrote:
Enable runtime PM in mtd driver to notify graphics driver that
whole card should be kept awake while nvm operations are
performed through this driver.
CC: Lucas De Marchi
Acked-by: Miq
On Mon, 10 Feb 2025 20:37:45 +0100 David Hildenbrand wrote:
> The single "real" user in the tree of make_device_exclusive_range() always
> requests making only a single address exclusive. The current implementation
> is hard to fix for properly supporting anonymous THP / large folios and
> for av
From: Saurabh Singh Sengar Sent: Monday, February
10, 2025 8:52 AM
>
> On Mon, Feb 10, 2025 at 06:58:25AM -0800, Saurabh Singh Sengar wrote:
> > On Mon, Feb 10, 2025 at 02:28:35PM +, Michael Kelley wrote:
> > > From: Saurabh Singh Sengar Sent: Monday,
> > > February 10, 2025 4:41 AM
> > >
On Tue, Feb 11, 2025 at 12:19:32AM +0100, Marijn Suijten wrote:
> What used to be the input_10_bits boolean - feeding into the lowest
> bit of DSC_ENC - on MSM downstream turned into an accidental OR with
> the full bits_per_component number when it was ported to the upstream
> kernel.
>
> On typi
From: Saurabh Singh Sengar Sent: Monday, February
10, 2025 7:33 PM
>
> On Mon, Feb 10, 2025 at 11:34:41AM -0800, mhkelle...@gmail.com wrote:
> > From: Michael Kelley
> >
> > When a Hyper-V DRM device is probed, the driver allocates MMIO space for
> > the vram, and maps it cacheable. If the devi
On Sun, Feb 09, 2025 at 10:42:52PM +0100, Marijn Suijten wrote:
> When configuring the timing of DSI hosts (interfaces) in
> dsi_timing_setup() all values written to registers are taking
> bonded-mode into account by dividing the original mode width by 2
> (half the data is sent over each of the tw
devm_kasprintf() calls can return null pointers on failure.
But some return values were not checked in zynqmp_audio_init().
Add NULL check in zynqmp_audio_init(), to handle kernel NULL
pointer dereference error.
Fixes: 3ec5c1579305 ("drm: xlnx: zynqmp_dpsub: Add DP audio support")
Signed-off-by: C
On Mon, Feb 10, 2025 at 11:34:41AM -0800, mhkelle...@gmail.com wrote:
> From: Michael Kelley
>
> When a Hyper-V DRM device is probed, the driver allocates MMIO space for
> the vram, and maps it cacheable. If the device removed, or in the error
> path for device probing, the MMIO space is released
On 11.02.2025 12:19 AM, Marijn Suijten wrote:
> What used to be the input_10_bits boolean - feeding into the lowest
> bit of DSC_ENC - on MSM downstream turned into an accidental OR with
> the full bits_per_component number when it was ported to the upstream
> kernel.
>
> On typical bpc=8 setups w
When compiling without CONFIG_IA32_EMULATION, there can be some errors:
drivers/accel/amdxdna/amdxdna_mailbox.c: In function ‘mailbox_release_msg’:
drivers/accel/amdxdna/amdxdna_mailbox.c:197:2: error: implicit declaration
of function ‘kfree’.
197 | kfree(mb_msg);
| ^
drivers/accel/a
On 2/9/2025 1:42 PM, Marijn Suijten wrote:
When DSC is enabled the number of interfaces is forced to be 1, and
documented that it is a "power-optimal" layout to use two DSC encoders
together with two Layer Mixers. However, the same layout (two DSC
hard-slice encoders with two LMs) is also use
On 2/9/2025 1:42 PM, Marijn Suijten wrote:
When configuring the timing of DSI hosts (interfaces) in
dsi_timing_setup() all values written to registers are taking
bonded-mode into account by dividing the original mode width by 2
(half the data is sent over each of the two DSI hosts), but the fu
On 2025/2/10 17:43, Jacek Lawrynowicz wrote:
Hi,
please move the header to the include block above an keep it sorted:
#include
-->#include <--
#include
Ok, I will send a v2 patch for this.
Su Hui
On 2/8/2025 9:05 AM, Su Hui wrote:
When compiling without CONFIG_IA32_EMULATION, there are
From: Tom Chung
[ Upstream commit f245b400a223a71d6d5f4c72a2cb9b573a7fc2b6 ]
This reverts commit
a2b5a9956269 ("drm/amd/display: Use HW lock mgr for PSR1")
Because it may cause system hang while connect with two edp panel.
Acked-by: Wayne Lin
Signed-off-by: Tom Chung
Signed-off-by: Alex Deuc
From: Tom Chung
[ Upstream commit f245b400a223a71d6d5f4c72a2cb9b573a7fc2b6 ]
This reverts commit
a2b5a9956269 ("drm/amd/display: Use HW lock mgr for PSR1")
Because it may cause system hang while connect with two edp panel.
Acked-by: Wayne Lin
Signed-off-by: Tom Chung
Signed-off-by: Alex Deuc
From: Tom Chung
[ Upstream commit f245b400a223a71d6d5f4c72a2cb9b573a7fc2b6 ]
This reverts commit
a2b5a9956269 ("drm/amd/display: Use HW lock mgr for PSR1")
Because it may cause system hang while connect with two edp panel.
Acked-by: Wayne Lin
Signed-off-by: Tom Chung
Signed-off-by: Alex Deuc
From: Alex Hung
[ Upstream commit 8adbb2a98b00926315fd513b5fe2596b5716b82d ]
[WHAT & HOW]
hpo_stream_to_link_encoder_mapping has size MAX_HPO_DP2_ENCODERS(=4),
but location can have size up to 6. As a result, it is necessary to
check location against MAX_HPO_DP2_ENCODERS.
Similiarly, disp_cfg_s
From: Tom Chung
[ Upstream commit f245b400a223a71d6d5f4c72a2cb9b573a7fc2b6 ]
This reverts commit
a2b5a9956269 ("drm/amd/display: Use HW lock mgr for PSR1")
Because it may cause system hang while connect with two edp panel.
Acked-by: Wayne Lin
Signed-off-by: Tom Chung
Signed-off-by: Alex Deuc
From: Alex Hung
[ Upstream commit 8adbb2a98b00926315fd513b5fe2596b5716b82d ]
[WHAT & HOW]
hpo_stream_to_link_encoder_mapping has size MAX_HPO_DP2_ENCODERS(=4),
but location can have size up to 6. As a result, it is necessary to
check location against MAX_HPO_DP2_ENCODERS.
Similiarly, disp_cfg_s
On 2/3/2025 9:29 AM, Krzysztof Kozlowski wrote:
PHY_CMN_CLK_CFG0 register is updated by the PHY driver and by two
divider clocks from Common Clock Framework:
devm_clk_hw_register_divider_parent_hw(). Concurrent access by the
clocks side is protected with spinlock, however driver's side in
res
On 2/10/2025 3:19 PM, Marijn Suijten wrote:
What used to be the input_10_bits boolean - feeding into the lowest
bit of DSC_ENC - on MSM downstream turned into an accidental OR with
the full bits_per_component number when it was ported to the upstream
kernel.
On typical bpc=8 setups we don't n
On Mon, 2025-02-10 at 21:35 +, Michael Kelley wrote:
> From: thomas@oracle.com Sent: Monday, February
> 10, 2025 7:08 AM
> >
> >
> > > > Then the question is why the efifb driver doesn't work in the kdump
> > > > kernel. Actually, it *does* work in many cases. I built the 6.13.0
> > >
See my comments inline below.
Regards,
Zhanjun Dong
On 2025-01-28 1:36 p.m., Alan Previn wrote:
GuC-Err-Capture should not be storing register snapshot
nodes directly inside of the top level xe_devcoredump_snapshot
structure that it doesn't control. Furthermore, that is
is not right from a driv
On Tue, Feb 11, 2025 at 12:05 PM Andrew Morton
wrote:
>
> On Mon, 10 Feb 2025 20:37:42 +0100 David Hildenbrand wrote:
>
> > Against mm-hotfixes-stable for now.
> >
> > Discussing the PageTail() call in make_device_exclusive_range() with
> > Willy, I recently discovered [1] that device-exclusive h
xe_devcoredump calls xe_engine_snapshot_capture_for_queue() to allocate
and populate the xe_hw_engine_snapshot structure. Move that function
back into xe_hw_engine.c since it doesn't make sense for
GuC-Err-Capture to allocate a structure it doesn't own.
v7: Rename function to respect "xe_hw_eng
The GuC-Error-Capture is currently reaching into xe_devcoredump
structure to store its own place-holder snaphot-ptr to workaround
the race between G2H-Error-Capture-Notification vs Drm-Scheduler
triggering GuC-Submission-exec-queue-timeout/kill.
>From a subsystem layering perspective, this isn't s
xe_hw_engine_print is called by debugfs to do an immediate raw
dump of the engine registers. It depends on hw_engine_snapshot_capture
that assumes a prior capture with a matching job is ready for printing.
However, for the debugfs case, there is no prior job so ensure
hw_engine_snapshot_capture can
Relocate the xe_engine_snapshot_print function from xe_guc_capture.c
into xe_hw_engine.c but split out the GuC-Err-Capture register printing
portion out into a separate helper inside xe_guc_capture.c so that
we can have a clear separation between printing the general engine info
vs GuC-Err-Capture
Update the comments on GuC-Err-Capture flows with the
updated function names.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/xe/xe_guc_capture.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_guc_capture.c
b/drivers/gpu/drm/xe/xe_g
GuC-Err-Capture should not be storing register snapshot
nodes directly inside of the top level xe_devcoredump_snapshot
structure that it doesn't control. Furthermore, that is
is not right from a driver subsystem layering perspective.
Instead, when a matching GuC-Err-Capture register snapshot is
av
Since '__guc_capture_parsed_output *' is a handle that
is retrieved, stored and relinquished by an entity
external to GuC (i.e. xe_devcoredump), lets rename it to
something formal without the'__' prefix and export it
via give a header file.
v7: - Copyright header fix in xe_guc_capture_snapshot_
Add myself as the maintainer of the recently orphaned repaper and
mi0283qt drivers.
Signed-off-by: Alex Lanzano
---
MAINTAINERS | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1c5b22f00434..b5e46f23d1ba 100644
--- a/MAINTAINERS
+++ b/MAIN
On 2025-02-10 18:13:58, Konrad Dybcio wrote:
> On 10.02.2025 6:10 PM, Konrad Dybcio wrote:
> > On 8.02.2025 11:09 PM, Marijn Suijten wrote:
> >> On 2025-02-03 21:14:26, Danila Tikhonov wrote:
...
> >>> dsc->simple_422 = 0;
> >>> dsc->convert_rgb = 1;
> >>> dsc->vbr_enable = 0;
> >>
> >> This
What used to be the input_10_bits boolean - feeding into the lowest
bit of DSC_ENC - on MSM downstream turned into an accidental OR with
the full bits_per_component number when it was ported to the upstream
kernel.
On typical bpc=8 setups we don't notice this because line_buf_depth is
always an od
On Mon, Feb 10, 2025 at 06:12:44PM +0100, Luca Ceresoli wrote:
> Hi Maxime, Dmitry
>
> On Fri, 7 Feb 2025 21:54:06 +0200
> Dmitry Baryshkov wrote:
>
> > > > +/* Internal function (for refcounted bridges) */
> > > > +void __drm_bridge_free(struct kref *kref)
> > > > +{
> > > > + struct drm_
On Mon, Feb 10, 2025 at 10:49:54PM +0800, Yongbang Shi wrote:
> From: Baihan Li
>
> Add dp serdes cfg in link training process, and related adapting
> and modificating. We change some init values about training,
Imperative language, please. Use 'change', not 'we change'.
> because we want compl
On Mon, 10 Feb 2025 20:37:42 +0100 David Hildenbrand wrote:
> Against mm-hotfixes-stable for now.
>
> Discussing the PageTail() call in make_device_exclusive_range() with
> Willy, I recently discovered [1] that device-exclusive handling does
> not properly work with THP, making the hmm-tests sel
On 2/10/25 15:18, Mario Limonciello wrote:
On 2/9/2025 16:50, Melissa Wen wrote:
When switching to drm_edid, we slightly changed how to get edid by
removing the possibility of getting them from dc_link when in aux
transaction mode. As MST doesn't initialize the connector with
`drm_connector_in
On 2/7/2025 4:27 PM, Dmitry Baryshkov wrote:
In order to simplify the driver even further and to remove the
boilerplate code, rewrite the audio interface to use the DRM HDMI Audio
framework.
Audio InfoFames are controlled centrally via the DRM HDMI framework.
Correct InfoFrame data is program
On 2/9/2025 16:50, Melissa Wen wrote:
When switching to drm_edid, we slightly changed how to get edid by
removing the possibility of getting them from dc_link when in aux
transaction mode. As MST doesn't initialize the connector with
`drm_connector_init_with_ddc()`, restore the original behavior
On 2/10/2025 6:24 AM, Dmitry Baryshkov wrote:
On Mon, Feb 10, 2025 at 01:54:29PM +0100, Marijn Suijten wrote:
On 2025-02-10 01:11:59, Dmitry Baryshkov wrote:
On Sun, Feb 09, 2025 at 10:42:53PM +0100, Marijn Suijten wrote:
Ordering issues here cause an uninitialized (default STANDALONE)
usec
On 2/9/2025 7:51 PM, Ethan Carter Edwards wrote:
There is a possibility for an uninitialized *ret* variable to be
returned in some code paths.
Fix this by initializing *ret* to 0.
Addresses-Coverity-ID: 1642546 ("Uninitialized scalar variable")
Fixes: 774bcfb731765d ("drm/msm/dpu: add suppor
On 2025-01-13 03:18, Simon Ser wrote:
> This patch should probably come after all patches introducing the
> properties referenced in the docs, e.g. NEXT and COLOR_PIPELINE.
> Probably after "[13/45] drm/colorop: Introduce
> DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE"?
>
>> +/**
>> + * DOC: overview
>>
From: thomas@oracle.com Sent: Monday, February 10,
2025 7:08 AM
>
>
>
> >> Then the question is why the efifb driver doesn't work in the kdump
> >> kernel. Actually, it *does* work in many cases. I built the 6.13.0 kernel
> >> on the Oracle Linux 9.4 system, and transferred the kernel imag
On Fri, Feb 07, 2025 at 01:55:58PM +0100, Thomas Hellström wrote:
> On Wed, 2025-01-29 at 11:51 -0800, Matthew Brost wrote:
> > Add unbind to SVM garbage collector. To facilitate add unbind support
> > function to VM layer which unbinds a SVM range. Also teach PY layer
>
> Should it be
> s/PY laye
On Tue, Jan 14, 2025 at 09:34:49AM +0100, Krzysztof Kozlowski wrote:
> On Fri, Jan 10, 2025 at 11:17:32AM -0500, Frank Li wrote:
> > This controller support scalable data lanes from 1 to 4. Add the
> > 'data-lanes' property to configure the number of MIPI display panel lanes
> > selected for boards
Failing to obtain the folio lock, for example because the folio is
concurrently getting migrated or swapped out, can easily make the callers
fail: for example, the hmm selftest can sometimes be observed to fail
because of this. Instead of forcing the caller to retry, let's simply
retry in this to-b
Ever since commit b756a3b5e7ea ("mm: device exclusive memory access")
we can return with a device-exclusive entry from page_vma_mapped_walk().
damon_folio_young_one() is not prepared for that, so teach it about these
PFN swap PTEs. Note that device-private entries are so far not applicable
on that
Now that conversion to device-exclusive does no longer perform an
rmap walk and all page_vma_mapped_walk() users were taught to
properly handle device-exclusive entries, let's treat device-exclusive
entries just as if they would be present, similar to how we handle
device-private entries already.
Ever since commit b756a3b5e7ea ("mm: device exclusive memory access")
we can return with a device-exclusive entry from page_vma_mapped_walk().
damon_folio_mkold_one() is not prepared for that and calls
damon_ptep_mkold() with PFN swap PTEs. Teach damon_ptep_mkold() to deal
with these PFN swap PTEs
Ever since commit b756a3b5e7ea ("mm: device exclusive memory access")
we can return with a device-exclusive entry from page_vma_mapped_walk().
page_idle_clear_pte_refs_one() is not prepared for that, so let's
teach it what to do with these PFN swap PTEs. Note that device-private
entries are so far
Ever since commit b756a3b5e7ea ("mm: device exclusive memory access")
we can return with a device-exclusive entry from page_vma_mapped_walk().
write_protect_page() is not prepared for that, so teach it about these
PFN swap PTEs. Note that device-private entries are so far not
applicable on that pa
Ever since commit b756a3b5e7ea ("mm: device exclusive memory access")
we can return with a device-exclusive entry from page_vma_mapped_walk().
try_to_migrate_one() is not prepared for that, so teach it about these
PFN swap PTEs. We already handle device-private entries by specializing
on the folio
Ever since commit b756a3b5e7ea ("mm: device exclusive memory access")
we can return with a device-exclusive entry from page_vma_mapped_walk().
page_vma_mkclean_one() is not prepared for that, so teach it about these
PFN swap PTEs. Note that device-private entries are so far not applicable
on that
Ever since commit b756a3b5e7ea ("mm: device exclusive memory access")
we can return with a device-exclusive entry from page_vma_mapped_walk().
try_to_unmap_one() is not prepared for that, so teach it about these
PFN swap PTEs. Note that device-private entries are so far not
applicable on that path
It's unclear why they would be considered migration entries; they are
not.
Likely we'll never really trigger that case in practice, because
migration (including folio split) of a folio that has device-exclusive
entries is never started, as we would detect "additional references":
device-exclusive
Ever since commit b756a3b5e7ea ("mm: device exclusive memory access")
we can return with a device-exclusive entry from page_vma_mapped_walk().
__replace_page() is not prepared for that, so teach it about these
PFN swap PTEs. Note that device-private entries are so far not
applicable on that path,
Against mm-hotfixes-stable for now.
Discussing the PageTail() call in make_device_exclusive_range() with
Willy, I recently discovered [1] that device-exclusive handling does
not properly work with THP, making the hmm-tests selftests fail if THPs
are enabled on the system.
Looking into more detail
Even though FOLL_SPLIT_PMD on hugetlb now always fails with -EOPNOTSUPP,
let's add a safety net in case FOLL_SPLIT_PMD usage would ever be reworked.
In particular, before commit 9cb28da54643 ("mm/gup: handle hugetlb in the
generic follow_page_mask code"), GUP(FOLL_SPLIT_PMD) would just have
return
There is no need for the distinction anymore; let's merge the readable
and writable device-exclusive entries into a single device-exclusive
entry type.
Acked-by: Simona Vetter
Reviewed-by: Alistair Popple
Signed-off-by: David Hildenbrand
---
include/linux/swap.h| 7 +++
include/linux/
Let's do it just like mprotect write-upgrade or during NUMA-hinting
faults on PROT_NONE PTEs: detect if the PTE can be writable by using
can_change_pte_writable().
Set the PTE only dirty if the folio is dirty: we might not
necessarily have a write access, and setting the PTE writable doesn't
requi
We require a writable PTE and only support anonymous folio: we can only
have exactly one PTE pointing at that page, which we can just lookup
using a folio walk, avoiding the rmap walk and the anon VMA lock.
So let's stop doing an rmap walk and perform a folio walk instead, so we
can easily just mo
The single "real" user in the tree of make_device_exclusive_range() always
requests making only a single address exclusive. The current implementation
is hard to fix for properly supporting anonymous THP / large folios and
for avoiding messing with rmap walks in weird ways.
So let's always process
We only have two FOLL_SPLIT_PMD users. While uprobe refuses hugetlb
early, make_device_exclusive_range() can end up getting called on
hugetlb VMAs.
Right now, this means that with a PMD-sized hugetlb page, we can end
up calling split_huge_pmd(), because pmd_trans_huge() also succeeds
with hugetlb
From: Michael Kelley
When a Hyper-V DRM device is probed, the driver allocates MMIO space for
the vram, and maps it cacheable. If the device removed, or in the error
path for device probing, the MMIO space is released but no unmap is done.
Consequently the kernel address space for the mapping is
On Fri, Feb 07, 2025 at 11:15:38AM +0100, Thomas Hellström wrote:
> On Wed, 2025-01-29 at 11:51 -0800, Matthew Brost wrote:
> > Clear root PT entry and invalidate entire VM's address space when
> > closing the VM. Will prevent the GPU from accessing any of the VM's
> > memory after closing.
> >
>
On Fri, Feb 07, 2025 at 06:43:11AM -0700, Upadhyay, Tejas wrote:
>
>
> > -Original Message-
> > From: Intel-xe On Behalf Of Thomas
> > Hellström
> > Sent: Friday, February 7, 2025 6:35 PM
> > To: Brost, Matthew ; intel-
> > x...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> >
On Wed, Jan 29, 2025 at 11:51:49AM -0800, Matthew Brost wrote:
> From: Thomas Hellström
>
> Add dma_addr res cursor which walks an array of drm_pagemap_dma_addr.
> Useful for SVM ranges and programing page tables.
>
> v3:
> - Better commit message (Thomas)
> - Use new drm_pagemap.h location
>
On Fri, Feb 07, 2025 at 06:47:38AM -0700, Upadhyay, Tejas wrote:
>
>
> > -Original Message-
> > From: Intel-xe On Behalf Of
> > Ghimiray, Himal Prasad
> > Sent: Friday, February 7, 2025 5:41 PM
> > To: Brost, Matthew ; intel-
> > x...@lists.freedesktop.org; dri-devel@lists.freedesktop.or
https://bugzilla.kernel.org/show_bug.cgi?id=219492
oyvi...@everdot.org changed:
What|Removed |Added
CC||oyvi...@everdot.org
--- Comment #2
LGTM
Reviewed-by: Zhanjun Dong
Regards,
Zhanjun Dong
On 2025-01-28 1:36 p.m., Alan Previn wrote:
Since '__guc_capture_parsed_output *' is a handle that
is retrieved, stored and relinquished by an entity
external to GuC (i.e. xe_devcoredump), lets rename it to
something formal without the'__'
On Fri, 2025-01-31 at 10:55 -0800, Teres Alexis, Alan Previn wrote:
> On Thu, 2025-01-30 at 17:42 -0500, Vivi, Rodrigo wrote:
> > On Tue, Jan 28, 2025 at 10:36:49AM -0800, Alan Previn wrote:
> >
> > >
alan:snip
> > > - if (!snapshot->matched_node)
> > > + gt = guc_to_gt(guc);
> > > +
On Thu, Feb 06, 2025 at 11:35:44AM +0100, Thomas Hellström wrote:
> Add Matthew Auld and Matthew Brost as TTM reviewers
>
> Cc: Matthew Auld
> Cc: Matthew Brost
Acked-by: Matthew Brost
> Cc: Christian König
> Cc: Dave Airlie
> Cc: Simona Vetter
> Cc: dri-devel@lists.freedesktop.org
> Cc: l
On Fri, Feb 07, 2025 at 09:34:00AM +0100, Thomas Hellström wrote:
> On Wed, 2025-01-29 at 11:51 -0800, Matthew Brost wrote:
> > From: Thomas Hellström
> >
> > Introduce drm_pagemap ops to map and unmap dma to VRAM resources. In
> > the
> > local memory case it's a matter of merely providing an of
On Thu, Feb 06, 2025 at 07:14:23PM +0100, Luca Ceresoli wrote:
> Adding a panel does currently not add a panel_bridge wrapping it. Usually
> the panel_bridge creation happens when some other driver (e.g. the previous
> bridge or the encoder) calls *_of_get_bridge() and the following element in
> th
On Thu, Feb 06, 2025 at 07:14:26PM +0100, Luca Ceresoli wrote:
> In order to support panels described either via graph links or via a
> subnode (e.g. "panel@0"), this driver uses low-level deprecated functions
> to find the next bridge. The resulting logic is complex and duplicates code
> already p
On Thu, Feb 06, 2025 at 07:14:25PM +0100, Luca Ceresoli wrote:
> devm_drm_of_get_bridge(), which is based on graph links, is the recommended
> function to get a pointer to the following bridge.
>
> This is valid even for panels, for which the recommended device tree
> description is via graph link
On Mon, Feb 10, 2025 at 04:23:44PM +0200, Dmitry Baryshkov wrote:
> On Mon, 10 Feb 2025 at 14:31, Maxime Ripard wrote:
> >
> > On Fri, Feb 07, 2025 at 09:54:06PM +0200, Dmitry Baryshkov wrote:
> > > On Fri, Feb 07, 2025 at 12:47:51PM +0100, Maxime Ripard wrote:
> > > > Hi,
> > > >
> > > > On Thu,
On 2/4/25 18:18, Philipp Zabel wrote:
> On Mo, 2025-02-03 at 19:15 +0100, Michal Wilczynski wrote:
>>
>> On 1/31/25 16:39, Matt Coster wrote:
>>> On 28/01/2025 19:48, Michal Wilczynski wrote:
Add reset controller driver for the T-HEAD TH1520 SoC that manages
hardware reset lines for va
On Mon, Feb 10, 2025 at 06:12:03PM +0100, Luca Ceresoli wrote:
> Hello Maxime, Dmitry,
>
> On Mon, 10 Feb 2025 16:23:44 +0200
> Dmitry Baryshkov wrote:
>
> > On Mon, 10 Feb 2025 at 14:31, Maxime Ripard
> > wrote:
> > >
> > > On Fri, Feb 07, 2025 at 09:54:06PM +0200, Dmitry Baryshkov wrote:
>
On 9.02.2025 6:05 AM, Dmitry Baryshkov wrote:
> There is no need to specify separate HPD gpio for the HDMI block. Use
> built-in HPD in order to detect if the monitor is plugged or not.
>
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by: Konrad Dybcio
Konrad
This tablet does not have dpio-common-bc powerwell init.
i915 :00:02.0: [drm] *ERROR* timeout setting power well state
(f3ff)
i915 :00:02.0: [drm] *ERROR* Display PHY 0 is not power up
Signed-off-by: Qs315490
---
.../drm/i915/display/intel_display_driver.c | 4 ++--
...
Hi Dmitry,
On Fri, 7 Feb 2025 21:57:30 +0200
Dmitry Baryshkov wrote:
> On Fri, Feb 07, 2025 at 11:44:01AM +0100, Luca Ceresoli wrote:
> > On Fri, 7 Feb 2025 05:17:43 +0200
> > Dmitry Baryshkov wrote:
> >
> > > On Thu, Feb 06, 2025 at 07:14:30PM +0100, Luca Ceresoli wrote:
> > > > Add a dev
On Fri, Feb 07, 2025 at 10:06:44AM +0100, Thomas Hellström wrote:
> On Wed, 2025-01-29 at 11:51 -0800, Matthew Brost wrote:
> > This patch introduces support for GPU Shared Virtual Memory (SVM) in
> > the
> > Direct Rendering Manager (DRM) subsystem. SVM allows for seamless
> > sharing of memory be
On Sun, Feb 09, 2025 at 03:25:26AM -0500, Neal Gompa wrote:
> On Friday, February 7, 2025 1:16:11 PM Eastern Standard Time Konstantin
> Ryabitsev wrote:
> > It is my goal to be able to give subsystems a way to use forges without it
> > impacting how they interact with upstream or handle tree-wide
1 - 100 of 220 matches
Mail list logo
