On 06.12.24 05:31, Abhinav Kumar wrote:
base-commit: b166256c1e6ce356fa1404d4c8531830e6f100a8
Hi Abhinav,
I would like to test / play around with this patchset, unfortunately
this base commit is not easy to find. Trying to apply without gives lots
of conflicts. Can you please rebase?
with
On Fri, May 09, 2025 at 08:56:01PM +0200, Neil Armstrong wrote:
> Hi,
>
> On Tue, 06 May 2025 02:43:38 +0800, I Hsin Cheng wrote:
> > Coverity scan reported the usage of "mode->clock * 1000" may lead to
> > integer overflow. Use "1000ULL" instead of "1000"
> > when utilizing it to avoid potential
Hi Krzysztof,
On 2025/5/9 15:11, Krzysztof Kozlowski wrote:
On 09/05/2025 09:02, Chaoyi Chen wrote:
+
+ clock-names:
+items:
+ - const: core-clk
+ - const: pclk
+ - const: spdif
+ - const: grf
+
+ extcon:
+$ref: /schemas/types.yaml#/definitions/phandle-array
+d
On Fri, May 9 2025 at 02:05:16 PM +, Alex Deucher
wrote:
bisect between 6.2.16 and 6.2.17 to identify the commit which broke
Are you asking for a 'diff' output of drm and amdgpu directories
between 6.2.16 (last of the 6.2 series) and 6.3 (start of the 6.3
series)? I can and will if you w
{
"emoji": "👍",
"version": 1
}
Hi Krzysztof,
On 2025/5/9 17:21, Krzysztof Kozlowski wrote:
On 09/05/2025 09:34, Chaoyi Chen wrote:
Hi Krzysztof,
On 2025/5/9 15:11, Krzysztof Kozlowski wrote:
On 09/05/2025 09:02, Chaoyi Chen wrote:
+
+ clock-names:
+items:
+ - const: core-clk
+ - const: pclk
+ - const:
On Fri, May 9 2025 at 01:11:17 PM +, Alex Deucher
wrote:
What display(s) are you using and how are they connected? Can you
bisect?
Not sure the question, but it's a tv thru HDMI.
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384
DisplayPort-0 disconnected primary (n
On Fri, May 9 2025 at 02:05:16 PM +, Alex Deucher
wrote:
Can you narrow down where it broke?
Have built kernels from 5.15 thru 6.2.16 (last of the 6.2 series),
have no issues, ran Xorg server as test. Kernels 6.13.4 down to 6.3
builds, more builds focused in the 6.3 series, have the 70%
On Fri, 2025-05-09 at 16:00 -0700, Jakub Kicinski wrote:
> On Fri, 09 May 2025 11:53:36 -0400 Jeff Layton wrote:
> > This one just fixes a typo in the ref_tracker_dir_init() kerneldoc
> > header. I'm only resending so the CI will pick it up.
>
> We got a bunch of:
>
> [0.457561][T0] ref_t
Hi,
On Wed, May 07, 2025 at 10:28:21AM +0200, Gerd Hoffmann wrote:
> Calling drm_dev_unplug() is the drm way to say the device
> is gone and can not be accessed any more.
>
> Cc: Michael S. Tsirkin
> Signed-off-by: Gerd Hoffmann
> Reviewed-by: Eric Auger
> Tested-by: Eric Auger
> ---
> drive
When we performed fuzz testing on DRM using syzkaller, we encountered
the following hard lockup issue:
Kernel panic - not syncing: Hard LOCKUP
CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.6.0+ #21
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Call Trace:
hrtimer_cancel+0x52/0x70 ke
On Fri, 9 May 2025 15:53:48 +0200, Luca Ceresoli wrote:
> devm_drm_put_bridge() is a temporary workaround waiting for the panel
> bridge lifetime rework. Add a TODO entry to not forget it must be removed
> after such rework.
>
> Suggested-by: Maxime Ripard
>
> [ ... ]
Acked-by: Maxime Ripard
On Fri, 9 May 2025 15:53:47 +0200, Luca Ceresoli wrote:
> This is the new API for allocating DRM bridges.
>
> The devm lifetime management of this driver is peculiar. The underlying
> device for the panel_bridge is the panel, and the devm lifetime is tied the
> panel device (panel->dev). However t
On Fri, 9 May 2025 15:53:38 +0200, Luca Ceresoli wrote:
> This is the new API for allocating DRM bridges.
>
> Switching from a non-devm to a devm allocation allows removing the kfree()
> in the remove function and in the probe error management code, and as a
> consequence to simplify the code flow
On Fri, 9 May 2025 15:53:46 +0200, Luca Ceresoli wrote:
> Bridges obtained via devm_drm_bridge_alloc(dev, ...) will be put when the
> requesting device (@dev) is removed.
>
> However drivers which obtained them may need to put the obtained reference
> explicitly. One such case is if they bind the
On Fri, 9 May 2025 15:53:42 +0200, Luca Ceresoli wrote:
> This is the new API for allocating DRM bridges.
>
> This driver allocates the DRM bridge separately from the main driver
> private struct, which prevents using the new devm_drm_bridge_alloc()
> API. Simplify the code by replacing the struct
On Fri, 9 May 2025 15:53:40 +0200, Luca Ceresoli wrote:
> This is the new API for allocating DRM bridges.
>
> Signed-off-by: Luca Ceresoli
>
Acked-by: Maxime Ripard
Thanks!
Maxime
On Fri, 9 May 2025 15:53:33 +0200, Luca Ceresoli wrote:
> This is the new API for allocating DRM bridges.
>
> Signed-off-by: Luca Ceresoli
Acked-by: Maxime Ripard
Thanks!
Maxime
On Fri, 9 May 2025 15:53:43 +0200, Luca Ceresoli wrote:
> This is the new API for allocating DRM bridges.
>
> This driver has a peculiar structure. zynqmp_dpsub.c is the actual driver,
> which delegates to a submodule (zynqmp_dp.c) the allocation of a
> sub-structure embedding the drm_bridge and i
On Fri, 9 May 2025 15:53:41 +0200, Luca Ceresoli wrote:
> This is the new API for allocating DRM bridges.
>
> Signed-off-by: Luca Ceresoli
>
Acked-by: Maxime Ripard
Thanks!
Maxime
On Fri, 9 May 2025 15:53:39 +0200, Luca Ceresoli wrote:
> This is the new API for allocating DRM bridges.
>
> Switching from a non-devm to a devm allocation allows removing the kfree()
> in the remove function and in the probe error management code, and as a
> consequence to simplify the code flow
On Fri, 9 May 2025 15:53:37 +0200, Luca Ceresoli wrote:
> This is the new API for allocating DRM bridges.
>
> Switching from a non-devm to a devm allocation allows removing the kfree()
> in the remove function and in the probe error management code, and as a
> consequence to simplify the code flow
On Fri, 9 May 2025 15:53:36 +0200, Luca Ceresoli wrote:
> This is the new API for allocating DRM bridges.
>
> Switching from a non-devm to a devm allocation allows removing the kfree()
> in the remove function and in the probe error management code, and as a
> consequence to simplify the code flow
On Fri, 9 May 2025 15:53:35 +0200, Luca Ceresoli wrote:
> This is the new API for allocating DRM bridges.
>
> Signed-off-by: Luca Ceresoli
>
Acked-by: Maxime Ripard
Thanks!
Maxime
On Fri, 9 May 2025 15:53:34 +0200, Luca Ceresoli wrote:
> This is the new API for allocating DRM bridges.
>
> Signed-off-by: Luca Ceresoli
>
Acked-by: Maxime Ripard
Thanks!
Maxime
On Fri, 9 May 2025 15:53:32 +0200, Luca Ceresoli wrote:
> This is the new API for allocating DRM bridges.
>
> Signed-off-by: Luca Ceresoli
Acked-by: Maxime Ripard
Thanks!
Maxime
On Fri, 9 May 2025 15:53:31 +0200, Luca Ceresoli wrote:
> This is the new API for allocating DRM bridges.
>
> Signed-off-by: Luca Ceresoli
>
Acked-by: Maxime Ripard
Thanks!
Maxime
On Fri, May 09, 2025 at 03:53:30PM +0200, Luca Ceresoli wrote:
> This is the new API for allocating DRM bridges.
>
> Signed-off-by: Luca Ceresoli
Acked-by: Maxime Ripard
Maxime
signature.asc
Description: PGP signature
On Fri, May 09, 2025 at 03:53:29PM +0200, Luca Ceresoli wrote:
> This is the new API for allocating DRM bridges.
>
> Signed-off-by: Luca Ceresoli
Acked-by: Maxime Ripard
signature.asc
Description: PGP signature
On Fri, May 09, 2025 at 03:53:28PM +0200, Luca Ceresoli wrote:
> devm_drm_bridge_alloc() is the new API to be used for allocating (and
> partially initializing) a private driver struct embedding a struct
> drm_bridge.
>
> For many drivers having a simple code flow in the probe function, this
> com
30 matches
Mail list logo
