a bridge or neither.
> - Select DRM_DISPLAY_DP_AUX_BUS for DRM_ANALOGIX_DP, and remove it for
>ROCKCHIP_ANALOGIX_DP.
> - Apply rockchip_dp_attach() to support the next bridge attachment for
>the Rockchip side.
> - Move next_bridge attachment from Analogix side to Rockchip/Exynos sides.
Exynos part still lacks "select DRM_BRIDGE_CONNECTOR" in Kconfig,
besides that it works fine on all my test boards. Fix this issue and
feel free to add:
Tested-by: Marek Szyprowski
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
On 03.09.2025 21:32, Henrik Grimler wrote:
> On Mon, Aug 25, 2025 at 04:16:50PM +0200, Marek Szyprowski wrote:
>> On 24.08.2025 13:16, Henrik Grimler wrote:
>>> To use MHL we currently need the MHL chip to be permanently on, which
>>> consumes unnecessary power. Let&#x
On 04.09.2025 05:19, Damon Ding wrote:
> On 9/1/2025 6:25 PM, Marek Szyprowski wrote:
>> On 01.09.2025 05:41, Damon Ding wrote:
>>> On 8/29/2025 4:23 PM, Marek Szyprowski wrote:
>>>> On 29.08.2025 10:08, Damon Ding wrote:
>>>>> On 8/20/2025 5:20 AM, Ma
On 01.09.2025 05:41, Damon Ding wrote:
> On 8/29/2025 4:23 PM, Marek Szyprowski wrote:
>> On 29.08.2025 10:08, Damon Ding wrote:
>>> On 8/20/2025 5:20 AM, Marek Szyprowski wrote:
>>>> On 15.08.2025 04:59, Damon Ding wrote:
>>>>> On 2025/8/15 5:16, Marek
On 29.08.2025 10:08, Damon Ding wrote:
> On 8/20/2025 5:20 AM, Marek Szyprowski wrote:
>> On 15.08.2025 04:59, Damon Ding wrote:
>>> On 2025/8/15 5:16, Marek Szyprowski wrote:
>>>> On 14.08.2025 16:33, Marek Szyprowski wrote:
>>>>> On 14.08.2025 12:47
ning_lane[] to set DPCD
> DP_TRAINING_LANEx_SET, which can remove the redundant assignments
> and make codes more consice.
>
> Signed-off-by: Damon Ding
Tested-by: Marek Szyprowski
> ---
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 8 ++--
> 1 file changed, 2 in
.../drm/bridge/analogix/analogix_dp_core.c| 123 +++---
> 1 file changed, 18 insertions(+), 105 deletions(-)
Tested-by: Marek Szyprowski
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
sii9234_cable_in(ctx);
>
> return 0;
> }
> @@ -929,7 +1004,15 @@ static void sii9234_remove(struct i2c_client *client)
> {
> struct sii9234 *ctx = i2c_get_clientdata(client);
>
> - sii9234_cable_out(ctx);
> + if (ctx->extcon) {
> + extcon_unregister_notifier(ctx->extcon, EXTCON_DISP_MHL,
> +&ctx->extcon_nb);
> + flush_work(&ctx->extcon_wq);
> + if (ctx->cable_state > 0)
> + sii9234_cable_out(ctx);
> + } else {
> + sii9234_cable_out(ctx);
> + }
> drm_bridge_remove(&ctx->bridge);
> }
>
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
tic page
> ranges.
>
> Cc: Marek Szyprowski
> Cc: Robin Murphy
> Signed-off-by: David Hildenbrand
Acked-by: Marek Szyprowski
> ---
> kernel/dma/remap.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/dma/remap.c b/kernel/dma/rema
o be
> contiguous.
>
> We can now drop the nth_page() usage in sg_page_iter_page().
>
> Signed-off-by: David Hildenbrand
Acked-by: Marek Szyprowski
> ---
> include/linux/scatterlist.h | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git
On 18.08.2025 16:26, Henrik Grimler wrote:
> On Thu, Aug 14, 2025 at 01:26:33PM +0200, Marek Szyprowski wrote:
>> On 24.07.2025 20:50, Henrik Grimler wrote:
>>> To use MHL we currently need the MHL chip to be permanently on, which
>>> consumes unnecessary power. Let&#x
On 15.08.2025 04:59, Damon Ding wrote:
> On 2025/8/15 5:16, Marek Szyprowski wrote:
>> On 14.08.2025 16:33, Marek Szyprowski wrote:
>>> On 14.08.2025 12:47, Damon Ding wrote:
>>>> PATCH 1 is a small format optimization for struct analogid_dp_device.
>>>
On 14.08.2025 16:33, Marek Szyprowski wrote:
> On 14.08.2025 12:47, Damon Ding wrote:
>> PATCH 1 is a small format optimization for struct analogid_dp_device.
>> PATCH 2 is to perform mode setting in &drm_bridge_funcs.atomic_enable.
>> PATCH 3-6 are preparations for a
e connector initilization to the Rockchip and Exynos sides.
>
> Changes in v4:
> - Rebase for the applied &drm_bridge_funcs.detect() modification commit.
> - Rename analogix_dp_find_panel_or_bridge() to analogix_dp_finish_probe().
> - Drop the drmm_encoder_init() modification commit.
> - Rename the &analogix_dp_plat_data.bridge to
>&analogix_dp_plat_data.next_bridge.
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
t, ctx);
>
> ctx->bridge.of_node = dev->of_node;
> drm_bridge_add(&ctx->bridge);
>
> - sii9234_cable_in(ctx);
> + if (!ctx->extcon)
> + sii9234_cable_in(ctx);
>
> return 0;
> }
> @@ -930,7 +1005,15 @
and may lead to
> double-free when the device is removed.
>
> Fixes: e7447128ca4a ("drm: bridge: Generalize Exynos-DSI driver into a
> Samsung DSIM bridge")
> Signed-off-by: Miaoqian Lin
Reviewed-by: Marek Szyprowski
> ---
> drivers/gpu/drm/bridge/samsung-dsim.
---
Thanks!
Acked-by: Marek Szyprowski
Tested-by: Marek Szyprowski
You should also add "select EXTCON" (like in case of Sii8620) to Kconfig
to avoid potential build break if extcon support is built as a module.
> drivers/gpu/drm/bridge/sii9234.c | 89
>
_dp_core.h| 8 +-
> drivers/gpu/drm/exynos/exynos_dp.c| 27 +-
> .../gpu/drm/rockchip/analogix_dp-rockchip.c | 42 +-
> include/drm/bridge/analogix_dp.h | 6 +-
> 5 files changed, 217 insertions(+), 236 deletions(-)
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
ruct drm_bridge is meant to be always embedded
>> in a driver-private struct. But several drivers are still using it, so
>> those would need to be updated beforehand:
>>
>> $ git grep -l driver_private -- drivers/gpu/drm/ | wc -l
>> 23
>> $
> Ah, you
driver_private -- drivers/gpu/drm/ | wc -l
> 23
> $
>
> So I think this patch should be taken as it fixes a regression. Do you
> agree on this?
Yes, please apply it as a fix :)
BTW, there are 2 more bridge drivers that need a fix similar to the
$subject patch:
$ git grep "bridge = devm_kzalloc" drivers/gpu
drivers/gpu/drm/sti/sti_hda.c: bridge = devm_kzalloc(dev,
sizeof(*bridge), GFP_KERNEL);
drivers/gpu/drm/sti/sti_hdmi.c: bridge = devm_kzalloc(dev,
sizeof(*bridge), GFP_KERNEL);
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
tching the driver to the new API.
Signed-off-by: Marek Szyprowski
---
.../drm/bridge/analogix/analogix_dp_core.c| 40 +--
.../drm/bridge/analogix/analogix_dp_core.h| 3 +-
2 files changed, 13 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix
MU: __sysmmu_enable_clocks enter
>>> [ 4.362777] I_HAVE_ADDED_THESE: SYSMMU: write: reg 0x val
>>> 0x0007
>>> [ 4.362782] I_HAVE_ADDED_THESE: SYSMMU: __sysmmu_init_config enter
>>> [ 4.362786] I_HAVE_ADDED_THESE: SYSMMU: write: reg 0x0004 val
>>> 0x01100784
>>> [ 4.362791] I_HAVE_ADDED_THESE: SYSMMU: __sysmmu_set_ptbase enter
>>> [ 4.362795] I_HAVE_ADDED_THESE: SYSMMU: write: reg 0x000c val
>>> 0x00042a64
>>> [ 4.362799] I_HAVE_ADDED_THESE: SYSMMU: __sysmmu_tlb_invalidate
>>> enter
>>> [ 4.362803] I_HAVE_ADDED_THESE: SYSMMU: write: reg 0x0010 val
>>> 0x0001
>>> [ 4.362808] I_HAVE_ADDED_THESE: SYSMMU: __sysmmu_enable_vid enter
>>> [ 4.362811] I_HAVE_ADDED_THESE: SYSMMU: write: reg 0x val
>>> 0x0005
>>>
>>> Then it continues booting as usual.
>>>
>>> My lack of understanding of the IOMMU and DRM subsystems are really
>>> limiting my triaging capabilities here, therefore I ask for any form
>>> guidance or assistance with this.
>>>
>>> Thank you.
>>>
>>> [1]
>>> https://lore.kernel.org/r/20250612-exynosdrm-decon-v2-0-d6c1d21c8...@disroot.org
>>> [2]
>>> https://lore.kernel.org/all/20250612-exynos7870-drm-dts-v1-2-88c0779af...@disroot.org
>>> [3]
>>> https://lore.kernel.org/all/20250612-exynos7870-drm-dts-v1-3-88c0779af...@disroot.org
>>> [4]
>>> https://protect2.fireeye.com/v1/url?k=015e6282-60d577b4-015fe9cd-74fe485cbff1-5039f5dfc286ac1d&q=1&e=4899b4fe-bcb8-43f2-87ed-92e79b0abe08&u=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Fv6.16-rc2%2Fsource%2Fdrivers%2Fiommu%2Fiommu.c%23L431
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
clearing the DSIM_STATE_INITIALIZED
> flag and uninitializing the clocks and irqs before calling
> samsung_dsim_init().
>
> Fixes: c9b1150a68d9 ("drm/atomic-helper: Re-order bridge chain pre-enable and
> post-disable")
> Reported-by: Hiago De Franco
>
On 18.06.2025 14:25, Tomi Valkeinen wrote:
> On 18/06/2025 15:06, Marek Szyprowski wrote:
>> Commit c9b1150a68d9 ("drm/atomic-helper: Re-order bridge chain pre-enable
>> and post-disable") changed the call sequence to the CRTC enable/disable
>> and bridge pre_enable
vice to be runtime resumed.
This patch adds runtime PM guards to the fimd_dp_clock_enable() function
to enable its proper operation also when the CRTC implemented by FIMD is
not yet enabled.
Fixes: 196e059a8a6a ("drm/exynos: convert clock_enable crtc callback to
pipeline clock")
Signed-off-
On 18.06.2025 10:27, Maxime Ripard wrote:
> On Wed, Jun 18, 2025 at 08:30:39AM +0200, Marek Szyprowski wrote:
>> On 16.06.2025 17:40, Tomi Valkeinen wrote:
>>> On 12/06/2025 09:31, Marek Szyprowski wrote:
>>>> On 12.06.2025 07:49, Tomi Valkeinen wrote:
>>>&
On 16.06.2025 17:40, Tomi Valkeinen wrote:
> On 12/06/2025 09:31, Marek Szyprowski wrote:
>> On 12.06.2025 07:49, Tomi Valkeinen wrote:
>>> On 11/06/2025 13:45, Marek Szyprowski wrote:
>>>> On 05.06.2025 19:15, Aradhya Bhatia wrote:
>>>>> From
On 12.06.2025 07:49, Tomi Valkeinen wrote:
> On 11/06/2025 13:45, Marek Szyprowski wrote:
>> On 05.06.2025 19:15, Aradhya Bhatia wrote:
>>> From: Aradhya Bhatia
>>>
>>> Move the bridge pre_enable call before crtc enable, and the bridge
>>> post_dis
ding
> - * element is a bridge this means it's called after that bridge's
> - * @atomic_post_disable or @post_disable function. If the preceding
> - * element is a &drm_encoder it's called right after the encoder's
> - * &drm_encoder_helper_funcs.atomic_disable hook.
> - *
>* The bridge must assume that the display pipe (i.e. clocks and timing
> - * signals) feeding it is no longer running when this callback is
> - * called.
> + * signals) feeding this bridge is no longer running when the
> + * @atomic_post_disable is called.
> + *
> + * This callback should perform all the actions required by the hardware
> + * after it has stopped receiving signals from the preceding element.
> + *
> + * If the preceding element is a &drm_bridge, then this is called after
> + * that bridge is post-disabled (unless marked otherwise by the
> + * @pre_enable_prev_first flag) via one of:
> + *
> + * - &drm_bridge_funcs.post_disable
> + * - &drm_bridge_funcs.atomic_post_disable
> + *
> + * If the preceding element of the bridge is a display controller, then
> + * this callback is called after the encoder is disabled via one of:
> + *
> + * - &drm_encoder_helper_funcs.atomic_disable
> + * - &drm_encoder_helper_funcs.prepare
> + * - &drm_encoder_helper_funcs.disable
> + * - &drm_encoder_helper_funcs.dpms
> + *
> + * and the CRTC is disabled via one of:
> + *
> + * - &drm_crtc_helper_funcs.prepare
> + * - &drm_crtc_helper_funcs.atomic_disable
> + * - &drm_crtc_helper_funcs.disable
> + * - &drm_crtc_helper_funcs.dpms
>*
>* The @atomic_post_disable callback is optional.
>*/
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
On 14.05.2025 15:44, Marek Szyprowski wrote:
> On 08.05.2025 11:57, Christian König wrote:
>> On 5/7/25 18:09, Marek Szyprowski wrote:
>>> Use common wrappers operating directly on the struct sg_table
>>> objects to
>>> fix incorrect use of scatt
e flushed for
deleting garbage data in video mode."
Your reasoning seems to be correct, it probably slipped into
MIPI_DSI_MODE flags just because it is in the same register.
Feel free to add:
Acked-by: Marek Szyprowski
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
On 08.05.2025 11:57, Christian König wrote:
> On 5/7/25 18:09, Marek Szyprowski wrote:
>> Use common wrappers operating directly on the struct sg_table objects to
>> fix incorrect use of scatterlists sync calls. dma_sync_sg_for_*()
>> functions have to be called with t
Dear All,
This patchset fixes the incorrect use of dma_sync_sg_*() calls in
media and related drivers. They are replaced with much safer
dma_sync_sgtable_*() variants, which take care of passing the proper
number of elements for the sync operation.
Best regards
Marek Szyprowski, PhD
Samsung R&a
Fixes: 1ffe09590121 ("udmabuf: fix dma-buf cpu access")
CC: sta...@vger.kernel.org
Signed-off-by: Marek Szyprowski
Acked-by: Vivek Kasireddy
---
drivers/dma-buf/udmabuf.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/
Fixes: 1ffe09590121 ("udmabuf: fix dma-buf cpu access")
Signed-off-by: Marek Szyprowski
Acked-by: Vivek Kasireddy
---
drivers/dma-buf/udmabuf.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index 7eee3eb47a8e..c9d0
Dear All,
This patchset fixes the incorrect use of dma_sync_sg_*() calls in
media and related drivers. They are replaced with much safer
dma_sync_sgtable_*() variants, which take care of passing the proper
number of elements for the sync operation.
Best regards
Marek Szyprowski, PhD
Samsung R&a
Dear All,
This patchset fixes the incorrect use of dma_sync_sg_*() calls in
media and related drivers. They are replaced with much safer
dma_sync_sgtable_*() variants, which take care of passing the proper
number of elements for the sync operation.
Best regards
Marek Szyprowski, PhD
Samsung R&a
Fixes: 1ffe09590121 ("udmabuf: fix dma-buf cpu access")
Signed-off-by: Marek Szyprowski
---
drivers/dma-buf/udmabuf.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index 7eee3eb47a8e..c9d0c68d2fcb 100644
--- a/
selector register twice which most likely messes up the things.
> But this is only a theory (since we don't have the traces yet).
Bingo! This patch (on top of current linux-next) fixed the probe issue.
Feel free to add:
Reported-by: Marek Szyprowski
Tested-by: Marek Szyprowski
(although I'm not sure if this is a fix for the generic case or just
this driver)
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
Hi Andy,
On 21.01.2025 14:29, Andy Shevchenko wrote:
> On Tue, Jan 21, 2025 at 08:33:09AM +0100, Marek Szyprowski wrote:
>> On 17.01.2025 18:28, Andy Shevchenko wrote:
>>> On Fri, Jan 17, 2025 at 05:05:42PM +0100, Marek Szyprowski wrote:
>>>
>>> Does it
On 17.01.2025 18:28, Andy Shevchenko wrote:
> On Fri, Jan 17, 2025 at 05:05:42PM +0100, Marek Szyprowski wrote:
>> On 17.01.2025 15:30, Andy Shevchenko wrote:
>>> On Fri, Jan 17, 2025 at 04:09:58PM +0200, Andy Shevchenko wrote:
>>>> On Fri, Jan 17, 2025 at 02:57:52PM
On 17.01.2025 18:28, Andy Shevchenko wrote:
> On Fri, Jan 17, 2025 at 05:05:42PM +0100, Marek Szyprowski wrote:
>> On 17.01.2025 15:30, Andy Shevchenko wrote:
>>> On Fri, Jan 17, 2025 at 04:09:58PM +0200, Andy Shevchenko wrote:
>>>> On Fri, Jan 17, 2025 at 02:57:52PM
On 17.01.2025 15:30, Andy Shevchenko wrote:
> On Fri, Jan 17, 2025 at 04:09:58PM +0200, Andy Shevchenko wrote:
>> On Fri, Jan 17, 2025 at 02:57:52PM +0100, Marek Szyprowski wrote:
>>> On 16.01.2025 13:42, Andy Shevchenko wrote:
>>>> If the selector register is repre
On 17.01.2025 15:09, Andy Shevchenko wrote:
> On Fri, Jan 17, 2025 at 02:57:52PM +0100, Marek Szyprowski wrote:
>> On 16.01.2025 13:42, Andy Shevchenko wrote:
>>> If the selector register is represented in each page, its value
>>> in accordance to the debugfs is stale b
(ret != 0)
> return ret;
> +
> + /*
> + * If selector register has been just updated, update the
> respective
> + * virtual copy as well.
> + */
> + if (page_chg &&
> + in_range(range->selector_reg, range->window_start,
> range->window_len))
> + _regmap_update_bits(map, sel_register, mask, val, NULL,
> false);
> }
>
> *reg = range->window_start + win_offset;
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
p table on Pi0-3.
>
> Correct that conditional.
>
> Fixes: 24c5ed3ddf27 ("drm/vc4: Introduce generation number enum")
> Signed-off-by: Dave Stevenson
Reported-by: Marek Szyprowski
Tested-by: Marek Szyprowski
> ---
> drivers/gpu/drm/vc4/vc4_hvs.c | 2 +-
> 1 file cha
t;drm/vc4: hvs: Ignore atomic_flush if we're disabled")
> Signed-off-by: Dave Stevenson
Tested-by: Marek Szyprowski
> ---
> drivers/gpu/drm/vc4/vc4_hvs.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drive
e364d196 ("drm/vc4: hvs: Don't write gamma luts on 2711")
> Reported-by: Marek Szyprowski
> Closes:
> https://lore.kernel.org/dri-devel/37051126-3921-4afe-a936-5f828bff5...@samsung.com/
> Signed-off-by: Dave Stevenson
Tested-by: Marek Szyprowski
> ---
> drivers
c5)
> + if (hvs->vc4->gen == VC4_GEN_4)
> return;
>
> /* The LUT memory is laid out with each HVS channel in order,
as changing the above check to 'if (hvs->vc4->gen > VC4_GEN_4)' fixes this
issue (tested also on top of linux-next). I
#x27; object
is used. Fix this.
Fixes: 45903624e9fc ("drm/vc4: Run DRM default client setup")
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/vc4/vc4_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 13a1ecd
If caller doesn't provide driver->fbdev_probe nor funcs->fb_probe, then
fail early instead of causing potential NULL pointer dereference, because
fb_helper->fb won't be initialized in such case.
Fixes: 5d08c44e47b9 ("drm/fbdev: Add memory-agnostic fbdev client")
Si
820020)
---[ end trace ]---
[1] https://patchwork.freedesktop.org/series/137389/
Best regards
Marek Szyprowski, PhD
Samsung R&D Institute Poland
Patch summary:
Marek Szyprowski (2):
drm/fbdev-helper: fail if driver provides no fbdev/fb probe functions
drm/vc4: Provid
'm not able to debug it further too, at least till the end of
August. Maybe we could keep old behavior for "exynos-dsi" compatible device?
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
e_handle(tmp_np)->dev)
> break;
> - }
>
> - if (!of_device_is_available(tmp_np)) {
> - of_node_put(tmp_np);
> + if (!of_device_is_available(tmp_np))
> return;
> - }
>
> tmp_np = of_get_next_parent(tmp_np);
> }
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
Cc: David Airlie
> Cc: Frieder Schrempf
> Cc: Inki Dae
> Cc: Jagan Teki
> Cc: Jernej Skrabec
> Cc: Jonas Karlman
> Cc: Laurent Pinchart
> Cc: Lucas Stach
> Cc: Maarten Lankhorst
> Cc: Marek Szyprowski
> Cc: Maxime Ripard
> Cc: Michael Walle
> Cc: Neil Arms
On 25.04.2024 22:30, Adam Ford wrote:
> On Thu, Apr 25, 2024 at 4:19 AM Marek Szyprowski
> wrote:
>> On 12.02.2024 00:09, Adam Ford wrote:
>>> When using video sync pulses, the HFP, HBP, and HSA are divided between
>>> the available lanes if there is more than one
ommit wait timed out
exynos-mixer 12c1.mixer: timeout waiting for VSYNC
Cc: sta...@vger.kernel.org
Fixes: 13d5b040363c ("drm/exynos: do not return negative values from
.get_modes()")
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 7 +--
1 file c
nds up being too small which can cause
> some monitors to not sync properly. In these instances, adjust htotal
> and hsync to round the HFP up, and recalculate the htotal.
>
> Tested-by: Frieder Schrempf # Kontron BL
> i.MX8MM with HDMI monitor
> Signed-off-by: Adam Ford
bove."
>
> With this patch, the clock rates now match the values used in NXP's
> downstream kernel.
>
> Fixes: 846307185f0f ("drm/bridge: samsung-dsim: update PLL reference clock")
> Signed-off-by: Adam Ford
> Reviewed-by: Frieder Schrempf
> Tested-
On 23.04.2024 22:44, Marek Szyprowski wrote:
> Commit 7af03e688792 ("drm/probe-helper: warn about negative
> .get_modes()") clarified, that .get_modes callback must not return
> negative values on failure, so fix sub-drivers to return 0 in case of
> errors. This fi
for VSYNC) observed on Trats2 board.
Cc: sta...@vger.kernel.org
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 4 ++--
drivers/gpu/drm/exynos/exynos_hdmi.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm
panels without integrated backlight control,
even if the needed modules have been properly loaded and probed.
Fix this by selecting BACKLIGHT_CLASS_DEVICE to be compiled-in in
multi_v7_defconfig.
Signed-off-by: Marek Szyprowski
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 ins
dules have been properly loaded and probed.
Fix this by selecting BACKLIGHT_CLASS_DEVICE to be compiled-in in
multi_v7_defconfig.
Signed-off-by: Marek Szyprowski
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig
b/a
I")
> Signed-off-by: Fedor Pchelkin
Reviewed-by: Marek Szyprowski
> ---
> drivers/gpu/drm/exynos/exynos_drm_gsc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> b/drivers/gpu/drm/exynos/exynos_drm_gsc
+0x2c0/0x448
> [8.899466] __lock_acquire+0x9d8/0x1950
> [ 8.899479] lock_acquire+0x238/0x354
> [ 8.899492] _raw_spin_lock_irqsave+0x50/0x6c
> [8.899507] regmap_lock_spinlock+0x14/0x24
> [8.899517] regmap_read+0x38/0x70
> [8.899528] vop2_isr+0x88/0x2a
tes is larger than 1024 bytes
>
> There is really no reason to copy the large exynos_drm_plane
> structure to the stack before using one of its members, so just
> use a pointer instead.
>
> Fixes: 6f8ee5c21722 ("drm/exynos: fimd: Make plane alpha configurable")
>
ache: %d\n", ret);
> + return;
> + }
>
> if (vop2->data->soc_id == 3566)
> vop2_writel(vop2, RK3568_OTP_WIN_EN, 1);
> @@ -913,8 +919,6 @@ static void vop2_disable(struct vop2 *vop2)
>
> pm_runtime_put_sync(vop2->dev);
>
> - regcache_mark_dirty(vop2->map);
> -
> clk_disable_unprepare(vop2->aclk);
> clk_disable_unprepare(vop2->hclk);
> }
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
encoder->funcs entry might be NULL, so check it first before calling its
methods. This fixes NULL pointer dereference observed on Rasberry Pi
3b/4b boards.
Fixes: caf525ed45b4 ("drm/encoder: register per-encoder debugfs dir")
Signed-off-by: Marek Szyprowski
---
This fixes the fo
dress the
> possible corner case of unintentional IRQ unmasking because of ISR
> execution after a call to synchronize_irq().
>
> At resume, clear each is_suspended bit in the reset path of JOB/MMU
> to allow unmasking the interrupts.
>
> Signed-off-by: AngeloGioacchino Del Reg
iewed-by: Boris Brezillon
> Reviewed-by: Steven Price
> Signed-off-by: AngeloGioacchino Del Regno
>
Tested-by: Marek Szyprowski
> ---
> drivers/gpu/drm/panfrost/panfrost_device.h | 2 ++
> drivers/gpu/drm/panfrost/panfrost_gpu.c| 10 +-
> drivers/gpu
ps
>
> Fixes: 22aa1a209018 ("drm/panfrost: Really power off GPU cores in
> panfrost_gpu_power_off()")
> Reviewed-by: Boris Brezillon
> Reviewed-by: Steven Price
> Signed-off-by: AngeloGioacchino Del Regno
>
Tested-by: Marek Szyprowski
> ---
>
> drivers/gpu/drm/panfrost/panfrost_mmu.h| 1 +
> 8 files changed, 70 insertions(+), 20 deletions(-)
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
On 24.11.2023 13:45, Marek Szyprowski wrote:
> On 22.11.2023 10:29, Krzysztof Kozlowski wrote:
>> On 22/11/2023 10:06, AngeloGioacchino Del Regno wrote:
>>>>>> Hey Krzysztof,
>>>>>>
>>>>>> This is interesting. It might be about the c
es, I also got into this issue some time ago, but I didn't report it
because I also had some power supply related problems on my test farm
and everything was a bit unstable. I wasn't 100% sure that the $subject
patch is responsible for the observed issues. Now, after fixing power
supply, I confirm that the issue was revealed by the $subject patch and
above mentioned change fixes the problem. Feel free to add:
Tested-by: Marek Szyprowski
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
es, I also got into this issue some time ago, but I didn't report it
because I also had some power supply related problems on my test farm
and everything was a bit unstable. I wasn't 100% sure that the $subject
patch is responsible for the observed issues. Now, after fixing power
supply, I confirm that the issue was revealed by the $subject patch and
above mentioned change fixes the problem. Feel free to add:
Tested-by: Marek Szyprowski
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
sume that
the device-tree you use for the bare metal run and Xen enabled run
doesn't differ in the areas describing the hardware blocks.
Please check if cherry-picking the commit
https://github.com/torvalds/linux/commit/bbc4d205d93f52ee18dfa7858d51489c0506547f
to your v6.1.59 based kernel helps anyhow.
If not, then as a temporary workaround please disable
CONFIG_DRM_EXYNOS_MIXER and CONFIG_DRM_EXYNOS_HDMI in your kernel config
and check what will happen (You will lose the HDMI output, but maybe
this won't a big issue).
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
still an error in the
> calculation of the porches and someone at NXP can chime in.
>
> Michael
>
> Signed-off-by: Michael Tretter
All my Exynos-based test boards with DSI display panels still work fine
with this patchset.
Feel free to add:
Tested-by: Marek Szyprowski
> ---
&g
thout any dependencies. It
>could potentially be removed later.
> - This patch also makes sure to set the drvdata to NULL in the case of
>bind errors to make sure that shutdown can't access freed data.
>
> Suggested-by: Maxime Ripard
> Reviewed-by: Maxime Rip
On 11.08.2023 14:59, Robert Foss wrote:
> On Wed, 9 Aug 2023 16:56:41 +0200, Marek Szyprowski wrote:
>> Samsung DSIM used in older Exynos SoCs (like Exynos 4210, 4x12, 3250)
>> doesn't report empty level of packer header FIFO. In case of those SoCs,
>> use the old way of
e
transfer").
Fixes: 14806c641582 ("drm: bridge: samsung-dsim: Drain command transfer FIFO
before transfer")
Signed-off-by: Marek Szyprowski
---
v4:
- made has_broken_fifoctrl_emptyhdr a bitfield
v3:
- fixed 'fixes' tag, added reviewed-by
v2:
- added additional delay when worka
e
transfer").
Fixes: 14806c641582 ("drm: bridge: samsung-dsim: Drain command transfer FIFO
before transfer")
Signed-off-by: Marek Szyprowski
Reviewed-by: Marek Vasut
---
v3:
- fixed 'fixes' tag, added reviewed-by
v2:
- added additional delay when workaround is used as s
e
transfer").
Fixes: 14806c641582 ("Drain command transfer FIFO before transfer")
Signed-off-by: Marek Szyprowski
---
v2:
- added additional delay when workaround is used as suggested by Marek Vasut
v1:
https://lore.kernel.org/all/20230718131859.3114135-1-m.szyprow...@samsung.com/
--
e
transfer").
Fixes: 14806c641582 ("Drain command transfer FIFO before transfer")
Signed-off-by: Marek Szyprowski
---
If I remember right, the problem with waiting for the empty command
transfer FIFO was there from the begging of the Exynos DSI driver and
Tomash Figa and Andrzej Hajda u
On 13.06.2023 13:15, Marek Szyprowski wrote:
> On 05.05.2023 13:25, Maxime Ripard wrote:
>> From: Stephen Boyd
>>
>> We'll need to turn the code in clk_mux_determine_rate_flags() to deal
>> with CLK_SET_RATE_NO_REPARENT into a helper clock drivers will be able
n ret;
> -
> - trace_clk_rate_request_done(&parent_req);
> -
> - best = parent_req.rate;
> - } else if (parent) {
> - best = clk_core_get_rate_nolock(parent);
> - } else {
> - best = clk_core_get_rate_nolock(core);
> - }
> -
> - goto out;
> - }
> + if (core->flags & CLK_SET_RATE_NO_REPARENT)
> + return clk_core_determine_rate_no_reparent(hw, req);
> /* find the parent that can provide the fastest rate <= rate */
> num_parents = core->num_parents;
> @@ -670,9 +683,7 @@ int clk_mux_determine_rate_flags(struct clk_hw *hw,
> if (!best_parent)
> return -EINVAL;
> -out:
> - if (best_parent)
> - req->best_parent_hw = best_parent->hw;
> + req->best_parent_hw = best_parent->hw;
> req->best_parent_rate = best;
> req->rate = best;
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
> +* doesn't state what the definition of the PHYTIMING
>> +* bits are beyond their address and bit position.
>> +* After reviewing NXP's downstream code, it appears
>> +* that the various PHYTIMING registers take the number
>> +* of cy
i.MX8M Nano and i.MX8M Plus, and should
> work on i.MX8M Mini as well. Marek Szyprowski has tested it on various
> Exynos boards.
>
> Adam Ford (5):
>drm: bridge: samsung-dsim: Fix PMS Calculator on imx8m[mnp]
>drm: bridge: samsung-dsim: Fetch pll-clock-frequency au
On 13.05.2023 06:25, Adam Ford wrote:
> On Fri, May 12, 2023 at 4:02 PM Marek Szyprowski
> wrote:
>> On 12.05.2023 22:00, Adam Ford wrote:
>>> On Fri, May 12, 2023 at 2:37 PM Lucas Stach wrote:
>>>> Am Samstag, dem 06.05.2023 um 14:24 -0500 schrieb Adam Ford:
>
work for
> Marek S and since there was so much churn getting the original driver
> ported, I thought it would be the safest thing to try to give the
> imx8m m/n/p the features without breaking the Exynos.
>
> Marek S - Do you want me to post this file without the extra checks to
> see if it still works with Exynos?
Feel free to send me patches to test or just point to your
work-in-progress git repo.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
cket size calculation
>
> drivers/gpu/drm/bridge/Kconfig| 1 +
> drivers/gpu/drm/bridge/samsung-dsim.c | 150 ++
> include/drm/bridge/samsung-dsim.h | 5 +
> 3 files changed, 136 insertions(+), 20 deletions(-)
Works fine (= doesn't break
On 28.04.2023 15:35, Adam Ford wrote:
> On Fri, Apr 28, 2023 at 7:31 AM Marek Szyprowski
> wrote:
>> On 24.04.2023 12:00, Adam Ford wrote:
>>> On Mon, Apr 24, 2023 at 3:25 AM Marek Szyprowski
>>> wrote:
>>>> On 23.04.2023 14:12, Adam Ford wrote:
>&
On 24.04.2023 12:00, Adam Ford wrote:
> On Mon, Apr 24, 2023 at 3:25 AM Marek Szyprowski
> wrote:
>> On 23.04.2023 14:12, Adam Ford wrote:
>>> The high-speed clock is hard-coded to the burst-clock
>>> frequency specified in the device tree. However, when
>>
if (driver_data->dynamic_dphy) {
>>>> + phy_mipi_dphy_get_default_config(clock_in_hz, bpp,
>>>> dsi->lanes, &cfg);
>>> This requires adding "select GENERIC_PHY_MIPI_DPHY" to DRM_SAMSUNG_DSIM,
>>> otherwise with CONFIG
= samsung_dsim_of_read_u32(node, "samsung,burst-clock-frequency",
> &dsi->burst_clk_rate);
> if (ret < 0)
> - return ret;
> + dsi->burst_clk_rate = 0;
>
> ret = samsung_dsim_of_read_u32(node, "samsung,esc-clock-frequency",
> &dsi->esc_clk_rate);
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
p down to 640x480 and a bunch in between with various refresh
>>>> rates too. That was the goal of this series.
>>>>
>>>> Instead of just using your patch as-is, I will adapt yours to use the
>>>> scaled clock to see how it behaves and get back to you.
nue;
> + }
> }
>
> dev_info(dev, "failed to get the clock: %s\n",
> clk_names[i]);
> return PTR_ERR(dsi->clks[i]);
> }
> +
> + if (strc
IDOUT_AVAILABLE;
> }
> @@ -1680,10 +1667,6 @@ static ssize_t samsung_dsim_host_transfer(struct
> mipi_dsi_host *host,
> if (!(dsi->state & DSIM_STATE_ENABLED))
> return -EINVAL;
>
> - ret = samsung_dsim_init(dsi);
> - if (ret)
> - return ret;
> -
> ret = mipi_dsi_create_packet(&xfer.packet, msg);
> if (ret < 0)
> return ret;
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
ly
> among the existing clients if/when required.
>
> I did the conversion from similar experience with other drivers. But I
> don't have the hardware to test this. Any testing is welcome.
Seems to be working fine. Tested with default framebuffer based console
and simple tool that w
/meson: dw-hdmi: Fix devm_regulator_*get_enable*()
conversion")
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/meson/meson_dw_hdmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
ind
Hi Ricardo,
On 09.03.2023 09:55, Ricardo Cañuelo wrote:
> On lun 09-01-2023 23:00:33, Marek Szyprowski wrote:
>> devm_regulator_get_enable_optional() function returns 0 on success, so
>> use it for the check if function succeded instead of the -ENODEV value.
>>
>> Fixe
1 - 100 of 1053 matches
Mail list logo
