Both the mode_switch parameter and the return value (a redraw needed)
are true/false. So switch them to bool, so that users won't return
-Eerrors or anything else.
And document the hook.
Signed-off-by: Jiri Slaby (SUSE)
Cc: Helge Deller
Cc: "James E.J. Bottomley"
Cc: Daniel Vetter
Cc:
Switch VESA macros to an enum and add and use VESA_BLANK_MAX. This
improves type checking in consw::con_blank().
There is a downside of this. The macros were defined twice: in
linux/console.h and uapi/linux/fb.h. We cannot remove the latter (uapi
header), but nor we want to expand them in the
There are VESA blanking constants defined in console.h already. So use
them in the console code instead of constant values.
Signed-off-by: Jiri Slaby (SUSE)
Cc: Helge Deller
Cc: "James E.J. Bottomley"
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc:
-1 is the same as VESA_VSYNC_SUSPEND in all con_blank() implementations.
So we can remove this special case from vgacon now too.
Despite con_blank() of fbcon looks complicated, the "if
(!fbcon_is_inactive(vc, info))" branch is not taken as we set
"ops->graphics = 1;" few lines above. So what
Again, fbcon_getxy() is the same as the default implementation since the
softscroll removal in commit 50145474f6ef (fbcon: remove soft scrollback
code). Drop that.
Signed-off-by: Jiri Slaby (SUSE)
Cc: Daniel Vetter
Cc: Helge Deller
Cc: linux-fb...@vger.kernel.org
Cc:
There is a switch decicing if cursor should be drawn or not. The whole
switch can be simplified to one line. Do this cleanup as a preparatory
work for the next patch. There, all the CM_* constants are removed.
Signed-off-by: Jiri Slaby (SUSE)
Cc: Daniel Vetter
Cc: Helge Deller
Cc:
fbcon_screen_pos() performs the same as the default implementation. The
only difference in the default implementation is that is considers both
vc->vc_origin and vc->vc_visible_origin. But given fbcon's softscroll
code was already removed in commit 50145474f6ef (fbcon: remove soft
scrollback
The return value of consw::con_set_origin() is only true/false, meaining
if vc->vc_origin is set to vc->vc_screenbuf or not.
So switch the type and returned values accordingly.
And document the hook.
Signed-off-by: Jiri Slaby (SUSE)
Cc: Helge Deller
Cc: linux-fb...@vger.kernel.org
Cc:
Make parameters of consw::con_putc() saner:
* x and y are unsigned now, as they cannot be negative, and
* ca is made u16, as it is composed of two 8bit values (character and
attribute). See the con_putcs() hook, u16/ushort is worked on there.
And document the hook.
Signed-off-by: Jiri Slaby
It's a name after all and that is not supposed to be changed. So make it
const to make this obvious.
Signed-off-by: Jiri Slaby (SUSE)
Cc: "James E.J. Bottomley"
Cc: Daniel Vetter
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-par...@vger.kernel.org
---
The return value of con_debug_enter() and con_debug_leave() is ignored
on many fronts. So just don't propagate errors (the current
implementations return 0 anyway) and make the return type a void.
Signed-off-by: Jiri Slaby (SUSE)
Cc: Daniel Vetter
Cc: Helge Deller
Cc:
The non-zero (true) return value from consw::con_switch() means a redraw
is needed. So make this return type a bool explicitly instead of int.
The latter might imply that -Eerrors are expected. They are not.
And document the hook.
Signed-off-by: Jiri Slaby (SUSE)
Cc: Helge Deller
Cc: "James
There is no difference between CM_MOVE and CM_DRAW. Either of them
enables the cursor. CM_ERASE then disables cursor.
So get rid of all of them and use simple "bool enable".
Note that this propagates down to the fbcon code.
And document the hook.
Signed-off-by: Jiri Slaby (SUSE)
Cc: Helge
This is only a preparation for the following cleanup patch to make it
easier. Provided CM_ERASE is the only different, use 'if' instead of
'switch+case' in all those.
Signed-off-by: Jiri Slaby (SUSE)
Cc: Helge Deller
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
---
All these consw::con_putc() implementations do the same as
consw::con_putcs() (only for one charattr) or even call
consw::con_putcs() on their own.
Drop them, as thanks to the new con_putc() helper in the previous patch,
the console code performs this already -- exactly if consw::con_putc()
is
'count' in consw::con_clear() is guaranteed to be positive. csi_X() (the
only caller) takes the minimum of the vc parameter (which is at least 1)
and count of characters till the end of the line. The latter is computed
as a subtraction of vc->vc_cols (count) and vc->state.x (offset). So for
the
In consw::con_clear():
* Height is always 1, so drop it.
* Offsets and width are always unsigned values, so re-type them as such.
This needs a new __fbcon_clear() in the fbcon code to still handle
height which might not be 1 when called internally.
Note that tests for negative count/width are
The 'init' parameter of consw::con_init() is true for the first call of
the hook on a particular console. So make the parameter a bool.
And document the hook.
Signed-off-by: Jiri Slaby (SUSE)
Cc: Helge Deller
Cc: "James E.J. Bottomley"
Cc: Daniel Vetter
Cc: linux-fb...@vger.kernel.org
Cc:
Push the console code (vt.c, vt.h, console.h, ...) into a bit more
maintainable state. Especially all around consw structure and document
it.
CSI parser is also a bit cleaned up. More to follow some time in the
next round.
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: Helge Deller
Since commit 74d58cd48a8f ("USB: sisusbvga: remove console support"),
vgacon_scrolldelta() is the only user of vc_scrolldelta_helper().
Inline the helper into vgacon_scrolldelta() and drop it.
Signed-off-by: Jiri Slaby (SUSE)
Cc: Helge Deller
Cc: linux-fb...@vger.kernel.org
Cc:
It is pretty unfortunate to set vc_data::vc_resize_user in two callers
of vc_do_resize(). vc_resize_user is immediately reset there (while
remembering it). So instead of this back and forth, pass 'from_user' as
a parameter.
Notes on 'int user':
* The name changes from 'user' to 'from_user' on
display_desc is a pointer to a RO string. Instead, switch display_desc
to a static array as we are used to. It BTW saves unnecessary 8B on the
stack.
Signed-off-by: Jiri Slaby (SUSE)
Cc: Daniel Vetter
Cc: Helge Deller
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
---
Hello Mirsad,
On Wed, Jan 17, 2024 at 07:47:49PM +0100, Mirsad Todorovac wrote:
> On 1/16/24 01:32, Mirsad Todorovac wrote:
> > On the Ubuntu 22.04 LTS Jammy platform, on a mainline vanilla torvalds tree
> > kernel, the boot
> > freezes upon first two lines and before any systemd messages.
> >
On 17/01/24 1:07 pm, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On 17/01/2024 03:22, dharm...@microchip.com wrote:
>> Hi Krzysztof,
>> On 10/01/24 11:31 pm, Krzysztof Kozlowski wrote:
>>> EXTERNAL EMAIL: Do not
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 943b9f0ab2cfbaea148dd6ac279957eb08b96904 Add linux-next specific
files for 20240117
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202401172119.fc2ic3l9-...@intel.com
https
Hi Hsin-Yi,
On Thu, Jan 18, 2024 at 9:59 AM Hsin-Yi Wang wrote:
>
> Similar to commit 26db46bc9c67 ("drm/bridge: parade-ps8640: Ensure bridge
> is suspended in .post_disable()"). Add a mutex to ensure that aux transfer
> won't race with atomic_disable by holding the PM reference and prevent
>
Hi Doug,
On Thu, Jan 18, 2024 at 2:37 AM Doug Anderson wrote:
>
> Hi,
>
> On Wed, Jan 17, 2024 at 9:34 AM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Tue, Jan 9, 2024 at 8:52 AM Doug Anderson wrote:
> > >
> > > Hi,
> > >
> > > On Tue, Jan 9, 2024 at 4:05 AM Pin-yen Lin wrote:
> > > >
> > > >
On Wed, Jan 17, 2024 at 11:12 AM Erico Nunes wrote:
>
> There are several unexplained and unreproduced cases of rendering
> timeouts with lima, for which one theory is high IRQ latency coming from
> somewhere else in the system.
> This kind of occurrence may cause applications to trigger
./drivers/gpu/drm/amd/display/dc/dml2/dml2_dc_resource_mgmt.c:703:47-49:
WARNING !A || A && B is equivalent to !A || B.
Reported-by: Abaci Robot
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=7931
Signed-off-by: Jiapeng Chong
---
On 2024/1/18 02:50, Markus Elfring wrote:
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.
…
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -144,6 +144,10 @@ static int
Do we need same for GP?
Regards,
Qiang
On Wed, Jan 17, 2024 at 11:12 AM Erico Nunes wrote:
>
> This is required for reliable hard resets. Otherwise, doing a hard reset
> while a task is still running (such as a task which is being stopped by
> the drm_sched timeout handler) may result in random
Similar to commit 26db46bc9c67 ("drm/bridge: parade-ps8640: Ensure bridge
is suspended in .post_disable()"). Add a mutex to ensure that aux transfer
won't race with atomic_disable by holding the PM reference and prevent
the bridge from suspend.
Also we need to use pm_runtime_put_sync_suspend() to
GP should also need this.
Regards,
Qiang
On Wed, Jan 17, 2024 at 11:12 AM Erico Nunes wrote:
>
> Lima pp jobs use an async reset to avoid having to wait for the soft
> reset right after a job. The soft reset is done at the end of a job and
> a reset_complete flag is expected to be set at the
So this is caused by same job trigger both done and timeout handling?
I think a better way to solve this is to make sure only one handler
(done or timeout) process the job instead of just making lima_pm_idle()
unique.
Regards,
Qiang
On Wed, Jan 17, 2024 at 11:12 AM Erico Nunes wrote:
>
> In
Hi Hans and Armin,
Am 17.01.24 um 20:03 schrieb Armin Wolf:
Am 17.01.24 um 17:50 schrieb Hans de Goede:
Hi All,
On 11/27/23 11:59, Werner Sembach wrote:
I also stumbled across a new Problem:
We have an upcoming device that has a per-key keyboard backlight, but does
the control
On Tue, Jan 16, 2024 at 09:40:50AM -0800, Lucas De Marchi wrote:
> Now that all the issues with 32bits are fixed, enable it again.
>
> Signed-off-by: Lucas De Marchi
I didn't test locally, but assuming you confirmed all the warnings are
gone now,
Reviewed-by: Matt Roper
> ---
>
On Tue, Jan 16, 2024 at 09:40:49AM -0800, Lucas De Marchi wrote:
> Cast the pointer to unsigned long and let it be implicitly extended to
> u64. This fixes the build on 32bits arch.
>
> Cc: Matthew Brost
> Cc: Niranjana Vishwanathapura
> Cc: Rodrigo Vivi
> Signed-off-by: Lucas De Marchi
On Tue, Jan 16, 2024 at 09:40:48AM -0800, Lucas De Marchi wrote:
> readq() is not available in 32bits. iosys-map already has the logic in
> place to use read u64 in all cases, so simply add a helper variable for
> using that.
>
> Fixes: 44e694958b95 ("drm/xe/display: Implement display support")
>
The pull request you sent on Mon, 15 Jan 2024 16:18:01 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2024-01-15-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8893a6bfff312ea6fee89bfaa8761f0b9456199b
Thank you!
--
Deet-doot-dot, I am a bot.
On Tue, Jan 16, 2024 at 09:40:47AM -0800, Lucas De Marchi wrote:
> resource_size_t uses %pa format in printk since the size varies
> depending on build options. However to keep the io_size/physical_size
> addition in the same call we can't pass the address without adding yet
> another variable in
On Tue, Jan 16, 2024 at 09:40:46AM -0800, Lucas De Marchi wrote:
> Use DIV_ROUND_UP_ULL() so it also works on 32bit build.
>
> Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
> Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Roper
> ---
>
On Wed, Jan 17, 2024 at 02:13:42PM -0600, Rob Herring wrote:
> On Tue, Jan 16, 2024 at 07:11:40PM +0530, Devarsh Thakkar wrote:
> > Add support for using TI Keystone DSS hardware present in display
> > sharing mode.
> >
> > TI Keystone DSS hardware supports partitioning of resources between
> >
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:
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
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
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
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
Signed-off-by: Oak Zeng
---
include/uapi/drm/xe_drm.h | 40 +++
1 file changed, 40 insertions(+)
diff --git a/include/uapi/drm/xe_drm.h b/include/uapi/drm/xe_drm.h
index 50bbea0992d9..551ed8706097 100644
--- a/include/uapi/drm/xe_drm.h
+++
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
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
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
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
---
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
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
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.
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
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
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
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
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
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
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
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
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 +++
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
Hi Thomas,
kernel test robot noticed the following build errors:
[auto build test ERROR on 05b317e8457c8e2bd1a797c9440ec07b7f341584]
url:
https://github.com/intel-lab-lkp/linux/commits/Thomas-Zimmermann/video-cmdline-Introduce-CONFIG_VIDEO-for-video-parameter/20240115-181419
base:
From: Dave Airlie
nvif_vmm_put gets called if addr is set, but if the allocation
fails we don't need to call put, otherwise we get a warning like
[523232.435671] [ cut here ]
[523232.435674] WARNING: CPU: 8 PID: 1505697 at
drivers/gpu/drm/nouveau/nvif/vmm.c:68
MSA MISC0 bit 1 to 7 contains Colorimetry Indicator Field.
dp_link_get_colorimetry_config() returns wrong colorimetry value
in the DP_TEST_DYNAMIC_RANGE_CEA case in the current implementation.
Hence fix this problem by having dp_link_get_colorimetry_config()
return defined CEA RGB colorimetry
Am 17.01.24 um 17:50 schrieb Hans de Goede:
Hi All,
On 11/27/23 11:59, Werner Sembach wrote:
I also stumbled across a new Problem:
We have an upcoming device that has a per-key keyboard backlight, but does the
control completely via a wmi/acpi interface. So no usable hidraw here for a
On Wed, 17 Jan 2024 at 21:41, Abhinav Kumar wrote:
>
> The commit 8b45a26f2ba9 ("drm/msm/dpu: reserve cdm blocks for writeback
> in case of YUV output") introduced a smatch warning about another
> conditional block in dpu_encoder_helper_phys_cleanup() which had assumed
> hw_pp will always be
On Tue, Jan 16, 2024 at 07:11:40PM +0530, Devarsh Thakkar wrote:
> Add support for using TI Keystone DSS hardware present in display
> sharing mode.
>
> TI Keystone DSS hardware supports partitioning of resources between
> multiple hosts as it provides separate register space and unique
>
Hi,
On Wed, Jan 17, 2024 at 11:39 AM Hsin-Yi Wang wrote:
>
> On Wed, Jan 17, 2024 at 10:35 AM Douglas Anderson
> wrote:
> >
> > After commit 26db46bc9c67 ("drm/bridge: parade-ps8640: Ensure bridge
> > is suspended in .post_disable()"), if we hit the error case in
> > ps8640_aux_transfer() then
Hi,
Le mercredi 06 décembre 2023 à 16:15 +0800, Yunfei Dong a écrit :
> From: Jeffrey Kardatzke
>
> Adds documentation for V4L2_MEMORY_FLAG_SECURE.
As I noticed from DMA Heap discussions, shall this also be renamed SECURE ->
RESTRICTED ?
regards,
Nicolas
>
> Signed-off-by: Jeffrey Kardatzke
The commit 8b45a26f2ba9 ("drm/msm/dpu: reserve cdm blocks for writeback
in case of YUV output") introduced a smatch warning about another
conditional block in dpu_encoder_helper_phys_cleanup() which had assumed
hw_pp will always be valid which may not necessarily be true.
Lets fix the other
On Wed, Jan 17, 2024 at 10:35 AM Douglas Anderson wrote:
>
> After commit 26db46bc9c67 ("drm/bridge: parade-ps8640: Ensure bridge
> is suspended in .post_disable()"), if we hit the error case in
> ps8640_aux_transfer() then we return without dropping the mutex. Fix
> this oversight.
>
> Fixes:
> kasprintf() returns a pointer to dynamically allocated memory
> which can be NULL upon failure. Ensure the allocation was successful
> by checking the pointer validity.
…
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -144,6 +144,10 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu,
>
On 1/17/2024 10:40 AM, Dmitry Baryshkov wrote:
On Wed, 17 Jan 2024 at 20:29, Kuogee Hsieh wrote:
On 1/17/2024 10:12 AM, Dmitry Baryshkov wrote:
On Wed, 17 Jan 2024 at 19:54, Kuogee Hsieh wrote:
MSA MISC0 bit 1 to 7 contains Colorimetry Indicator Field. At
current implementation, at
This makes it possible to understand the dependencies between jobs.
Possible usage of this trace:
* stuttering issues like Mesa !9189
* incorrect synchronization: I don't have a link for this one, but having
these events was very useful to debug a virtio-gpu / native-context /
radeonsi sync
This new event can be used to trace where a given dma_fence is added
as a dependency of some other work.
I plan to use it in amdgpu.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/dma-buf/dma-fence.c | 1 +
include/trace/events/dma_fence.h | 34
2
On Wed, 17 Jan 2024 at 20:29, Kuogee Hsieh wrote:
>
>
> On 1/17/2024 10:12 AM, Dmitry Baryshkov wrote:
> > On Wed, 17 Jan 2024 at 19:54, Kuogee Hsieh wrote:
> >> MSA MISC0 bit 1 to 7 contains Colorimetry Indicator Field. At
> >> current implementation, at DP_TEST_DYNAMIC_RANGE_CEA case the
> >
Hi,
On Wed, Jan 17, 2024 at 9:34 AM Doug Anderson wrote:
>
> Hi,
>
> On Tue, Jan 9, 2024 at 8:52 AM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Tue, Jan 9, 2024 at 4:05 AM Pin-yen Lin wrote:
> > >
> > > The ps8640 bridge seems to expect everything to be power cycled at the
> > > disable
After commit 26db46bc9c67 ("drm/bridge: parade-ps8640: Ensure bridge
is suspended in .post_disable()"), if we hit the error case in
ps8640_aux_transfer() then we return without dropping the mutex. Fix
this oversight.
Fixes: 26db46bc9c67 ("drm/bridge: parade-ps8640: Ensure bridge is suspended in
On Tue, Jan 16, 2024 at 7:12 PM Erico Nunes wrote:
>
> Make the messages more consistent by showing the pp name.
>
> Signed-off-by: Erico Nunes
Reviewed-by: Vasily Khoruzhick
> ---
> drivers/gpu/drm/lima/lima_pp.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git
On Tue, Jan 16, 2024 at 7:12 PM Erico Nunes wrote:
>
> Marking the context as guilty currently only makes the application which
> hits a single timeout problem to stop its rendering context entirely.
> All jobs submitted later are dropped from the guilty context.
>
> Lima runs on fairly
On 1/17/2024 10:12 AM, Dmitry Baryshkov wrote:
On Wed, 17 Jan 2024 at 19:54, Kuogee Hsieh wrote:
MSA MISC0 bit 1 to 7 contains Colorimetry Indicator Field. At
current implementation, at DP_TEST_DYNAMIC_RANGE_CEA case the
In the current implementation, in the ... case
Colorimetry Indicator
On Tue, Jan 16, 2024 at 7:12 PM Erico Nunes wrote:
>
> There are several unexplained and unreproduced cases of rendering
> timeouts with lima, for which one theory is high IRQ latency coming from
> somewhere else in the system.
> This kind of occurrence may cause applications to trigger
On Tue, Jan 16, 2024 at 7:12 PM Erico Nunes wrote:
>
> This is required for reliable hard resets. Otherwise, doing a hard reset
> while a task is still running (such as a task which is being stopped by
> the drm_sched timeout handler) may result in random mmu write timeouts
> or lockups which
On Tue, Jan 16, 2024 at 7:12 PM Erico Nunes wrote:
>
> Lima pp jobs use an async reset to avoid having to wait for the soft
> reset right after a job. The soft reset is done at the end of a job and
> a reset_complete flag is expected to be set at the next job.
> However, in case the user runs
On Tue, Jan 16, 2024 at 7:12 PM Erico Nunes wrote:
>
> In case a task manages to complete but it took just long enough to also
> trigger the timeout handler, the current code results in a refcount
> imbalance on lima_pm_idle.
>
> While this can be a rare occurrence, when it happens it may fill
On Wed, 17 Jan 2024 at 19:54, Kuogee Hsieh wrote:
>
> MSA MISC0 bit 1 to 7 contains Colorimetry Indicator Field. At
> current implementation, at DP_TEST_DYNAMIC_RANGE_CEA case the
In the current implementation, in the ... case
> Colorimetry Indicator Field is mistakenly left shifted one extra
>
DMA buffers allocated from the CMA dma-buf heap get counted under
RssFile for processes that map them and trigger page faults. In
addition to the incorrect accounting reported to userspace, reclaim
behavior was influenced by the MM_FILEPAGES counter until linux 6.8, but
this memory is not
MSA MISC0 bit 1 to 7 contains Colorimetry Indicator Field. At
current implementation, at DP_TEST_DYNAMIC_RANGE_CEA case the
Colorimetry Indicator Field is mistakenly left shifted one extra
bit. This patch return correct value of colorimetry at
dp_link_get_colorimetry_config() to fix this problem.
Hi Jani and Maxime
On 1/17/2024 2:16 AM, Jani Nikula wrote:
On Wed, 17 Jan 2024, Maxime Ripard wrote:
Hi,
On Tue, Jan 16, 2024 at 02:22:03PM -0800, Jessica Zhang wrote:
This series introduces a simulated MIPI DSI panel.
Currently, the only way to validate DSI connectors is with a physical
Hi,
On Tue, Jan 9, 2024 at 8:52 AM Doug Anderson wrote:
>
> Hi,
>
> On Tue, Jan 9, 2024 at 4:05 AM Pin-yen Lin wrote:
> >
> > The ps8640 bridge seems to expect everything to be power cycled at the
> > disable process, but sometimes ps8640_aux_transfer() holds the runtime
> > PM reference and
Hi All,
On 11/27/23 11:59, Werner Sembach wrote:
> I also stumbled across a new Problem:
>
> We have an upcoming device that has a per-key keyboard backlight, but does
> the control completely via a wmi/acpi interface. So no usable hidraw here for
> a potential userspace driver
On 17/01/2024 16:26, Jani Nikula wrote:
On Thu, 04 Jan 2024, Jocelyn Falempe wrote:
This is needed for drm_panic, to draw the font, and fill
the background color, in multiple color format.
v5:
* Change the drawing API, use drm_fb_blit_from_r1() to draw the font.
* Also add
On 17/01/2024 16:06, Thomas Zimmermann wrote:
Hi
Am 04.01.24 um 17:00 schrieb Jocelyn Falempe:
This is needed for drm_panic, to draw the font, and fill
the background color, in multiple color format.
TBH, I don't like this patch at all. It looks like you're reimplementing
existing
On 1/10/24 2:29 AM, Tony Lindgren wrote:
* Andrew Davis [240109 17:20]:
--- a/arch/arm/boot/dts/ti/omap/dra7.dtsi
+++ b/arch/arm/boot/dts/ti/omap/dra7.dtsi
@@ -850,12 +850,19 @@ target-module@5600 {
;
ti,sysc-sidle = ,
Hi
Am 04.01.24 um 17:00 schrieb Jocelyn Falempe:
[...]
+ /**
+* @get_scanout_buffer:
+*
+* Get the current scanout buffer, to display a panic message with
drm_panic.
+* The driver should do the minimum changes to provide a linear buffer,
that
+* can
1 - 100 of 171 matches
Mail list logo
