The nvbios_iccsense_parse function allocates memory for sensor data
but fails to free it when the function exits, leading to a memory
leak. Add proper cleanup to free the allocated memory.
Signed-off-by: Zhanxin Qi
---
drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c | 3 +++
1 file changed,
Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks.
Fixes: efcd0107727c ("drm/msm/dpu: add support for SM8550")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/
Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks.
Fixes: 0e91bcbb0016 ("drm/msm/dpu: Add SM8350 to hw catalog")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu
Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks.
Fixes: b94747f7d8c7 ("drm/msm/dpu: add support for SM8650 DPU")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/
On SDM670 the DPU has two DSPP blocks compared to 4 DSPP blocks on
SDM845. Currently SDM670 just reuses LMs and DSPPs from SDM845. Define
platform-specific configuration for those blocks.
Fixes: e140b7e496b7 ("drm/msm/dpu: Add hw revision 4.1 (SDM670)")
Signed-off-by: Dmitry Baryshkov
---
.../gp
Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks.
Fixes: f5abecfe339e ("drm/msm/dpu: enable DSPP and DSC on sc8180x")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/d
Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks.
Fixes: e3b1f369db5a ("drm/msm/dpu: Add X1E80100 support")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/
Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks.
Fixes: 05ae91d960fd ("drm/msm/dpu: enable DSPP support on SM8[12]50")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/
Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks.
Fixes: 05ae91d960fd ("drm/msm/dpu: enable DSPP support on SM8[12]50")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/
/disp/dpu1/catalog/dpu_9_2_x1e80100.h | 2 +
8 files changed, 66 insertions(+), 2 deletions(-)
---
base-commit: 4172e9bbb583a2af5f1a3db437caf72a90714ad9
change-id: 20241216-dpu-fix-catalog-63a3bc0db31e
Best regards,
--
Dmitry Baryshkov
On Fri, Dec 13, 2024 at 04:03:00PM +0200, Tomi Valkeinen wrote:
>
> -required:
> - - port@0
> - - port@1
> -
> unevaluatedProperties: false
>
>renesas,cmms:
> @@ -817,6 +814,54 @@ allOf:
> - reset-names
> - renesas,vsps
>
> + - if:
> + properties
On 2024/12/15 21:10, Dmitry Baryshkov wrote:
On Tue, 10 Dec 2024 14:53:51 +0800, Fange Zhang wrote:
This series aims to enable display on the QCS615 platform
1.Add MDSS & DPU support for QCS615
2.Add DSI support for QCS615
QCS615 platform supports DisplayPort, and this feature will be adde
= LM_0,
},
};
---
base-commit: a3d570eace66b4016f2692a6f1045742ee70c6b1
change-id: 20241216-dpu-fix-sm6150-17f0739f8fe0
Best regards,
--
Dmitry Baryshkov
On 2024-12-15 21:53, Marek Olšák wrote:
> The comment explains the problem with DRM_FORMAT_MOD_LINEAR.
>
> Signed-off-by: Marek Olšák mailto:marek.ol...@amd.com>>
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 78abd819fd62e..8ec4163429014 100644
> --- a/
On Fri, Dec 13, 2024 at 05:01:03PM +0530, Akhil P Oommen wrote:
> A612 GPU requires an additional smmu_vote clock. Update the bindings to
> reflect this.
>
> Signed-off-by: Akhil P Oommen
> ---
> .../devicetree/bindings/display/msm/gpu.yaml | 36
> ++
> 1 file changed,
On Fri, Dec 13, 2024 at 05:01:04PM +0530, Akhil P Oommen wrote:
> RGMU a.k.a Reduced Graphics Management Unit is a small state machine
> with the sole purpose of providing IFPC support. Compared to GMU, it
What is IFPC?
> doesn't manage GPU clock, voltage scaling, bw voting or any other
> functio
On Mon, Dec 16, 2024 at 08:33:23AM +, Xin Ji wrote:
> > -Original Message-
> > From: Dmitry Baryshkov
> > Sent: Friday, December 13, 2024 9:17 PM
> > To: Xin Ji
> > Cc: Andrzej Hajda ; Neil Armstrong
> > ; Robert Foss ; Laurent
> > Pinchart
> > ; Jonas Karlman ;
> > Jernej Skrabec ;
Hello dri maintainers/developers,
This is a 31-day syzbot report for the dri subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/dri
During the period, 2 new issues were detected and 0 were fixed.
In total, 18 issues are still open and 31 have alre
On Mon, 16 Dec 2024 at 08:28, Liu Ying wrote:
>
> On 12/13/2024, Dmitry Baryshkov wrote:
> > On Fri, 13 Dec 2024 at 08:06, Liu Ying wrote:
> >>
> >> On 12/12/2024, Dmitry Baryshkov wrote:
> >>> On Wed, Dec 11, 2024 at 03:43:20PM +0800, Liu Ying wrote:
> On 12/10/2024, Dmitry Baryshkov wrote:
Thanks for the patch, some notes below.
On Mon, Dec 16, 2024 at 09:52:46AM +0800, Zhanxin Qi wrote:
> The nvbios_iccsense_parse function allocates memory for sensor data
> but fails to free it when the function exits, leading to a memory
> leak. Add proper cleanup to free the allocated memory.
>
On 14/12/2024 00:46, Konrad Dybcio wrote:
On 13.12.2024 5:55 PM, Akhil P Oommen wrote:
On 12/13/2024 10:10 PM, neil.armstr...@linaro.org wrote:
On 13/12/2024 17:31, Konrad Dybcio wrote:
On 13.12.2024 5:28 PM, neil.armstr...@linaro.org wrote:
On 13/12/2024 16:37, Konrad Dybcio wrote:
On 13.12
On Mon, Dec 16, 2024 at 09:54:09AM +0100, Andrej Picej wrote:
> Add a optional properties to change LVDS output voltage. This should not
> be static as this depends mainly on the connected display voltage
> requirement. We have three properties:
> - "ti,lvds-termination-ohms", which sets near end t
On Wed, 2024-12-11 at 11:01 -0800, Matthew Brost wrote:
> On Tue, Nov 19, 2024 at 02:56:12PM +0100, Thomas Hellström wrote:
> > On Tue, 2024-10-15 at 20:24 -0700, Matthew Brost wrote:
> > > Add SVM range invalidation vfunc.
> > >
> > > v2:
> > > - Don't run invalidation if VM is closed
> > > - C
On Wed, 2024-12-11 at 11:07 -0800, Matthew Brost wrote:
> On Tue, Nov 19, 2024 at 03:26:32PM +0100, Thomas Hellström wrote:
> > On Tue, 2024-10-15 at 20:25 -0700, Matthew Brost wrote:
> > > Add (re)bind to SVM page fault handler. To facilitate add support
> > > function to VM layer which (re)binds
On Mon, Dec 16, 2024 at 10:11:54AM +0100, Heiko Stübner wrote:
> Am Montag, 16. Dezember 2024, 09:57:41 CET schrieb Dmitry Baryshkov:
> > On Mon, Dec 16, 2024 at 11:12:17AM +0800, Damon Ding wrote:
> > > RK3588 integrates the analogix eDP 1.3 TX controller IP and the HDMI/eDP
> > > TX Combo PHY bas
On Mon, Dec 16, 2024 at 11:01:23AM +0100, Thomas Hellström wrote:
> On Wed, 2024-12-11 at 11:01 -0800, Matthew Brost wrote:
> > On Tue, Nov 19, 2024 at 02:56:12PM +0100, Thomas Hellström wrote:
> > > On Tue, 2024-10-15 at 20:24 -0700, Matthew Brost wrote:
> > > > Add SVM range invalidation vfunc.
>
On Fri, Dec 06, 2024 at 12:15:58PM +0200, Dmitry Baryshkov wrote:
> Add necessary glue code to be able to use new HDMI codec framework from
> the DRM bridge drivers. The drm_bridge implements a limited set of the
> hdmi_codec_ops interface, with the functions accepting both
> drm_connector and drm_
On Fri, 6 Dec 2024 12:15:59 +0200, Dmitry Baryshkov wrote:
> Make the Lontium LT9611 DSI-to-HDMI bridge driver use the DRM HDMI Codec
> framework. This enables programming of Audio InfoFrames using the HDMI
> Connector interface and also enables support for the missing features,
> including the ELD
On Mon, Dec 16, 2024 at 8:59 AM Connor Abbott wrote:
>
> On Mon, Dec 16, 2024 at 11:55 AM Akhil P Oommen
> wrote:
> >
> > On 12/13/2024 10:40 PM, Antonino Maniscalco wrote:
> > > On 12/13/24 5:50 PM, Akhil P Oommen wrote:
> > >> On 12/12/2024 9:44 PM, Antonino Maniscalco wrote:
> > >>> On 12/12/2
On Fri, Dec 06, 2024 at 12:16:00PM +0200, Dmitry Baryshkov wrote:
> The HDMI Connectors need to perform a variety of tasks when the HDMI
> connector state changes. Such tasks include setting or invalidating CEC
> address, notifying HDMI codec driver, updating scrambler data, etc.
>
> Implementing
This series brings small improvements to the DRM documentation, logging and
a warning on an incorrect code path.
Signed-off-by: Luca Ceresoli
---
Changes in v3:
- patch 3: various fixes suggested by Jani Nikula and kernel test robot
- Updated reviewed-by tags
- Link to v2:
https://lore.kernel.or
Add a wrapper to kref_read() just like the ones already in place for
kref_get() and kref_put(). This will be used for sanity checks on object
lifetime.
Signed-off-by: Luca Ceresoli
---
Changed in v3:
* use conventions for 'Returns' doc syntax
* ditch DRM_DEBUG() and as a consequence rework a
Remove unintended extra word.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Luca Ceresoli
---
include/drm/drm_mode_object.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_mode_object.h b/include/drm/drm_mode_object.h
index
08d7a7f0188fea79e2d8ad5ee6cc5044300
This message reports a mismatch between new_crtc_state->enable and
has_connectors, which should be either both true or both false. However it
does not mention which one is true and which is false, which can be useful
for debugging. Add the value of both avriables to the log message.
Reviewed-by: D
Calling drm_connector_cleanup() should only be done via the free_cb =>
.destroy path, which cleans up the struct drm_connector only when the
refcount drops to zero.
A cleanup done with a refcount higher than 0 can result from buggy code,
e.g. by doing cleanup directly in the drivers teardown code.
On 12/13/2024 11:20 PM, Rob Clark wrote:
> On Fri, Dec 13, 2024 at 8:47 AM Akhil P Oommen
> wrote:
>>
>> On 12/12/2024 10:42 PM, Rob Clark wrote:
>>> On Thu, Dec 12, 2024 at 9:08 AM Rob Clark wrote:
On Thu, Dec 12, 2024 at 7:59 AM Akhil P Oommen
wrote:
>
> On 12/5/2024 1
Add the Tianma Micro-electronics TM070JDHG34-00 7.0" LVDS LCD TFT panel.
Signed-off-by: Luca Ceresoli
---
Changes in v2:
- fix inverted lines
---
Documentation/devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bi
Add Tianma TM070JDHG34-00 7.0" 1280x800 LVDS RGB TFT LCD panel.
Panel info and datasheet: https://fortec.us/products/tm070jdhg34-00/
Reviewed-by: Neil Armstrong
Signed-off-by: Luca Ceresoli
---
Changes in v2: none
---
drivers/gpu/drm/panel/panel-simple.c | 42 +
Raag Jadav is introducing a new DRM API for generating "device wedged events",
to notify userspace when the device needs userspace intervention after a GPU
reset[1]. I did a simple patch to add support for it for amdgpu for the
telemetry aspect of the event. Tested in Steam Deck. This patch require
Use DRM's device wedged event to notify userspace that a reset had
happened. For now, only use `none` method meant for telemetry
capture.
In the future we might want to report a recovery method if the reset didn't
succeed.
Acked-by: Shashank Sharma
Signed-off-by: André Almeida
---
v3: fix if co
This small series adds DT bindings and panel-simple implementation for the
Tianma TM070JDHG34-00 7" panel. Due to how the datasheet computes the
blanking time, a quirk is needed in the timing implementation. A comment
documents that in patch 2.
Signed-off-by: Luca Ceresoli
---
Changes in v2:
- Fi
On 16/12/24 - 17:40, Luca Ceresoli wrote:
> Add a wrapper to kref_read() just like the ones already in place for
> kref_get() and kref_put(). This will be used for sanity checks on object
> lifetime.
>
> Signed-off-by: Luca Ceresoli
Acked-by: Louis Chauvet
Thanks,
Louis Chauvet
> ---
>
> Ch
On Mon, Dec 16, 2024 at 06:20:04PM +0100, Maxime Ripard wrote:
> On Fri, Dec 06, 2024 at 12:16:00PM +0200, Dmitry Baryshkov wrote:
> > The HDMI Connectors need to perform a variety of tasks when the HDMI
> > connector state changes. Such tasks include setting or invalidating CEC
> > address, notify
On Mon, Dec 16, 2024 at 8:13 AM Imre Deak wrote:
>
> Hi Harry, Leo, Alex, Wayne,
>
> could you please ack this change as well?
Patches 1-9 are:
Acked-by: Alex Deucher
Feel free to take this one through whichever tree you are planning to
commit these to.
Alex
>
> Thanks,
> Imre
>
> A typo belo
On 16/12/2024 13:07, Arunpravin Paneer Selvam wrote:
- Added a testcase to verify the multiroot force merge fini.
- Added a new field in_use to track the mm freed status.
Signed-off-by: Arunpravin Paneer Selvam
Signed-off-by: Lin.Cao
---
drivers/gpu/drm/drm_buddy.c| 20 ++
On 12/16/2024 3:06 AM, Maxime Ripard wrote:
On Wed, Dec 11, 2024 at 01:18:41PM -0800, Jessica Zhang wrote:
Call encoder mode_set() when connectors are changed. This avoids issues
for cases where the connectors are changed but CRTC mode is not.
Looks great, thanks a lot for doing the tests :
Quoting Dmitry Baryshkov (2024-12-15 14:44:07)
> Use msm_dp_utils_pack_sdp_header() and call msm_dp_write_link() directly
> to program audio packet data. Use 0 as Packet ID, as it was not
> programmed earlier.
>
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by: Stephen Boyd
Tested-by: Stephen
Quoting Dmitry Baryshkov (2024-12-15 14:44:10)
> The dp_audio module doesn't make any use of the passed DP panel
> instance. Drop the argument.
>
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by: Stephen Boyd
Tested-by: Stephen Boyd # sc7180-trogdor
Quoting Dmitry Baryshkov (2024-12-15 14:44:21)
> Now as the msm_dp_catalog module became nearly empty, drop it, accessing
> registers directly from the corresponding submodules.
>
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by: Stephen Boyd
Tested-by: Stephen Boyd # sc7180-trogdor
Quoting Dmitry Baryshkov (2024-12-15 14:44:11)
> It's the dp_panel's duty to clear the MMSS_DP_DSC_DTO register. Once DP
> driver gets DSC support, it will handle that register in other places
> too. Split a call to write 0x0 to that register to a separate function.
>
> Signed-off-by: Dmitry Barysh
Quoting Dmitry Baryshkov (2024-12-15 14:44:20)
> There is little point in rereading DP controller revision over and over
> again. Read it once, after the first software reset and propagate it to
> the dp_panel module.
>
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by: Stephen Boyd
Tested-by:
On Mon, Dec 16, 2024 at 05:21:34PM +0100, Luca Ceresoli wrote:
> Add the Tianma Micro-electronics TM070JDHG34-00 7.0" LVDS LCD TFT panel.
>
> Signed-off-by: Luca Ceresoli
Acked-by: Conor Dooley
signature.asc
Description: PGP signature
On 16/12/2024 13:07, Arunpravin Paneer Selvam wrote:
From: Lin.Cao
If buddy manager have more than one roots and each root have sub-block
need to be free. When drm_buddy_fini called, the first loop of
force_merge will merge and free all of the sub block of first root,
which offset is 0x0 and si
On Fri, Dec 06, 2024 at 05:44:15PM +, Sverdlin, Alexander wrote:
> Hello Conor,
>
> On Fri, 2024-12-06 at 17:14 +, Conor Dooley wrote:
> > > Add Texas Instruments' LP8864/LP8866 bindings into LP8860 converting them
> > > into YAML format simultaneously. While here, drop the index of the "l
For the nouveau bits:
Reviewed-by: Lyude Paul
On Fri, 2024-12-13 at 13:46 +0800, Yafang Shao wrote:
> Since task->comm is guaranteed to be NUL-terminated, we can print it
> directly without the need to copy it into a separate buffer. This
> simplifies the code and avoids unnecessary operations.
On 12/16/24 12:38, Mario Limonciello wrote:
On 12/13/2024 17:29, Lizhi Hou wrote:
For input structures, it is better to check if the pad is zero.
Thus, the pad bytes might be usable in the future.
IIRC you should pick up:
Suggested-by: Jeffrey Hugo
Sure. Will add it.
Signed-off-by: Liz
On 12/16/2024 12:27 AM, Dmitry Baryshkov wrote:
Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks.
Fixes: 05ae91d960fd ("drm/msm/dpu: enable DSPP support on SM8[12]50")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h | 2 ++
1 file chan
On 12/16/2024 12:27 AM, Dmitry Baryshkov wrote:
Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks.
Fixes: f5abecfe339e ("drm/msm/dpu: enable DSPP and DSC on sc8180x")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 2 ++
1 file chang
On 12/16/2024 10:28 PM, Connor Abbott wrote:
> On Mon, Dec 16, 2024 at 11:55 AM Akhil P Oommen
> wrote:
>>
>> On 12/13/2024 10:40 PM, Antonino Maniscalco wrote:
>>> On 12/13/24 5:50 PM, Akhil P Oommen wrote:
On 12/12/2024 9:44 PM, Antonino Maniscalco wrote:
> On 12/12/24 4:58 PM, Akhil P
For the nouveau portions:
Reviewed-by: Lyude Paul
On Sat, 2024-12-14 at 15:37 +0200, Dmitry Baryshkov wrote:
> The mode_valid() callbacks of drm_encoder, drm_crtc and drm_bridge
> take a const struct drm_display_mode argument. Change the mode_valid
> callback of drm_connector to also take a cons
Reviewed-by: Lyude Paul
On Sat, 2024-12-14 at 15:37 +0200, Dmitry Baryshkov wrote:
> The mode_valid() callbacks of drm_encoder, drm_crtc and drm_bridge
> accept const struct drm_display_mode argument. Change the mode_valid
> callback of drm_encoder_slave to also accept const argument.
>
> Review
On 12/12, Maíra Canal wrote:
> `bo->seqno`, `bo->write_seqno`, and `exec->bin_dep_seqno` are leftovers
> from a time when VC4 didn't support DMA Reservation Objects. When they
> were introduced, it made sense to think about tracking the correspondence
> between the BOs and the jobs through the job'
On Mon, Dec 16, 2024 at 12:25 PM Akhil P Oommen
wrote:
>
> On 12/16/2024 10:28 PM, Connor Abbott wrote:
> > On Mon, Dec 16, 2024 at 11:55 AM Akhil P Oommen
> > wrote:
> >>
> >> On 12/13/2024 10:40 PM, Antonino Maniscalco wrote:
> >>> On 12/13/24 5:50 PM, Akhil P Oommen wrote:
> On 12/12/2024
On 12/15/2024 2:44 PM, Dmitry Baryshkov wrote:
There is little point in rereading DP controller revision over and over
again. Read it once, after the first software reset and propagate it to
the dp_panel module.
Good idea, can be posted even separately in front of the catalog rework
as it
On 12/13/2024 17:29, Lizhi Hou wrote:
For input structures, it is better to check if the pad is zero.
Thus, the pad bytes might be usable in the future.
IIRC you should pick up:
Suggested-by: Jeffrey Hugo
Signed-off-by: Lizhi Hou
---
drivers/accel/amdxdna/aie2_ctx.c | 3 +++
driver
On 12/14/2024 2:05 PM, Dmitry Baryshkov wrote:
On Sat, 14 Dec 2024 at 22:53, Abhinav Kumar wrote:
Hi Dmitry
On 12/12/2024 3:09 PM, Dmitry Baryshkov wrote:
On Thu, 12 Dec 2024 at 21:15, Abhinav Kumar wrote:
On 12/12/2024 12:52 AM, Dmitry Baryshkov wrote:
On Thu, 12 Dec 2024 at 04:59,
Reviewed-by: Lyude Paul
On Wed, 2024-12-11 at 15:04 +0200, Abel Vesa wrote:
> LTTPRs operating modes are defined by the DisplayPort standard and the
> generic framework now provides a helper to switch between them, which
> is handling the explicit disabling of non-transparent mode and its
> disab
On 12/12, Maíra Canal wrote:
> The function `vc4_queue_seqno_cb()` is no longer needed, as we are
> using DMA Reservation Objects to track BOs. Using DMA Resv, we can use
> `dma_fence_add_callback()` to perform the async page flip.
>
> Signed-off-by: Maíra Canal
> ---
> drivers/gpu/drm/vc4/vc4_d
On Mon, Dec 16, 2024 at 4:27 AM Michel Dänzer
wrote:
> On 2024-12-15 21:53, Marek Olšák wrote:
> > The comment explains the problem with DRM_FORMAT_MOD_LINEAR.
> >
> > Signed-off-by: Marek Olšák marek.ol...@amd.com>>
> >
> > diff --git a/include/uapi/drm/drm_fourcc.h
> b/include/uapi/drm/drm_fou
Hello,
syzbot found the following issue on:
HEAD commit:2e7aff49b5da Merge branches 'for-next/core' and 'for-next/..
git tree: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
for-kernelci
console output: https://syzkaller.appspot.com/x/log.txt?x=17c49be858
kernel conf
From: Bartosz Golaszewski
On Thu, 12 Dec 2024 18:36:27 +, Dave Stevenson wrote:
> I missed the DT errors from the recent patchset[1] (DT patches
> in linux-next via Florian, DRM bindings patches on dri-misc-next)
> as Rob's bot report got spam filtered, so this is a fixup set.
>
> Largely i
Am Montag, 16. Dezember 2024, 09:57:41 CET schrieb Dmitry Baryshkov:
> On Mon, Dec 16, 2024 at 11:12:17AM +0800, Damon Ding wrote:
> > RK3588 integrates the analogix eDP 1.3 TX controller IP and the HDMI/eDP
> > TX Combo PHY based on a Samsung IP block, and there are also two
> > independent eDP di
On Mon, Dec 16, 2024 at 11:12:24AM +0800, Damon Ding wrote:
> Add the necessary DT changes to enable eDP0 on RK3588S EVB1 board:
> - Add edp-panel node
> - Set pinctrl of pwm12 for backlight
> - Enable edp0/hdptxphy0/vp2
>
> Signed-off-by: Damon Ding
>
> ---
>
> Changes in v2:
> - Remove bright
On Mon, Dec 16, 2024 at 5:46 AM Lucas Stach wrote:
> Am Montag, dem 16.12.2024 um 10:27 +0100 schrieb Michel Dänzer:
> > On 2024-12-15 21:53, Marek Olšák wrote:
> > > The comment explains the problem with DRM_FORMAT_MOD_LINEAR.
> > >
> > > Signed-off-by: Marek Olšák marek.ol...@amd.com>>
> > >
>
On 12/16/2024 12:27 AM, Dmitry Baryshkov wrote:
Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks.
Fixes: 0e91bcbb0016 ("drm/msm/dpu: Add SM8350 to hw catalog")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h | 2 ++
1 file changed, 2 i
On 12/13/2024 17:29, Lizhi Hou wrote:
Switch mailbox message id and hardware context id management over from
the idr api to the xarray api.
Signed-off-by: Lizhi Hou
Reviewed-by: Mario Limonciello
---
drivers/accel/amdxdna/TODO | 1 -
drivers/accel/amdxdna/aie2_ctx.c|
This change actually meant here? It seems like it should be it's own
change.
Agree. Hopefully, the patch 1 - 4 are good to go and I do not need to
resend them. :)
Yeah those are fine at this point. They've gotten good feedback, no
complaints from LKP robot. I think you can just send th
On Mon, Dec 16, 2024 at 9:53 AM Simona Vetter
wrote:
> On Mon, Dec 16, 2024 at 11:46:13AM +0100, Lucas Stach wrote:
> > Am Montag, dem 16.12.2024 um 10:27 +0100 schrieb Michel Dänzer:
> > > On 2024-12-15 21:53, Marek Olšák wrote:
> > > > The comment explains the problem with DRM_FORMAT_MOD_LINEAR
On 12/16/2024 12:27 AM, Dmitry Baryshkov wrote:
Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks.
Fixes: 05ae91d960fd ("drm/msm/dpu: enable DSPP support on SM8[12]50")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h | 2 ++
1 file chan
On Mon, Dec 16, 2024 at 01:11:35PM -0800, Abhinav Kumar wrote:
>
>
> On 12/16/2024 12:27 AM, Dmitry Baryshkov wrote:
> > Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks.
> >
> > Fixes: 05ae91d960fd ("drm/msm/dpu: enable DSPP support on SM8[12]50")
> > Signed-off-by: Dmitry Baryshkov
On Mon, Dec 16, 2024 at 11:46:21AM -0800, Abhinav Kumar wrote:
>
>
> On 12/15/2024 2:44 PM, Dmitry Baryshkov wrote:
> > It's the dp_panel's duty to clear the MMSS_DP_DSC_DTO register. Once DP
> > driver gets DSC support, it will handle that register in other places
> > too. Split a call to write
On Mon, Dec 16, 2024 at 11:32:57AM -0800, Abhinav Kumar wrote:
>
>
> On 12/15/2024 2:44 PM, Dmitry Baryshkov wrote:
> > Use msm_dp_utils_pack_sdp_header() and call msm_dp_write_link() directly
> > to program audio packet data. Use 0 as Packet ID, as it was not
> > programmed earlier.
> >
> > Sig
implementation for lm_pair, its used even to
> decide the LM pair for CWB mux. Upstream has a simpler implementation of
> just doing that in the code of using ODD LMs for ODD CWB muxes and even LMs
> for even CWB muxes. So fix is okay but not needed.
So which topology is supposed to work with LM_0 / LM_2 pair?
I'd still prefer to land the fix for the sake of catalog having the
correct data.
>
> >
> > ---
> > base-commit: a3d570eace66b4016f2692a6f1045742ee70c6b1
> > change-id: 20241216-dpu-fix-sm6150-17f0739f8fe0
> >
> > Best regards,
--
With best wishes
Dmitry
* Dr. David Alan Gilbert (li...@treblig.org) wrote:
> * Thomas Zimmermann (tzimmerm...@suse.de) wrote:
> > Hi
> >
> >
> > Am 16.12.24 um 14:46 schrieb Dr. David Alan Gilbert:
> > [...]
> > >
> > > > The attached patch fixes the problem for me. Could you please test and
> > > > report back the re
On 12/16/2024 12:27 AM, Dmitry Baryshkov wrote:
Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks.
Fixes: efcd0107727c ("drm/msm/dpu: add support for SM8550")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h | 2 ++
1 file changed, 2 ins
On 12/16/2024 12:27 AM, Dmitry Baryshkov wrote:
Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks.
Fixes: b94747f7d8c7 ("drm/msm/dpu: add support for SM8650 DPU")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h | 2 ++
1 file changed,
On 12/16/2024 2:21 PM, Dmitry Baryshkov wrote:
On Mon, Dec 16, 2024 at 01:11:35PM -0800, Abhinav Kumar wrote:
On 12/16/2024 12:27 AM, Dmitry Baryshkov wrote:
Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks.
Fixes: 05ae91d960fd ("drm/msm/dpu: enable DSPP support on SM8[12]50")
On 12/16/2024 12:27 AM, Dmitry Baryshkov wrote:
Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks.
Fixes: e3b1f369db5a ("drm/msm/dpu: Add X1E80100 support")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h | 2 ++
1 file changed, 2 ins
Ensure HDMI connector initialization fails when the presence of
HDMI_COLORSPACE_YUV420 in the given supported_formats bitmask doesn't
match the value of drm_connector->ycbcr_420_allowed.
Suggested-by: Dmitry Baryshkov
Signed-off-by: Cristian Ciocaltea
---
drivers/gpu/drm/drm_connector.c | 3 +++
Bridges having the DRM_BRIDGE_OP_HDMI flag set in drm_bridge->ops are
supposed to rely on drm_bridge->supported_formats bitmask to advertise
the supported colorspaces, including HDMI_COLORSPACE_YUV420. Therefore,
the newly introduced drm_bridge->ycbcr_420_allowed flag becomes
redundant in this par
Bridges with DRM_BRIDGE_OP_HDMI set in drm_bridge->ops are expected to
rely on drm_bridge->supported_formats to advertise the supported
colorspaces, including HDMI_COLORSPACE_YUV420.
However, when drm_bridge_connector gets initialised, only
drm_bridge->ycbcr_420_allowed is considered in the proces
On Fri, Dec 13, 2024 at 12:47 AM Yafang Shao wrote:
>
> Since task->comm is guaranteed to be NUL-terminated, we can print it
> directly without the need to copy it into a separate buffer. This
> simplifies the code and avoids unnecessary operations.
>
> Signed-off-by: Yafang Shao
> Cc: Kees Cook
On Mon, Dec 16, 2024 at 11:16:11AM -0800, Abhinav Kumar wrote:
>
>
> On 12/13/2024 12:38 PM, Dmitry Baryshkov wrote:
> > On Fri, 13 Dec 2024 at 21:15, Abhinav Kumar
> > wrote:
> > >
> > >
> > >
> > > On 12/12/2024 5:05 PM, Dmitry Baryshkov wrote:
> > > > On Thu, Dec 12, 2024 at 11:11:54AM -0
On Mon, Dec 16, 2024 at 12:45:13PM -0800, Abhinav Kumar wrote:
>
>
> On 12/14/2024 2:05 PM, Dmitry Baryshkov wrote:
> > On Sat, 14 Dec 2024 at 22:53, Abhinav Kumar
> > wrote:
> > >
> > > Hi Dmitry
> > >
> > > On 12/12/2024 3:09 PM, Dmitry Baryshkov wrote:
> > > > On Thu, 12 Dec 2024 at 21:15,
On 12/16/2024 2:24 PM, Dmitry Baryshkov wrote:
On Mon, Dec 16, 2024 at 11:32:57AM -0800, Abhinav Kumar wrote:
On 12/15/2024 2:44 PM, Dmitry Baryshkov wrote:
Use msm_dp_utils_pack_sdp_header() and call msm_dp_write_link() directly
to program audio packet data. Use 0 as Packet ID, as it was
Hi Dmitry,
On 12/10/24 3:12 AM, Dmitry Baryshkov wrote:
> On Fri, Dec 06, 2024 at 10:00:46PM +0200, Cristian Ciocaltea wrote:
>> Bridges having the DRM_BRIDGE_OP_HDMI flag set in drm_bridge->ops are
>> supposed to rely on drm_bridge->supported_formats bitmask to advertise
>> the supported colorspa
On Tue, Dec 17, 2024 at 12:54:08AM +0200, Cristian Ciocaltea wrote:
> Ensure HDMI connector initialization fails when the presence of
> HDMI_COLORSPACE_YUV420 in the given supported_formats bitmask doesn't
> match the value of drm_connector->ycbcr_420_allowed.
>
> Suggested-by: Dmitry Baryshkov
>
On Tue, Dec 17, 2024 at 12:54:07AM +0200, Cristian Ciocaltea wrote:
> Bridges having the DRM_BRIDGE_OP_HDMI flag set in drm_bridge->ops are
> supposed to rely on drm_bridge->supported_formats bitmask to advertise
> the supported colorspaces, including HDMI_COLORSPACE_YUV420. Therefore,
> the newly
On Mon, Dec 16, 2024 at 02:50:13PM +, Derek Foreman wrote:
> Just a ping - is there anything further I need to do here?
I expected that the patch should have been reviewed by Maxime. I'll
check if it's okay to push it with Angelo's and mine reviews.
>
> On 2024-12-03 03:45, AngeloGioacchino
On Tue, Dec 17, 2024 at 01:17:48AM +0200, Cristian Ciocaltea wrote:
> Hi Dmitry,
>
> On 12/10/24 3:12 AM, Dmitry Baryshkov wrote:
> > On Fri, Dec 06, 2024 at 10:00:46PM +0200, Cristian Ciocaltea wrote:
> >> Bridges having the DRM_BRIDGE_OP_HDMI flag set in drm_bridge->ops are
> >> supposed to rely
1 - 100 of 346 matches
Mail list logo
