This driver, for the time being, assumes that the kernel page size is 4kB,
so it fails on loong64 and aarch64 with 16kB pages, and ppc64el with 64kB
pages.
Signed-off-by: Simon Richter
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/xe/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/d
On 7/9/25 13:56, Melissa Wen wrote:
No I think it will not work as expected for movable 3D LUT, since
movable 3D LUT is a MPC capability.
I have actually sent a patch in the past to clarify this on DCN401. So,
this check doesn't cover this driver anymore, for example.
- https://lore.kernel.o
On Saturday, August 2nd, 2025 at 03:49, Alex Hung wrote:
> It may be better to change it now if we know it needs changing in the
> future.
It would become mutable only for hardware that supports switching the
interpolation. It would remain immutable otherwise.
Immutable is an indication that us
Hi Simon,
It may be better to change it now if we know it needs changing in the
future.
Hi Xaver,
Do you think this need to be immutable or mutable? Do you believe this
need to be mutable?
On 7/9/25 14:30, Simon Ser wrote:
On Tuesday, June 17th, 2025 at 06:27, Alex Hung wrote:
- 1D LU
Instead of using the "sha1" crypto_shash, simply call the sha1() library
function. This is simpler and faster.
Signed-off-by: Eric Biggers
---
Note: this patch depends on the SHA-1 library functions that were merged
in v6.17-rc1.
drivers/gpu/drm/bridge/Kconfig | 3 +--
drivers/gpu/drm/b
On 7/14/2025 4:54 AM, Dmitry Baryshkov wrote:
On Fri, Jul 11, 2025 at 05:58:23PM -0700, Jessica Zhang wrote:
Currently, the DP link training is being done during HPD. Move
link training to atomic_enable() in accordance with the atomic_enable()
documentation.
In addition, don't disable the li
On Fri, Aug 01, 2025 at 06:26:47PM +, Cavitt, Jonathan wrote:
> -Original Message-
> From: Intel-gfx On Behalf Of Colin
> Ian King
> Sent: Friday, August 1, 2025 8:17 AM
> To: Jani Nikula ; Vivi, Rodrigo
> ; Tvrtko Ursulin ; David Airlie
> ; Simona Vetter ;
> intel-...@lists.freede
On Fri, Aug 01, 2025 at 06:27:25PM +, Cavitt, Jonathan wrote:
> -Original Message-
> From: Intel-xe On Behalf Of Colin
> Ian King
> Sent: Friday, August 1, 2025 9:47 AM
> To: Jani Nikula ; Vivi, Rodrigo
> ; Joonas Lahtinen ;
> Tvrtko Ursulin ; David Airlie ;
> Simona Vetter ; intel
Apologies, I saw your changes for another chipset, but missed the
nouveau part. I've responded to your thread now. Thanks for making the fix!
-James
On 7/31/25 19:28, Imre Deak wrote:
On Thu, Jul 31, 2025 at 04:41:04PM -0700, James Jones wrote:
Plumb the format info from .fb_create() all the
Review-by: James Jones
Tested-by: James Jones
Tested on GB203, TU102, and NV50.
Thanks,
-James
On 7/28/25 03:16, Imre Deak wrote:
Plumb the format info from .fb_create() all the way to
drm_helper_mode_fill_fb_struct() to avoid the redundant
lookup.
The patch is based on the driver parts of
On Fri, 2025-08-01 at 15:42 +, Timur Tabi wrote:
> On Fri, 2025-08-01 at 17:12 +0200, Danilo Krummrich wrote:
> > On Fri Aug 1, 2025 at 4:50 PM CEST, Timur Tabi wrote:
> > > Does mean that the TODO has been done, or that someone completely forgot
> > > and now your patch
> > > is
> > > remove
The __clear_task_blocked_on() helper added a number of sanity
checks ensuring we hold the mutex wait lock and that the task
we are clearing blocked_on pointer (if set) matches the mutex.
However, there is an edge case in the _ww_mutex_wound() logic
where we need to clear the blocked_on pointer for
On Thu, Jul 31, 2025 at 10:09 PM K Prateek Nayak wrote:
> At the very least I think we should make a local copy of "p->blocked_on"
> to see a consistent view throughout __clear_task_blocked_on() - task either
> sees it is blocked on the mutex and clear "p->blocked_on", or it sees it is
> blocked o
-Original Message-
From: Intel-xe On Behalf Of Colin Ian
King
Sent: Friday, August 1, 2025 9:47 AM
To: Jani Nikula ; Vivi, Rodrigo
; Joonas Lahtinen ;
Tvrtko Ursulin ; David Airlie ; Simona
Vetter ; intel-...@lists.freedesktop.org;
intel...@lists.freedesktop.org; dri-devel@lists.freed
-Original Message-
From: Intel-gfx On Behalf Of Colin
Ian King
Sent: Friday, August 1, 2025 8:17 AM
To: Jani Nikula ; Vivi, Rodrigo
; Tvrtko Ursulin ; David Airlie
; Simona Vetter ;
intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Cc: kernel-janit...@vger.kernel.org; li
Later gens have both a PIPE_BR and PIPE_NONE section. The snapshot tool
seems to expect this for x1-85 as well. I guess this was just a bug in
downstream kgsl, which went unnoticed?
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_gen7_0_0_snapshot.h | 11 +--
drivers/gpu
We weren't setting the # of captured debugbus blocks.
Reported-by: Connor Abbott
Suggested-by: Connor Abbott
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.
Program the selector _after_ selecting the aperture. This aligns with
the downstream driver, and fixes a case where we were failing to capture
ctx0 regs (and presumably what we thought were ctx1 regs were actually
ctx0).
Suggested-by: Akhil P Oommen
Signed-off-by: Rob Clark
---
drivers/gpu/drm
The bitfield positions changed in a7xx.
v2: Don't open-code the bitfield building
v3: Also fix cx_debugbus
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 32 ++-
drivers/gpu/drm/msm/registers/adreno/a6xx.xml | 14 +++-
2 files changed, 37 insert
This is needed to properly interpret some of the sections.
v2: Fix missing \n
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c
Various fixes I've found so far while ingesting upstream devcore dumps
into internal tools.
Rob Clark (7):
drm/msm: Add missing "location"s to devcoredump
drm/msm: Fix section names and sizes
drm/msm: Fix order of selector programming in cluster snapshot
drm/msm: Constify snapshot tables
A bit of divergence from the downstream driver from which these headers
were imported. But no need for these tables not to be const.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 2 +-
drivers/gpu/drm/msm/adreno/adreno_gen7_0_0_snapshot.h | 8
d
The section names randomly appended _DATA or _ADDR in many cases, and/or
didn't match the reg names. Fix them so crashdec can properly resolve
the section names back to reg names.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h | 38 +--
.../drm/msm/ad
On Tue, Jul 29, 2025 at 07:00:30PM +0530, Nilesh Laad wrote:
> Add 3840x2160@30 mode in lt9611uxc modes to add support for
> 4K@30 resolution.
>
> Signed-off-by: Nilesh Laad
> ---
> drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/d
On Wed, Jul 30, 2025 at 06:09:38PM +0530, Ayushi Makhija wrote:
> Currently, the high bitfield of certain DSI registers
> do not align with the configuration of the SWI registers
> description. This can lead to wrong programming these DSI
> registers, for example for 4k resloution where H_TOTAL is
On Fri, Aug 01, 2025 at 11:07:35PM +0800, Jun Nie wrote:
> Currently, SSPPs are assigned to a maximum of two pipes. However,
> quad-pipe usage scenarios require four pipes and involve configuring
> two stages. In quad-pipe case, the first two pipes share a set of
> mixer configurations and enable m
On Fri, Aug 01, 2025 at 11:07:25PM +0800, Jun Nie wrote:
> Current code will validate current plane and previous plane to
> confirm they can share a SSPP with multi-rect mode. The SSPP
> is already allocated for previous plane, while current plane
> is not associated with any SSPP yet. Null pointer
Hi Maxime,
On Fri, 25 Jul 2025 16:15:23 +0200
Maxime Ripard wrote:
> On Mon, Jul 14, 2025 at 12:32:40PM +0200, Luca Ceresoli wrote:
> > Hi Maxime,
> >
> > On Thu, 10 Jul 2025 09:13:46 +0200
> > Maxime Ripard wrote:
> >
> > > On Wed, Jul 09, 2025 at 06:48:03PM +0200, Luca Ceresoli wrote:
>
The bridge returned by drm_bridge_get_next_bridge() is refcounted. Put it
when done. We need to ensure it is not put before either next_bridge or
next_bridge_state is in use, thus for simplicity use a cleanup action.
Signed-off-by: Luca Ceresoli
---
Changed in v2:
- use cleanup action instead o
The bridge returned by drm_bridge_get_next_bridge() is refcounted. Put it
when done. We need to ensure it is not put before either next_bridge or
next_bridge_state is in use, thus for simplicity use a cleanup action.
Signed-off-by: Luca Ceresoli
---
Changed in v2:
- use cleanup action instead o
drm_bridge_get_next_bridge() returns a bridge pointer that the
caller could hold for a long time. Increment the refcount of the returned
bridge and document it must be put by the caller.
Reviewed-by: Maxime Ripard
Signed-off-by: Luca Ceresoli
---
include/drm/drm_bridge.h | 9 -
1 file c
Simplify code to know whether a bridge is the last in the chain by using
drm_bridge_is_last().
Reviewed-by: Maxime Ripard
Signed-off-by: Luca Ceresoli
---
drivers/gpu/drm/display/drm_bridge_connector.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/disp
Some code needing to know whether a bridge is the last in a chain currently
call drm_bridge_get_next_bridge(). However drm_bridge_get_next_bridge()
will soon increment the refcount of the returned bridge, which would make
such code more annoying to write.
In preparation for drm_bridge_get_next_bri
Add an equivalent of drm_bridge_chain_get_first_bridge() to get the last
bridge.
Reviewed-by: Maxime Ripard
Signed-off-by: Luca Ceresoli
---
include/drm/drm_bridge.h | 18 ++
1 file changed, 18 insertions(+)
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index
Use drm_bridge_chain_get_last_bridge() instead of open coding a loop with
two invocations of drm_bridge_get_next_bridge() per iteration.
Besides being cleaner and more efficient, this change is necessary in
preparation for drm_bridge_get_next_bridge() to get a reference to the
returned bridge.
Si
Use drm_bridge_chain_get_last_bridge() instead of open coding a loop with
two invocations of drm_bridge_get_next_bridge() per iteration.
Besides being cleaner and more efficient, this change is necessary in
preparation for drm_bridge_get_next_bridge() to get a reference to the
returned bridge.
Re
Add an equivalent of list_first_entry_or_null() to obtain the last element
of a list.
Signed-off-by: Luca Ceresoli
---
Cc: Andy Shevchenko
Cc: Andrew Morton
Cc: Zijun Hu
Cc: Greg Kroah-Hartman
---
include/linux/list.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/incl
Note: the cover in v1 was mentioning by mistake
drm_bridge_get_last_bridge() instead of drm_bridge_get_next_bridge().
This series adds drm_bridge_get/put() calls for DRM bridges returned by
drm_bridge_get_next_bridge().
This is part of the work towards removal of bridges from
On Fri, Aug 01, 2025 at 06:50:18PM +0200, David Hildenbrand wrote:
> On 01.08.25 18:40, Jason Gunthorpe wrote:
> > On Fri, Jul 25, 2025 at 10:31:25AM +1000, Alistair Popple wrote:
> >
> > > The only issue would be if there were generic code paths that somehow
> > > have a
> > > raw pfn obtained f
On Sun, Jul 20, 2025 at 11:59:10PM -0700, Christoph Hellwig wrote:
> > + /*
> > +* Don't fault in device private pages owned by the caller,
> > +* just report the PFN.
> > +*/
> > + if (pgmap->owner == range->dev_private_owner) {
> > + *hmm_pfn = swp_offset_pfn(entry);
> >
On 01.08.25 18:40, Jason Gunthorpe wrote:
On Fri, Jul 25, 2025 at 10:31:25AM +1000, Alistair Popple wrote:
The only issue would be if there were generic code paths that somehow have a
raw pfn obtained from neither a page-table walk or struct page. My assumption
(yet to be proven/tested) is that
There is an extraneous space before a newline in a drm_dbg_kms message.
Remove the space.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/display/intel_bw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/
On Thu, Jul 24, 2025 at 12:30:34AM -0700, Christoph Hellwig wrote:
> On Wed, Jul 23, 2025 at 12:55:22AM -0300, Jason Gunthorpe wrote:
> > On Mon, Jul 21, 2025 at 12:03:41AM -0700, Christoph Hellwig wrote:
> > > On Fri, Jul 18, 2025 at 02:51:11PM +0300, Yonatan Maman wrote:
> > > > From: Yonatan Mam
On Fri, Jul 25, 2025 at 10:31:25AM +1000, Alistair Popple wrote:
> The only issue would be if there were generic code paths that somehow have a
> raw pfn obtained from neither a page-table walk or struct page. My assumption
> (yet to be proven/tested) is that these paths don't exist.
hmm does it,
On Fri, 2025-08-01 at 17:12 +0200, Danilo Krummrich wrote:
> On Fri Aug 1, 2025 at 4:50 PM CEST, Timur Tabi wrote:
> > Does mean that the TODO has been done, or that someone completely forgot
> > and now your patch
> > is
> > remove all reminders?
> >
> > If it's the format, maybe add a fixes: ta
On Fri, Aug 1, 2025 at 2:11 AM Philipp Zabel wrote:
>
> On Thu, Jul 31, 2025 at 9:38 PM Alex Deucher wrote:
>>
>> On Thu, Jul 31, 2025 at 3:33 AM Philipp Zabel
>> wrote:
>> >
>> > Don't wake the GPU if libdrm queries the mmGB_ADDR_CONFIG register
>> > value during amdgpu_query_gpu_info_init().
Hi Greg and Shradha,
could you please check the comment below about the 4ad8d57d902f backport
commit in the v6.1.y stable tree and if you agree with the reasoning why
it has an issue, then suggest a way to resolve it?
Also, AFAICS, other stable trees are not affected, since the original
5abffb66d
There are a couple of redundant repeated checks on err being non-zero that
are always true because they are inside a previous check on err being
non-zero. Remove the duplicated checks.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c | 6 ++
1 file chan
On Thu, Jul 31, 2025 at 08:03:36PM +, Summers, Stuart wrote:
> On Thu, 2025-07-10 at 11:08 -0400, Rodrigo Vivi wrote:
> > From: Badal Nilawar
> >
> > Introduce a debug filesystem node to disable late binding fw reload
> > during the system or runtime resume. This is intended for situations
>
Hi,
On 8/1/25 23:56, Thomas Hellström wrote:
Would you mind if we did the following:
[...]
And instead here add
depends on PAGE_SIZE_4KB || COMPILE_TEST || BROKEN
That is a lot nicer, I like it.
Simon
OpenPGP_signature.asc
Description: OpenPGP digital signature
On Fri Aug 1, 2025 at 4:50 PM CEST, Timur Tabi wrote:
> Does mean that the TODO has been done, or that someone completely forgot and
> now your patch is
> remove all reminders?
>
> If it's the format, maybe add a fixes: tag for the commit that resolved the
> TODO?
The TODO was introduced by comm
To support high-resolution cases that exceed the width limitation of
a pair of SSPPs, or scenarios that surpass the maximum MDP clock rate,
additional pipes are necessary to enable parallel data processing
within the SSPP width constraints and MDP clock rate.
Request 4 mixers and 4 DSCs for high-r
The content of every half of screen is sent out via one interface in
dual-DSI case. The content for every interface is blended by a LM
pair in quad-pipe case, thus a LM pair should not blend any content
that cross the half of screen in this case. Clip plane into pipes per
left and right half screen
Currently, SSPPs are assigned to a maximum of two pipes. However,
quad-pipe usage scenarios require four pipes and involve configuring
two stages. In quad-pipe case, the first two pipes share a set of
mixer configurations and enable multi-rect mode when certain
conditions are met. The same applies
Currently, only 2 pipes are used at most for a plane. A stage structure
describes the configuration for a mixer pair. So only one stage is needed
for current usage cases. The quad-pipe case will be added in future and 2
stages are used in the case. So extend the stage to an array with array
size ST
Currently MAX_CHANNELS_PER_ENC is defined as 2, because 2 channels are
supported at most in one encoder. The case of 4 channels per encoder is
to be added. To avoid breaking current WB usage case, use dedicated WB
definition before 4 WB usage case is supported in future.
Signed-off-by: Jun Nie
Re
The stage contains configuration for a mixer pair. Currently the plane
supports just one stage and 2 pipes. Quad-pipe support will require
handling 2 stages and 4 pipes at the same time. In preparation for that
add a separate define, PIPES_PER_PLANE, to denote number of pipes that
can be used by th
There are 2 pipes in a drm plane at most currently, while 4 pipes are
required for quad-pipe case. Generalize the handling to pipe pair and
ease handling to another pipe pair later. Store pipes in array with
removing dedicated r_pipe.
Signed-off-by: Jun Nie
Reviewed-by: Dmitry Baryshkov
Reviewed
Add pipe as trace argument in trace_dpu_crtc_setup_mixer() to ease
converting pipe into pipe array later.
Signed-off-by: Jun Nie
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 10 +-
There are 2 interfaces and 4 pingpong in quad pipe. Map the 2nd
interface to 3rd PP instead of the 2nd PP.
Signed-off-by: Jun Nie
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 10 --
1 file changed, 8 insertions(+), 2 deletio
Current code only supports usage cases with one pair of mixers at
most. To support quad-pipe usage case, two pairs of mixers need to
be reserved. The lm_count for all pairs is cleared if a peer
allocation fails in current implementation. Reset the current lm_count
to an even number instead of compl
Currently, only one pair of mixers is supported, so a non-zero counter
value is sufficient to identify the correct mixer within that pair.
However, future implementations may involve multiple mixer pairs. With
the current implementation, all mixers within the second pair would be
incorrectly select
It is more likely that resource allocation may fail in complex usage
case, such as quad-pipe case, than existing usage cases.
A resource type ID is printed on failure in the current implementation,
but the raw ID number is not explicit enough to help easily understand
which resource caused the fail
Current code will validate current plane and previous plane to
confirm they can share a SSPP with multi-rect mode. The SSPP
is already allocated for previous plane, while current plane
is not associated with any SSPP yet. Null pointer is referenced
when validating the SSPP of current plane. Skip SS
2 or more SSPPs and dual-DSI interface are need for super wide panel.
And 4 DSC are preferred for power optimal in this case due to width
limitation of SSPP and MDP clock rate constrain. This patch set
extends number of pipes to 4 and revise related mixer blending logic
to support quad pipe. All th
On 8/1/2025 3:32 PM, Dan Carpenter wrote:
> The xe_migrate_alloc() function returns NULL on error. It doesn't return
> error pointers. Update the checking to match.
>
> Fixes: a843b9894705 ("drm/xe/vf: Fix VM crash during VF driver release")
> Signed-off-by: Dan Carpenter
Reviewed-by: Micha
On Fri, 2025-08-01 at 16:39 +0200, Thomas Hellström wrote:
> On Fri, 2025-08-01 at 19:19 +0900, Simon Richter wrote:
> > This driver, for the time being, assumes that the kernel page size
> > is
> > 4kB,
> > so it fails on loong64 and aarch64 with 16kB pages, and ppc64el
> > with
> > 64kB
> > pages
Does mean that the TODO has been done, or that someone completely forgot and
now your patch is
remove all reminders?
If it's the format, maybe add a fixes: tag for the commit that resolved the
TODO?
On Fri, 2025-08-01 at 09:45 +0200, Philipp Stanner wrote:
> struct nouveau_channel contains the
On 7/31/2025 6:35 PM, Lizhi Hou wrote:
The suspend and resume callbacks for pm and runtime pm should be same.
During suspending, it needs to stop all hardware contexts first. And
the hardware contexts will be restarted after the device is resumed.
Signed-off-by: Lizhi Hou
---
drivers/accel/a
The current blending algorithm requires that vkms_state->active_planes be
ordered by z-order. This has not been an issue so far because the planes
are registered in the correct order in DRM (primary-overlay-cursor).
This new algorithm now uses the configured z-order to populate
active_planes.
Sign
Currently no zpos are defined for vkms planes. This is not yet an
issue, but with the future introduction of configfs, we need to have a way
to properly order plane composition.
In order to make it predictable, add zpos=0 for primary, zpos=1 for
overlays and zpos=2 for cursor. This will be configu
--
drivers/gpu/drm/vkms/vkms_drv.c | 1 +
drivers/gpu/drm/vkms/vkms_plane.c | 12
3 files changed, 33 insertions(+), 6 deletions(-)
---
base-commit: 82928cc1c2b2be16ea6ee9e23799ca182e1cd37c
change-id: 20250801-vkms-fix-zpos-1dc6a3f51a50
Best regards,
--
Louis Chauvet
On Fri, 2025-08-01 at 19:19 +0900, Simon Richter wrote:
> This driver, for the time being, assumes that the kernel page size is
> 4kB,
> so it fails on loong64 and aarch64 with 16kB pages, and ppc64el with
> 64kB
> pages.
>
> Signed-off-by: Simon Richter
> Cc: sta...@vger.kernel.org
Reviewed-by:
>>-Original Message-
>>From: Imre Deak
>>Sent: Wednesday, July 30, 2025 11:02 PM
>>To: Huhulea, Nicusor Liviu (FT FDS CES LX PBU 1)
>>
>>Cc: sta...@vger.kernel.org; dri-devel@lists.freedesktop.org; intel-
>>g...@lists.freedesktop.org; cip-...@lists.cip-project.org;
>>jouni.hogan...@inte
> Subject: Re: [PATCH 03/28] drm/writeback: Define function to get
> drm_connector from writeback
>
> > > > >
> > > > > > Now that drm_connector may not always be embedded within
> > > > > > drm_writeback_connector, let's define a function which either
> > > > > > uses the writeback helper hook th
On 01/08/2025 17:22, Kandpal, Suraj wrote:
Subject: Re: [PATCH 7/8] drm: writeback: drop excess connector initialization
functions
This should be drm/writeback
No:
$ git log --oneline --no-merges next/master
drivers/gpu/drm/drm_writeback.c
fb721b2c35b1 drm: writeback: Fix drm_writeback_con
> Subject: Re: [PATCH 8/8] drm: writeback: rename
> drm_writeback_connector_init_with_encoder()
Same here drm/writeback
Regards,
Suraj Kandpal
>
>
>
> Le 01/08/2025 à 15:51, Dmitry Baryshkov a écrit :
> > Rename drm_writeback_connector_init_with_encoder() to
> > drm_writeback_connector_init()
> Subject: Re: [PATCH 7/8] drm: writeback: drop excess connector initialization
> functions
This should be drm/writeback
Regards,
Suraj Kandpal
>
>
>
> Le 01/08/2025 à 15:51, Dmitry Baryshkov a écrit :
> > Now as all drivers have been converted to
> > drmm_writeback_connector_init(), drop dr
On Fri, Aug 01, 2025 at 01:17:50PM +0300, Marius Vlad wrote:
> From: Derek Foreman
>
> Add a way to know the actual bpc of a running link.
>
> Drivers might change the current bpc link value due to changes in mode
> line or refresh rates. For example when enabling VRR the underlying
> hardware m
Le 01/08/2025 à 15:51, Dmitry Baryshkov a écrit :
Use drmm_plain_encoder_alloc() to allocate simple encoder and
drmm_writeback_connector_init() in order to initialize writeback
connector instance.
Signed-off-by: Dmitry Baryshkov
---
.../drm/arm/display/komeda/komeda_wb_connector.c | 30 +
Le 01/08/2025 à 15:51, Dmitry Baryshkov a écrit :
Use drmm_plain_encoder_alloc() to allocate simple encoder and
drmm_writeback_connector_init() in order to initialize writeback
connector instance.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Louis Chauvet
---
drivers/gpu/drm/msm/disp/
Le 01/08/2025 à 15:51, Dmitry Baryshkov a écrit :
Now as all drivers have been converted to
drmm_writeback_connector_init(), drop drm_writeback_connector_init() and
drm_writeback_connector::encoder field, they are unused now.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Louis Chauvet
--
Le 01/08/2025 à 15:51, Dmitry Baryshkov a écrit :
Use drmm_plain_encoder_alloc() to allocate simple encoder and
drmm_writeback_connector_init() in order to initialize writeback
connector instance.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/renesas/rcar-du/rcar_du_writeback.c| 23 +
Le 01/08/2025 à 15:51, Dmitry Baryshkov a écrit :
Use drmm_plain_encoder_alloc() to allocate simple encoder and
drmm_writeback_connector_init() in order to initialize writeback
connector instance.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Louis Chauvet
---
drivers/gpu/drm/vc4/vc4_t
Le 01/08/2025 à 15:51, Dmitry Baryshkov a écrit :
Use drmm_plain_encoder_alloc() to allocate simple encoder and
drmm_writeback_connector_init() in order to initialize writeback
connector instance.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/arm/malidp_mw.c | 25 ++--
Le 01/08/2025 à 15:51, Dmitry Baryshkov a écrit :
Use drmm_plain_encoder_alloc() to allocate simple encoder and
drmm_writeback_connector_init() in order to initialize writeback
connector instance.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Louis Chauvet
---
drivers/gpu/drm/amd/displ
Le 01/08/2025 à 15:51, Dmitry Baryshkov a écrit :
Rename drm_writeback_connector_init_with_encoder() to
drm_writeback_connector_init() and adapt its interface to follow
drmm_writeback_connector_init().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_writeback.c | 14 +++---
s@msm/dpu@renesas/r-car@ in the Subject.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "
On Fri, Aug 01, 2025 at 04:51:13PM +0300, Dmitry Baryshkov wrote:
> Use drmm_plain_encoder_alloc() to allocate simple encoder and
> drmm_writeback_connector_init() in order to initialize writeback
> connector instance.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> .../gpu/drm/renesas/rcar-du/rcar_
On Fri, 01 Aug 2025, Dmitry Baryshkov wrote:
> Yes. Basically, that's why I suggest refacoring drm_writeback_connector
> to mvoe drm_connector_writeback into drm_connector itself (like it's done
> for drm_connector_hdmi).
Ah, sorry, I think I missed that portion in my post-vacation email
catch-up
Rename drm_writeback_connector_init_with_encoder() to
drm_writeback_connector_init() and adapt its interface to follow
drmm_writeback_connector_init().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_writeback.c | 14 +++---
include/drm/drm_writeback.h | 10 +-
2 file
Now as all drivers have been converted to
drmm_writeback_connector_init(), drop drm_writeback_connector_init() and
drm_writeback_connector::encoder field, they are unused now.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_writeback.c | 55 -
incl
Use drmm_plain_encoder_alloc() to allocate simple encoder and
drmm_writeback_connector_init() in order to initialize writeback
connector instance.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/vc4/vc4_txp.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/driver
Use drmm_plain_encoder_alloc() to allocate simple encoder and
drmm_writeback_connector_init() in order to initialize writeback
connector instance.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/renesas/rcar-du/rcar_du_writeback.c| 23 +++---
1 file changed, 16 insertions(+),
Use drmm_plain_encoder_alloc() to allocate simple encoder and
drmm_writeback_connector_init() in order to initialize writeback
connector instance.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
d
Use drmm_plain_encoder_alloc() to allocate simple encoder and
drmm_writeback_connector_init() in order to initialize writeback
connector instance.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/arm/malidp_mw.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
Use drmm_plain_encoder_alloc() to allocate simple encoder and
drmm_writeback_connector_init() in order to initialize writeback
connector instance.
Signed-off-by: Dmitry Baryshkov
---
.../drm/arm/display/komeda/komeda_wb_connector.c | 30 --
1 file changed, 17 insertions(+),
Use drmm_plain_encoder_alloc() to allocate simple encoder and
drmm_writeback_connector_init() in order to initialize writeback
connector instance.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c| 2 +-
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_wb.
+--
9 files changed, 77 insertions(+), 131 deletions(-)
---
base-commit: 94f208ff622b09309358abaf26d7acca0c318fae
change-id: 20250801-wb-drop-encoder-97a0c75bd5d7
Best regards,
--
With best wishes
Dmitry
The xe_migrate_alloc() function returns NULL on error. It doesn't return
error pointers. Update the checking to match.
Fixes: a843b9894705 ("drm/xe/vf: Fix VM crash during VF driver release")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/xe/xe_sriov_vf_ccs.c | 4 ++--
1 file changed, 2 inse
1 - 100 of 145 matches
Mail list logo
