https://bugzilla.kernel.org/show_bug.cgi?id=218292
--- Comment #7 from m...@bewi.at ---
(In reply to Bagas Sanjaya from comment #6)
> (In reply to mail from comment #4)
> > >
> > > > Info for my System:
> > > >
> > > > Graphics Platform: X11
> > > > Processors: 16 × AMD Ryzen 7 PRO 7840U w/
To mirror the CPU page table from GPU side, we register a mmu interval
notifier (in the coming patch of this series). Core mm call back to
GPU driver whenever there is a change to certain virtual address range,
i.e., range is released or unmapped by user etc.
This patch implemented the GPU driver
On gpu page fault of a virtual address, try to fault in the virtual
address range to gpu page table and let HW to retry on the faulty
address.
Right now, we always migrate the whole vma which contains the fault
address to GPU. This is subject to change of a more sophisticated
migration policy:
Introduce xe_svm_build_sg helper function to build a scatter
gather table from a hmm_range struct. This is prepare work
for binding hmm range to gpu.
Signed-off-by: Oak Zeng
Co-developed-by: Niranjana Vishwanathapura
Signed-off-by: Niranjana Vishwanathapura
Cc: Matthew Brost
Cc: Thomas
Under the picture of svm, CPU and GPU program share one same
virtual address space. The backing store of this virtual address
space can be either in system memory or device memory. Since GPU
device memory is remaped as DEVICE_PRIVATE, CPU can't access it.
Any CPU access to device memory causes a
Clean up svm range during process exit: Zap GPU page table of
the svm process on process exit; unregister all the mmu interval
notifiers which are registered before; free svm range and svm
data structure.
Signed-off-by: Oak Zeng
Cc: Niranjana Vishwanathapura
Cc: Matthew Brost
Cc: Thomas
DRM_XE_SVM kernel config entry is added so
xe svm feature can be configured before kernel
compilation.
Signed-off-by: Oak Zeng
Co-developed-by: Niranjana Vishwanathapura
Signed-off-by: Niranjana Vishwanathapura
Cc: Matthew Brost
Cc: Thomas Hellström
Cc: Brian Welty
---
Move access_type and pagefault struct to header file so it
can be shared with svm sub-system. This is preparation work
for enabling page fault for svm.
Signed-off-by: Oak Zeng
Cc: Niranjana Vishwanathapura
Cc: Matthew Brost
Cc: Thomas Hellström
Cc: Brian Welty
---
drivers/gpu/drm/xe/xe_gt.h
Introduce xe_migrate_svm function for data migration.
This function is similar to xe_migrate_copy function
but has different parameters. Instead of BO and ttm
resource parameters, it has source and destination
buffer's dpa address as parameter. This function is
intended to be used by svm
Add a helper function svm_populate_range to populate
a svm range. This functions calls hmm_range_fault
to read CPU page tables and populate all pfns of this
virtual address range into an array, saved in hmm_range::
hmm_pfns. This is prepare work to bind a svm range to
GPU. The hmm_pfns array will
Add helper function xe_bind_svm_range to bind a svm range
to gpu. A temporary xe_vma is created locally to re-use
existing page table update functions which are vma-based.
The svm page table update lock design is different from
userptr and bo page table update. A xe_pt_svm_pre_commit
function is
xe driver register mmu interval notifier to core mm to monitor vma
change. We register mmu interval notifier for each svm range. mmu
interval notifier should be unregistered in a worker (see next patch
in this series), so also initialize kernel worker to unregister mmu
interval notifier.
Add function to trace svm range migration, either
from vram to sram, or sram to vram
Signed-off-by: Oak Zeng
Cc: Niranjana Vishwanathapura
Cc: Matthew Brost
Cc: Thomas Hellström
Cc: Brian Welty
---
drivers/gpu/drm/xe/xe_svm_migrate.c | 1 +
drivers/gpu/drm/xe/xe_trace.h | 30
Add xe_svm and xe_svm_range data structure. Each xe_svm
represents a svm address space and it maps 1:1 to the
process's mm_struct. It also maps 1:1 to the gpu xe_vm
struct.
Each xe_svm_range represent a virtual address range inside
a svm address space. It is similar to CPU's vm_area_struct,
or
Memory remap GPU vram using devm_memremap_pages, so each GPU vram
page is backed by a struct page.
Those struct pages are created to allow hmm migrate buffer b/t
GPU vram and CPU system memory using existing Linux migration
mechanism (i.e., migrating b/t CPU system memory and hard disk).
This is
Since the source pages of the svm range can be physically none
contiguous, and the destination vram pages can also be none
contiguous, there is no easy way to migrate multiple pages per
blitter command. We do page by page migration for now.
Migration is best effort. Even if we fail to migrate
Create the xe_svm struct during xe_vm creation.
Add xe_svm to a global hash table so later on
we can retrieve xe_svm using mm_struct (the key).
Destroy svm process during xe_vm close.
Also add a helper function to retrieve svm struct
from mm struct
Signed-off-by: Oak Zeng
Cc: Niranjana
A svm subsystem friendly function is added for svm range invalidation
purpose. svm subsystem doesn't maintain xe_vma, so a temporary xe_vma
is used to call function xe_vma_invalidate_vma
Not sure whether this works or not. Will have to test. if a temporary
vma doesn't work, we will have to call
Function xe_devm_alloc_pages allocate pages from drm buddy and perform
house keeping work for all the pages allocated, such as get a page
refcount, keep a bitmap of all pages to denote whether a page is in
use, put pages to a drm lru list for eviction purpose.
Function xe_devm_free_blocks return
Signed-off-by: Oak Zeng
Cc: Niranjana Vishwanathapura
Cc: Matthew Brost
Cc: Thomas Hellström
Cc: Brian Welty
---
drivers/gpu/drm/xe/xe_svm_devmem.c | 5 -
drivers/gpu/drm/xe/xe_trace.h | 35 ++
2 files changed, 39 insertions(+), 1 deletion(-)
diff --git
This is the very basic SVM (shared virtual memory) support in XeKmd
driver. SVM allows the programmer to use a shaed virtual address space
between CPU program and GPU program. It abstracts away from the user
the location of the backing memory in a mixed CPU and GPU programming
environment.
This
All valid virtual address range are maintained in svm's
range_tree. This functions iterate svm's range tree and
return the svm range that contains specific address.
Signed-off-by: Oak Zeng
Cc: Niranjana Vishwanathapura
Cc: Matthew Brost
Cc: Thomas Hellström
Cc: Brian Welty
---
xe_vm tracepoint is extended to also print svm.
Signed-off-by: Oak Zeng
Cc: Niranjana Vishwanathapura
Cc: Matthew Brost
Cc: Thomas Hellström
Cc: Brian Welty
---
drivers/gpu/drm/xe/xe_trace.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
Add shared virtual memory document.
Signed-off-by: Oak Zeng
Co-developed-by: Niranjana Vishwanathapura
Signed-off-by: Niranjana Vishwanathapura
Cc: Matthew Brost
Cc: Thomas Hellström
Cc: Brian Welty
---
Documentation/gpu/xe/index.rst | 1 +
Documentation/gpu/xe/xe_svm.rst | 8 +++
2023년 12월 20일 (수) 오후 7:45, Marek Szyprowski 님이 작성:
> On 20.12.2023 10:53, Fedor Pchelkin wrote:
> > Do not forget to call clk_disable_unprepare() on the first element of
> > ctx->clocks array.
> >
> > Found by Linux Verification Center (linuxtesting.org).
> >
> > Fixes: 8b7d3ec83aba ("drm/exynos:
2023년 12월 19일 (화) 오전 11:11, Frieder Schrempf 님이
작성:
> On 01.12.23 10:04, Michael Walle wrote:
> >> The FORCE_STOP_STATE bit is unsuitable to force the DSI link into LP-11
> >> mode. It seems the bridge internally queues DSI packets and when the
> >> FORCE_STOP_STATE bit is cleared, they are sent
Document nested struct members with full names as described in
Documentation/doc-guide/kernel-doc.rst.
i915_gem_context_types.h:420: warning: Excess struct member 'lock' description
in 'i915_gem_context'
Signed-off-by: Randy Dunlap
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc:
Document nested struct members with full names as described in
Documentation/doc-guide/kernel-doc.rst.
i915_perf_types.h:341: warning: Excess struct member 'ptr_lock' description in
'i915_perf_stream'
i915_perf_types.h:341: warning: Excess struct member 'head' description in
'i915_perf_stream'
Document nested struct members with full names as described in
Documentation/doc-guide/kernel-doc.rst.
intel_gsc.h:34: warning: Excess struct member 'gem_obj' description in
'intel_gsc'
Also add missing field member descriptions.
Signed-off-by: Randy Dunlap
Cc: Jani Nikula
Cc: Joonas
Document nested struct members with full names as described in
Documentation/doc-guide/kernel-doc.rst.
intel_guc.h:305: warning: Excess struct member 'lock' description in 'intel_guc'
intel_guc.h:305: warning: Excess struct member 'guc_ids' description in
'intel_guc'
intel_guc.h:305: warning:
On Wed, Dec 20, 2023 at 06:12:55PM -0800, Sean Christopherson wrote:
> On Wed, Dec 20, 2023, Yan Zhao wrote:
> > On Tue, Dec 19, 2023 at 12:26:45PM +0800, Yan Zhao wrote:
> > > On Mon, Dec 18, 2023 at 07:08:51AM -0800, Sean Christopherson wrote:
> > > > > > Implementation Consideration
> > > > > >
https://bugzilla.kernel.org/show_bug.cgi?id=218292
--- Comment #6 from Bagas Sanjaya (bagasdo...@gmail.com) ---
(In reply to mail from comment #4)
> >
> > > Info for my System:
> > >
> > > Graphics Platform: X11
> > > Processors: 16 × AMD Ryzen 7 PRO 7840U w/ Radeon 780M Graphics
> > > Memory:
On Wed, Dec 20, 2023, Yan Zhao wrote:
> On Tue, Dec 19, 2023 at 12:26:45PM +0800, Yan Zhao wrote:
> > On Mon, Dec 18, 2023 at 07:08:51AM -0800, Sean Christopherson wrote:
> > > > > Implementation Consideration
> > > > > ===
> > > > > There is a previous series [1] from google to serve the same
From: John Harrison
To prevent running out of bits, new w/a enable flags are being added
via a KLV system instead of a 32 bit flags word.
Signed-off-by: John Harrison
Reviewed-by: Vinay Belgaumkar
---
.../gpu/drm/i915/gt/uc/abi/guc_errors_abi.h | 1 +
From: John Harrison
Enable Wa_14019159160 and Wa_16019325821 for MTL
RCS/CCS workarounds for MTL.
v2: Fix bug in WA KLV implementation (offset not being reset to start
of list). Add better comment to prep patch about how KLVs can be added.
Add a module parameter override and disable the w/a
From: John Harrison
Some platforms require holding RCS context switches until CCS is idle
(the reverse w/a of Wa_14014475959). Some platforms require both
versions.
Signed-off-by: John Harrison
Reviewed-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 19
From: John Harrison
Use the new w/a KLV support to enable a MTL w/a. Note, this w/a is a
super-set of Wa_16019325821, so requires turning that one as well as
setting the new flag for Wa_14019159160 itself.
Signed-off-by: John Harrison
Reviewed-by: Vinay Belgaumkar
---
Hi John,
On Tue, Dec 19, 2023 at 11:59:57AM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Avoid the following lockdep complaint:
> <4> [298.856498] ==
> <4> [298.856500] WARNING: possible circular locking dependency
On Wed, 2023-12-13 at 16:23 -0500, Vivi, Rodrigo wrote:
> On Tue, Dec 12, 2023 at 08:57:16AM -0800, Alan Previn wrote:
> > If we are at the end of suspend or very early in resume
> > its possible an async fence signal (via rcu_call) is triggered
> > to free_engines which could lead us to the
Hi,
On Wed, Dec 20, 2023 at 2:14 PM Hsin-Yi Wang wrote:
>
> Some edp panel requires T10 (Delay from end of valid video data transmitted
> by the Source device to power-off) less than 500ms. Using autosuspend with
> delay set as 1000 violates this requirement.
>
> Use put_sync_suspend in
Some edp panel requires T10 (Delay from end of valid video data transmitted
by the Source device to power-off) less than 500ms. Using autosuspend with
delay set as 1000 violates this requirement.
Use put_sync_suspend in unprepare to meet the spec. For other cases (such
as getting EDID), it still
On 12/19/2023 6:48 PM, yang.gua...@zte.com.cn wrote:
From: Yang Guang
dev_err_probe() can check if the error code is -EPROBE_DEFER
and can return the error code, replacing dev_err() with it
simplifies the code.
Signed-off-by: Chen Haonan
Reviewed-by: Jessica Zhang
Thanks,
Jessica
On 04/12/2023 18:33, Boris Brezillon wrote:
+/**
+ * cs_slot_sync_queue_state_locked() - Synchronize the queue slot priority
+ * @ptdev: Device.
+ * @csg_id: Group slot.
+ * @cs_id: Queue slot.
+ *
+ * Queue state is updated on group suspend or STATUS_UPDATE event.
+ */
+static void
Ok, I've done more detailed testing, and it seems this patch results in
lots of dropped frames. I'm sorry for not being more thorough earlier.
I'll do some more testing without this patch and might have to either
remove it from V2 of this series.
I need to see if the same stability can be
Hi,
On 14/12/2023 13:42, Arunpravin Paneer Selvam wrote:
- Add tracking clear page feature.
- Driver should enable the DRM_BUDDY_CLEARED flag if it
successfully clears the blocks in the free path. On the otherhand,
DRM buddy marks each block as cleared.
- Track the available cleared
On 19.12.2023 19:22, Rodrigo Vivi wrote:
Hi Dave and Sima,
Here goes a v2 of our first pull request.
First PR: https://lore.kernel.org/all/zxzta75g5vhcr...@intel.com/
The lack of committer signature blocked Dave's tools on getting that.
I'm sorry for that.
As you know we were maintaining
On 12/15/2023 11:05 AM, Jeffrey Hugo wrote:
On 12/8/2023 9:34 AM, Jeffrey Hugo wrote:
A set of cleanups to the driver to improve error cases and reduce some
code duplication.
Jeffrey Hugo (2):
accel/qaic: Fix MHI channel struct field order
accel/qaic: Order pci_remove() operations in
On 12/20/2023 12:02 AM, Jacek Lawrynowicz wrote:
On 15.12.2023 19:06, Jeffrey Hugo wrote:
On 12/8/2023 9:34 AM, Jeffrey Hugo wrote:
From: Pranjal Ramajor Asha Kanojiya
Offload the balancing of init and destroy calls to DRM managed APIs.
mutex destroy for ->cntl_mutex is not called during
Hi Sam,
On Wed, 2023-12-20 at 16:22 +0100, Sam Ravnborg wrote:
> > The leon3_generic machine is maintained by different people so I'd suggest
> > contacting them: see [1] for their contact details. I see there is an
> > avocado boot test for the leon3_generic machine included within the QEMU
> >
On 12/20/23 17:29, Lucas De Marchi wrote:
On Wed, Dec 20, 2023 at 05:17:49PM +0100, Thomas Hellström wrote:
On 12/20/23 17:13, Lucas De Marchi wrote:
On Wed, Dec 20, 2023 at 03:42:14PM +0100, Thomas Hellström wrote:
If using the VM_BIND_OP_UNMAP_ALL without any bound vmas for the
vm, we
On 12/19/2023 2:32 PM, Dmitry Baryshkov wrote:
On Tue, 19 Dec 2023 at 18:18, Kuogee Hsieh wrote:
Hi Dmitry,
Anymore comments from you?
No, for some reason I missed this patch. Please excuse me.
On 12/14/2023 10:56 AM, Kuogee Hsieh wrote:
At DSC V1.1 DCE (Display Compression Engine)
Hi Dave, Sima,
A few holiday fixes for 6.7.
The following changes since commit ceb6a6f023fd3e8b07761ed900352ef574010bcb:
Linux 6.7-rc6 (2023-12-17 15:19:28 -0800)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-6.7-2023-12-20
for
On Wed, Dec 20, 2023 at 05:17:49PM +0100, Thomas Hellström wrote:
On 12/20/23 17:13, Lucas De Marchi wrote:
On Wed, Dec 20, 2023 at 03:42:14PM +0100, Thomas Hellström wrote:
If using the VM_BIND_OP_UNMAP_ALL without any bound vmas for the
vm, we will end up dereferencin an uninitialized
On Mon, Dec 04, 2023 at 06:33:04PM +0100, Boris Brezillon wrote:
> This is the last piece missing to expose the driver to the outside
> world.
>
> This is basically a wrapper between the ioctls and the other logical
> blocks.
>
> v3:
> - Add acks for the MIT/GPL2 relicensing
> - Fix 32-bit
Hi Mark,
On Wed, Dec 20, 2023 at 11:30:27AM +, Mark Cave-Ayland wrote:
> On 20/12/2023 10:47, Arnd Bergmann wrote:
>
> > On Wed, Dec 20, 2023, at 09:54, John Paul Adrian Glaubitz wrote:
> > > On Wed, 2023-12-20 at 08:36 +, Arnd Bergmann wrote:
> > > > All of these were found through
Dne sreda, 20. december 2023 ob 08:14:27 CET je Frank Oltmanns napisal(a):
>
> On 2023-12-19 at 18:04:29 +0100, Jernej Škrabec
> wrote:
> > Dne ponedeljek, 18. december 2023 ob 14:35:23 CET je Frank Oltmanns
> > napisal(a):
> >> This panel is used in the pinephone that runs on a Allwinner A64
On Tue, 19 Dec 2023 at 23:03, Sam Ravnborg via B4 Relay
wrote:
>
> This is the second attempt to sunset sun4m and sun4d.
> See [1] for the inital attempt.
>
> The sun4m and sun4d parts of the kernel have seen no real interest
> for several years now. Last time a few people surfaced, but it was
>
On 20/12/2023 10:47, Arnd Bergmann wrote:
On Wed, Dec 20, 2023, at 09:54, John Paul Adrian Glaubitz wrote:
On Wed, 2023-12-20 at 08:36 +, Arnd Bergmann wrote:
All of these were found through inspection rather than testing,
so there is a good chance that other fatal kernel bugs prevent
Dne sreda, 20. december 2023 ob 08:09:28 CET je Frank Oltmanns napisal(a):
>
> On 2023-12-19 at 17:54:19 +0100, Jernej Škrabec
> wrote:
> > Dne ponedeljek, 18. december 2023 ob 14:35:22 CET je Frank Oltmanns
> > napisal(a):
> >> The Allwinner A64 manual lists the following constraint for the
>
On Mon, Dec 04, 2023 at 06:33:01PM +0100, Boris Brezillon wrote:
> Contains everything that's FW related, that includes the code dealing
> with the microcontroller unit (MCU) that's running the FW, and anything
> related to allocating memory shared between the FW and the CPU.
>
> A few global FW
Dne sreda, 20. december 2023 ob 07:58:07 CET je Frank Oltmanns napisal(a):
> Hi Jernej!
>
> On 2023-12-19 at 17:46:08 +0100, Jernej Škrabec
> wrote:
> > Hi Frank!
> >
> > Dne ponedeljek, 18. december 2023 ob 14:35:19 CET je Frank Oltmanns
> > napisal(a):
> >> The Allwinner A64 manual lists the
https://bugzilla.kernel.org/show_bug.cgi?id=218292
--- Comment #5 from m...@bewi.at ---
Sorry i forgot to say. I don't tried the 6.5 Kernel. v6.1. works. v6.6. doesn't
work.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of
https://bugzilla.kernel.org/show_bug.cgi?id=218292
--- Comment #4 from m...@bewi.at ---
(In reply to Bagas Sanjaya from comment #1)
> (In reply to mail from comment #0)
> > Hello all!
> >
> > I’ve a problem with the wake up from screen sleep (not whole computer
> sleeo,
> > only display) and
https://bugzilla.kernel.org/show_bug.cgi?id=218292
--- Comment #3 from m...@bewi.at ---
Created attachment 305635
--> https://bugzilla.kernel.org/attachment.cgi?id=305635=edit
dmesg6.6.x_not_working
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are
https://bugzilla.kernel.org/show_bug.cgi?id=218292
--- Comment #2 from m...@bewi.at ---
Created attachment 305634
--> https://bugzilla.kernel.org/attachment.cgi?id=305634=edit
dmesg6.1.x_working
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are
Le lundi 18 décembre 2023 à 10:50 +0800, Qiang Yu a écrit :
> Thanks for the fix. It could be done in a simpler way that swap the
> va_start/va_end init/fini and empty_vm create/release.
The thing is I do not get what you suggest by swaping :-/
Do you mean I should check for "dev->va_end -
Function mtk_dsi_ps_control() is a subset of mtk_dsi_ps_control_vact():
merge the two in one mtk_dsi_ps_control() function by adding one
function parameter `config_vact` which, when true, writes the VACT
related registers.
Signed-off-by: AngeloGioacchino Del Regno
---
Instead of open coding bitshifting for various register fields,
use the bitfield macro FIELD_PREP(): this allows to enhance the
human readability, decrease likeliness of mistakes (and register
field overflowing) and also to simplify the code.
The latter is especially seen in
Change magic numerical masks with usage of the GENMASK() macro
to improve readability.
This commit brings no functional changes.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 46 --
1 file changed, 24 insertions(+), 22
In mtk_dsi_phy_timconfig(), we're dividing the `data_rate` variable,
expressed in Hz to retrieve a value in MHz: instead of open-coding,
use the HZ_PER_MHZ definition, available in linux/units.h.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 3 ++-
1 file
Changes in v2:
- Rebased over next-20231213
This series performs some cleanups for mtk_dsi, enhancing human
readability, using kernel provided macros where possible and
also reducing code size.
Tested on MT8173 and MT8192 Chromebooks (using a DSI<->DP bridge)
and on MT6795 Sony Xperia M5 (DSI
Change check of DDC status. Instead of silently not reading EDID when in
"IDLE" state [1]. Wait for HDCP being initialized because the EDID and
HDCP block shares memory [2].
[1]
ADV7511 Programming Guide revision G: Table 11: DDCController Status:
0xC8 [3:0] DDC Controller State
0b
Currently reading EDID only works because usually only two EDID blocks
of 128 bytes is used. Where an EDID segment holds 256 bytes or two EDID
blocks. And the first EDID segment read works fine but E-EDID specifies
up to 128 segments.
The logic is broken so change EDID segment index to multiple
Hi
Am 20.12.23 um 14:06 schrieb Jocelyn Falempe:
I just merged it to drm-misc-fixes:
https://cgit.freedesktop.org/drm/drm-misc/commit/?h=drm-misc-fixes=11f9eb899ecc8c02b769cf8d2532ba12786a7af7
Thanks,
Thanks a lot for the fix.
Best regards
Thomas
--
Thomas Zimmermann
Graphics Driver
Allocate stifb's instance of fb_info with framebuffer_alloc(). This
is the preferred way of creating fb_info with associated driver data
stored in struct fb_info.par. Requires several, but minor, changes
through out the driver's code.
The intended side effect of this patch is that the new
The info field in struct sti_struct was used to detect the default
display device. That test is now done with the respective Linux device
and the info field is unused. Remove it.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/stifb.c | 3 ---
include/video/sticore.h | 4
2
Update fb_is_primary device() on parisc to detect the primary display
device from the Linux device instance. Aligns the code with the other
architectures. A later patch will remove the fbdev dependency from the
function's interface.
Signed-off-by: Thomas Zimmermann
---
arch/parisc/video/fbdev.c
On parisc, change detection of the primary framebuffer to test for
the Linux device instead of fbdev's fb_info in fb_is_primary_device().
Makes the test independent from fbdev.
This patchset is part of a larger effort to clean up the low-level
display handling. There are various functions that
Store the ROM's parent device in each STI struct, so we can associate
the STI framebuffer with a device.
The new field will eventually replace the fbdev subsystem's info field,
which the function fb_is_primary_device() currently requires to detect
the firmware's output. By using the device
Hi Alexey,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on dtor-input/next dtor-input/for-linus linus/master
v6.7-rc6 next-20231220]
[cannot apply to tip/x86/vmware]
[If your patch is applied to the wrong
I just merged it to drm-misc-fixes:
https://cgit.freedesktop.org/drm/drm-misc/commit/?h=drm-misc-fixes=11f9eb899ecc8c02b769cf8d2532ba12786a7af7
Thanks,
--
Jocelyn
https://bugzilla.kernel.org/show_bug.cgi?id=218292
Bagas Sanjaya (bagasdo...@gmail.com) changed:
What|Removed |Added
CC|
Add fails and flakes files for mt8173 and mt8183 mediatek-drm
driver tests. Add fails, skips and flakes files for rk3288 and
rk3399 rockchip-drm driver tests. Add fails file for meson-drm
display driver tests.
Signed-off-by: Vignesh Raman
---
.../xfails/mediatek-mt8173-display-flakes.txt | 13
Rename the names of xfail files for Mediatek (mt8173 and mt8183),
Rockchip (rk3288 and rk3399), and Meson (g12b) to include
information about the tested driver and whether it is related
to display or GPU testing.
Signed-off-by: Vignesh Raman
---
...ediatek-mt8173-fails.txt =>
DRM CI tests panfrost drivers, and track of which tests
are failing, flaking or being skipped by the ci in the
expectations files. So add entry for these files, so
that the corresponding driver maintainer can be notified
when they change.
Signed-off-by: Vignesh Raman
---
MAINTAINERS | 1 +
1
Since the correct driver name is passed from the job to
test gpu and display driver, remove the check to set
IGT_FORCE_DRIVER based on driver name.
Signed-off-by: Vignesh Raman
---
drivers/gpu/drm/ci/igt_runner.sh | 10 --
1 file changed, 10 deletions(-)
diff --git
Meson SOC have a separate display controller and GPU,
with different drivers for each. Add support in drm-ci
to test both these drivers.
Signed-off-by: Vignesh Raman
---
drivers/gpu/drm/ci/test.yml | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git
Rockchip rk3288 and rk3399 SOCs have a separate display controller
and GPU, with different drivers for each. Add support in drm-ci
to test both these drivers.
Signed-off-by: Vignesh Raman
---
drivers/gpu/drm/ci/test.yml | 50 -
1 file changed, 38
Mediatek 8173 and 8183 SOCs have a separate display controller
and GPU, with different drivers for each. Add support in drm-ci
to test both these drivers.
Powervr driver was merged in linux kernel, but there's no mediatek
support yet. So disable the mt8173-gpu job which uses powervr driver.
Enable CONFIG_DRM_ANALOGIX_ANX7625 in the arm64 defconfig to get
display driver probed on the mt8183-kukui-jacuzzi-juniper machine.
arch/arm64/configs/defconfig has CONFIG_DRM_ANALOGIX_ANX7625=m,
but drm-ci don't have initrd with modules, so add
CONFIG_DRM_ANALOGIX_ANX7625=y in CI arm64 config.
Some ARM SOCs have a separate display controller and GPU, each with
different drivers. For mediatek mt8173, the GPU driver is powervr,
and the display driver is mediatek. In the case of mediatek mt8183,
the GPU driver is panfrost, and the display driver is mediatek.
With rockchip rk3288/rk3399,
Ville Syrjala writes:
> From: Ville Syrjälä
>
> Sprinkle some extra WARNs around so that we might catch
> premature framebuffer destruction more readily.
>
> Signed-off-by: Ville Syrjälä
> ---
Acked-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red
Ville Syrjala writes:
Hello Ville,
> From: Ville Syrjälä
>
> If we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl()
> we proceed to unref the fb and then retry the whole thing from the top.
> But we forget to reset the fb pointer back to NULL, and so if we then
> get another
On 12/19/23 23:43, Helen Koike wrote:
> Hi,
>
> On 14/12/2023 06:38, Bagas Sanjaya wrote:
>> Hi all,
>>
>> I'm referring to dependabot PR on torvalds.git GitHub mirror [1]. I know
>> that PRs submitted there are not accepted (the repo is essentially read-only
>> mirror), hence this mail question.
Hi Maintainers,
There are some flaky tests reported for rk3288 and rk3399 rockchip-drm
display driver testing in drm-ci.
=== rockchip rk3288 ===
# Board Name: rk3288-veyron-jaq.dtb
# Failure Rate: 50
# IGT Version: 1.28-gd2af13d9f
# Linux Version: 6.7.0-rc3
Pipeline url:
On Wed, Dec 20, 2023, at 09:54, John Paul Adrian Glaubitz wrote:
> On Wed, 2023-12-20 at 08:36 +, Arnd Bergmann wrote:
>> All of these were found through inspection rather than testing,
>> so there is a good chance that other fatal kernel bugs prevent
>> testing in qemu, at least until the
On 20.12.2023 10:53, Fedor Pchelkin wrote:
> Do not forget to call clk_disable_unprepare() on the first element of
> ctx->clocks array.
>
> Found by Linux Verification Center (linuxtesting.org).
>
> Fixes: 8b7d3ec83aba ("drm/exynos: gsc: Convert driver to IPP v2 core API")
> Signed-off-by: Fedor
MT8195 WROT inherited from MT8183, add the corresponding
compatible name to it.
Signed-off-by: Moudy Ho
Reviewed-by: AngeloGioacchino Del Regno
Acked-by: Krzysztof Kozlowski
---
.../devicetree/bindings/media/mediatek,mdp3-wrot.yaml | 6 +-
1 file changed, 5 insertions(+), 1
Add compatible string and GCE property for MT8195 SPLIT, of
which is operated by MDP3.
Signed-off-by: Moudy Ho
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: AngeloGioacchino Del Regno
---
.../display/mediatek/mediatek,split.yaml | 27 +++
1 file changed, 27 insertions(+)
Add a compatible string for the MERGE block in MediaTek MT8195 that
is controlled by MDP3.
Signed-off-by: Moudy Ho
Reviewed-by: AngeloGioacchino Del Regno
Acked-by: Krzysztof Kozlowski
---
.../devicetree/bindings/display/mediatek/mediatek,merge.yaml | 1 +
1 file changed, 1 insertion(+)
1 - 100 of 124 matches
Mail list logo
