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-by: F
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
ls 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 insertio
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/arch/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
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/0x2ac
> [8.899540] __handle_irq_event_percpu+0xa4/0x2bc
> [8.899553]
024 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")
> Signed-off-by: Arnd
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 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
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 Regno
&
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
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/
drivers/gpu/drm/panfrost/panfrost_mmu.h| 1 +
> 8 files changed, 70 insertions(+), 20 deletions(-)
>
Best regards
--
Marek Szyprowski, PhD
Samsung R 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
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 Institute Poland
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 Institute Poland
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 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
ncies. 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 Ripard
> Signed-off-by:
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 wait
nsfer").
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 workaround is used a
nsfer").
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 suggested by Mar
nsfer").
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/
---
dr
nsfer").
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 use
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
&
;
> - } 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 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 cycles and use vario
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 automat
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:
>
arek 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 Institute Poland
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 Exyno
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
>>
->dynamic_dphy) {
>>>> + phy_mipi_dphy_get_default_config(clock_in_hz, bpp,
>>>> dsi->lanes, );
>>> This requires adding "select GENERIC_PHY_MIPI_DPHY" to DRM_SAMSUNG_DSIM,
>>> otherwise with CONFIG_DRM_SAMSUNG_DSIM=m:
>>
amsung_dsim_of_read_u32(node, "samsung,burst-clock-frequency",
> >burst_clk_rate);
> if (ret < 0)
> - return ret;
> + dsi->burst_clk_rate = 0;
>
> ret = samsung_dsim_of_read_u32(node, "samsung,esc-clock-frequency",
> >esc_clk_rate);
Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland
arious 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.
>>>>
>>> Thanks, that would
}
> }
>
> dev_info(dev, "failed to get the clock: %s\n",
> clk_names[i]);
> return PTR_ERR(dsi->clks[i]);
> }
> +
> + if (strcmp(clk_names[i], "sclk_mipi") == 0)
> + dsi->pll_clk_rate = clk_get_rate(dsi->clks[i]);
> }
>
> dsi->reg_base = devm_platform_ioremap_resource(pdev, 0);
Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland
;
> }
> @@ -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(, msg);
> if (ret < 0)
> return ret;
Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland
he 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 writes RGB data to /d
n: 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
index 53
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
_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:
>
thread+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've observ
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 the me
(connector, _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 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
(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 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 Szypro
h 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
> - fix bridge chain
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 flags
are reversed both i
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
TIALIZED
> 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
bcb8658f5b64d..172f271520c78 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -663,6 +663,7 @@ extern void fb_deferred_io_open(struct fb_info *info,
> struct inode *inode,
> struct file *file);
> extern
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 Institute Poland
signed int *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 Institute Poland
Hi Jagan,
On 15.11.2022 10:20, Jagan Teki wrote:
> On Tue, Nov 15, 2022 at 2:18 PM Frieder Schrempf
> wrote:
>> On 15.11.22 09:09, Marek Szyprowski wrote:
>>> On 14.11.2022 18:07, Jagan Teki wrote:
>>>> On Mon, Nov 14, 2022 at 8:10 PM Marek Szyprowski
>&
Hi Jagan,
On 14.11.2022 18:07, Jagan Teki wrote:
> On Mon, Nov 14, 2022 at 8:10 PM Marek Szyprowski
> wrote:
>> On 14.11.2022 11:57, Marek Szyprowski wrote:
>>> On 10.11.2022 19:38, Jagan Teki wrote:
>>>> Finding the right input bus format throughout
On 14.11.2022 11:57, Marek Szyprowski wrote:
> On 10.11.2022 19:38, Jagan Teki wrote:
>> Finding the right input bus format throughout the pipeline is hard
>> so add atomic_get_input_bus_fmts callback and initialize with the
>> proper input format from list of sup
idge_funcs
> samsung_dsim_bridge_funcs = {
> .atomic_duplicate_state =
> drm_atomic_helper_bridge_duplicate_state,
> .atomic_destroy_state =
> drm_atomic_helper_bridge_destroy_state,
> .atomic_reset = drm_atomic_helper_bridge_re
;
>>> Diffstat looks like this:
>>>
>>> drivers/gpu/drm/bridge/samsung-dsim.c | 1703
>>> ++
>>> drivers/gpu/drm/exynos/Kconfig | 1 +
>>> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 1766
>>> ++-
>>> include/drm/bridge/samsung-dsim.h | 113 ++
>>> 7 files changed, 1952 insertions(+), 1653 deletions(-)
>>>
>>> Looks to me like most of the code is just moved from existing driver in
>>> this patch.
>>
>> Yeah, as I explained (from commit) it is moved, updated, and written
>> the plat code. How about this head?
>>
>> "drm: bridge: Add Samsung DSIM bridge (Split from exynos_drm_dsi)"
>
> I disagree with the "Add" part of the Subject, but I'll wait for
> others' opinion here.
Maybe something like a "Generalize Exynos-DSI DRM driver into a generic
Samsung DSIM bridge"?
Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland
document fsl,imx8mm-mipi-dsim
>
> Patch 0010: add i.MX8MM DSIM support
>
> Tested in Engicam i.Core MX8M Mini SoM.
This finally doesn't break Exynos DSI. :) Feel free to add:
Acked-by: Marek Szyprowski
Tested-by: Marek Szyprowski
The next step would be to merge Dave's patchset an
= samsung_dsim_atomic_enable,
> .atomic_disable = samsung_dsim_atomic_disable,
> diff --git a/include/drm/bridge/samsung-dsim.h
> b/include/drm/bridge/samsung-dsim.h
> index 57b27d75369e..0c5a905f3de7 100644
> --- a/include/drm/bridge/samsung-dsim.h
>
e proper bridge chain
> * rework initialization issue
> * fix header includes in proper way
>
> v2:
> * fixed exynos dsi driver conversion (Marek Szyprowski)
> * updated commit message
> * updated MAINTAINERS file
>
> v1:
> * don't maintain component_ops in bridge driver
&
c_check
>drm: bridge: samsung-dsim: Add platform PLL_P (PMS_P) offset
>drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts
>drm: bridge: samsung-dsim: Add input_bus_flags
>dt-bindings: display: exynos: dsim: Add NXP i.MX8MM sup
Hi Jagan,
On 16.09.2022 12:21, Jagan Teki wrote:
> On Fri, Sep 16, 2022 at 1:58 PM Marek Szyprowski
> wrote:
>> On 14.09.2022 11:39, Jagan Teki wrote:
>>> On Wed, Sep 14, 2022 at 2:51 PM Marek Szyprowski
>>> wrote:
>>>> On 13.09.2022 19:29, Jagan Teki w
Hi Jagan,
On 14.09.2022 11:39, Jagan Teki wrote:
> On Wed, Sep 14, 2022 at 2:51 PM Marek Szyprowski
> wrote:
>> On 13.09.2022 19:29, Jagan Teki wrote:
>>> On Wed, Sep 7, 2022 at 3:34 PM Marek Szyprowski
>>> wrote:
>>>> On 06.09.2022 21:07, Jagan Teki w
Hi Jagan,
On 13.09.2022 19:29, Jagan Teki wrote:
> On Wed, Sep 7, 2022 at 3:34 PM Marek Szyprowski
> wrote:
>> On 06.09.2022 21:07, Jagan Teki wrote:
>>> On Mon, Sep 5, 2022 at 4:54 PM Marek Szyprowski
>>> wrote:
>>>> On 02.09.2022 12:47, Marek Szyprows
Hi Jagan,
On 06.09.2022 21:07, Jagan Teki wrote:
> On Mon, Sep 5, 2022 at 4:54 PM Marek Szyprowski
> wrote:
>> On 02.09.2022 12:47, Marek Szyprowski wrote:
>>> On 29.08.2022 20:40, Jagan Teki wrote:
>>>> Samsung MIPI DSIM controller is common DSI IP that can
Hi All,
On 02.09.2022 12:47, Marek Szyprowski wrote:
> On 29.08.2022 20:40, Jagan Teki wrote:
>> Samsung MIPI DSIM controller is common DSI IP that can be used in
>> various
>> SoCs like Exynos, i.MX8M Mini/Nano.
>>
>> In order to access this DSI control
k initialization issue
> * fix header includes in proper way
>
> v2:
> * fixed exynos dsi driver conversion (Marek Szyprowski)
> * updated commit message
> * updated MAINTAINERS file
>
> v1:
> * don't maintain component_ops in bridge driver
> * don't maintain platform glue
nit(dsi);
> - if (ret)
> - return ret;
> - dsi->state |= DSIM_STATE_INITIALIZED;
> - }
> + ret = samsung_dsim_init(dsi);
> + if (ret)
> + return ret;
>
> ret = mipi_dsi_create_packet(, msg);
> if (ret < 0)
Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland
exynos_dsi driver first (even if the kernel is booted on non-exynos board).
Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland
On 13.06.2022 13:34, Jagan Teki wrote:
> On Mon, Jun 13, 2022 at 5:02 PM Marek Szyprowski
> wrote:
>> On 13.06.2022 13:17, Jagan Teki wrote:
>>> On Wed, May 11, 2022 at 4:01 PM Andrzej Hajda
>>> wrote:
>>>> On 04.05.2022 13:40, Jagan Teki wrote:
PI then atomic_check is the proper helper.
>
>> 2. Where this requirement comes from? As Marek says it breaks Samsung
>> platforms and is against DSIM specification[1]:
> At least the bridge chain starting from LCDIF+DSIM requires active high sync.
Then please make this specific to the imx variant. The current version
breaks DSI operation on all Exynos based boards.
Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland
On 11.05.2022 17:02, Marek Szyprowski wrote:
> On 04.05.2022 13:40, Jagan Teki wrote:
>> Host transfer() in DSI master will invoke only when the DSI commands
>> are sent from DSI devices like DSI Panel or DSI bridges and this
>> host transfer wouldn't invoke for I2C-bas
Hi Dave,
On 11.05.2022 17:47, Dave Stevenson wrote:
> On Wed, 11 May 2022 at 15:58, Marek Szyprowski
> wrote:
>> On 05.04.2022 13:43, Dave Stevenson wrote:
>>> On Fri, 18 Mar 2022 at 12:25, Dave Stevenson
>>> wrote:
>>>> On Fri, 4 Mar 2022 at 15:18,
rm: dsi: Attach in_bridge in MIC driver")
Signed-off-by: Marek Szyprowski
---
A few words of comment. The mentioned commit has my Tested-by tag and
indeed I gave it. However that time due to remote work and incorrect
camera configuration in the office I was not able to check if the board
r
On 11.05.2022 17:47, Marek Vasut wrote:
> On 5/11/22 16:58, Marek Szyprowski wrote:
>> Hi Dave,
>>
>> On 05.04.2022 13:43, Dave Stevenson wrote:
>>> On Fri, 18 Mar 2022 at 12:25, Dave Stevenson
>>> wrote:
>>>> On Fri, 4 Mar 2022 at 15:18, Dave
1 - 100 of 1028 matches
Mail list logo
