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
Hello,
On 07.03.2023 10:22, Jagan Teki wrote:
> On Tue, Mar 7, 2023 at 1:25 PM Jagan Teki wrote:
>> On Tue, Mar 7, 2023 at 4:11 AM Marek Szyprowski
>> wrote:
>>> On 06.03.2023 18:24, Jagan Teki wrote:
>>>> On Mon, Mar 6, 2023 at 4:32 PM Marek Szyprowski
&g
Dear Jagan,
On 06.03.2023 18:24, Jagan Teki wrote:
> On Mon, Mar 6, 2023 at 4:32 PM Marek Szyprowski
> wrote:
>> On 04.03.2023 19:59, Jagan Teki wrote:
>>> On Sat, Mar 4, 2023 at 3:56 AM Marek Szyprowski
>>> wrote:
>>>> On 03.03.2023 15:51, Jagan Tek
Hi Jagan,
On 04.03.2023 19:59, Jagan Teki wrote:
> On Sat, Mar 4, 2023 at 3:56 AM Marek Szyprowski
> wrote:
>> On 03.03.2023 15:51, Jagan Teki wrote:
>>> This series supports common bridge support for Samsung MIPI DSIM
>>> which is used in Exynos and i.MX8MM S
input_bus_fmts logic
>
> Changes for v11:
> - collect RB from Frieder Schrempf
> - collect ACK from Rob
> - collect ACK from Robert
> - fix BIT macro replacements
> - fix checkpatch --strict warnings
> - fix unneeded commit text
> - drop extra lines
>
> Changes for v10:
gt; kthread+0xfc/0x110
> ret_from_fork+0x10/0x20
> ---[ end trace ]---
>
> Reported-by: Laurentiu Palcu
> Fixes: c8268795c9a9 ("drm/probe-helper: enable and disable HPD on connectors")
> Signed-off-by: Dmitry Baryshkov
Seems to be fixing the issue I
Hi Neil,
On 12.01.2023 10:35, Neil Armstrong wrote:
> On 11/01/2023 13:41, Marek Szyprowski wrote:
>> On 02.11.2022 19:07, Dmitry Baryshkov wrote:
>>> Use drm_connector's helpers enable_hpd and disable_hpd to enable and
>>> disable HPD automatically by t
d(connector, &drm_bridge_connector_helper_funcs);
>
> - if (bridge_connector->bridge_hpd) {
> + if (bridge_connector->bridge_hpd)
> connector->polled = DRM_CONNECTOR_POLL_HPD;
> - drm_bridge_connector_enable_hpd(connector);
> - }
> else if (bridge_connector->bridge_detect)
> connector->polled = DRM_CONNECTOR_POLL_CONNECT
> | DRM_CONNECTOR_POLL_DISCONNECT;
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
devm_regulator_get_enable_optional() function returns 0 on success, so
use it for the check if function succeded instead of the -ENODEV value.
Fixes: 429e87063661 ("drm/meson: dw-hdmi: Use devm_regulator_*get_enable*()")
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/meson/meson
ne should be "if (ret < 0)", otherwise it breaks hdmi support.
I've noticed this once this change has been merged to linux-next and all
my Amlogic Meson based boards failed to initialize HDMI. Is it possible
to fix this in drm tree or do I need to send the incremental fixup?
> + return ret;
>
> meson_dw_hdmi->hdmitx_apb = devm_reset_control_get_exclusive(dev,
> "hdmitx_apb");
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
On 14.12.2022 06:33, Jagan Teki wrote:
> On Tue, Dec 13, 2022 at 9:11 PM Marek Szyprowski
> wrote:
>> On 13.12.2022 16:15, Jagan Teki wrote:
>>> On Tue, Dec 13, 2022 at 8:24 PM Marek Szyprowski
>>> wrote:
>>>> On 13.12.2022 15:18, Jagan Teki wrote:
&
On 13.12.2022 16:15, Jagan Teki wrote:
> On Tue, Dec 13, 2022 at 8:24 PM Marek Szyprowski
> wrote:
>> On 13.12.2022 15:18, Jagan Teki wrote:
>>> On Tue, Dec 13, 2022 at 7:31 PM Marek Szyprowski
>>> wrote:
>>>> On 13.12.2022 13:20, Marek Szyprowski wr
On 13.12.2022 15:18, Jagan Teki wrote:
> On Tue, Dec 13, 2022 at 7:31 PM Marek Szyprowski
> wrote:
>> On 13.12.2022 13:20, Marek Szyprowski wrote:
>>> On 13.12.2022 11:40, Jagan Teki wrote:
>>>> On Tue, Dec 13, 2022 at 2:28 PM Marek Szyprowski
>>>>
On 13.12.2022 13:20, Marek Szyprowski wrote:
> On 13.12.2022 11:40, Jagan Teki wrote:
>> On Tue, Dec 13, 2022 at 2:28 PM Marek Szyprowski
>> wrote:
>>> On 12.12.2022 16:33, Jagan Teki wrote:
>>>
>>> On Mon, Dec 12, 2022 at 8:52 PM Marek Szyprowski
>
Hi,
On 13.12.2022 11:40, Jagan Teki wrote:
> On Tue, Dec 13, 2022 at 2:28 PM Marek Szyprowski
> wrote:
>> On 12.12.2022 16:33, Jagan Teki wrote:
>>
>> On Mon, Dec 12, 2022 at 8:52 PM Marek Szyprowski
>> wrote:
>>
>> On 12.12.2022 09:43, Marek Szyprows
On 12.12.2022 16:33, Jagan Teki wrote:
> On Mon, Dec 12, 2022 at 8:52 PM Marek Szyprowski
> wrote:
>> On 12.12.2022 09:43, Marek Szyprowski wrote:
>>> On 12.12.2022 09:32, Jagan Teki wrote:
>>>> On Mon, Dec 12, 2022 at 1:56 PM Marek Szyprowski
>>>
08-dsi-v9-fixed
With that fixes, feel free to add:
Tested-by: Marek Szyprowski
to all common/Exynos related patches.
> Changes for v9:
> - rebase on drm-misc-next
> - drop drm bridge attach fix for Exynos
> - added prepare_prev_first flag
> - added pre_enable_prev_first flag
>
On 12.12.2022 09:43, Marek Szyprowski wrote:
> On 12.12.2022 09:32, Jagan Teki wrote:
>> On Mon, Dec 12, 2022 at 1:56 PM Marek Szyprowski
>> wrote:
>>> Hi Jagan,
>>>
>>> On 09.12.2022 16:23, Jagan Teki wrote:
>>>> The existing drm panels a
On 09.12.2022 16:23, Jagan Teki wrote:
> From: Marek Szyprowski
>
> Restore the proper bridge chain by finding the previous bridge
> in the chain instead of passing NULL.
>
> This establishes a proper bridge chain while attaching downstream
> bridges.
>
> v9, v4:
>
On 12.12.2022 10:03, Jagan Teki wrote:
> On Mon, Dec 12, 2022 at 2:28 PM Marek Szyprowski
> wrote:
>> Hi Jagan,
>>
>> On 09.12.2022 16:23, Jagan Teki wrote:
>>> HFP/HBP/HSA/EOT_PACKET modes in Exynos DSI host specifies
>>> 0 = Enable and 1 = Disable.
on the core patches
and don't add more random 'fixes' to each new version.
This change has to be discussed separately. The values written by the
Exynos DSI driver to the registers ARE CORRECT and DSI panels work fine
with such configuration. So either everything is correct, or these fla
On 12.12.2022 09:32, Jagan Teki wrote:
> On Mon, Dec 12, 2022 at 1:56 PM Marek Szyprowski
> wrote:
>> Hi Jagan,
>>
>> On 09.12.2022 16:23, Jagan Teki wrote:
>>> The existing drm panels and bridges in Exynos required host
>>> initialization during
IZED
> flag and triggers from host transfer.
>
> Do this exclusively for Exynos.
>
> Initial logic is derived from Marek Szyprowski changes.
>
> Signed-off-by: Marek Szyprowski
> Signed-off-by: Jagan Teki
> ---
> Changes from v9:
> - derived from v8
> - added c
>>>> On Mon, 5 Dec 2022 at 07:30, Frieder Schrempf
>>>> wrote:
>>>>> On 02.12.22 15:55, Dave Stevenson wrote:
>>>>>> Hi Marek
>>>>>>
>>>>>> On Fri, 2 Dec 2022 at 12:21, Marek Vasut wrote:
>>>>>&g
On 17.11.2022 18:21, Marek Szyprowski wrote:
> On 17.11.2022 17:07, Thomas Zimmermann wrote:
>> Am 17.11.22 um 13:57 schrieb Marek Szyprowski:
>>> On 15.11.2022 12:58, Thomas Zimmermann wrote:
>>>> Schedule the deferred-I/O worker instead of the damage worker a
Hi,
Sorry for delay, I was on a sick leave last 2 weeks.
On 28.11.2022 15:43, Jagan Teki wrote:
> ,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut wrote:
>> On 11/23/22 21:09, Jagan Teki wrote:
>>> On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut wrote:
>>>> On 11/17/22
On 17.11.2022 17:07, Thomas Zimmermann wrote:
> Am 17.11.22 um 13:57 schrieb Marek Szyprowski:
>> On 15.11.2022 12:58, Thomas Zimmermann wrote:
>>> Schedule the deferred-I/O worker instead of the damage worker after
>>> writing to the fbdev framebuffer. The deferr
d transfer, this
>> helps existing DSI panels work on exynos platform (form Marek
>> Szyprowski).
>>
>> v8, v7, v6, v5:
>> * none
>>
>> v4:
>> * update init handling to ensure host init done on first cmd transfer
>>
>> v3:
>> * none
>>
&g
struct file *file);
> extern void fb_deferred_io_cleanup(struct fb_info *info);
> +extern void fb_deferred_io_schedule_flush(struct fb_info *info);
> extern int fb_deferred_io_fsync(struct file *file, loff_t start,
> loff_t end, int datasync);
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
On 16.11.2022 11:49, Marek Vasut wrote:
> On 11/16/22 09:07, Marek Szyprowski wrote:
>> On 15.11.2022 13:00, Marek Vasut wrote:
>>> On 11/14/22 08:49, Jagan Teki wrote:
>>>> On Sun, Nov 13, 2022 at 5:51 AM Marek Vasut wrote:
>>>>>
>>>>
t; Daniel Vetter
> Cai Huoqing
> Neil Roberts
> Marek Szyprowski
> Emil Velikov
> Sam Ravnborg
> Boris Brezillon
> Dan Carpenter
>
> Signed-off-by: Robert Swindells
Acked-by: Marek Szyprowski
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
nt *num_input_fmts)
>>>> +{
>>>> + u32 *input_fmts;
>>>> +
>>>> + if (!samsung_dsim_pixel_output_fmt_supported(output_fmt))
>>>> + return NULL;
>>>> +
>>>> + *num_input_fmts = 1;
>>>
>>> Shouldn't this be 6 ?
>>>
>>>> + input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
>>>> + if (!input_fmts)
>>>> + return NULL;
>>>> +
>>>> + input_fmts[0] = output_fmt;
>>>
>>> Shouldn't this be a list of all 6 supported pixel formats ?
>>
>> Negotiation would settle to return one input_fmt from the list of
>> supporting output_fmts. so the num_input_fmts would be 1 rather than
>> the number of fmts in the supporting list. This is what I understood
>> from the atomic_get_input_bus_fmts API. let me know if I miss
>> something here.
>
> How does the negotiation work for this kind of pipeline:
>
> LCDIFv3<->DSIM<->HDMI bridge<->HDMI connector
>
> where all elements (LCDIFv3, DSIM, HDMI bridge) can support either
> RGB888 or packed YUV422 ?
>
> Who decides the format used by such pipeline ?
>
> Why should it be the DSIM bridge and not e.g. the HDMI bridge or the
> LCDIFv3 ?
If I got it right, the drivers reports their preference for the returned
formats. The format that is first in the reported array is the most
preferred one. This probably means that in your case the HDMI bridge
decides by reporting RGB or YUV first (if all elements supports both).
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
1 - 100 of 1022 matches
Mail list logo
