Hi all,
Sorry for my late reply. I don't know if you still remember this thread, let me
give a quick summary:
1. We want to implement the dGPU prime feature in guest VM. But we
encountered this issue: virtio-gpu doesn’t have ->get_sg_table implemented
which is required by drm_gem_map_attach
[+cc Alex]
On Fri, Nov 29, 2024 at 06:42:18AM +1000, Dave Airlie wrote:
Alex Deucher (3):
drm/amdgpu/jpeg: cancel the jpeg worker
Hi folks,
When merging this PR into linus-next I've started the following warning
triggered by the commit above:
[4.356975] WARNING: CPU: 1 PID: 1 at ker
On 2024/11/26 6:08, Dmitry Baryshkov wrote:
On Mon, 25 Nov 2024 at 09:39, fange zhang wrote:
On 2024/11/22 18:22, Dmitry Baryshkov wrote:
On Fri, Nov 22, 2024 at 05:56:52PM +0800, Fange Zhang wrote:
From: Li Liu
Add display MDSS and DSI configuration for QCS615 RIDE board.
QCS615 has
On Thu, Nov 28, 2024 at 2:46 AM Sui Jingfeng wrote:
>
> Hi,
>
> On 2024/11/27 17:58, Chen-Yu Tsai wrote:
> > Revisiting this thread since I just stepped on the same problem on a
> > different device.
> >
> > On Thu, Nov 14, 2024 at 9:12 PM Maxime Ripard wrote:
> >> On Tue, Oct 29, 2024 at 10:53:4
From: Ville Syrjälä
We no longer store a cache vrefresh value in the mode.
Remove the stale information from drm_vrefresh() docs.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_modes.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/dri
From: Ville Syrjälä
drm_mode_vrefresh() is trying to avoid divide by zero
by checking whether htotal or vtotal are zero. But we may
still end up with a div-by-zero of vtotal*htotal*...
Cc: sta...@vger.kernel.org
Reported-by: syzbot+622bba18029bcde67...@syzkaller.appspotmail.com
Closes: https://s
From: Ville Syrjälä
Fix a potential div-by-zero in drm_mode_vrefresh()
TODO: should probably make drm_mode_setcrtc() not even print the
(potentially partially) converted mode, and instead print
the original umode..
Test-with: 20241128190927.26033-1-ville.syrj...@linux.intel.com
Vil
On 11/13/24 1:45 PM, John Watts wrote:
> It really seems like the code means mixers here.
True, I was wrong about my statement. But with A133, the case of independent DE
is unique, which I couldn't test yet.
> If my thoughts are correct, this would break use of mixer0 and mixer1 at the
> same time
Thanks for the feedback, the problem is anyway real breaking userspace apps
if my patch is not in use. I have actually spend this day for investigating
and testing another gpu hang bug that has been reported originally by
others on gfx1010/AMD RX 5700. I thought originally that the bug is
different
Hi Heiko,
On 2024/11/27 19:04, Heiko Stübner wrote:
Hi Damon,
Am Mittwoch, 27. November 2024, 12:00:10 CET schrieb Damon Ding:
Hi Heiko:
On 2024/11/27 17:29, Heiko Stübner wrote:
Hi Damon,
Am Mittwoch, 27. November 2024, 08:51:51 CET schrieb Damon Ding:
Add basic support for RBR/HBR/HBR2 l
On 11/28/2024, Sui Jingfeng wrote:
> Hi,
Hi,
>
> On 2024/11/25 17:33, Liu Ying wrote:
>> i.MX8qxp Display Controller display engine consists of all processing
>> units that operate in a display clock domain. Add minimal feature
>> support with FrameGen and TCon so that the engine can output dis
Matthew Brost writes:
[...]
> + * 3) Invalidation driver vfunc.
> + *
> + * void driver_invalidation(struct drm_gpusvm *gpusvm,
> + *struct drm_gpusvm_notifier *notifier,
> + *const struct mmu_notifier_range *mmu_range)
> + * {
> + *
Matthew Brost writes:
> Avoid multiple CPU page faults to the same device page racing by trying
> to lock the page in do_swap_page before taking an extra reference to the
> page. This prevents scenarios where multiple CPU page faults each take
> an extra reference to a device page, which could
> Here's a first attempt to address this bug. Could you please apply the
> attached patch and report on the results? It should work against the
> upcoming v6.13-rc1 or against a recent drm-misc-next.
Hi. No luck yet.
I collected crashes before the patch:
BUG: Bad page map in process husband pte
Hi Arun,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-intel/for-linux-next-fixes]
[also build test WARNING on v6.12 next-20241128]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
When mapping the pages of a BO, either a heap type at page fault time or
else a non-heap BO at object creation time, if the ARM page table mapping
function fails, we unmap what had been mapped so far and bail out.
Signed-off-by: Adrián Larumbe
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 44 +++
This is v2 of
https://lore.kernel.org/dri-devel/20241014233758.994861-1-adrian.laru...@collabora.com/
This patch series is a collection of minor fixes and improvements I came up
with while working on driver related stuff.
Changelog:
v2:
- Removed commit that provided an explicit fence cleanup
This is to make LLVM syntactic analysers happy.
Signed-off-by: Adrián Larumbe
---
drivers/gpu/drm/panfrost/panfrost_mmu.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.h
b/drivers/gpu/drm/panfrost/panfrost_mmu.h
index e6e6966a0cca..27c3c65ed074 100644
Avoid waiting for the DRM scheduler job timedout handler, and instead, let
the DRM scheduler core signal the error fence immediately when HW job
submission fails.
That means we must also decrement the runtime-PM refcnt for the device,
because the job will never be enqueued or inflight.
Signed-off
Just in case we're dealing with a yet not recognised device.
Signed-off-by: Adrián Larumbe
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_gpu.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c
b/driver
The as_in_use_mask device state variable is no longer in use.
Signed-off-by: Adrián Larumbe
---
drivers/gpu/drm/panfrost/panfrost_device.h | 1 -
drivers/gpu/drm/panfrost/panfrost_mmu.c| 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
b/drivers/
Rather than remasking interrupts after a device reset in the main reset
path, allow selecting whether to do this with an additional bool parameter.
To this end, split reenabling job interrupts into two functions, one that
clears the interrupts and another one which unmasks them conditionally.
Sig
If we reach the beginning of the LRU AS list, then return an error.
Signed-off-by: Adrián Larumbe
---
drivers/gpu/drm/panfrost/panfrost_job.c | 6 +-
drivers/gpu/drm/panfrost/panfrost_mmu.c | 5 +++--
drivers/gpu/drm/panfrost/panfrost_mmu.h | 2 +-
drivers/gpu/drm/panfrost/panfro
Drop the deprecated DRM driver allocation method in favour of
devm_drm_dev_alloc(). Overall just make it the same as in Panthor.
Also discard now superfluous generic and platform device pointers inside
the main panfrost device structure.
Some ancient checkpatch issues unearthed as a result of thes
On Fri, 15 Nov 2024 16:11:31 +0100, Heiko Stuebner wrote:
> The clock is in Hz while the value checked against is in kHz, so
> actual frequencies will never be able to be below to max value.
> Fix this by specifying the max-value in Hz too.
>
>
Applied, thanks!
[1/1] drm/rockchip: vop2: fix r
From: John Harrison
Adding lockdep checking to the coredump code showed that there was an
existing violation. The dev_coredumpm_timeout() call is used to
register the dump with the base coredump subsystem. However, that
makes multiple memory allocations, only some of which use the GFP_
flags pass
BO validation during vm_bind could trigger memory eviction when
system runs under memory pressure. Right now we blindly evict
BOs of all VMs. This scheme has a problem when system runs in
none recoverable page fault mode: even though the vm_bind could
be successful by evicting BOs, the later the re
Hi Linus,
Merge window fixes, mostly amdgpu and xe, with a few other minor ones,
all looks fairly normal,
Dave.
drm-next-2024-11-29:
drm fixes for v6.13-rc1
i915:
- hdcp: Fix when the first read and write are retried
xe:
- Wake up waiters after wait condition set to true
- Mark the preempt fen
Add a helper to check if the memory stats is zero, this will be used to
check for memory accounting errors.
Signed-off-by: Yunxiang Li
Reviewed-by: Christian König
CC: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/drm_file.c | 10 ++
include/drm/drm_file.h | 1 +
2 files chan
Define how to handle buffers with multiple possible placement so we
don't get incompatible implementations. Callout the resident requirement
for drm-purgeable- explicitly. Remove the confusing requirement for
there to be only drm-memory- or only drm-resident-, and clarify that
drm-memory- is legacy
When memory stats is generated fresh everytime by going though all the
BOs, their active information is quite easy to get. But if the stats are
tracked with BO's state this becomes harder since the job scheduling
part doesn't really deal with individual buffers.
Make drm-active- optional to enable
Hi!
Julian Orth reported at
https://bugzilla.kernel.org/show_bug.cgi?id=219106 that
udmabuf_create() checks for F_SEAL_WRITE in a racy way, so a udmabuf
can end up holding references to pages in a write-sealed memfd, which
theoretically breaks one of the security properties of memfd sealing.
See a
Hi
Am 11.11.24 um 14:42 schrieb Nuno Gonçalves:
On Mon, Nov 11, 2024 at 1:22 PM Thomas Zimmermann wrote:
The patch in question changes the whole memory management of the
affected code. It's also noteworthy that most of it has been reworked
for the upcoming v6.12. Maybe this already fixed the p
Hi Dave, Simona
An all-Matt drm-xe-next-fixes PR this week.
Thanks,
Thomas
drm-xe-next-fixes-2024-11-28:
Driver Changes:
- Update xe2 graphics name string (Matt Roper)
- Fix a couple of guc submit races (Matt Auld)
- Fix pat index usage in migrate (Matt Auld)
- Ensure non-cached migrate pagetabl
This series introduces device wedged event in DRM subsystem and uses
it in xe and i915 drivers. Detailed description in commit message.
This was earlier attempted as xe specific uevent in v1 and v2.
https://patchwork.freedesktop.org/series/136909/
Similar work by André Almeida.
https://lore.kerne
Now that we have device wedged event provided by DRM core, make use
of it and support both driver rebind and bus-reset based recovery.
With this in place, userspace will be notified of wedged device on
gt reset failure.
Signed-off-by: Raag Jadav
Reviewed-by: Aravind Iddamsetty
---
drivers/gpu/d
Introduce device wedged event, which notifies userspace of 'wedged'
(hanged/unusable) state of the DRM device through a uevent. This is
useful especially in cases where the device is no longer operating as
expected and has become unrecoverable from driver context. Purpose of
this implementation is
Add documentation for device wedged event in a new 'Device wedging'
chapter. The describes basic definitions, prerequisites and consumer
expectations along with an example.
v8: Improve documentation (Christian, Rodrigo)
v9: Add prerequisites section (Christian)
v10: Clarify mmap cleanup and cons
This was previously attempted as xe specific reset uevent but dropped
in commit 77a0d4d1cea2 ("drm/xe/uapi: Remove reset uevent for now")
as part of refactoring.
Now that we have device wedged event provided by DRM core, make use
of it and support both driver rebind and bus-reset based recovery.
W
Add restricted memory allocation to the TEE subsystem. Restricted memory
is not be accessible by kernel during normal circumstances. A new ioctl
TEE_IOC_RSTMEM_ALLOC is added to allocate these restricted memory
buffers.
The restricted memory is allocated for a specific use-case, like Secure
Video
Add support in the OP-TEE backend driver for restricted memory
allocation.
The restricted memory can be allocated from a static carveout, but also
be dynamically allocated from CMA and turned into restricted memory by
OP-TEE, inaccessible by the kernel. The restricted memory configuration
is depen
The OP-TEE backend driver has two internal function pointers to convert
between the subsystem type struct tee_param and the OP-TEE type struct
optee_msg_param.
The conversion is done from one of the types to the other, which is then
involved in some operation and finally converted back to the orig
Update the header files describing the secure world ABI, both with and
without FF-A. The ABI is extended to deal with restricted memory, but as
usual backward compatible.
Signed-off-by: Jens Wiklander
---
drivers/tee/optee/optee_ffa.h | 27 ++---
drivers/tee/optee/optee_msg.h | 65 ++
Hi,
This patch set allocates the restricted DMA-bufs via the TEE subsystem.
This a big update compared to the previous patch set [1].
The TEE subsystem handles the DMA-buf allocations since it is the TEE
(OP-TEE, AMD-TEE, TS-TEE, or perhaps a future QTEE) which sets up the
restrictions for the me
Hi Lyude,
> On 30 Sep 2024, at 20:10, Lyude Paul wrote:
>
> A binding for checking drm_device.num_crtcs. We'll need this in a moment
> for vblank support, since setting it up requires knowing the number of
> CRTCs that a driver has initialized.
>
> Signed-off-by: Lyude Paul
> ---
> rust/kernel
Hi Lyude,
> On 30 Sep 2024, at 20:10, Lyude Paul wrote:
>
> This is just a crate-private helper to use Lock::from_raw() to provide an
> immutable reference to the DRM event_lock, so that it can be used like a
> normal rust spinlock. We'll need this for adding vblank related bindings.
>
> Signed
Hi Lyude
> On 30 Sep 2024, at 20:10, Lyude Paul wrote:
>
> Optional trait methods for implementing the atomic_enable and
> atomic_disable callbacks of a CRTC.
>
> Signed-off-by: Lyude Paul
> ---
> rust/kernel/drm/kms/crtc.rs | 76 -
> 1 file changed, 74 inser
Hi Lyude,
> On 30 Sep 2024, at 20:10, Lyude Paul wrote:
>
> Optional trait methods for implementing the atomic_begin and atomic_flush
> callbacks for a CRTC.
>
> Signed-off-by: Lyude Paul
> ---
> rust/kernel/drm/kms/crtc.rs | 78 -
> 1 file changed, 76 insert
Hi Lyude,
> On 30 Sep 2024, at 20:10, Lyude Paul wrote:
>
> Returns the Framebuffer currently assigned in an atomic plane state.
A bit unrelated to this patch, but can you have more than one framebuffer
active?
i.e.: for things like overlays, etc
>
> Signed-off-by: Lyude Paul
> ---
> rust
On Thu, Nov 28, 2024 at 11:57:16AM +0100, Andrej Picej wrote:
> Hi Maxime,
>
> On 28. 11. 24 11:29, Maxime Ripard wrote:
> > On Thu, Nov 28, 2024 at 09:46:33AM +0100, Andrej Picej wrote:
> > > On 27. 11. 24 16:16, Rob Herring wrote:
> > > > On Wed, Nov 27, 2024 at 11:30:29AM +0100, Andrej Picej wr
> On 30 Sep 2024, at 20:10, Lyude Paul wrote:
>
> This adds some very simple bindings for drm_framebuffer. We don't use them
> much yet, but we'll eventually be using them when rvkms eventually gets CRC
> and writeback support. Just like Connector objects, these use RcModeObject.
Yeah, for th
On Thu, Nov 28, 2024 at 04:46:53PM +0800, Sui Jingfeng wrote:
> Hi,
>
> On 2024/11/25 17:33, Liu Ying wrote:
> > i.MX8qxp Display Controller display engine consists of all processing
> > units that operate in a display clock domain. Add minimal feature
> > support with FrameGen and TCon so that t
On 28/11/2024 14:26, Dmitry Baryshkov wrote:
On Thu, Nov 28, 2024 at 11:25:46AM +0100, Neil Armstrong wrote:
Each GPU OPP requires a specific peak DDR bandwidth, let's add
those to each OPP and also the related interconnect path.
Signed-off-by: Neil Armstrong
---
arch/arm64/boot/dts/qcom/sm8
Hi Lyude,
> On 30 Sep 2024, at 20:10, Lyude Paul wrote:
>
> Add a binding for drm_atomic_helper_check_plane_state(). Since we want to
> make sure that the user is passing in the new state for a Crtc instead of
> an old state, we explicitly ask for a reference to a BorrowedCrtcState.
>
> Signed-
Hi Dave, Sima,
here's the PR of drm-misc-fixes for this week. The first two patches
are from last weeks PR drm-misc-fixes-2024-11-21, which should be merged
first.
Best regards
Thomas
drm-misc-fixes-2024-11-28:
Short summary of fixes pull:
dma-buf:
- Fix dma_fence_array_signaled() to ensure for
Hi Lyude
> On 30 Sep 2024, at 20:10, Lyude Paul wrote:
>
> Add a binding for checking drm_plane_state.crtc. Note that we don't have a
> way of knowing what DriverCrtc implementation would be used here (and want
> to make this function also available on OpaquePlaneState types), so we
> return an
Hi Lyude,
> On 30 Sep 2024, at 20:10, Lyude Paul wrote:
>
> A binding for checking drm_crtc_state.active.
>
> Signed-off-by: Lyude Paul
> ---
> rust/kernel/drm/kms/crtc.rs | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/rust/kernel/drm/kms/crtc.rs b/rust/kernel/drm/kms/crtc.rs
> On 30 Sep 2024, at 20:10, Lyude Paul wrote:
>
> A mandatory trait method used for implementing DRM's atomic plane update
> callback.
>
> Signed-off-by: Lyude Paul
> ---
> rust/kernel/drm/kms/plane.rs | 39 +++-
> 1 file changed, 38 insertions(+), 1 deletion(-
Hi Lyude,
> On 30 Sep 2024, at 20:10, Lyude Paul wrote:
>
> Optional trait method for implementing a plane's atomic_check().
>
> Signed-off-by: Lyude Paul
> ---
> rust/kernel/drm/kms/plane.rs | 41 +++-
> 1 file changed, 40 insertions(+), 1 deletion(-)
>
> diff
Hi Lyude,
> On 30 Sep 2024, at 20:10, Lyude Paul wrote:
>
> A mandatory trait method used for implementing DRM's atomic plane update
> callback.
>
> Signed-off-by: Lyude Paul
> ---
> rust/kernel/drm/kms/plane.rs | 39 +++-
> 1 file changed, 38 insertions(+), 1 de
Hi Lyude,
> On 30 Sep 2024, at 20:10, Lyude Paul wrote:
>
> An optional trait method for implementing a CRTC's atomic state check.
A more thorough explanation like you had in your last patch would be nice here.
By `atomic state check` you mean after the state has been duplicated, and
mutated,
On Thu, Nov 28, 2024 at 11:25:45AM +0100, Neil Armstrong wrote:
> Now all the DDR bandwidth voting via the GPU Management Unit (GMU)
> is in place, declare the Bus Control Modules (BCMs) and the
> corresponding parameters in the GPU info struct and add the
> GMU_BW_VOTE feature bit to enable it.
>
On Thu, Nov 28, 2024 at 11:25:47AM +0100, Neil Armstrong wrote:
> Each GPU OPP requires a specific peak DDR bandwidth, let's add
> those to each OPP and also the related interconnect path.
>
> Signed-off-by: Neil Armstrong
> ---
> arch/arm64/boot/dts/qcom/sm8650.dtsi | 14 ++
> 1 fil
On Thu, Nov 28, 2024 at 11:25:46AM +0100, Neil Armstrong wrote:
> Each GPU OPP requires a specific peak DDR bandwidth, let's add
> those to each OPP and also the related interconnect path.
>
> Signed-off-by: Neil Armstrong
> ---
> arch/arm64/boot/dts/qcom/sm8550.dtsi | 11 +++
> 1 file c
On Thu, Nov 28, 2024 at 11:25:41AM +0100, Neil Armstrong wrote:
> Even if the code uses ARRAY_SIZE() to fill those tables,
> it's still a best practice to not use magic values for
> tables in structs.
>
> Suggested-by: Dmitry Baryshkov
> Signed-off-by: Neil Armstrong
> ---
> drivers/gpu/drm/msm
Hi Dave, Simona,
A pull request with a single obvious patch in it. Consequently it's very likely
to break the world and everything in it. As famous last words I'll add: "the
affected source file seems to compile on 32-bits and 64-bits x86".
Cheers,
~Maarten
drm-misc-next-fixes-2024-11-28:
A si
looks good
On Fri, Nov 15, 2024 at 11:35 PM Easwar Hariharan
wrote:
>
> Changes made with the following Coccinelle rules:
>
> @@ constant C; @@
>
> - msecs_to_jiffies(C * 1000)
> + secs_to_jiffies(C)
>
> @@ constant C; @@
>
> - msecs_to_jiffies(C * MSEC_PER_SEC)
> + secs_to_jiffies(C)
>
> Signed-
looks good
On Sat, Nov 16, 2024 at 12:32 AM Easwar Hariharan
wrote:
>
> Changes made with the following Coccinelle rules:
>
> @@ constant C; @@
>
> - msecs_to_jiffies(C * 1000)
> + secs_to_jiffies(C)
>
> @@ constant C; @@
>
> - msecs_to_jiffies(C * MSEC_PER_SEC)
> + secs_to_jiffies(C)
>
> Signed-
Hi Jiasheng,
On Wed, Nov 27, 2024 at 08:10:42PM +, Jiasheng Jiang wrote:
> From: Jiasheng Jiang
>
> Replace "slab_priorities" with "slab_dependencies" in the error handler
> to avoid memory leak.
>
> Fixes: 32eb6bcfdda9 ("drm/i915: Make request allocation caches global")
> Cc: # v5.2+
> Re
On Thu, 21 Nov 2024, Antheas Kapenekakis wrote:
> Add a sysfs attribute to allow informing the kernel about the current
> standby state, those being: "active", "screen_off", "sleep", and
> "resume" (to prepare turning the display on). The final modern
> standby state DRIPS is omitted, as that is e
On 13/11/2024 11:26, AngeloGioacchino Del Regno wrote:
> The MediaTek MT8188 SoC has a Mali-G57 MC3 GPU and, similarly to
> MT8192, it has yet another special GPU ID.
>
> Add the GPU ID to the list and treat it as a standard Mali-G57.
>
> Signed-off-by: AngeloGioacchino Del Regno
>
Pushed to d
Hi Heiko,
kernel test robot noticed the following build errors:
[auto build test ERROR on linus/master]
[also build test ERROR on v6.12 next-20241128]
[cannot apply to rockchip/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest
When the runtime PM resume callback returns an error, it puts the device
in a state where it can't be resumed anymore. Make sure we can recover
from such transient failures by calling pm_runtime_set_suspended()
explicitly after a pm_runtime_resume_and_get() failure.
v2:
- Add a comment explaining
Forgot to CC PHYTEC upstream mailing list. Doing this now.
On 27. 11. 24 11:30, Andrej Picej wrote:
Hi all,
This patch series depends on the patch
"[PATCH 11/15] arm64: dts: imx8mm-phyboard-polis: Add support for PEB-AV-10"
(https://lore.kernel.org/linux-arm-kernel/20241125081814.397352-12-andr
Hello,
Here's a collection of patches improving robustness to failures in
the device resume/suspend path. Those failures are pretty hard to
reproduce (happens once in a while on a deqp-vk run), so I used a
mechanism to fake them.
Faking a FW boot failure is kinda tricky though, which means the
la
devfreq_{resume,suspend}_device() don't bother undoing the suspend_count
modifications if something fails, so either it assumes failures are
harmless, or it's super fragile/buggy. In either case it's not something
we can address at the driver level, so let's just assume failures are
harmless for no
WARN() will return true if the condition is true, false otherwise.
If we store the return of drm_WARN_ON() in ret, we lose the actual
error code.
v2:
- Add R-b
Fixes: 5fe909cae118 ("drm/panthor: Add the device logical block")
Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
---
drivers
The runtime PM resume operation is not guaranteed to succeed, but if it
fails, the device should be in a suspended state. Make sure we're robust
to resume failures in the unplug path.
v2:
- Move the bit that belonged in the next commit
- Drop the panthor_device_unplug() changes
Signed-off-by: Bor
If we do a GPU soft-reset, that's no longer fast reset. This also means
the slow reset fallback doesn't work because the MCU state is only reset
after a GPU soft-reset.
Let's move the retry logic to panthor_device_resume() to issue a
soft-reset between the fast and slow attempts, and patch
panthor
Hi Maxime,
On 28. 11. 24 11:29, Maxime Ripard wrote:
On Thu, Nov 28, 2024 at 09:46:33AM +0100, Andrej Picej wrote:
On 27. 11. 24 16:16, Rob Herring wrote:
On Wed, Nov 27, 2024 at 11:30:29AM +0100, Andrej Picej wrote:
From: Janine Hagemann
Add an optional property to change LVDS output volta
On Wed, Nov 27, 2024 at 02:19:32PM +0100, Christian König wrote:
> Am 26.11.24 um 18:46 schrieb Matthew Brost:
> > Non-contiguous VRAM cannot easily be mapped in TTM nor can non-visible
> > VRAM easily be accessed. Add ttm_bo_access, which is similar to
> > ttm_bo_vm_access, to access such memory.
Il 28/11/24 07:02, CK Hu (胡俊光) ha scritto:
Hi, Angelo:
On Wed, 2024-11-20 at 13:45 +0100, AngeloGioacchino Del Regno wrote:
External email : Please do not click links or open attachments until you have
verified the sender or the content.
Add a binding for the HDMI TX v2 Encoder found in Medi
Il 28/11/24 04:08, CK Hu (胡俊光) ha scritto:
On Wed, 2024-11-27 at 13:44 +0100, AngeloGioacchino Del Regno wrote:
External email : Please do not click links or open attachments until you have
verified the sender or the content.
Il 27/11/24 10:04, CK Hu (胡俊光) ha scritto:
On Wed, 2024-11-27 at 0
On Thu, Nov 28, 2024 at 09:46:33AM +0100, Andrej Picej wrote:
> On 27. 11. 24 16:16, Rob Herring wrote:
> > On Wed, Nov 27, 2024 at 11:30:29AM +0100, Andrej Picej wrote:
> > > From: Janine Hagemann
> > >
> > > Add an optional property to change LVDS output voltage. This depends on
> > > the conne
The Adreno GPU Management Unit (GMU) can also scale the ddr
bandwidth along the frequency and power domain level, but for
now we statically fill the bw_table with values from the
downstream driver.
Only the first entry is used, which is a disable vote, so we
currently rely on scaling via the linux
The Adreno GPU Management Unit (GMU) can also scale DDR Bandwidth along
the Frequency and Power Domain level, but by default we leave the
OPP core scale the interconnect ddr path.
While scaling via the interconnect path was sufficient, newer GPUs
like the A750 requires specific vote paremeters and
Each GPU OPP requires a specific peak DDR bandwidth, let's add
those to each OPP and also the related interconnect path.
Signed-off-by: Neil Armstrong
---
arch/arm64/boot/dts/qcom/sm8550.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi
b
Now all the DDR bandwidth voting via the GPU Management Unit (GMU)
is in place, declare the Bus Control Modules (BCMs) and the
corresponding parameters in the GPU info struct and add the
GMU_BW_VOTE feature bit to enable it.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/msm/adreno/a6xx_catal
Each GPU OPP requires a specific peak DDR bandwidth, let's add
those to each OPP and also the related interconnect path.
Signed-off-by: Neil Armstrong
---
arch/arm64/boot/dts/qcom/sm8650.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi
voted for a
same OPP, whatever decision is done by the GMU, it will
ensure all resources votes are synchronized.
Depends on [1] to avoid crashing when getting OPP bandwidths.
[1]
https://lore.kernel.org/all/20241128-topic-opp-fix-assert-index-check-v1-0-cb8bd4c03...@linaro.org/
Ran full vulkan-cts
The Adreno GPU Management Unit (GMU) can also scale the DDR Bandwidth
along the Frequency and Power Domain level, until now we left the OPP
core scale the OPP bandwidth via the interconnect path.
In order to enable bandwidth voting via the GPU Management
Unit (GMU), when an opp is set by devfreq w
Even if the code uses ARRAY_SIZE() to fill those tables,
it's still a best practice to not use magic values for
tables in structs.
Suggested-by: Dmitry Baryshkov
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 11 +++
1 file changed, 7 insertions(+), 4 deletion
Just a friendly reminder.
On 11/12/24 10:00 AM, Anastasia Belova wrote:
Switch to a managed drm device to cleanup some error handling
and make future work easier.
Fix dereference of NULL in meson_drv_bind_master by removing
drm_dev_put(drm) before meson_encoder_*_remove and
component_unbind_all
On Wed, 13 Nov 2024 17:02:57 +0100
Boris Brezillon wrote:
> Drop the _RD_ in the flag names.
>
> Signed-off-by: Boris Brezillon
Queued to drm-misc-next.
> ---
> drivers/gpu/drm/panthor/panthor_fw.c | 62 ++--
> 1 file changed, 31 insertions(+), 31 deletions(-)
>
> di
Hi,
On 2024/11/25 17:33, Liu Ying wrote:
i.MX8qxp Display Controller display engine consists of all processing
units that operate in a display clock domain. Add minimal feature
support with FrameGen and TCon so that the engine can output display
timings. The display engine driver as a master b
Hi Rob,
On 27. 11. 24 16:16, Rob Herring wrote:
On Wed, Nov 27, 2024 at 11:30:29AM +0100, Andrej Picej wrote:
From: Janine Hagemann
Add an optional property to change LVDS output voltage. This depends on
the connected display specifications. With this property we directly set
the LVDS_VCOM (0
1 - 100 of 102 matches
Mail list logo
