Commit ec144244a43f ("drm/gem-shmem: Acquire reservation lock in GEM
pin/unpin callbacks") moved locking DRM object's dma reservation to
drm_gem_shmem_object_pin, and made drm_gem_shmem_pin_locked public, so we
need to make sure the non-NULL check warning is also added to the latter.
Signed-off-by
This is v3 of
https://lore.kernel.org/dri-devel/20240424090429.57de7...@collabora.com/
The goal of this patch series is fixing a deadlock upon locking the dma
reservation
of a DRM gem object when pinning it, at a prime import operation.
Changes from v2:
- Removed comment explaining reason why
When Panfrost must pin an object that is being prepared a dma-buf
attachment for on behalf of another driver, the core drm gem object pinning
code already takes a lock on the object's dma reservation.
However, Panfrost GEM object's pinning callback would eventually try taking
the lock on the same
https://bugzilla.kernel.org/show_bug.cgi?id=218785
The Linux kernel's regression tracker (Thorsten Leemhuis)
(regressi...@leemhuis.info) changed:
What|Removed |Added
C
Because the else clause after the return clause is not useful, remove it
to get a better look.
Reviewed-by: Jessica Zhang
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/pane
Having conditional around the of_node pointer of the drm_bridge structure
is not necessary anymore, since drm_bridge structure always has the of_node
member since the commit d8dfccde2709 ("drm/bridge: Drop conditionals around
of_node pointers").
So drop the conditional, please also note that this
Hi,
On 2024/5/1 05:33, Doug Anderson wrote:
Hi,
On Mon, Apr 29, 2024 at 6:16 PM 隋景峰 wrote:
Hi,
-原始邮件-
发件人: "Maxime Ripard"
发送时间: 2024-04-29 19:30:24 (星期一)
收件人: "Sui Jingfeng"
抄送: "Sui Jingfeng" , "Maarten Lankhorst" , "Thomas Zimmermann" , "David
Airlie" , "Daniel Vetter" , "Do
On Tue, Apr 30, 2024 at 08:57:48PM +0200, Daniel Vetter wrote:
> On Tue, Apr 30, 2024 at 02:30:02PM -0300, Jason Gunthorpe wrote:
> > On Mon, Apr 29, 2024 at 10:25:48AM +0200, Thomas Hellström wrote:
> >
> > > > Yes there is another common scheme where you bind a window of CPU to
> > > > a
> > > >
Hi Weishi,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on drm/drm-next drm-exynos/exynos-drm-next
drm-intel/for-linux-next drm-intel/for-linux-next-fixes drm-tip/drm-tip
linus/master v6.9-rc6 next-20240430]
[If
On Sun, 21 Apr 2024 23:30:33 -0700
Vivek Kasireddy wrote:
> From Jason Gunthorpe:
> "dma-buf has become a way to safely acquire a handle to non-struct page
> memory that can still have lifetime controlled by the exporter. Notably
> RDMA can now import dma-buf FDs and build them into MRs which all
On 4/30/2024 1:29 PM, Rodrigo Vivi wrote:
> On Tue, Apr 30, 2024 at 05:38:02PM +, Easwar Hariharan wrote:
>> 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], f
Hi Weishi,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on drm/drm-next drm-exynos/exynos-drm-next
drm-intel/for-linux-next-fixes drm-tip/drm-tip linus/master v6.9-rc6
next-20240430]
[If your patch is applied to
Hi,
On Mon, Apr 29, 2024 at 6:16 PM 隋景峰 wrote:
>
> Hi,
>
>
> > -原始邮件-
> > 发件人: "Maxime Ripard"
> > 发送时间: 2024-04-29 19:30:24 (星期一)
> > 收件人: "Sui Jingfeng"
> > 抄送: "Sui Jingfeng" , "Maarten Lankhorst"
> > , "Thomas Zimmermann"
> > , "David Airlie" , "Daniel Vetter"
> > , "Douglas Ande
On Tue, Apr 30, 2024 at 05:38:02PM +, Easwar Hariharan wrote:
> 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 terminology for users of
> I2C_ALGOBIT b
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: d04466706db5e241ee026f17b5f920e50dee26b5 Add linux-next specific
files for 20240430
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202404301738.j71xgyar-...@intel.com
Unverified
Hi Dave and Sima,
Here goes one extra, and really the last one targeting 6.10.
We have decided to do this extra one so we could include the
good clean-up on i915/xe's fbdev work done by Thomas Zimmermann.
And it looks like he has more work on top of that, so it would
be good to propagate this ini
Hi,
On Tue, Apr 23, 2024 at 7:30 PM Cong Yang
wrote:
>
> The Starry HX83102 based mipi panel should never have been part of the boe
> tv101wum driver. Discussion with Doug and Linus in V1 [1], we need a
> separate driver to enable the hx83102 controller.
>
> In hx83102 driver, add DSI commands as
On Tue, Apr 30, 2024 at 11:55 AM Jens Axboe wrote:
>
> On 4/30/24 12:29 PM, Mina Almasry wrote:
> > On Tue, Apr 30, 2024 at 6:46?AM Jens Axboe wrote:
> >>
> >> On 4/26/24 8:11 PM, Mina Almasry wrote:
> >>> On Fri, Apr 26, 2024 at 5:18?PM David Wei wrote:
>
> On 2024-04-02 5:20 pm, Mina
On Tue, Apr 30, 2024 at 02:30:02PM -0300, Jason Gunthorpe wrote:
> On Mon, Apr 29, 2024 at 10:25:48AM +0200, Thomas Hellström wrote:
>
> > > Yes there is another common scheme where you bind a window of CPU to
> > > a
> > > window on the device and mirror a fixed range, but this is a quite
> > > d
On 4/30/24 12:29 PM, Mina Almasry wrote:
> On Tue, Apr 30, 2024 at 6:46?AM Jens Axboe wrote:
>>
>> On 4/26/24 8:11 PM, Mina Almasry wrote:
>>> On Fri, Apr 26, 2024 at 5:18?PM David Wei wrote:
On 2024-04-02 5:20 pm, Mina Almasry wrote:
> @@ -69,20 +106,26 @@ net_iov_binding(const str
On Mon, Apr 29, 2024 at 1:39 PM Jim Cromie wrote:
>
> Tell the compiler about our vectors (array,length), in 2 places:
>
these are not flex-arrays, using counted-by is wrong here.
Ive dropped this commit, series rebases clean wo it.
> h: struct _ddebug_info, which keeps refs to the __dyndbg_*
On 2024-04-25 07:21, Dan Carpenter wrote:
> These lines are indented too far. Clean the whitespace.
>
Thanks.
Reviewed-by: Harry Wentland
In the process of merging it into amd-staging-drm-next.
Harry
> Signed-off-by: Dan Carpenter
> ---
> v2: Delete another blank line (checkpatch.pl --s
On 2024-04-24 12:28, Colin Ian King wrote:
> There are various spelling mistakes in dml2_printf messages, fix them.
>
Thanks.
Reviewed-by: Harry Wentland
In the process of merging it into amd-staging-drm-next.
Harry
> Signed-off-by: Colin Ian King
> ---
> .../dc/dml2/dml21/src/dml2_core
On 2024-04-24 12:14, Nathan Chancellor wrote:
> When building with clang 19 or newer (which strengthened some of the
> enum conversion warnings for C), there is a warning (or error with
> CONFIG_WERROR=y) around doing arithmetic with an enumerated type and a
> floating point expression.
>
>
On Tue, Apr 30, 2024 at 6:46 AM Jens Axboe wrote:
>
> On 4/26/24 8:11 PM, Mina Almasry wrote:
> > On Fri, Apr 26, 2024 at 5:18?PM David Wei wrote:
> >>
> >> On 2024-04-02 5:20 pm, Mina Almasry wrote:
> >>> @@ -69,20 +106,26 @@ net_iov_binding(const struct net_iov *niov)
> >>> */
> >>> typedef
On 2024-04-22 04:58, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> drm_color_ctm_3x4 is some undocumented amgdpu private
> uapi and thus has no business being in drm_mode.h.
> At least move it to some amdgpu specific header, albeit
> with the wrong namespace as maybe something somewhere
> is
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 terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the specific
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 terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the specific
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 terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the specific
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 terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the specific
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 terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the specific
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 terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the specific
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 terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the specific
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 terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the specific
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 terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the specific
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 terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the specific
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 terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the specific
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 terminology for users of
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the specific
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 terminology for users of the
I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
in the spec
On Mon, Apr 29, 2024 at 10:25:48AM +0200, Thomas Hellström wrote:
> > Yes there is another common scheme where you bind a window of CPU to
> > a
> > window on the device and mirror a fixed range, but this is a quite
> > different thing. It is not SVA, it has a fixed range, and it is
> > probably b
Hi,
On 2024/4/30 22:32, Andy Shevchenko wrote:
On Fri, Apr 26, 2024 at 04:43:18AM +0800, Sui Jingfeng wrote:
On 2024/4/26 03:10, Andy Shevchenko wrote:
On Fri, Apr 26, 2024 at 02:08:16AM +0800, Sui Jingfeng wrote:
On 2024/4/25 22:26, Andy Shevchenko wrote:
It seems driver missed the point o
Hi,
On 2024/4/30 17:26, Maxime Ripard wrote:
Hi,
On Tue, Apr 30, 2024 at 01:35:21AM +0800, Sui Jingfeng wrote:
Linux kernel puts strict limits on which functions and data structures
are available to loadable kernel modules; only those that have been
explicitly exported with EXPORT_SYMBOL() or
On Tue, 30 Apr 2024 17:40:54 +0100
Liviu Dudau wrote:
> On Tue, Apr 30, 2024 at 01:28:52PM +0200, 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_PO
Hi,
On 2024/4/30 07:10, Jessica Zhang wrote:
On 4/29/2024 10:12 AM, Sui Jingfeng wrote:
The else clause after the ruturn clause is not useful.
Hi Sui,
Spelling nit: ruturn --> return
Thanks for pointed out, will be fixed.
Besides that,
Reviewed-by: Jessica Zhang
Thanks,
Jessica
On Tue, Apr 16, 2024 at 9:29 PM Jiapeng Chong
wrote:
>
> ./drivers/gpu/drm/vmwgfx/vmwgfx_vkms.c: vmwgfx_vkms.h is included more than
> once.
>
> Reported-by: Abaci Robot
> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=8772
> Signed-off-by: Jiapeng Chong
> ---
> drivers/gpu/drm/vmwgfx/
On 2024/4/25 22:26, Andy Shevchenko wrote:
In one case the -1 is returned which is quite confusing code for
the wrong device ID, in another the ret is returning instead of
plain 0 that also confusing as readed may ask the possible meaning
of positive codes, which are never the case there. Conve
Hi Marcelo,
First of all, thanks a lot for your patch! Please check some of my
inline comments.
On 4/27/24 10:05 AM, Marcelo Mendes Spessoto Junior wrote:
Fix most of the display documentation compile warnings by
documenting struct mpc_funcs functions in dc/inc/hw/mpc.h file.
Could you add
Hi,
On 2024/4/25 22:26, Andy Shevchenko wrote:
GPIO controller might not be available when driver is being probed.
There are plenty of reasons why, one of which is deferred probe.
Since GPIOs are optional, return any error code we got to the upper
layer, including deferred probe. With that in
On Tue, Apr 30, 2024 at 01:28:52PM +0200, 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.
>
> v2:
> - Ne
On 2024/4/30 22:13, Andy Shevchenko wrote:
On Fri, Apr 26, 2024 at 05:13:43AM +0800, Sui Jingfeng wrote:
On 2024/4/26 03:12, Andy Shevchenko wrote:
On Fri, Apr 26, 2024 at 02:53:22AM +0800, Sui Jingfeng wrote:
On 2024/4/26 02:08, Sui Jingfeng wrote:
...
Are you speaking to yourself? I'm t
On Tue, Apr 30, 2024 at 01:28:51PM +0200, 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, a
Allows PTE kind and tile mode on BO create with VM_BIND, as well as adds a
GETPARAM to indicate this change. This is needed to support modifiers in NVK
and ensure correctness when dealing with the nouveau GL driver.
---
v2 of the VMA PTE kind and tile mode patch. This one adds the kind and tile
On Tue, Apr 30, 2024 at 01:28:50PM +0200, 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_coun
On 4/30/24 16:53, Jani Nikula wrote:
On Tue, 30 Apr 2024, Danilo Krummrich wrote:
After dropping linux/debugfs.h include from drm/drm_print.h the following
files in i915 miss the linux/debugfs.h include: i915_debugfs.c,
i915_debugfs_params.c and i915_gpu_error.c.
Add the include to fix the cor
On Tue, Apr 30, 2024 at 01:28:49PM +0200, 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
> handlin
On Tue, 30 Apr 2024, Danilo Krummrich wrote:
> After dropping linux/debugfs.h include from drm/drm_print.h the following
> files in i915 miss the linux/debugfs.h include: i915_debugfs.c,
> i915_debugfs_params.c and i915_gpu_error.c.
>
> Add the include to fix the corresponding build errors.
>
> Re
On Fri, Apr 26, 2024 at 04:43:18AM +0800, Sui Jingfeng wrote:
> On 2024/4/26 03:10, Andy Shevchenko wrote:
> > On Fri, Apr 26, 2024 at 02:08:16AM +0800, Sui Jingfeng wrote:
> > > On 2024/4/25 22:26, Andy Shevchenko wrote:
> > > > It seems driver missed the point of proper use of device property API
On 30/04/2024 06:11, Vignesh Raman wrote:
Now the testlist is used from IGT build, so update
xfails with the new testlist.
Signed-off-by: Vignesh Raman
---
.../gpu/drm/ci/xfails/amdgpu-stoney-fails.txt | 47 +++
.../drm/ci/xfails/amdgpu-stoney-flakes.txt| 8 +-
.../gpu/drm/c
On 30/04/2024 06:11, Vignesh Raman wrote:
Skip driver specific tests and skip kms tests for
panfrost driver since it is not a kms driver.
Signed-off-by: Vignesh Raman
---
.../gpu/drm/ci/xfails/amdgpu-stoney-skips.txt | 14 +-
drivers/gpu/drm/ci/xfails/i915-amly-skips.txt |
On 30/04/2024 06:11, Vignesh Raman wrote:
With latest IGT, the tests tries to load the module and it
fails. So build the virtual GPU driver for virtio as module.
Signed-off-by: Vignesh Raman
Acked-by: Helen Koike
---
drivers/gpu/drm/ci/build.sh | 1 -
drivers/gpu/drm/ci/igt_run
On 30/04/2024 06:11, Vignesh Raman wrote:
zlib.net is not allowing tarball download anymore and results
in below error in kernel+rootfs_arm32 container build,
urllib.error.HTTPError: HTTP Error 403: Forbidden
urllib.error.HTTPError: HTTP Error 415: Unsupported Media Type
Uprev mesa to latest
On 29/04/2024 09:24, Thomas Zimmermann wrote:
Am 26.04.24 um 14:10 schrieb Jocelyn Falempe:
plane->state and plane->state->fb can be NULL, so add a check before
dereferencing them.
Found by testing with the imx driver.
Fixes: 879b3b6511fe9 ("drm/fb_dma: Add generic get_scanout_buffer()
fo
On 4/30/24 15:18, Chaitanya Kumar Borah wrote:
Add the missing break statement that causes the following build error
CC [M] drivers/gpu/drm/i915/display/intel_display_device.o
../drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c: In function
‘build_registry’:
../drivers/
After dropping linux/debugfs.h include from drm/drm_print.h the following
files in i915 miss the linux/debugfs.h include: i915_debugfs.c,
i915_debugfs_params.c and i915_gpu_error.c.
Add the include to fix the corresponding build errors.
Reported-by: kernel test robot
Fixes: 33d5ae6cacf4 ("drm/pr
On Tue, Apr 30, 2024 at 04:38:55PM +0300, Jani Nikula wrote:
> On Tue, 30 Apr 2024, Daniel Vetter wrote:
> > Might also be a good idea to wait a bit in case there's any regression
> > reports for really old userspace. But I guess there's not a high chance
> > for that to happen here, so imo fine t
On Fri, Apr 26, 2024 at 05:13:43AM +0800, Sui Jingfeng wrote:
> On 2024/4/26 03:12, Andy Shevchenko wrote:
> > On Fri, Apr 26, 2024 at 02:53:22AM +0800, Sui Jingfeng wrote:
> > > On 2024/4/26 02:08, Sui Jingfeng wrote:
...
> > Are you speaking to yourself? I'm totally lost.
> >
> > Please, if yo
On Tue, Apr 30, 2024 at 06:48:40PM GMT, Chaitanya Kumar Borah wrote:
Add the missing break statement that causes the following build error
CC [M] drivers/gpu/drm/i915/display/intel_display_device.o
../drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c: In function
‘build_registry
On 4/26/24 8:11 PM, Mina Almasry wrote:
> On Fri, Apr 26, 2024 at 5:18?PM David Wei wrote:
>>
>> On 2024-04-02 5:20 pm, Mina Almasry wrote:
>>> @@ -69,20 +106,26 @@ net_iov_binding(const struct net_iov *niov)
>>> */
>>> typedef unsigned long __bitwise netmem_ref;
>>>
>>> +static inline bool net
On Tue, 30 Apr 2024, Daniel Vetter wrote:
> Might also be a good idea to wait a bit in case there's any regression
> reports for really old userspace. But I guess there's not a high chance
> for that to happen here, so imo fine to just go ahead right away.
This small bit is definitely easier to r
On 4/27/24 03:11, Mina Almasry wrote:
On Fri, Apr 26, 2024 at 5:18 PM David Wei wrote:
On 2024-04-02 5:20 pm, Mina Almasry wrote:
@@ -69,20 +106,26 @@ net_iov_binding(const struct net_iov *niov)
*/
typedef unsigned long __bitwise netmem_ref;
+static inline bool netmem_is_net_iov(const n
Adding dri-devel because this is kinda more important.
On Mon, Apr 29, 2024 at 04:28:42PM -0500, Lucas De Marchi wrote:
> On Mon, Apr 29, 2024 at 02:45:26PM GMT, Rodrigo Vivi wrote:
> > On Mon, Apr 29, 2024 at 04:17:54PM +0100, Matthew Auld wrote:
> > > On 29/04/2024 14:52, Lucas De Marchi wrote:
Add the missing break statement that causes the following build error
CC [M] drivers/gpu/drm/i915/display/intel_display_device.o
../drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c: In function
‘build_registry’:
../drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:1266:3: er
On 4/30/24 15:06, Lucas De Marchi wrote:
On Fri, Apr 26, 2024 at 06:08:19PM GMT, Danilo Krummrich wrote:
On 4/25/24 18:38, Timur Tabi wrote:
On Thu, 2024-04-25 at 15:22 +0200, Danilo Krummrich wrote:
+ size_t length;
+
+ /* Remove any whitespace from the parameter string */
+
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 limited by
> implementation constraints, and all kno
On Mon, Apr 29, 2024 at 08:53:15PM +0300, Jani Nikula wrote:
> On Mon, 29 Apr 2024, Hamza Mahfooz wrote:
> > On 4/29/24 12:43, Jani Nikula wrote:
> >> The driver date serves no useful purpose, because it's hardly ever
> >> updated. The information is misleading at best.
> >>
> >> As described in
On Fri, Apr 26, 2024 at 06:08:19PM GMT, Danilo Krummrich wrote:
On 4/25/24 18:38, Timur Tabi wrote:
On Thu, 2024-04-25 at 15:22 +0200, Danilo Krummrich wrote:
+ size_t length;
+
+ /* Remove any whitespace from the parameter string */
+ length = strip(p,
On Fri, Apr 19, 2024 at 03:20:19PM +0200, Jocelyn Falempe wrote:
> drm_panic has been introduced recently, and uses the same fonts as
> FRAMEBUFFER_CONSOLE.
>
> Signed-off-by: Jocelyn Falempe
Acked-by: Daniel Vetter
lib/fonts/ doesn't seem to have a designated maintainer, so please push
this t
On Fri, Apr 19, 2024 at 5:34 PM Nam Cao wrote:
>
> On 2024-04-19 Patrik Jakobsson wrote:
> > Neither cancel_delayed_work_sync() or flush_delayed_work() prevent new
> > work from being scheduled after they return.
>
> flush_delayed_work() is called during device closing. And because no
> writes are
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 the MCU_CONTROL register.
Fixes: 2718d91816ee ("drm/panthor: Add th
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 and partially
hardcoded paths (meaning main display through O
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
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.
v2:
- New patch
Fixes: 9cca48fa4f89 ("drm/panthor: Add the heap logical block")
Repo
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.
v2:
- Fix the check
Fixes: 9cca48fa4f89 ("
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 ex
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.
Regards,
Boris
Antonino Maniscalco (1):
drm/panthor: Fi
5.15-stable review patch. If anyone has any objections, please let me know.
--
From: Zack Rusin
[ Upstream commit a60ccade88f926e871a57176e86a34bbf0db0098 ]
The conditional was supposed to prevent enabling of a crtc state
without a set primary plane. Accidently it also prevent
On 24.04.2024 5:29 PM, Xilin Wu via B4 Relay wrote:
> From: Xilin Wu
>
> AYN Odin 2 is a gaming handheld based on QCS8550, which is derived
> from SM8550 but without modem RF system.
>
> This commit brings support for:
> * Remoteprocs
> * UFS storage
> * SD Card
> * Type-C with USB3 10Gbps and D
On Thu, Apr 25, 2024 at 05:26:18PM +0300, Andy Shevchenko wrote:
> GPIO controller might not be available when driver is being probed.
> There are plenty of reasons why, one of which is deferred probe.
>
> Since GPIOs are optional, return any error code we got to the upper
> layer, including defer
On Thu, Apr 25, 2024 at 05:26:17PM +0300, Andy Shevchenko wrote:
> It seems driver missed the point of proper use of device property APIs.
> Correct this by updating headers and calls respectively.
>
> Fixes: 5a04227326b0 ("drm/panel: Add ilitek ili9341 panel driver")
> Signed-off-by: Andy Shevche
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 and partially
hardcoded paths (meaning main display through OF graph and external
display hardcoded, because of
On Tue, Apr 30, 2024 at 02:41:18PM +0530, Vignesh Raman wrote:
> Stop vendoring the testlist into the kernel. Instead, use the
> testlist from the IGT build to ensure we do not miss renamed
> or newly added tests.
>
> Signed-off-by: Vignesh Raman
> ---
> drivers/gpu/drm/ci/build-igt.sh | 23 +
On Tue, Apr 30, 2024 at 02:41:21PM +0530, Vignesh Raman wrote:
> Now the testlist is used from IGT build, so update
> xfails with the new testlist.
>
> Signed-off-by: Vignesh Raman
> ---
> .../gpu/drm/ci/xfails/amdgpu-stoney-fails.txt | 47 +++
> .../drm/ci/xfails/amdgpu-stoney-flakes.tx
On Tue, Apr 30, 2024 at 02:41:20PM +0530, Vignesh Raman wrote:
> Skip driver specific tests and skip kms tests for
> panfrost driver since it is not a kms driver.
>
> Signed-off-by: Vignesh Raman
> ---
> .../gpu/drm/ci/xfails/amdgpu-stoney-skips.txt | 14 +-
> drivers/gpu/drm/ci/xf
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 wrote:
> > > > On Fri, Apr 26, 2024 at 04:43:18AM +0800, Sui Jingfeng wrote:
> > > > > O
Hi,
On Tue, Apr 30, 2024 at 01:35:21AM +0800, Sui Jingfeng wrote:
> Linux kernel puts strict limits on which functions and data structures
> are available to loadable kernel modules; only those that have been
> explicitly exported with EXPORT_SYMBOL() or EXPORT_SYMBOL_GPL() are
> accessible. In th
Now the testlist is used from IGT build, so update
xfails with the new testlist.
Signed-off-by: Vignesh Raman
---
.../gpu/drm/ci/xfails/amdgpu-stoney-fails.txt | 47 +++
.../drm/ci/xfails/amdgpu-stoney-flakes.txt| 8 +-
.../gpu/drm/ci/xfails/amdgpu-stoney-skips.txt | 15
driver
Skip driver specific tests and skip kms tests for
panfrost driver since it is not a kms driver.
Signed-off-by: Vignesh Raman
---
.../gpu/drm/ci/xfails/amdgpu-stoney-skips.txt | 14 +-
drivers/gpu/drm/ci/xfails/i915-amly-skips.txt | 14 +-
drivers/gpu/drm/ci/xfails/i91
With latest IGT, the tests tries to load the module and it
fails. So build the virtual GPU driver for virtio as module.
Signed-off-by: Vignesh Raman
---
drivers/gpu/drm/ci/build.sh | 1 -
drivers/gpu/drm/ci/igt_runner.sh | 6 +++---
drivers/gpu/drm/ci/image-tags.yml | 4 ++--
drivers/gpu/
Stop vendoring the testlist into the kernel. Instead, use the
testlist from the IGT build to ensure we do not miss renamed
or newly added tests.
Signed-off-by: Vignesh Raman
---
drivers/gpu/drm/ci/build-igt.sh | 23 +
drivers/gpu/drm/ci/igt_runner.sh |9 +-
drivers/gpu/drm/ci/testlist.txt
zlib.net is not allowing tarball download anymore and results
in below error in kernel+rootfs_arm32 container build,
urllib.error.HTTPError: HTTP Error 403: Forbidden
urllib.error.HTTPError: HTTP Error 415: Unsupported Media Type
Uprev mesa to latest version which includes a fix for this issue.
ht
1 - 100 of 113 matches
Mail list logo
