Ok, I'm getting tired of seeing these for the USB portion of the tree,
so I went to look for:
On Fri, May 03, 2024 at 04:44:42AM +0800, kernel test robot wrote:
> |-- arc-randconfig-002-20240503
> | `-- drivers-usb-dwc3-core.c:warning:variable-hw_mode-set-but-not-used
This warning (same for
On Thu, May 02, 2024 at 06:52:16PM -0700, Ashok Kumar wrote:
> Corrected coding style CHECK: Alignment should match open parenthesis
>
The original author was aligned it deliberately to improve readability.
Just ignore checkpatch on this.
regards,
dan carpenter
Hi,
On 2024/5/3 01:28, Andy Shevchenko wrote:
On Fri, May 03, 2024 at 12:25:17AM +0800, Sui Jingfeng wrote:
On 2024/5/2 16:32, Andy Shevchenko wrote:
On Wed, May 01, 2024 at 12:27:14AM +0800, Sui Jingfeng wrote:
On 2024/4/30 22:13, Andy Shevchenko wrote:
On Fri, Apr 26, 2024 at 05:13:43AM
Hi Linus,
Weekly fixes, mostly made up from amdgpu and some panel changes.
Otherwise xe, nouveau, vmwgfx and a couple of others, all seems pretty
on track.
Dave.
drm-fixes-2024-05-03:
drm fixes for 6.9-rc7
amdgpu:
- Fix VRAM memory accounting
- DCN 3.1 fixes
- DCN 2.0 fix
- DCN 3.1.5 fix
- DCN
Corrected coding style CHECK: Alignment should match open parenthesis
Signed-off-by: Ashok Kumar
---
drivers/staging/fbtft/fb_tinylcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/fbtft/fb_tinylcd.c
b/drivers/staging/fbtft/fb_tinylcd.c
index
On Fri, May 03, 2024 at 01:14:45AM +0100, Al Viro wrote:
> On Thu, May 02, 2024 at 05:10:18PM -0700, Kees Cook wrote:
>
> > But anyway, there needs to be a general "oops I hit 0"-aware form of
> > get_file(), and it seems like it should just be get_file() itself...
>
> ... which brings back the
On Thu, May 02, 2024 at 05:10:18PM -0700, Kees Cook wrote:
> But anyway, there needs to be a general "oops I hit 0"-aware form of
> get_file(), and it seems like it should just be get_file() itself...
... which brings back the question of what's the sane damage mitigation
for that. Adding
On Fri, May 03, 2024 at 12:41:52AM +0100, Al Viro wrote:
> On Thu, May 02, 2024 at 04:21:13PM -0700, Kees Cook wrote:
> > On Fri, May 03, 2024 at 12:12:28AM +0100, Al Viro wrote:
> > > On Thu, May 02, 2024 at 03:52:21PM -0700, Kees Cook wrote:
> > >
> > > > As for semantics, what do you mean?
On Thu, May 2, 2024 at 4:48 PM Douglas Anderson wrote:
>
> As evidenced by in-field reports, this panel shipped on pompom but we
> never added the ID and thus we're stuck w/ conservative timings. The
> panel was part of early patches but somehow got left off in the
> end. :( Add it in now.
>
>
Hi Jacopo,
On Thu, May 02, 2024 at 11:02:27AM +0200, Jacopo Mondi wrote:
> Hello
>which tree should this patch be collected from now that it has
> been reviewed ?
I think this can go through drm-misc. I'm not sure what the rule is for
patches that touch core code like these, can then be
As evidenced by in-field reports, this panel shipped on pompom but we
never added the ID and thus we're stuck w/ conservative timings. The
panel was part of early patches but somehow got left off in the
end. :( Add it in now.
For future reference, EDID from this panel is:
On Thu, May 02, 2024 at 04:21:13PM -0700, Kees Cook wrote:
> On Fri, May 03, 2024 at 12:12:28AM +0100, Al Viro wrote:
> > On Thu, May 02, 2024 at 03:52:21PM -0700, Kees Cook wrote:
> >
> > > As for semantics, what do you mean? Detecting dec-below-zero means we
> > > catch underflow, and detected
On Fri, May 03, 2024 at 12:12:28AM +0100, Al Viro wrote:
> On Thu, May 02, 2024 at 03:52:21PM -0700, Kees Cook wrote:
>
> > As for semantics, what do you mean? Detecting dec-below-zero means we
> > catch underflow, and detected inc-from-zero means we catch resurrection
> > attempts. In both cases
On Thu, May 02, 2024 at 03:52:21PM -0700, Kees Cook wrote:
> As for semantics, what do you mean? Detecting dec-below-zero means we
> catch underflow, and detected inc-from-zero means we catch resurrection
> attempts. In both cases we avoid double-free, but we have already lost
> to a potential
On Fri, May 03, 2024 at 12:53:56AM +0200, Jann Horn wrote:
> On Fri, May 3, 2024 at 12:34 AM Kees Cook wrote:
> > If f_count reaches 0, calling get_file() should be a failure. Adjust to
> > use atomic_long_inc_not_zero() and return NULL on failure. In the future
> > get_file() can be annotated
On Fri, May 3, 2024 at 12:34 AM Kees Cook wrote:
> If f_count reaches 0, calling get_file() should be a failure. Adjust to
> use atomic_long_inc_not_zero() and return NULL on failure. In the future
> get_file() can be annotated with __must_check, though that is not
> currently possible.
[...]
>
On Thu, May 02, 2024 at 11:42:50PM +0100, Al Viro wrote:
> On Thu, May 02, 2024 at 03:33:40PM -0700, Kees Cook wrote:
> > Underflow of f_count needs to be more carefully detected than it
> > currently is. The results of get_file() should be checked, but the
> > first step is detection. Redefine
On Thu, May 02, 2024 at 03:33:40PM -0700, Kees Cook wrote:
> Underflow of f_count needs to be more carefully detected than it
> currently is. The results of get_file() should be checked, but the
> first step is detection. Redefine f_count from atomic_long_t to
> refcount_long_t.
It is
On 5/2/2024 3:32 PM, Douglas Anderson wrote:
The debug print clearly lacks a \n at the end. Add it.
Fixes: 8f86c82aba8b ("drm/connector: demote connector force-probes for non-master
clients")
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/drm_connector.c | 2 +-
1 file changed, 1
Duplicate the refcount_t types and APIs gain refcount_long_t. This is
needed for larger counters that while currently very unlikely to overflow,
still want to detect and mitigate underflow.
Generate refcount-long.h via direct string replacements. Doing macros
like compat_binfmt_elf doesn't appear
Underflow of f_count needs to be more carefully detected than it
currently is. The results of get_file() should be checked, but the
first step is detection. Redefine f_count from atomic_long_t to
refcount_long_t.
Signed-off-by: Kees Cook
---
Cc: Christian Brauner
Cc: Alexander Viro
Cc: Jan
The correct helper for taking an f_count reference is get_file(). Use it
and check results.
Signed-off-by: Kees Cook
---
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: David Airlie
Cc: Daniel Vetter
Cc: Andi Shyti
Cc: Lucas De Marchi
Cc: Matt Atwood
Cc:
If f_count reaches 0, calling get_file() should be a failure. Adjust to
use atomic_long_inc_not_zero() and return NULL on failure. In the future
get_file() can be annotated with __must_check, though that is not
currently possible.
Signed-off-by: Kees Cook
---
Cc: Christian Brauner
Cc: Alexander
The correct helper for taking an f_count reference is get_file().
Now that it checks for 0 counts, use it and check results.
Signed-off-by: Kees Cook
---
Cc: Zack Rusin
Cc: Broadcom internal kernel review list
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Hi,
Failure with f_count reference counting are better contained by
an actual reference counting type, like refcount_t. The first step
is for get_file() to use inc_not_zero to avoid resurrection. I also
found a couple open-coded modifications of f_count that should be using
get_file(). Since long
The debug print clearly lacks a \n at the end. Add it.
Fixes: 8f86c82aba8b ("drm/connector: demote connector force-probes for
non-master clients")
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/drm_connector.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 5/2/2024 3:46 AM, Thomas Zimmermann wrote:
>
>
> Am 30.04.24 um 19:38 schrieb Easwar Hariharan:
>> I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
>> with more appropriate terms. Inspired by and following on to Wolfram's
>> series to fix drivers/i2c/[1], fix the
There is a confusing pattern in the kernel to use a variable named 'timeout' to
store the result of wait_for_completion_timeout() causing patterns like:
timeout = wait_for_completion_timeout(...)
if (!timeout) return -ETIMEDOUT;
with all kinds of permutations. Use 'time_left' as
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 9c6ecb3cb6e20c4fd7997047213ba0efcf9ada1a Add linux-next specific
files for 20240502
Unverified Error/Warning (likely false positive, please contact us if
interested):
drivers/gpu/drm/amd
Hi Jason,
I tried to understand how you supposed us to use hmm range fault... it seems
you want us to call hmm range fault two times on each gpu page fault:
1.
Call Hmm_range_fault first time, pfn of the fault address is set with
HMM_PFN_REQ_FAULT
Other pfns in the PREFAULT_SIZE range will be
Hi Dave, Sima,
here's the PR for drm-misc-fixes for this week.
Best regards
Thomas
drm-misc-fixes-2024-05-02:
Short summary of fixes pull:
imagination:
- fix page-count macro
nouveau:
- avoid page-table allocation failures
- fix firmware memory allocation
panel:
- ili9341: avoid OF for
On Tue, 30 Apr 2024 13:37:27 +0200
Boris Brezillon wrote:
> In the post_reset function, if the fast reset didn't succeed, we
> are not clearing the fast_reset flag, which prevents firmware
> sections from being reloaded. While at it, use panthor_fw_stop()
> instead of manually writing DISABLE to
We need to undo what was done in panthor_sched_pre_reset() even if the
reset failed. We just flag all previously running groups as terminated
when that happens to unblock things.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panthor/panthor_device.c | 7 +--
Avoids use-after-free situations when panthor_fw_unplug() is called
and the kernel BO was mapped to the FW VM.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panthor/panthor_fw.c| 4 ++--
drivers/gpu/drm/panthor/panthor_gem.c | 8 +---
drivers/gpu/drm/panthor/panthor_gem.h |
Hello,
This is a collection of fixes for bugs found while chasing an
unrecoverable fault leading to a device unplug (because of some
other bugs that was introduced in my local dev branch).
The first patch makes sure we immediately reset the GPU on an
unrecoverable fault, and following patches
This way get NULL derefs instead of use-after-free if the FW VM is
referenced after the device has been unplugged.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panthor/panthor_fw.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panthor/panthor_fw.c
If the FW reports an unrecoverable fault, we need to reset the GPU
before we can start re-using it again.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panthor/panthor_device.c | 1 +
drivers/gpu/drm/panthor/panthor_device.h | 1 +
drivers/gpu/drm/panthor/panthor_sched.c | 11
On Fri, May 03, 2024 at 01:28:26AM +0800, Sui Jingfeng wrote:
> On 2024/5/2 15:34, Neil Armstrong wrote:
> > On 30/04/2024 11:34, Maxime Ripard wrote:
> > > On Tue, Apr 30, 2024 at 12:54:39AM +0800, Sui Jingfeng wrote:
> > > > On 2024/4/29 19:55, Maxime Ripard wrote:
> > > > > On Sat, Apr 27, 2024
On Fri, May 03, 2024 at 12:25:17AM +0800, Sui Jingfeng wrote:
> On 2024/5/2 16:32, Andy Shevchenko wrote:
> > On Wed, May 01, 2024 at 12:27:14AM +0800, Sui Jingfeng wrote:
> > > On 2024/4/30 22:13, Andy Shevchenko wrote:
> > > > On Fri, Apr 26, 2024 at 05:13:43AM +0800, Sui Jingfeng wrote:
...
>
Hi,
On 2024/5/2 15:34, Neil Armstrong wrote:
On 30/04/2024 11:34, Maxime Ripard wrote:
On Tue, Apr 30, 2024 at 12:54:39AM +0800, Sui Jingfeng wrote:
On 2024/4/29 19:55, Maxime Ripard wrote:
On Sat, Apr 27, 2024 at 01:57:46PM +0800, Sui Jingfeng wrote:
On 2024/4/26 14:23, Maxime Ripard
On Thu, 02 May 2024 22:51:21 +0530, Shresth Prasad wrote:
> `dev->of_node` already has a reference to the device_node and calling
> of_node_get on it is unnecessary. All conresponding calls to
> of_node_put are also removed.
>
>
Applied, thanks!
[1/1] backlight: sky81452-backlight: Remove
`dev->of_node` already has a reference to the device_node and calling
of_node_get on it is unnecessary. All conresponding calls to
of_node_put are also removed.
Reviewed-by: Daniel Thompson
Signed-off-by: Shresth Prasad
---
Changes in v3:
- Remove unnecessary braces
Hi,
On Thu, May 2, 2024 at 1:23 AM Linus Walleij wrote:
>
> On Wed, May 1, 2024 at 5:43 PM Douglas Anderson wrote:
>
> > Through a cooperative effort between Hsin-Yi Wang and Dmitry
> > Baryshkov, we have realized the dev_err() in the
> > mipi_dsi_*_write_seq() macros was causing quite a bit of
On 30/04/2024 13:33, AngeloGioacchino Del Regno wrote:
Il 30/04/24 12:17, Alexandre Mergnat ha scritto:
Hi Angelo,
On 09/04/2024 14:02, AngeloGioacchino Del Regno wrote:
This series was tested on MT8195 Cherry Tomato and on MT8395 Radxa
NIO-12L with both hardcoded paths, OF graph support
On Thu, 2 May 2024 16:47:56 +0100
Steven Price wrote:
> On 02/05/2024 16:40, Boris Brezillon wrote:
> > The field used to store the chunk size if 12 bits wide, and the encoding
> > is chunk_size = chunk_header.chunk_size << 12, which gives us a
> > theoretical [4k:8M] range. This range is
Make sure the user is aware that drm_panthor_tiler_heap_destroy::handle
must be a handle previously returned by
DRM_IOCTL_PANTHOR_TILER_HEAP_CREATE.
v4:
- Add Steve's R-b
v3:
- New patch
Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
---
include/uapi/drm/panthor_drm.h | 6 +-
1
The heap ID is used to index the heap context pool, and allocating
in the [1:MAX_HEAPS_PER_POOL] leads to an off-by-one. This was
originally to avoid returning a zero heap handle, but given the handle
is formed with (vm_id << 16) | heap_id, with vm_id > 0, we already can't
end up with a valid heap
From: Antonino Maniscalco
If the kernel couldn't allocate memory because we reached the maximum
number of chunks but no render passes are in flight
(panthor_heap_grow() returning -ENOMEM), we should defer the OOM
handling to the FW by returning a NULL chunk. The FW will then call
the tiler OOM
The field used to store the chunk size if 12 bits wide, and the encoding
is chunk_size = chunk_header.chunk_size << 12, which gives us a
theoretical [4k:8M] range. This range is further limited by
implementation constraints, and all known implementations seem to
impose a [128k:8M] range, so do the
It doesn't make sense to have a maximum number of chunks smaller than
the initial number of chunks attached to the context.
Fix the uAPI header to reflect the new constraint, and mention the
undocumented "initial_chunk_count > 0" constraint while at it.
v3:
- Add R-b
v2:
- Fix the check
Fixes:
This is a collection of tiler heap fixes for bugs/oddities found while
looking at incremental rendering.
Ideally, we want to land those before 6.10 is released, so we don't need
to increment the driver version to reflect the ABI changes.
Changelog detailed in each commit.
Regards,
Boris
On Thu, 2 May 2024 16:52:24 +0100
Steven Price wrote:
> On 02/05/2024 16:40, Boris Brezillon wrote:
> > The heap ID is used to index the heap context pool, and allocating
> > in the [1:MAX_HEAPS_PER_POOL] leads to an off-by-one. This was
> > originally to avoid returning a zero heap handle, but
On Thu, 02 May 2024, Lee Jones wrote:
> On Wed, 17 Apr 2024 17:31:05 +0200, Flavio Suligoi wrote:
> > The mp3309 has two configuration registers, named according to their
> > address (0x00 and 0x01).
> > In the second register (0x01), the bit DIMS (Dimming Mode Select) must
> > be always 0
On Wed, 17 Apr 2024 17:31:05 +0200, Flavio Suligoi wrote:
> The mp3309 has two configuration registers, named according to their
> address (0x00 and 0x01).
> In the second register (0x01), the bit DIMS (Dimming Mode Select) must
> be always 0 (zero), in both analog (via i2c commands) and pwm
On Thu, 2 May 2024 17:52:48 +0200
Boris Brezillon wrote:
> When we check for state values returned by the FW, we only cover part of
> the 0:7 range. Make sure we catch FW inconsistencies by adding a default
> to the switch statement, and flagging the group state as unknown in that
> case.
>
>
Hi,
On Thu, May 2, 2024 at 6:42 AM Linus Walleij wrote:
>
> On Wed, May 1, 2024 at 5:43 PM Douglas Anderson wrote:
>
> > Consensus on the mailing lists is that panels shouldn't use a table of
> > init commands but should instead use init functions. With the recently
> > introduced
Hi Dave and Sima,
Please pull the drm-xe-fixes for this week targeting v6.9-rc7.
Two important fixes: one avoiding a use-after-free in the rebind worker
and the other to make display work in ADL-N.
thanks
Lucas De Marchi
drm-xe-fixes-2024-05-02:
- Fix UAF on rebind worker
- Fix ADL-N display
Hi,
On 2024/5/2 16:32, Andy Shevchenko wrote:
On Wed, May 01, 2024 at 12:27:14AM +0800, Sui Jingfeng wrote:
On 2024/4/30 22:13, Andy Shevchenko wrote:
On Fri, Apr 26, 2024 at 05:13:43AM +0800, Sui Jingfeng wrote:
...
the former might be subdivided to "is it swnode backed or real fwnode
On 02/05/2024 16:27, Doug Anderson wrote:
Hi,
On Thu, May 2, 2024 at 12:48 AM Neil Armstrong
wrote:
Hi,
On 01/05/2024 17:41, Douglas Anderson wrote:
The consensus of many DRM folks is that we want to move away from DSI
drivers defining tables of init commands. Instead, we want to move to
On Fri, 26 Apr 2024 22:56:02 +0900, Masahiro Yamada wrote:
> When you create a submenu using the 'menu' syntax, there is no
> ambiguity about its end because the code between 'menu' and 'endmenu'
> becomes the submenu.
>
> In contrast, 'menuconfig' does not have the corresponding end marker.
>
On Thu, 04 Apr 2024, Yoshinori Sato wrote:
> Various parameters of SM501 can be set using platform_data,
> so parameters cannot be passed in the DeviceTree target.
> Expands the parameters set in platform_data so that they can be
> specified using DeviceTree properties.
>
> Signed-off-by:
On Thu, 25 Apr 2024 12:18:29 +0100
Steven Price wrote:
> On 25/04/2024 11:39, Boris Brezillon wrote:
> > We can use upd_ctx.timedout_mask directly, and the faulty_slots update
> > in the flush_caches_failed situation is never used.
> >
> > Suggested-by: Suggested-by: Steven Price
>
> I'm
When we check for state values returned by the FW, we only cover part of
the 0:7 range. Make sure we catch FW inconsistencies by adding a default
to the switch statement, and flagging the group state as unknown in that
case.
When an unknown state is detected, we trigger a reset, and consider the
On 02/05/2024 16:40, Boris Brezillon wrote:
> Make sure the user is aware that drm_panthor_tiler_heap_destroy::handle
> must be a handle previously returned by
> DRM_IOCTL_PANTHOR_TILER_HEAP_CREATE.
>
> Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
> ---
>
On 02/05/2024 16:40, Boris Brezillon wrote:
> The heap ID is used to index the heap context pool, and allocating
> in the [1:MAX_HEAPS_PER_POOL] leads to an off-by-one. This was
> originally to avoid returning a zero heap handle, but given the handle
> is formed with (vm_id << 16) | heap_id, with
On 02/05/2024 16:40, Boris Brezillon wrote:
> The field used to store the chunk size if 12 bits wide, and the encoding
> is chunk_size = chunk_header.chunk_size << 12, which gives us a
> theoretical [4k:8M] range. This range is further limited by
> implementation constraints, and all known
Make sure the user is aware that drm_panthor_tiler_heap_destroy::handle
must be a handle previously returned by
DRM_IOCTL_PANTHOR_TILER_HEAP_CREATE.
Signed-off-by: Boris Brezillon
---
include/uapi/drm/panthor_drm.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
The heap ID is used to index the heap context pool, and allocating
in the [1:MAX_HEAPS_PER_POOL] leads to an off-by-one. This was
originally to avoid returning a zero heap handle, but given the handle
is formed with (vm_id << 16) | heap_id, with vm_id > 0, we already can't
end up with a valid heap
The field used to store the chunk size if 12 bits wide, and the encoding
is chunk_size = chunk_header.chunk_size << 12, which gives us a
theoretical [4k:8M] range. This range is further limited by
implementation constraints, and all known implementations seem to
impose a [128k:8M] range, so do the
It doesn't make sense to have a maximum number of chunks smaller than
the initial number of chunks attached to the context.
Fix the uAPI header to reflect the new constraint, and mention the
undocumented "initial_chunk_count > 0" constraint while at it.
v3:
- Add R-b
v2:
- Fix the check
Fixes:
This is a collection of tiler heap fixes for bugs/oddities found while
looking at incremental rendering.
Ideally, we want to land those before 6.10 is released, so we don't need
to increment the driver version to reflect the ABI changes.
Changelog detailed in each commit.
Regards,
Boris
From: Antonino Maniscalco
If the kernel couldn't allocate memory because we reached the maximum
number of chunks but no render passes are in flight
(panthor_heap_grow() returning -ENOMEM), we should defer the OOM
handling to the FW by returning a NULL chunk. The FW will then call
the tiler OOM
On Thu, 2024-05-02 at 09:46 -0300, Jason Gunthorpe wrote:
> On Thu, May 02, 2024 at 11:11:04AM +0200, Thomas Hellström wrote:
>
> > It's true the cpu vma lookup is a remnant from amdkfd. The idea
> > here is
> > to replace that with fixed prefaulting ranges of tunable size. So
> > far,
> > as you
On Thu, 2 May 2024 16:36:02 +0200
Boris Brezillon wrote:
> On Thu, 2 May 2024 15:26:55 +0100
> Steven Price wrote:
>
> > On 02/05/2024 15:15, Boris Brezillon wrote:
> > > On Thu, 2 May 2024 15:03:51 +0100
> > > Steven Price wrote:
> > >
> > >> On 30/04/2024 12:28, Boris Brezillon
On Thu, May 02, 2024 at 09:03:31AM +, Hsin-Te Yuan wrote:
> Add a perporty to indicate whether anx7625 should shift the first audio
> data bit. The default TDM setting is to shift the first audio data bit.
>
> Signed-off-by: Hsin-Te Yuan
> ---
>
On Thu, 2 May 2024 15:26:55 +0100
Steven Price wrote:
> On 02/05/2024 15:15, Boris Brezillon wrote:
> > On Thu, 2 May 2024 15:03:51 +0100
> > Steven Price wrote:
> >
> >> On 30/04/2024 12:28, Boris Brezillon wrote:
> >>> ID 0 is reserved to encode 'no-tiler-heap', the heap ID range is
>
Hi all,
Continuing after the brief IRC discussion yesterday regarding work
queues being prone to deadlocks or not, I had a browse around the code
base and ended up a bit confused.
When drm_sched_init documents and allocates an *ordered* wq, if no
custom one was provided, could someone
Hi,
On Thu, May 2, 2024 at 12:48 AM Neil Armstrong
wrote:
>
> Hi,
>
> On 01/05/2024 17:41, Douglas Anderson wrote:
> > The consensus of many DRM folks is that we want to move away from DSI
> > drivers defining tables of init commands. Instead, we want to move to
> > init functions that can use
On 02/05/2024 15:15, Boris Brezillon wrote:
> On Thu, 2 May 2024 15:03:51 +0100
> Steven Price wrote:
>
>> On 30/04/2024 12:28, Boris Brezillon wrote:
>>> ID 0 is reserved to encode 'no-tiler-heap', the heap ID range is
>>> [1:MAX_HEAPS_PER_POOL], which we occasionally need to turn into an index
Dave, Sima
This week's small set of fixes for drm-next.
drm-xe-next-fixes-2024-05-02:
Driver Changes:
- Fix for a backmerge going slightly wrong.
- An UAF fix
- Avoid a WA error on LNL.
Thanks,
Thomas
The following changes since commit 4a56c0ed5aa0bcbe1f5f7d755fb1fe1ebf48ae9c:
Merge tag
Hey,
Den 2024-04-24 kl. 18:56, skrev Friedrich Vock:
Hi everyone,
recently I've been looking into remedies for apps (in particular, newer
games) that experience significant performance loss when they start to
hit VRAM limits, especially on older or lower-end cards that struggle
to fit both
On Thu, 2 May 2024 15:03:51 +0100
Steven Price wrote:
> On 30/04/2024 12:28, Boris Brezillon wrote:
> > ID 0 is reserved to encode 'no-tiler-heap', the heap ID range is
> > [1:MAX_HEAPS_PER_POOL], which we occasionally need to turn into an index
> > in the [0:MAX_HEAPS_PER_POOL-1] when we want
On 30/04/2024 12:28, Boris Brezillon wrote:
> ID 0 is reserved to encode 'no-tiler-heap', the heap ID range is
> [1:MAX_HEAPS_PER_POOL], which we occasionally need to turn into an index
> in the [0:MAX_HEAPS_PER_POOL-1] when we want to access the context object.
This might be a silly question,
On 30/04/2024 14:08, Adrián Larumbe wrote:
> Hi Boris,
>
> On 30.04.2024 13:28, Boris Brezillon wrote:
>> The field used to store the chunk size if 12 bits wide, and the encoding
>> is chunk_size = chunk_header.chunk_size << 12, which gives us a
>> theoretical [4k:8M] range. This range is further
On 30/04/2024 12:28, Boris Brezillon wrote:
> It doesn't make sense to have a maximum number of chunks smaller than
> the initial number of chunks attached to the context.
>
> Fix the uAPI header to reflect the new constraint, and mention the
> undocumented "initial_chunk_count > 0" constraint
On 30/04/2024 12:28, Boris Brezillon wrote:
> From: Antonino Maniscalco
>
> If the kernel couldn't allocate memory because we reached the maximum
> number of chunks but no render passes are in flight
> (panthor_heap_grow() returning -ENOMEM), we should defer the OOM
> handling to the FW by
On Wed, Apr 24, 2024 at 06:06:52PM +0530, Aravind Iddamsetty wrote:
>
> On 24/04/24 17:21, Maxime Ripard wrote:
> > On Mon, Apr 22, 2024 at 12:27:53PM +0530, Aravind Iddamsetty wrote:
> >> In scenarios where drm_dev_put is directly called by driver we want to
> >> release
On Wed, May 1, 2024 at 5:43 PM Douglas Anderson wrote:
> Consensus on the mailing lists is that panels shouldn't use a table of
> init commands but should instead use init functions. With the recently
> introduced mipi_dsi_dcs_write_seq_multi() this is not only clean/easy
> but also saves space.
On Thu, May 02, 2024 at 07:50:36AM +, Kasireddy, Vivek wrote:
> Hi Jason,
<...>
> > I'd rather we stick with the original design. Leon is working on DMA
> > API changes that should address half the issue.
> Ok, I'll keep an eye out for Leon's work.
The code for v1 is here:
On Thu, May 02, 2024 at 11:11:04AM +0200, Thomas Hellström wrote:
> It's true the cpu vma lookup is a remnant from amdkfd. The idea here is
> to replace that with fixed prefaulting ranges of tunable size. So far,
> as you mention, the prefaulting range has been determined by the CPU
> vma size.
Hi
Am 02.05.24 um 14:00 schrieb Boris Brezillon:
On Thu, 2 May 2024 13:59:41 +0200
Boris Brezillon wrote:
Hi Thomas,
On Thu, 2 May 2024 13:51:16 +0200
Thomas Zimmermann wrote:
Hi,
ignoring my r-b on patch 1, I'd like to rethink the current patches in
general.
I think
On Thu, 2 May 2024 13:59:41 +0200
Boris Brezillon wrote:
> Hi Thomas,
>
> On Thu, 2 May 2024 13:51:16 +0200
> Thomas Zimmermann wrote:
>
> > Hi,
> >
> > ignoring my r-b on patch 1, I'd like to rethink the current patches in
> > general.
> >
> > I think drm_gem_shmem_pin() should become the
Hi Thomas,
On Thu, 2 May 2024 13:51:16 +0200
Thomas Zimmermann wrote:
> Hi,
>
> ignoring my r-b on patch 1, I'd like to rethink the current patches in
> general.
>
> I think drm_gem_shmem_pin() should become the locked version of _pin(),
> so that drm_gem_shmem_object_pin() can call it
It is impossible to add each and every possible DDP path combination
for each and every possible combination of SoC and board: right now,
this driver hardcodes configuration for 10 SoCs and this is going to
grow larger and larger, and with new hacks like the introduction of
mtk_drm_route which is
1 - 100 of 169 matches
Mail list logo
