在 2024-07-03星期三的 23:11 -0700，Christoph Hellwig写道：
> On Thu, Jul 04, 2024 at 10:00:52AM +0800, Icenowy Zheng wrote:
> > So I here want to ask a question as an individual hacker: what's
> > the
> > policy of linux-pci towards these non-coherent PCIe
> > implementations?
> >
> > If the sentences of C
On Thu, Jul 04, 2024 at 11:47:22AM +0530, Ekansh Gupta wrote:
>
>
> On 7/3/2024 4:09 PM, Greg KH wrote:
> > On Wed, Jul 03, 2024 at 12:22:00PM +0530, Ekansh Gupta wrote:
> >> @@ -268,6 +272,7 @@ struct fastrpc_channel_ctx {
> >>struct fastrpc_session_ctx session[FASTRPC_MAX_SESSIONS];
> >>
On 7/3/2024 4:12 PM, Dmitry Baryshkov wrote:
> On Wed, Jul 03, 2024 at 12:22:00PM GMT, Ekansh Gupta wrote:
>> Memory intensive applications(which requires more tha 4GB) that wants
>> to offload tasks to DSP might have to split the tasks to multiple
>> user PD to make the resources available. For
On 7/4/2024 11:47 AM, Ekansh Gupta wrote:
>
> On 7/3/2024 4:09 PM, Greg KH wrote:
>> On Wed, Jul 03, 2024 at 12:22:00PM +0530, Ekansh Gupta wrote:
>>> @@ -268,6 +272,7 @@ struct fastrpc_channel_ctx {
>>> struct fastrpc_session_ctx session[FASTRPC_MAX_SESSIONS];
>>> spinlock_t lock;
>>>
On 7/3/2024 4:09 PM, Greg KH wrote:
> On Wed, Jul 03, 2024 at 12:22:00PM +0530, Ekansh Gupta wrote:
>> @@ -268,6 +272,7 @@ struct fastrpc_channel_ctx {
>> struct fastrpc_session_ctx session[FASTRPC_MAX_SESSIONS];
>> spinlock_t lock;
>> struct idr ctx_idr;
>> +struct ida dsp_pg
On Wed, Jul 03, 2024 at 05:33:57PM +0200, Jocelyn Falempe wrote:
> This series adds a new panic screen, with the kmsg data embedded in a QR-code.
>
> The main advantage of QR-code, is that you can copy/paste the debug data to a
> bug report.
>
> The QR-code encoder is written in rust, and is ver
Thanks a lot for your help Thomas.
On Wed, Jul 3, 2024 at 4:52 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 30.06.24 um 18:59 schrieb Wu Hoi Pok:
> > .load and drm_dev_alloc are deprecated. These patch series aims to
> > remove them.
> >
> > v3: Both v1 and v2 sucks. v3 improves greatly on readabili
These panels have some common cmds (e0h~e3h,80h), let's break
them into helper functions.
Signed-off-by: Cong Yang
---
.../gpu/drm/panel/panel-jadard-jd9365da-h3.c | 89 +++
1 file changed, 53 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-jadard-jd9365
The Melfas lmfbx101117480 is a 10.1" WXGA TFT LCD panel with jadard-jd9365da
controller. Hence, we add a new compatible with panel specific config.
Signed-off-by: Cong Yang
Acked-by: Conor Dooley
---
.../devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml| 1 +
1 file changed, 1 inser
The Melfas lmfbx101117480 is a 10.1" WXGA TFT-LCD panel, use jd9365da
controller, which fits in nicely with the existing panel-jadard-jd9365da-h3
driver. Hence, we add a new compatible with panel specific config.
Signed-off-by: Cong Yang
Acked-by: Linus Walleij
---
.../gpu/drm/panel/panel-jadar
This series support for Melfas lmfbx101117480 MIPI-DSI panel with
jadard-jd9365da controller.
Add compatible for melfas lmfbx101117480 in dt-bindings.
Break some CMDS into helper functions.
Changes in v2:
- PATCH 1/3: No change.
- PATCH 2/3: No change..
- PATCH 3/7: Break some CMDS into helper fun
Hi,
Linus Walleij 于2024年7月3日周三 21:10写道：
>
> On Tue, Jul 2, 2024 at 3:02 PM Cong Yang
> wrote:
>
> > The Melfas lmfbx101117480 is a 10.1" WXGA TFT-LCD panel, use jd9365da
> > controller, which fits in nicely with the existing panel-jadard-jd9365da-h3
> > driver. Hence, we add a new compatible wit
Hi Johan，
Thanks for your patch。
At 2024-07-03 22:20:27, "Johan Jonker" wrote:
>Add sound support to the RK3066 HDMI driver.
>The HDMI TX audio source is connected to I2S_8CH.
>
>Signed-off-by: Zheng Yang
>Signed-off-by: Johan Jonker
>---
>
>Changed V9:
> Use late_register and early_unregi
Hi Dragan，
At 2024-07-04 07:32:02, "Dragan Simic" wrote:
>After the additional firmware-related module information was introduced by
>the commit c0677e41a47f ("drm/rockchip: cdn-dp-core: add MODULE_FIRMWARE
>macro"), there's no longer need for the firmware-loading workarounds whose
>sole purpose
在 2024-07-03星期三的 16:08 -0500，Bjorn Helgaas写道：
> On Wed, Jul 03, 2024 at 04:52:30PM +0800, Jiaxun Yang wrote:
> > 在2024年7月2日七月 下午6:03，Jiaxun Yang写道：
> > > 在2024年7月2日七月 下午5:27，Christian König写道：
> > > > Am 02.07.24 um 11:06 schrieb Icenowy Zheng:
> > > > > [SNIP] However I don't think the definition
Clean up a few logged messages, which were previously worded as rather
incomplete sentences separated by periods. This was both a bit unreadable
and grammatically incorrect, so convert them into partial sentences separated
(or connected) by semicolons, together with some wording improvements.
Sig
After the additional firmware-related module information was introduced by
the commit c0677e41a47f ("drm/rockchip: cdn-dp-core: add MODULE_FIRMWARE
macro"), there's no longer need for the firmware-loading workarounds whose
sole purpose was to prevent the missing firmware blob in an initial ramdisk
Quoting Ryan Walklin (2024-07-03 03:51:09)
> diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-de2.c
> b/drivers/clk/sunxi-ng/ccu-sun8i-de2.c
> index b0b8dba239aec..36b9eadb80bb5 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun8i-de2.c
> +++ b/drivers/clk/sunxi-ng/ccu-sun8i-de2.c
> @@ -7,6 +7,7 @@
> #includ
Allocated canvases may not be released on the error exit path of
meson_drv_bind_master(), leading to resource leaking. Rewrite exit path
to release canvases on error.
Fixes: 2bf6b5b0e374 ("drm/meson: exclusively use the canvas provider module")
Signed-off-by: Yao Zi
---
drivers/gpu/drm/meson/mes
On 7/3/2024 10:13 PM, Dmitry Baryshkov wrote:
> On Tue, Jul 02, 2024 at 10:57:36PM GMT, Amirreza Zarrabi wrote:
>> Qualcomm TEE hosts Trusted Applications and Services that run in the
>> secure world. Access to these resources is provided using object
>> capabilities. A TEE client with access to
Hi Dave, Sima,
More new stuff for 6.11. There will be a few additional patches next
week for new IPs that were added in this cycle just to get them tied off,
but this should be it for general changes.
The following changes since commit 15eb8573ad72a97b8f70e3c88b9bef6ddc861f77:
drm/amd: Don't
On Wed, Jul 03, 2024 at 04:52:30PM +0800, Jiaxun Yang wrote:
> 在2024年7月2日七月 下午6:03，Jiaxun Yang写道：
> > 在2024年7月2日七月 下午5:27，Christian König写道：
> >> Am 02.07.24 um 11:06 schrieb Icenowy Zheng:
> >>> [SNIP] However I don't think the definition of the AGP spec could apply
> >>> on all
> >>> PCI(e) impl
On Wed, Jul 03, 2024 at 05:38:09PM +0200, Thomas Hellström wrote:
> Initially intended for experimenting with different backup
> solutions (shmem vs direct swap cache insertion), abstract
> the backup destination using a virtual base class.
>
> Also provide a sample implementation for shmem.
>
>
On Wed, Jul 3, 2024 at 3:20 PM Hamza Mahfooz wrote:
>
> We want all DML changes to be reviewed by Chaitanya or Jun. So, add an
> entry for DML to MAINTAINERS.
>
> Suggested-by: Rodrigo Siqueira
> Signed-off-by: Hamza Mahfooz
Acked-by: Alex Deucher
> ---
> MAINTAINERS | 7 +++
> 1 file ch
On Wed, Jul 03, 2024 at 05:38:08PM +0200, Thomas Hellström wrote:
> Use the LRU walker for eviction. This helps
> removing a lot of code with weird locking
> semantics.
>
> The functionality is slightly changed so that
> when trylocked buffer objects are exhausted, we
> continue to interleave walk
We want all DML changes to be reviewed by Chaitanya or Jun. So, add an
entry for DML to MAINTAINERS.
Suggested-by: Rodrigo Siqueira
Signed-off-by: Hamza Mahfooz
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7fec8ddb8d5b..d2fb60fee7e8
Hi Dave, Sima,
Fixes for 6.10.
The following changes since commit 22a40d14b572deb80c0648557f4bd502d7e83826:
Linux 6.10-rc6 (2024-06-30 14:40:44 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-6.10-2024-07-03
for you to fetc
On Wed, 3 Jul 2024 09:56:45 -0700 Mina Almasry wrote:
> > Is this really sufficient in terms of locking? @binding is not
> > RCU-protected and neither is the reader guaranteed to be in
> > an RCU critical section. Actually the "reader" tries to take a ref
> > and use this struct so it's not even a
On Wed, Jul 03, 2024 at 05:38:07PM +0200, Thomas Hellström wrote:
> Rework the TTM swapping to use the LRU walker helper.
> This helps fixing up the ttm_bo_swapout() interface
> to be consistent about not requiring any locking.
>
> For now mimic the current behaviour of using trylock
> only. We co
On Wed, Jul 03, 2024 at 05:38:05PM +0200, Thomas Hellström wrote:
> To address the problem with hitches moving when bulk move
> sublists are lru-bumped, register the list cursors with the
> ttm_lru_bulk_move structure when traversing its list, and
> when lru-bumping the list, move the cursor hitch
On Tue, Jul 2, 2024 at 8:15 AM Suren Baghdasaryan wrote:
>
> On Tue, Jul 2, 2024 at 7:34 AM Andrew Morton
> wrote:
> >
> > On Tue, 2 Jul 2024 09:13:35 +0200 Christian König
> > wrote:
> >
> > > yes that is
> > > intentionally a define and not an inline function.
> > >
> > > See this patch here
Introduce a test to cover the creation of framebuffer with
modifier on a device that doesn't support it.
Signed-off-by: Carlos Eduardo Gallo Filho
---
v2:
- Reorder kunit cases alphabetically.
v3:
- Replace the use of void pointer on drm_framebuffer_test_priv struct.
- Test return value of
Add a single KUnit test case for the drm_framebuffer_free function.
Signed-off-by: Carlos Eduardo Gallo Filho
---
v2:
- Reorder kunit cases alphabetically.
v3:
- Replace the use of void pointer on drm_framebuffer_test_priv struct.
- Remove the test with unregistered framebuffer object.
-
The dev_private member of drm_device is deprecated and its use should
be avoided. Stop using it by embedding the drm_device onto a mock struct.
The new mock struct allows to share variables and even further mocks
over the tests in a cleaner way than using dev_private void pointer.
Also start usin
Add a single KUnit test case for the drm_framebuffer_cleanup function.
Signed-off-by: Carlos Eduardo Gallo Filho
---
v2:
- Reorder kunit cases alphabetically.
- Rely on drm_kunit_helper_alloc_device() for mock initialization.
v3:
- Init framebuffers using drm_framebuffer_init().
- Add doc
Extend the existing test case to cover:
1. Invalid flag atribute in the struct drm_mode_fb_cmd2.
2. Pixel format which requires non-linear modifier with
DRM_FORMAT_MOD_LINEAR set.
3. Buffer offset for inexistent plane
Signed-off-by: Carlos Eduardo Gallo Filho
---
v2:
- Remove strcpy to strscpy
This patchset includes new KUnit tests for 5 untested functions from
drm_framebuffer.c and improvements to the existent one.
The first patch replace the use of dev_private member from drm_device
mock on the existent test by embedding it into an outer struct containing
a generic pointer.
The patch
Replace the use of strcpy to strscpy on the test_to_desc of the
drm_test_framebuffer_create test for better security and reliability.
Signed-off-by: Carlos Eduardo Gallo Filho
---
drivers/gpu/drm/tests/drm_framebuffer_test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dri
Add two KUnit test cases for the drm_framebuffer_lookup function, one for
the base case, that tests if the lookup finds the correct framebuffer object
and another that tests the lookup for an inexistent framebuffer.
Signed-off-by: Carlos Eduardo Gallo Filho
---
v2:
- Reorder kunit cases alphabe
Add three KUnit test cases for the drm_framebuffer_init function:
1. Test if expected values are being set after drm_framebuffer_init() call.
2. Try to init a framebuffer without setting its format.
3. Try calling drm_framebuffer_init() with mismatch of the drm_device passed
at the first argume
Add a parametrized test for the drm_framebuffer_check_src_coords function.
Signed-off-by: Carlos Eduardo Gallo Filho
---
v2:
- Order kunit cases alphabetically.
- Rename check_src_coords_case to drm_framebuffer_check_src_coords_case.
- Remove unnecessary comments.
- Add framebuffer size a
On Tue, Jul 2, 2024 at 6:09 PM Jakub Kicinski wrote:
>
> On Fri, 28 Jun 2024 00:32:40 + Mina Almasry wrote:
> > + if (binding->list.next)
> > + list_del(&binding->list);
> > +
> > + xa_for_each(&binding->bound_rxq_list, xa_idx, rxq) {
>
> nit: s/bound_rxq_list/bound_rxqs/ ?
On 03/07/2024 18:27, Kees Cook wrote:
On Wed, Jul 03, 2024 at 10:22:11AM +0200, Petr Mladek wrote:
On Wed 2024-07-03 09:57:26, Jocelyn Falempe wrote:
On 02/07/2024 22:29, Kees Cook wrote:
On Tue, Jul 02, 2024 at 02:26:04PM +0200, Jocelyn Falempe wrote:
kmsg_dump doesn't forward the panic
On 7/3/24 9:05 AM, Christian Eggers wrote:
> Based on the existing ST7586 driver. But the ST7539 ...
> - is monochrome only
> - has 8 VERTICAL pixels per byte
> - doesn't support any MIPI DCS commands
> - has (a few) 16 bit commands
> - doesn't support setting a clipping rect when writing to the RA
On Mon, Jun 10, 2024 at 04:55:38PM +0800, Lu Baolu wrote:
> Replace iommu_domain_alloc() with iommu_paging_domain_alloc().
>
> Signed-off-by: Lu Baolu
Acked-by: Michael S. Tsirkin
I assume it's merged with the rest of the stuff, right?
> ---
> drivers/vhost/vdpa.c | 14 ++
> 1 f
On Wed, Jul 03, 2024 at 10:22:11AM +0200, Petr Mladek wrote:
> On Wed 2024-07-03 09:57:26, Jocelyn Falempe wrote:
> >
> >
> > On 02/07/2024 22:29, Kees Cook wrote:
> > > On Tue, Jul 02, 2024 at 02:26:04PM +0200, Jocelyn Falempe wrote:
> > > > kmsg_dump doesn't forward the panic reason string to t
On Wed, Jul 03, 2024 at 04:56:46PM +0100, Steven Price wrote:
> If a queue is already assigned to the hardware, then a newly submitted
> job can start straight away without waiting for the tick. However in
> this case the devfreq infrastructure isn't notified that the GPU is
> busy. By the time the
On Wed, 2024-07-03 at 15:26 +0200, Christian König wrote:
> The TTM eviction path has some additional requirements which make it
> necessary to trylock an object and then eventually keep or drop the
> lock
> again.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/drm_exec.c | 77
>
Got it.
I had some mental block about passing designated intializers as macro args.
it just worked, I needed to eyeball the .i file just to be sure.
thanks.
I have a fixup patch.
whats the best thing to do with it, squash it in for later ? send in
reply here ?
On Wed, Jul 3, 2024 at 5:52 AM Ville
While working on rvkms, I noticed that there's no code that actually uses
the drm_pending_vblank_event that's embedded in vkms_output. So, just drop
the member from the struct.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/vkms/vkms_drv.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/driver
Add the DPCD register for the LTTPR PHY OUI. This will be used by a
later i915 patch to dump the descriptors for the detected LTTPR PHYs.
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak
---
include/drm/display/drm_dp.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/
Hi Stefan
On Wed, 3 Jul 2024 at 16:32, Stefan Wahren wrote:
>
> Am 03.07.24 um 12:28 schrieb Stefan Wahren:
> > Hi Maxime,
> >
> > Am 02.07.24 um 15:48 schrieb Maxime Ripard:
> >> Hi,
> >>
> >> On Sun, Jun 30, 2024 at 05:36:48PM GMT, Stefan Wahren wrote:
> >>> Suspend of VC4 HDMI will likely trig
On Wed, 3 Jul 2024 16:56:46 +0100
Steven Price wrote:
> If a queue is already assigned to the hardware, then a newly submitted
> job can start straight away without waiting for the tick. However in
> this case the devfreq infrastructure isn't notified that the GPU is
> busy. By the time the tick
If a queue is already assigned to the hardware, then a newly submitted
job can start straight away without waiting for the tick. However in
this case the devfreq infrastructure isn't notified that the GPU is
busy. By the time the tick happens the job might well have finished and
no time will be acc
On Wed, 2024-07-03 at 15:25 +0200, Christian König wrote:
> Some contended objects might never be locked again in the case of
> eviction
> handling for example.
>
> Make sure that those doesn't show up in the list of locked objects
> until
> they are explicitely mentioned.
Could you be a bit more
On Wed, 3 Jul 2024 16:29:00 +0100
Steven Price wrote:
> diff --git a/drivers/gpu/drm/panthor/panthor_sched.c
> b/drivers/gpu/drm/panthor/panthor_sched.c
> index 79ffcbc41d78..42929e147107 100644
> --- a/drivers/gpu/drm/panthor/panthor_sched.c
> +++ b/drivers/gpu/drm/panthor/panthor_sched.c
> @@
This patch adds a new panic screen, with a QR code and the kmsg data
embedded.
If DRM_PANIC_SCREEN_QR_CODE_URL is set, then the kmsg data will be
compressed with zlib and encoded as a numerical segment, and appended
to the url as a url parameter. This allows to save space, and put
about ~7500 bytes
Move logo rectangle initialisation, and logo drawing in separate
functions, so they can be re-used by different panic screens.
It prepares the introduction of the QR-code panic screen.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/drm_panic.c | 57 +
1 fi
Check if two rectangles overlap.
It's a bit similar to drm_rect_intersect() but this won't modify
the rectangle.
Simplifies a bit drm_panic.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/drm_panic.c | 3 +--
include/drm/drm_rect.h | 15 +++
2 files changed, 16 insertions(+
Add a parameter to the blit function, to upscale the image.
This is necessary to draw QR-code, otherwise, the pixels are usually
too small to be readable by most QR-code reader.
It can also be used later for drawing fonts on high-DPI display.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/dr
This series adds a new panic screen, with the kmsg data embedded in a QR-code.
The main advantage of QR-code, is that you can copy/paste the debug data to a
bug report.
The QR-code encoder is written in rust, and is very specific to drm_panic.
The reason is that it is called in a panic handler,
Hi Maxime,
Thanks for your detail explain, it is make sense to reset the HDMI link.
I will implement it later.
B.R
Sandor
> -Original Message-
> From: Maxime Ripard
> Sent: 2024年7月2日 20:40
> To: Sandor Yu
> Cc: Alexander Stein ; Andrzej Hajda
> ; Neil Armstrong ;
> Robert Foss ; Lauren
Hi Pierre,
On 6/14/24 05:16, Pierre-Eric Pelloux-Prayer wrote:
This commit adds a document section in drm-uapi.rst about tracepoints,
and mark the events gpu_scheduler_trace.h as stable uAPI.
The goal is to explicitly state that tools can rely on the fields,
formats and semantics of these event
On Wed, Jul 03, 2024 at 10:31:44PM +1200, Ryan Walklin wrote:
> The WL-355608-A8 is a 3.5" 640x480@60Hz RGB LCD display from an unknown
> OEM used in a number of handheld gaming devices made by Anbernic.
> Previously committed using the OEM serial without a vendor prefix,
> however following subseq
On Wed, Jul 03, 2024 at 10:31:46PM +1200, Ryan Walklin wrote:
> make dt_bindings_check reports that sck-gpios and num-chipselects are
> required for spi nodes, therefore add these to the example.
>
> Signed-off-by: Ryan Walklin
I forgot to reply to, or somehow didn't notice your reply to my comm
The XE_PL_TT watermark was set to 50% of system memory.
The idea behind that was unclear since the net effect is that
TT memory will be evicted to TTM_PL_SYSTEM memory if that
watermark is exceeded, requiring PPGTT rebinds and dma
remapping. But there is no similar watermark for TTM_PL_SYSTEM
memor
Rather than relying on the TTM watermark accounting add a shrinker
for xe_bos in TT or system memory.
Leverage the newly added TTM per-page shrinking and shmem backup
support.
Although xe doesn't fully support WONTNEED (purgeable) bos yet,
introduce and add shrinker support for purgeable ttm_tts.
Use fault-injection to test partial TTM swapout and interrupted swapin.
Return -EINTR for swapin to test the callers ability to handle and
restart the swapin, and on swapout perform a partial swapout to test that
the swapin and release_shrunken functionality.
Cc: Christian König
Cc: Somalapuram A
Provide a helper to shrink ttm_tt page-vectors on a per-page
basis. A ttm_backup backend could then in theory get away with
allocating a single temporary page for each struct ttm_tt.
This is accomplished by splitting larger pages before trying to
back them up.
In the future we could allow ttm_bac
Initially intended for experimenting with different backup
solutions (shmem vs direct swap cache insertion), abstract
the backup destination using a virtual base class.
Also provide a sample implementation for shmem.
While when settling on a preferred backup solution, one could
perhaps skip the a
Use the LRU walker for eviction. This helps
removing a lot of code with weird locking
semantics.
The functionality is slightly changed so that
when trylocked buffer objects are exhausted, we
continue to interleave walks with ticket-locks while
there is still progress made. The list walks are
not r
Rework the TTM swapping to use the LRU walker helper.
This helps fixing up the ttm_bo_swapout() interface
to be consistent about not requiring any locking.
For now mimic the current behaviour of using trylock
only. We could be using ticket-locks here but defer
that until it's deemed necessary. The
Provide a generic LRU walker in TTM, in the spirit of drm_gem_lru_scan()
but building on the restartable TTM LRU functionality.
The LRU walker optionally supports locking objects as part of
a ww mutex locking transaction, to mimic to some extent the
current functionality in ttm. However any -EDEAD
To address the problem with hitches moving when bulk move
sublists are lru-bumped, register the list cursors with the
ttm_lru_bulk_move structure when traversing its list, and
when lru-bumping the list, move the cursor hitch to the tail.
This also means it's mandatory for drivers to call
ttm_lru_bu
Have iterators insert themselves into the list they are iterating
over using hitch list nodes. Since only the iterator owner
can remove these list nodes from the list, it's safe to unlock
the list and when continuing, use them as a starting point. Due to
the way LRU bumping works in TTM, newly adde
To make the transition to using lru hitches easier,
simplify the ttm_resource_manager_next() interface to only take
the cursor and reuse ttm_resource_manager_next() functionality
from ttm_resource_manager_first().
Cc: Christian König
Cc: Somalapuram Amaranath
Cc: Matthew Brost
Cc:
Signed-off-b
To be able to handle list unlocking while traversing the LRU
list, we want the iterators not only to point to the next
position of the list traversal, but to insert themselves as
list nodes at that point to work around the fact that the
next node might otherwise disappear from the list while
the it
This series implements TTM shrinker / eviction helpers and an xe bo
shrinker. It builds on two previous series, *and obsoletes these*. First
https://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg484425.html
Second the previous TTM shrinker series
https://lore.kernel.org/linux-mm/b74913
Am 03.07.24 um 12:28 schrieb Stefan Wahren:
Hi Maxime,
Am 02.07.24 um 15:48 schrieb Maxime Ripard:
Hi,
On Sun, Jun 30, 2024 at 05:36:48PM GMT, Stefan Wahren wrote:
Suspend of VC4 HDMI will likely triggers a warning from
vc4_hdmi_connector_detect_ctx() during poll of connector status.
The powe
On 24/06/2024 12:23, Adrián Larumbe wrote:
> Hi Steven,
>
> On 13.06.2024 16:28, Steven Price wrote:
>> On 06/06/2024 01:49, Adrián Larumbe wrote:
>>> This patch series enables userspace utilities like gputop and nvtop to
>>> query a render context's fdinfo file and figure out rates of engine
>>>
On Wed, Jul 03, 2024 at 10:51:08PM +1200, Ryan Walklin wrote:
> The Allwinner H616 and variants have a new display engine revision
> (DE33).
>
> The mixer configuration registers are significantly different to the DE3
> and DE2 revisions, being split into separate top and display blocks,
> therefo
[AMD Official Use Only - AMD Internal Distribution Only]
Alex publishes the amd-staging-drm-next branch regularly where all our kernel
commits go.
See the gfx12 modifiers that Mesa exposes.
Marek
From: Simon Ser
Sent: Tuesday, July 2, 2024 12:39:10 PM
To: Ols
On Mon, Jul 01, 2024 at 02:28:31PM +0300, Jani Nikula wrote:
> On Fri, 28 Jun 2024, Imre Deak wrote:
> > This is v2 of [1], renaming the helpers from drm_x16 to fxp_q4 as
> > suggested by Jani.
> >
> > [1] https://lore.kernel.org/all/20240614173911.3743172-1-imre.d...@intel.com
> >
> > Cc: Jani Ni
On 2024-07-03 15:20, Steven Price wrote:
On 03/07/2024 13:42, Dragan Simic wrote:
On 2024-06-17 22:17, Dragan Simic wrote:
Panfrost DRM driver uses devfreq to perform DVFS, while using
simple_ondemand
devfreq governor by default. This causes driver initialization to
fail on
boot when simple_on
On 2024-07-03 15:20, Boris Brezillon wrote:
On Wed, 03 Jul 2024 14:42:37 +0200
Dragan Simic wrote:
On 2024-06-17 22:17, Dragan Simic wrote:
> Panfrost DRM driver uses devfreq to perform DVFS, while using
> simple_ondemand
> devfreq governor by default. This causes driver initialization to fail
On Wed, 2024-07-03 at 16:30 +0200, Christian König wrote:
> Am 03.07.24 um 15:59 schrieb Thomas Hellström:
> > On Wed, 2024-07-03 at 15:53 +0200, Thomas Hellström wrote:
> > > On Wed, 2024-07-03 at 15:40 +0200, Thomas Hellström wrote:
> > > > Hi, Christian,
> > > >
> > > > On Wed, 2024-07-03 at 15
Am 03.07.24 um 15:59 schrieb Thomas Hellström:
On Wed, 2024-07-03 at 15:53 +0200, Thomas Hellström wrote:
On Wed, 2024-07-03 at 15:40 +0200, Thomas Hellström wrote:
Hi, Christian,
On Wed, 2024-07-03 at 15:25 +0200, Christian König wrote:
Hi guys,
We recently ran into a problem with deadlocks
Sometimes the system [1] hangs on x86 I/O machine checks. However, the
expected behavior is to reboot the system, as the machine check handler
ultimately triggers a panic(), initiating a reboot in the last step.
The root cause is that sometimes the panic() is blocked when
drm_fb_helper_damage() in
Add sound support to the RK3066 HDMI driver.
The HDMI TX audio source is connected to I2S_8CH.
Signed-off-by: Zheng Yang
Signed-off-by: Johan Jonker
---
Changed V9:
Use late_register and early_unregister hooks to
(un)register the "hdmi-audio-codec" driver.
restyle
Changed V8:
return -E
[AMD Official Use Only - AMD Internal Distribution Only]
Reviewed-by: Fangzhi Zuo
> -Original Message-
> From: Wayne Lin
> Sent: Wednesday, June 26, 2024 4:48 AM
> To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: ly...@redhat.com; jani.nik...@intel.com; imre.d...
It looks like the virtio-gpu flush should be fenced, but on the host side the
received flush cmd doesn't have the fence flag set, and no fence_id. So, I
have to reply right away instead of waiting for scanout to complete. Is that
expected? then what's the right way to vsync the guest?
At the
On Wed, 2024-07-03 at 15:53 +0200, Thomas Hellström wrote:
> On Wed, 2024-07-03 at 15:40 +0200, Thomas Hellström wrote:
> > Hi, Christian,
> >
> > On Wed, 2024-07-03 at 15:25 +0200, Christian König wrote:
> > > Hi guys,
> > >
> > > We recently ran into a problem with deadlocks during eviction and
Am 03.07.24 um 15:40 schrieb Thomas Zimmermann:
The VIDRST pin controls CRTC synchronization with an external clock
Jocelyn, see sec 5.6 of the G200 programming manual for details on this.
chip, such as a BMC or TV encoder. This patchset separates the CRTC
state from the BMC state and stre
The BMC's scanout synchronization is only indirectly related to the
VIDRST functionality. Do some renaming.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_bmc.c | 14 +++---
drivers/gpu/drm/mgag200/mgag200_drv.h | 8
2 files changed, 11 insertions(+), 11 d
Start and stop the BMC scanout from the BMC encoder's atomic_enable
and atomic_disable helpers. The BMC stops scanning out at the beginning
of a modeset operation and restarts the scanout at the end of the
modeset.
Only G200EW3 and G200WB require this procedure. Drop the original
vidrst callbacks
The callbacks disable_vidrst and enable_vidrst are obsolete and unused.
Their functionality has been integrated into the BMC's encoder. Remove
the fields from struct mgag200_device_funcs.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_drv.h| 12
drivers/gpu
The VRSTEN and HRSTEN bits control whether a CRTC synchronizes its
display signal with an external source on the VIDRST pin. The G200WB
and G200EW3 models synchronize with a BMC chip, but different external
video encoders, such as the Matrox Maven, can also be attached to the
pin.
Only set VRSTEN
The VIDRST pin controls CRTC synchronization with an external clock
chip, such as a BMC or TV encoder. This patchset separates the CRTC
state from the BMC state and streamlines the driver code.
Patch one moves the VIDRST programming logic into the CRTC modesetting
code. The status of the rsp flag
1 - 100 of 189 matches
Mail list logo
