dentry *root,
+ struct drm_minor *minor)
{
return 0;
}
---
base-commit: fc71f615fd08a530d24c7af0a1efa72ec6ea8e34
change-id: 20230913-fix-drm_debugfs_remove_files-stub-bd864127c162
Best regards,
Since we have enabled sharing of SSPP blocks between two planes, it is
now possible to use twice as much planes as there are hardware SSPP
blocks. Create additional overlay planes.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 12
1 file changed, 12
As promised in the basic wide planes support ([1]) here comes a series
supporting 2*max_linewidth for all the planes.
Note: Unlike v1 and v2 this series finally includes support for
additional planes - having more planes than the number of SSPP blocks.
Note: this iteration features handling of
Make dpu_rm_print_state() also output the SSPP allocation state.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index
It is possible to slightly bend the limitations of the HW blender. If
two rectangles are contiguous (like two rectangles of a single plane)
they can be blended using a single LM blending stage, allowing one to
blend more planes via a single LM.
Signed-off-by: Dmitry Baryshkov
---
Since SmartDMA planes provide two rectangles, it is possible to use them
to drive two different DRM planes, first plane getting the rect_0,
another one using rect_1 of the same SSPP. The sharing algorithm is
pretty simple, it requires that each of the planes can be driven by the
single rectangle
Move a call to dpu_plane_check_inline_rotation() to the
dpu_plane_atomic_check_pipe() function, so that the rot90 constraints
are checked for both pipes. Also move rotation field from struct
dpu_plane_state to struct dpu_sw_pipe_cfg.
Signed-off-by: Dmitry Baryshkov
---
Only several SSPP blocks support such features as YUV output or scaling,
thus different DRM planes have different features. Properly utilizing
all planes requires the attention of the compositor, who should
prefer simpler planes to YUV-supporting ones. Otherwise it is very easy
to end up in a
Split dpu_plane_atomic_check() function into two pieces:
dpu_plane_atomic_check_nopipe() performing generic checks on the pstate,
without touching the associated pipe,
and
dpu_plane_atomic_check_pipes(), which takes into account used pipes.
Signed-off-by: Dmitry Baryshkov
---
In preparation for virtualized planes support, move pstate->pipe
initialization from dpu_plane_reset() to dpu_plane_atomic_check(). In
case of virtual planes the plane's pipe will not be known up to the
point of atomic_check() callback.
Signed-off-by: Dmitry Baryshkov
---
Virtual wide planes give high amount of flexibility, but it is not
always enough:
In parallel multirect case only the half of the usual width is supported
for tiled formats. Thus the whole width of two tiled multirect
rectangles can not be greater than max_linewidth, which is not enough
for some
Take into account the plane rotation and flipping when calculating src
positions for the wide plane parts.
This is not an issue yet, because rotation is only supported for the
UBWC planes and wide UBWC planes are rejected anyway because in parallel
multirect case only the half of the usual width
Provide atomic_print_state callback to the DPU's private object. This
way the debugfs/dri/0/state will also include RM's internal state.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 4 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 2 ++
The helper drm_atomic_helper_check_plane_state() runs several checks on
plane src and dst rectangles, including the check whether required
scaling fits into the required margins. The msm driver would benefit
from having a function that does all these checks except the scaling
one. Split them into
On 2023-09-14 00:18, Luben Tuikov wrote:
> On 2023-09-11 22:16, Matthew Brost wrote:
>> Rather than a global modparam for scheduling policy, move the scheduling
>> policy to scheduler / entity so user can control each scheduler / entity
>> policy.
>>
>> v2:
>> -
On 2023-09-11 22:16, Matthew Brost wrote:
> Rather than a global modparam for scheduling policy, move the scheduling
> policy to scheduler / entity so user can control each scheduler / entity
> policy.
>
> v2:
> - s/DRM_SCHED_POLICY_MAX/DRM_SCHED_POLICY_COUNT (Luben)
> - Only include policy
On 9/13/23 10:48, Boris Brezillon wrote:
> On Wed, 13 Sep 2023 03:56:14 +0300
> Dmitry Osipenko wrote:
>
>> On 9/5/23 11:03, Boris Brezillon wrote:
* But
+ * acquiring the obj lock in
drm_gem_shmem_release_pages_locked() can
+ * cause a
On 2023-09-12 11:02, Matthew Brost wrote:
> On Tue, Sep 12, 2023 at 09:29:53AM +0200, Boris Brezillon wrote:
>> On Mon, 11 Sep 2023 19:16:04 -0700
>> Matthew Brost wrote:
>>
>>> @@ -1071,6 +1063,7 @@ static int drm_sched_main(void *param)
>>> *
>>> * @sched: scheduler instance
>>> * @ops:
On 2023-09-11 22:16, Matthew Brost wrote:
> In XE, the new Intel GPU driver, a choice has made to have a 1 to 1
has --> was
> mapping between a drm_gpu_scheduler and drm_sched_entity. At first this
> seems a bit odd but let us explain the reasoning below.
It's totally fine! :-)
>
> 1. In XE
[Public]
> -Original Message-
> From: Imre Deak
> Sent: Tuesday, September 12, 2023 7:19 PM
> To: Lin, Wayne
> Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
> ly...@redhat.com; jani.nik...@intel.com; ville.syrj...@linux.intel.com;
> Wentland, Harry ; Zuo, Jerry
>
On 2023-09-11 22:16, Matthew Brost wrote:
> If the TDR is set to a value, it can fire before a job is submitted in
> drm_sched_main. The job should be always be submitted before the TDR
> fires, fix this ordering.
>
> v2:
> - Add to pending list before run_job, start TDR after (Luben, Boris)
>
On 2023-09-11 22:16, Matthew Brost wrote:
> Add helper to set TDR timeout and restart the TDR with new timeout
> value. This will be used in XE, new Intel GPU driver, to trigger the TDR
> to cleanup drm_sched_entity that encounter errors.
Do you just want to trigger the cleanup or do you really
On 2023-09-11 22:16, Matthew Brost wrote:
> Provide documentation to guide in ways to teardown an entity.
>
> Signed-off-by: Matthew Brost
> ---
> Documentation/gpu/drm-mm.rst | 6 ++
> drivers/gpu/drm/scheduler/sched_entity.c | 19 +++
> 2 files changed, 25
On 2023-09-11 22:16, Matthew Brost wrote:
> As a prerequisite to merging the new Intel Xe DRM driver [1] [2], we
> have been asked to merge our common DRM scheduler patches first.
>
> This a continuation of a RFC [3] with all comments addressed, ready for
> a full review, and hopefully in state
_minor *minor)
+ int count, struct dentry *root,
+ struct drm_minor *minor)
{
return 0;
}
---
base-commit: fc71f615fd08a530d24c7af0a1efa72ec6ea8e34
change-id: 20230913-fix-drm_debugfs_remove_files-stub-bd864127c162
Best regards,
--
Nathan Chancellor
On 9/13/23 10:43, Melissa Wen wrote:
Hi,
This is an update of previous RFC [0] improving the data collection of
Gamma Correction and Blend Gamma color blocks.
As I mentioned in the last version, I'm updating the color state part of
DTN log to match DCN3.0 HW better. Currently, the DTN log
Debugging PXP issues can't even begin without understanding precedding
sequence of events. Add drm_dbg into the most important PXP events.
v2 : - remove __func__ since drm_dbg covers that (Jani).
- add timeout of the restart from front-end (Alan).
Signed-off-by: Alan Previn
---
On 9/13/23 10:43, Melissa Wen wrote:
DCN3 DPP color state was uncollected and some state elements from DCN1
doesn't fit DCN3. Create new elements according to DCN3 color caps and
fill them up for DTN log output.
rfc-v2:
- fix reading of gamcor and blnd gamma states
Signed-off-by: Melissa
On 9/13/23 10:43, Melissa Wen wrote:
Prepare to hook color state logging according to DCN version.
Signed-off-by: Melissa Wen
---
.../amd/display/dc/dcn10/dcn10_hw_sequencer.c | 27 +--
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git
On Mon, Sep 04, 2023 at 06:58:20AM +, Lin, Wayne wrote:
> [Public]
>
> Thank you Lyude and Alex!
This patch had i915 changes, please also Cc the
intel-...@lists.freedesktop.org list for such patchsets, so that
we get CI test results for it.
Also, I think patches with i915 changes need an
If a sink is removed in the middle of payload addition the corresponding
AUX transfer will fail as expected, so tune the error message down to a
debug messge.
Cc: Wayne Lin
Cc: Lyude Paul
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak
---
Return an error during payload addition if the payload port isn't
found. This shouldn't change the behavior since only the i915 driver
checks the return value, printing an error message in case of a failure.
While at it simplify the control flow.
Cc: Wayne Lin
Cc: Lyude Paul
Cc:
Fix the NULL dereference leading to the following stack trace:
[ 129.687181] i915 :00:02.0: [drm:drm_dp_add_payload_part1
[drm_display_helper]] VCPI 1 for port 5be4423e not in topology, not
creating a payload to remote
[ 129.687257] BUG: kernel NULL pointer dereference, address:
On Mon, 2023-09-11 at 12:26 +0300, Jani Nikula wrote:
> On Wed, 06 Sep 2023, Alan Previn wrote:
> > Debugging PXP issues can't even begin without understanding precedding
> > sequence of events. Add drm_dbg into the most important PXP events.
> >
> > Signed-off-by: Alan Previn
alan:snip
>
> >
On 9/11/2023 2:01 AM, John Watts wrote:
Many of these registers have a known name in the public datasheet.
Document them as comments for reference.
Signed-off-by: John Watts
---
.../gpu/drm/panel/panel-newvision-nv3052c.c | 261 +-
1 file changed, 132 insertions(+), 129
On 9/11/2023 2:02 AM, John Watts wrote:
Panel initialization registers are per-display and not tied to the
controller itself. Different panels will specify their own registers.
Attach the sequences to the panel info struct so future panels
can specify their own sequences.
Signed-off-by: John
y_state *mst_state;
> >>>>> struct drm_dp_mst_topology_mgr *mst_mgr;
> >>>>> - struct drm_dp_mst_atomic_payload *new_payload, *old_payload;
> >>>>> + struct drm_dp_mst_atomic_payload *new_payload, old_payload;
> >>>>> enum mst_progress_status set_flag = MST_ALLOCATE_NEW_PAYLOAD;
> >>>>> enum mst_progress_status clr_flag = MST_CLEAR_ALLOCATED_PAYLOAD;
> >>>>> int ret = 0;
> >>>>> @@ -365,8 +365,8 @@ bool dm_helpers_dp_mst_send_payload_allocation(
> >>>>> ret = drm_dp_add_payload_part2(mst_mgr,
> >>>>> mst_state->base.state, new_payload);
> >>>>> } else {
> >>>>> dm_helpers_construct_old_payload(stream->link,
> >>>>> mst_state->pbn_div,
> >>>>> - new_payload,
> >>>>> old_payload);
> >>>>> - drm_dp_remove_payload_part2(mst_mgr, mst_state,
> >>>>> old_payload, new_payload);
> >>>>> + new_payload,
> >>>>> _payload);
> >>>>> + drm_dp_remove_payload_part2(mst_mgr, mst_state,
> >>>>> _payload, new_payload);
> >>>>> }
> >>>>>
> >>>>> if (ret) {
> >>>>>
> >>>>> ---
> >>>>> base-commit: 8569c31545385195bdb0c021124e68336e91c693
> >>>>> change-id:
> >>>>> 20230913-fix-wuninitialized-dm_helpers_dp_mst_send_payload_allocation-c37b33aaad18
> >>>>>
> >>>>> Best regards,
> >>>> --
> >>>> Hamza
> >>>>
> >> --
> >> Hamza
> >>
> --
> Hamza
>
On Wed, Sep 13 2023 at 09:47, Linus Torvalds wrote:
> On Wed, 13 Sept 2023 at 07:21, Tetsuo Handa
> wrote:
>>
>> Hello. A deadlock was reported in drivers/gpu/drm/vkms/ .
>> It looks like this locking pattern remains as of 6.6-rc1. Please fix.
>>
>> void drm_crtc_vblank_off(struct drm_crtc *crtc)
w_payload, _payload);
+ drm_dp_remove_payload_part2(mst_mgr, mst_state, _payload,
new_payload);
}
if (ret) {
---
base-commit: 8569c31545385195bdb0c021124e68336e91c693
change-id:
20230913-fix-wuninitialized-dm_helpers_dp_mst_send_payload_allocation-c37b33aaad18
Best
gt;>>enum mst_progress_status set_flag = MST_ALLOCATE_NEW_PAYLOAD;
> >>>enum mst_progress_status clr_flag = MST_CLEAR_ALLOCATED_PAYLOAD;
> >>>int ret = 0;
> >>> @@ -365,8 +365,8 @@ bool dm_helpers_dp_mst_send_payload_a
{
---
base-commit: 8569c31545385195bdb0c021124e68336e91c693
change-id:
20230913-fix-wuninitialized-dm_helpers_dp_mst_send_payload_allocation-c37b33aaad18
Best regards,
--
Hamza
--
Hamza
eam->link,
> > mst_state->pbn_div,
> > - new_payload, old_payload);
> > - drm_dp_remove_payload_part2(mst_mgr, mst_state, old_payload,
> > new_payload);
> > + new_payload, _payload);
> > + drm_dp_remove_payload_part2(mst_mgr, mst_state, _payload,
> > new_payload);
> > }
> >
> > if (ret) {
> >
> > ---
> > base-commit: 8569c31545385195bdb0c021124e68336e91c693
> > change-id:
> > 20230913-fix-wuninitialized-dm_helpers_dp_mst_send_payload_allocation-c37b33aaad18
> >
> > Best regards,
> --
> Hamza
>
Hi Dave, Daniel,
Fixes for 6.6.
The following changes since commit afaf2b38025ab327c85e218f36d1819e777d4d45:
Merge tag 'drm-misc-next-fixes-2023-09-11' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2023-09-11 16:23:42
+0200)
are available in the Git repository at:
This is a note to let you know that I've just added the patch titled
drm/ast: Fix DRAM init on AST2200
to the 6.5-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
drm/ast: Fix DRAM init on AST2200
to the 6.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
drm/ast: Fix DRAM init on AST2200
to the 5.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
On 13.09.2023 21:19, Danila Tikhonov wrote:
> SM7150 has 5 power levels which correspond to 5 speed-bin values: 0,
> 128, 146, 167, 172. Speed-bin value is calulated as FMAX/4.8MHz round up
> to zero decimal places.
>
> The vendor's FW GMU is called a618_gmu.bin. And also a618 on SM7150 uses
>
This is a note to let you know that I've just added the patch titled
drm/ast: Fix DRAM init on AST2200
to the 5.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
drm/ast: Fix DRAM init on AST2200
to the 5.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
drm/ast: Fix DRAM init on AST2200
to the 4.19-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
drm/ast: Fix DRAM init on AST2200
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
Hi,
On Fri, Sep 1, 2023 at 4:40 PM Douglas Anderson wrote:
>
>
> NOTE: in order to avoid email sending limits on the cover letter, I've
> split this patch series in two. Patches that target drm-misc and ones
> that don't. The cover letter of the two is identical other than this note.
>
> This
Hi,
On Thu, Sep 7, 2023 at 7:15 AM Maxime Ripard wrote:
>
> > a) Block landing the change to "panel-tdo-tl070wsh30.c" until after
> > all drivers properly call drm_atomic_helper_shutdown().
>
> I don't think we care about all drivers here. Only the driver it's
> enabled with would be a blocker.
Hi,
On Fri, Sep 1, 2023 at 4:42 PM Douglas Anderson wrote:
>
> Based on grepping through the source code this driver appears to be
> missing a call to drm_atomic_helper_shutdown() at system shutdown time
> and at driver unbind time. Among other things, this means that if a
> panel is in use that
Hi,
On Fri, Sep 1, 2023 at 4:42 PM Douglas Anderson wrote:
>
> Based on grepping through the source code this driver appears to be
> missing a call to drm_atomic_helper_shutdown() at system shutdown
> time. Among other things, this means that if a panel is in use that it
> won't be cleanly
Hi,
On Fri, Aug 4, 2023 at 2:07 PM Douglas Anderson wrote:
>
> As talked about in commit d2aacaf07395 ("drm/panel: Check for already
> prepared/enabled in drm_panel"), we want to remove needless code from
> panel drivers that was storing and double-checking the
> prepared/enabled state. Even if
Hi,
On Fri, Aug 4, 2023 at 2:07 PM Douglas Anderson wrote:
>
> As talked about in commit d2aacaf07395 ("drm/panel: Check for already
> prepared/enabled in drm_panel"), we want to remove needless code from
> panel drivers that was storing and double-checking the
> prepared/enabled state. Even if
Hi,
On Fri, Aug 4, 2023 at 2:07 PM Douglas Anderson wrote:
>
> As talked about in commit d2aacaf07395 ("drm/panel: Check for already
> prepared/enabled in drm_panel"), we want to remove needless code from
> panel drivers that was storing and double-checking the
> prepared/enabled state. Even if
Hi,
On Tue, Sep 5, 2023 at 2:14 PM Doug Anderson wrote:
>
> Hi,
>
> On Mon, Sep 4, 2023 at 12:55 AM Maxime Ripard wrote:
> >
> > On Fri, 1 Sep 2023 16:39:52 -0700, Douglas Anderson wrote:
> > > As with other places in the Linux kernel--kfree(NULL) being the most
> > > famous example--it's
Hi,
On Wed, Sep 6, 2023 at 7:28 AM Douglas Anderson wrote:
>
> As per the discussion on the lists [1], changes to this driver
> generally flow through drm-misc. If they need to be coordinated with
> v4l2 they sometimes go through Philipp Zabel's tree instead. List both
> trees in MAINTAINERS.
Hi Doug,
Le mercredi 13 septembre 2023 à 09:25 -0700, Doug Anderson a écrit :
> Hi,
>
> On Tue, Sep 5, 2023 at 1:16 PM Doug Anderson
> wrote:
> >
> > Paul,
> >
> > On Mon, Sep 4, 2023 at 2:15 AM Paul Cercueil
> > wrote:
> > >
> > > Hi Douglas,
> > >
> > > Le vendredi 01 septembre 2023 à
On Wed, 13 Sep 2023 09:46:45 -0700
Rob Clark wrote:
> On Wed, Sep 13, 2023 at 12:36 AM Boris Brezillon
> wrote:
> >
> > On Tue, 12 Sep 2023 19:14:35 -0700
> > Rob Clark wrote:
> >
> > > On Tue, Sep 12, 2023 at 6:46 PM Rob Clark wrote:
> > > >
> > > > On Tue, Sep 12, 2023 at 2:32 AM Boris
On Wed, 13 Sept 2023 at 18:48, Sebastian Andrzej Siewior
wrote:
>
> On 2023-07-05 10:30:25 [+0100], Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin
> >
> > Commit ade8a0f59844 ("drm/i915: Make all GPU resets atomic") added a
> > preempt disable section over the hardware reset callback to prepare
On 9/13/23 10:14, Jocelyn Falempe wrote:
> On 12/09/2023 17:57, Michel Dänzer wrote:
>> On 9/11/23 10:38, Pekka Paalanen wrote:
>>> On Fri, 8 Sep 2023 17:10:46 +0200
>>> Thomas Zimmermann wrote:
Am 08.09.23 um 16:41 schrieb Pekka Paalanen:
> On Fri, 8 Sep 2023 15:56:51 +0200
> Thomas
On Wed, 13 Sep 2023 15:11:08 +0300
Tomi Valkeinen wrote:
> On 13/09/2023 09:59, Andreas Kemnade wrote:
> > Some 3.0 source has it set behind a if (omap4).
> > Maybe it is helpful maybe not, at least in the omap4460
> > trm these bits are marked as reserved.
> > But maybe some dsi video mode
yload,
new_payload);
+new_payload, _payload);
+ drm_dp_remove_payload_part2(mst_mgr, mst_state, _payload,
new_payload);
}
if (ret) {
---
base-commit: 8569c31545385195bdb0c021124e68336e91c693
change-id:
20230913-fix-wuninitialized-dm_helpers_dp_mst_send_payload_allocation
On Wed, 13 Sept 2023 at 07:21, Tetsuo Handa
wrote:
>
> Hello. A deadlock was reported in drivers/gpu/drm/vkms/ .
> It looks like this locking pattern remains as of 6.6-rc1. Please fix.
>
> void drm_crtc_vblank_off(struct drm_crtc *crtc) {
> spin_lock_irq(>event_lock);
>
On Wed, Sep 13, 2023 at 12:36 AM Boris Brezillon
wrote:
>
> On Tue, 12 Sep 2023 19:14:35 -0700
> Rob Clark wrote:
>
> > On Tue, Sep 12, 2023 at 6:46 PM Rob Clark wrote:
> > >
> > > On Tue, Sep 12, 2023 at 2:32 AM Boris Brezillon
> > > wrote:
> > > >
> > > > On Tue, 12 Sep 2023 09:37:00 +0100
>
Logging DCN3 MPC state was following DCN1 implementation that doesn't
consider new DCN3 MPC color blocks. Create new elements according to
DCN3 MPC color caps and a new DCN3-specific function for reading MPC
data.
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/dc/dcn30/dcn30_mpc.c | 55
Add color caps information for DPP and MPC block to show HW color caps.
Signed-off-by: Melissa Wen
---
.../amd/display/dc/dcn10/dcn10_hw_sequencer.c | 23 +++
.../drm/amd/display/dc/dcn30/dcn30_hwseq.c| 23 +++
2 files changed, 46 insertions(+)
diff --git
Color caps changed between HW versions which caused DCN10 color state
sections on DTN log no longer fit DCN3.0 versions. Create a
DCN3.0-specific color state logging and hook it to drivers of DCN3.0
family.
rfc-v2:
- detail RAM mode for gamcor and blnd gamma blocks
Signed-off-by: Melissa Wen
DCN3 DPP color state was uncollected and some state elements from DCN1
doesn't fit DCN3. Create new elements according to DCN3 color caps and
fill them up for DTN log output.
rfc-v2:
- fix reading of gamcor and blnd gamma states
Signed-off-by: Melissa Wen
---
Prepare to hook color state logging according to DCN version.
Signed-off-by: Melissa Wen
---
.../amd/display/dc/dcn10/dcn10_hw_sequencer.c | 27 +--
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
Hi,
This is an update of previous RFC [0] improving the data collection of
Gamma Correction and Blend Gamma color blocks.
As I mentioned in the last version, I'm updating the color state part of
DTN log to match DCN3.0 HW better. Currently, the DTN log considers the
DCN10 color pipeline, which
Hi,
On Tue, Sep 5, 2023 at 1:16 PM Doug Anderson wrote:
>
> Paul,
>
> On Mon, Sep 4, 2023 at 2:15 AM Paul Cercueil wrote:
> >
> > Hi Douglas,
> >
> > Le vendredi 01 septembre 2023 à 16:41 -0700, Douglas Anderson a écrit :
> > > Based on grepping through the source code this driver appears to be
Hi,
On Wed, Sep 6, 2023 at 1:39 AM Maxime Ripard wrote:
>
> On Tue, Sep 05, 2023 at 01:16:08PM -0700, Doug Anderson wrote:
> > > > ---
> > > > This commit is only compile-time tested.
> > > >
> > > > NOTE: this patch touches a lot more than other similar patches since
> > > > the bind() function
{
---
base-commit: 8569c31545385195bdb0c021124e68336e91c693
change-id:
20230913-fix-wuninitialized-dm_helpers_dp_mst_send_payload_allocation-c37b33aaad18
Best regards,
--
Hamza
yload_part2(mst_mgr, mst_state, _payload,
new_payload);
}
if (ret) {
---
base-commit: 8569c31545385195bdb0c021124e68336e91c693
change-id:
20230913-fix-wuninitialized-dm_helpers_dp_mst_send_payload_allocation-c37b33aaad18
Best regards,
--
Nathan Chancellor
On 9/13/23 17:33, Christian König wrote:
Am 13.09.23 um 17:15 schrieb Danilo Krummrich:
On 9/13/23 16:26, Christian König wrote:
Am 13.09.23 um 14:16 schrieb Danilo Krummrich:
As mentioned in a different mail thread, the reply is based on the assumption
that we don't support anything else
Hi,
On Tue, Sep 5, 2023 at 7:23 AM Doug Anderson wrote:
>
> Hi,
>
> On Sun, Sep 3, 2023 at 8:53 AM Russell King (Oracle)
> wrote:
> >
> > On Fri, Sep 01, 2023 at 04:41:12PM -0700, Douglas Anderson wrote:
> > > Based on grepping through the source code this driver appears to be
> > > missing a
Am 13.09.23 um 17:15 schrieb Danilo Krummrich:
On 9/13/23 16:26, Christian König wrote:
Am 13.09.23 um 14:16 schrieb Danilo Krummrich:
As mentioned in a different mail thread, the reply is based on the
assumption
that we don't support anything else than GPUVM updates from the IOCTL.
I think
Am 13.09.23 um 17:13 schrieb Thomas Hellström:
Hi Christian
On 9/13/23 16:26, Christian König wrote:
Am 13.09.23 um 14:16 schrieb Danilo Krummrich:
As mentioned in a different mail thread, the reply is based on the
assumption
that we don't support anything else than GPUVM updates from the
Hi Christian
On 9/13/23 16:26, Christian König wrote:
Am 13.09.23 um 14:16 schrieb Danilo Krummrich:
As mentioned in a different mail thread, the reply is based on the
assumption
that we don't support anything else than GPUVM updates from the IOCTL.
I think that this assumption is
On Wed, 13 Sep 2023 16:29:30 +0200
Thomas Hellström wrote:
> On 9/13/23 16:01, Boris Brezillon wrote:
> > On Wed, 13 Sep 2023 15:22:56 +0200
> > Thomas Hellström wrote:
> >
> >> On 9/13/23 13:33, Boris Brezillon wrote:
> >>> On Wed, 13 Sep 2023 12:39:01 +0200
> >>> Thomas Hellström wrote:
On 9/13/23 16:26, Christian König wrote:
Am 13.09.23 um 14:16 schrieb Danilo Krummrich:
As mentioned in a different mail thread, the reply is based on the assumption
that we don't support anything else than GPUVM updates from the IOCTL.
I think that this assumption is incorrect.
Well, more
Hello. A deadlock was reported in drivers/gpu/drm/vkms/ .
It looks like this locking pattern remains as of 6.6-rc1. Please fix.
void drm_crtc_vblank_off(struct drm_crtc *crtc) {
spin_lock_irq(>event_lock);
drm_vblank_disable_and_save(dev, pipe) {
__disable_vblank(dev, pipe) {
Am 12.09.23 um 04:16 schrieb Matthew Brost:
Provide documentation to guide in ways to teardown an entity.
Signed-off-by: Matthew Brost
---
Documentation/gpu/drm-mm.rst | 6 ++
drivers/gpu/drm/scheduler/sched_entity.c | 19 +++
2 files changed, 25
Replace all code that initializes or releases fbdev emulation
throughout the driver. Instead initialize the fbdev client by a
single call to i915_fbdev_setup() after i915 has registered its
DRM device. Just like similar code in other drivers, i915 fbdev
emulation now acts as a regular DRM client.
Move code from ad-hoc fbdev callbacks into DRM client functions
and remove the old callbacks. The functions instruct the client
to poll for changed output or restore the display.
The DRM core calls both, the old callbacks and the new client
helpers, from the same places. The new functions perform
Initialize i915's fbdev client by giving an instance of struct
drm_client_funcs to drm_client_init(). Also clean up with
drm_client_release().
Doing this in i915 prevents fbdev helpers from initializing and
releasing the client internally (see drm_fb_helper_init()). No
functional change yet; the
Convert i915's fbdev code to struct drm_client. Replaces the current
ad-hoc integration. The conversion includes a number of cleanups.
As with most other driver's fbdev emulation, fbdev in i915 is now
just another DRM client that runs after the DRM device has been
registered. This allows to
Move functions within intel_fbdev.c to simplify later updates. No
functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/i915/display/intel_fbdev.c | 154 ++---
1 file changed, 77 insertions(+), 77 deletions(-)
diff --git
On 11/09/23 03:46, Matthew Auld wrote:
On 09/09/2023 17:09, Arunpravin Paneer Selvam wrote:
Problem statement: The current method roundup_power_of_two()
to allocate contiguous address triggers -ENOSPC in some cases
even though we have enough free spaces and so to help with
that we introduce a
hi, Arvind Yadav,
we know this commit is quite old, but it shows persistent low rate issue and
parent keeps clean even when we run both this commit and parent up to ~300
times.
the config to build both kernel is a randconfig as in
https://download.01.org/0day-ci/archive/20230913
On Wed, Sep 13, 2023 at 03:19:00PM +0300, José Pekkarinen wrote:
> Similarly to the drm_exec_test module, the drm_modes_test
> shows the following output on dmesg on load:
>
> [ 5556.674834] KTAP version 1
> [ 5556.674841] 1..1
> [ 5556.675317] KTAP version 1
> [ 5556.675321] # Subtest:
On Thu, May 25, 2023 at 11:09:30AM +0300, Luca Coelho wrote:
> On Tue, 2023-05-02 at 17:39 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > ICL doesn't support FEC with a x1 DP link. Make sure
> > we don't try to enable FEC in such cases.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
On Wed, Sep 13, 2023 at 05:01:40PM +0300, José Pekkarinen wrote:
> On 2023-09-13 12:50, Maxime Ripard wrote:
> > Hi,
> >
> > On Wed, Sep 13, 2023 at 11:32:23AM +0300, José Pekkarinen wrote:
> > > Running drm_exec_test by modprobing the module I
> > > observe the following output:
> > >
> > > [
On Thu, May 25, 2023 at 12:51:28PM +0300, Luca Coelho wrote:
> On Wed, 2023-05-03 at 14:36 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Track DP enhanced framing properly in the crtc state instead
> > of relying just on the cached DPCD everywhere, and hook it
> > up into the state
On 9/13/23 16:01, Boris Brezillon wrote:
On Wed, 13 Sep 2023 15:22:56 +0200
Thomas Hellström wrote:
On 9/13/23 13:33, Boris Brezillon wrote:
On Wed, 13 Sep 2023 12:39:01 +0200
Thomas Hellström wrote:
Hi,
On 9/13/23 09:19, Boris Brezillon wrote:
On Wed, 13 Sep 2023 17:05:42 +1000
Am 13.09.23 um 14:16 schrieb Danilo Krummrich:
As mentioned in a different mail thread, the reply is based on the assumption
that we don't support anything else than GPUVM updates from the IOCTL.
I think that this assumption is incorrect.
Vulkan is just once specific use case, but this here
1 - 100 of 162 matches
Mail list logo
