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.
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 +-
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
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 +-
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 ++--
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
On Tue, Aug 29, 2023 at 05:30:55AM +, Brandon Pollack wrote:
> From: Jim Shargo
>
> This is a small refactor to make ConfigFS support easier. This should be
> a no-op refactor.
>
> Signed-off-by: Jim Shargo
> Signed-off-by: Brandon Pollack
This should be part of the series to switch over
On Tue, Aug 29, 2023 at 05:30:54AM +, Brandon Pollack wrote:
> From: Jim Shargo
>
> This change supports multiple CRTCs, encoders, connectors instead of one
> of each per device.
>
> Since ConfigFS-based devices will support multiple crtcs, it's useful to
> move all of the
On Monday, April 29th, 2024 at 18: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 Documentation/gpu/drm-internals.rst:
>
> The driver date, formatted as MMDD, is meant to
On Tue, Aug 29, 2023 at 05:30:52AM +, Brandon Pollack wrote:
> Since Jim is busy with other work and I'm working on some things that
> rely on this, I've taken up the task of doing the iterations. I've
> addressed the comments as best I can (those replies are to each
> individual change) and
Jani Nikula writes:
> The driver date serves no useful purpose, because it's hardly ever
> updated. The information is misleading at best.
>
> As described in Documentation/gpu/drm-internals.rst:
>
> The driver date, formatted as MMDD, is meant to identify the date
> of the latest
On Tue, Aug 29, 2023 at 05:30:53AM +, Brandon Pollack wrote:
> From: Jim Shargo
>
> This is a small refactor to make ConfigFS support easier. Once we
> support ConfigFS, there can be multiple devices instantiated by the
> driver, and so moving everything into managed memory makes things much
On Tue, Aug 29, 2023 at 05:30:56AM +, Brandon Pollack wrote:
> From: Jim Shargo
>
> This change adds the basic scaffolding for ConfigFS, including setting
> up the default directories. It does not allow for the registration of
> configfs-backed devices, which is complex and provided in a
On Tue, Aug 29, 2023 at 05:30:59AM +, Brandon Pollack wrote:
> This change adds the ability to read or write a "1" or a "0" to the
> newly added "connected" attribute of a connector in the vkms entry in
> configfs.
>
> A write will trigger a call to drm_kms_helper_hotplug_event, causing a
>
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
On Tue, 30 Apr 2024, Simon Ser wrote:
> On Monday, April 29th, 2024 at 18: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 Documentation/gpu/drm-internals.rst:
>>
>> The
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
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 +-
>
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 +++
>
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
Hi,
I got following kernel WARNING when the my 2-core KVM(6.9.0-rc6) is under high
cpu load.
[Mon Apr 29 21:36:04 2024] [ cut here ]
[Mon Apr 29 21:36:04 2024] workqueue: WQ_MEM_RECLAIM
ttm:ttm_bo_delayed_delete [ttm] is flushing !WQ_MEM_RECLAIM
Uprev mesa to the latest version and 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.
Update the xfails with the latest testlist run.
Also build virtual GPU driver for virtio as module.
The flakes
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
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
Hi,
On Mon, Apr 29, 2024 at 10:17:45AM +0200, Sean Nyekjaer wrote:
> On Wed, Apr 24, 2024 at 09:21:17AM UTC, Maxime Ripard wrote:
> > Hi,
> >
> > Sorry, my previous review didn't go through.
> >
> > On Fri, Mar 22, 2024 at 11:47:31AM +0100, Sean Nyekjaer wrote:
> > > When using the DSI
On Tue, Aug 29, 2023 at 05:30:57AM +, Brandon Pollack wrote:
> From: Jim Shargo
>
> VKMS now supports creating and using virtual devices!
>
> In addition to the enabling logic, this commit also prevents users from
> adding new objects once a card is registered.
>
> Signed-off-by: Jim
On Tue, Aug 29, 2023 at 05:30:57AM +, Brandon Pollack wrote:
> From: Jim Shargo
>
> VKMS now supports creating and using virtual devices!
>
> In addition to the enabling logic, this commit also prevents users from
> adding new objects once a card is registered.
I forgot one comment ... I
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:
> > > > >
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
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
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 =
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()
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
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
>
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
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 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
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
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
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
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
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 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 -
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 */
+
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
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:
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
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
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")
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:
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:
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’:
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 +-
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 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
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
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
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
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
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
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.
>
>
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
> ---
>
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
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
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
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
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
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
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
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
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 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 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
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
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:
> -
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.
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
> ---
>
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
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
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,
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()
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
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 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
> > >
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
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
1 - 100 of 110 matches
Mail list logo
